Yes, though since I'm always logged into Google it only asked for permission the first time. It isn't a perfect solution and someone could make a project that would delete the contents of the cloud folder they designated for saving Snap! projects. But the cloud services I know of have a way to undelete if noticed within 30 days.
A safer solution but not as featureful is to save a project to a file that is automatically backed up to Google Drive, DropBox, Microsoft, etc. Or to a file that is on a network drive (I think many schools only provide network drives on student PCs). Then they can load their projects from any computer that has access to the cloud drives.
To share or publish Snap! projects one could do that on the Snap! site without using Snap!. Just a drag and drop of a local project file would be required.
How bad would it be if Snap! checked before running any user JavaScript whether the user is logged in. A dialog would appear saying "For security reasons Snap! can't run block X while you are logged in. Logout if you really want to run it."? Maybe that's a better price to pay for security than turning off user JavaScript.
Harvey, Brian, and Jens Mönig. "Bringing “no ceiling” to scratch: Can one language serve kids and computer scientists." Proc. Constructionism (2010): 1-10
argue that Snap! is also for computer scientists? And computer scientists can rely upon JSF to explore new directions for block-based languages. JSF is a much better solution than forking the source code and hosting a variant when the changes are largely additive.
Yes, that's one of the solutions we're considering. But we still would want it to be possible to use libraries while logged in, so we'd still probably put library JS code into the Snap! kernel.
Sorry I probably should have combined all these into one message...
Anyway, yes, that's true.
We're not going to take any hasty action. This discussion is helpful. But we do have to reach some resolution to the security issues in the fairly near future.
Well, it's not directly about security, but it is relevant to the discussions we're having.
Actually I'm sort of in the middle of this issue; just about two hours ago I got yelled at by Jens for trying to write a piece of JS to do something that could be done in a different way in Snap!, namely, use the dimension input to SET PEN (dimension) TO ... to dispatch automatically to a helper procedure that does the work of that kind of setting. After a ton of debugging, which turned out to be mostly because I don't really speak JS rather than because I don't really understand how Snap! works (although that's true too), I wrote this:
So the reason I'm telling you all this is that I, too, want to know how Snap! works on the inside, but I'm 70+ years old, and I've read (and taught) SICP, so I know a thing or two about computer science, and I'm not preventing myself from learning computer science by poking around inside Snap!.
(Plus, I'm allegedly a Snap! developer, even though my contributions have mainly been in libraries and documentation, so I feel like I really should know my way around the code. But that's not really pertinent to this conversation.)
Edit: Jens yelling at me was before I finally got it debugged.
Interesting story. Note that your JS solution works even if a user adds a set pen to block which may or may not be intended. And that if Snap! itself added new set pen to blocks the Snap! version would need to be edited while the JS version would include the new ones.
Perhaps Snap! should have a block that searches for blocks...
As Jens says, you and I, in slightly different ways, are starting down the road of metaprogramming, leading to macros, which are the last remaining major Scheme feature we lack.
OTOH he points out that if I dispatch in JS rather than use an explicit dispatch list, it's no longer possible to do Unused blocks or to figure out the transitive closure when the user asks to export only a subset of the blocks in a project.
Everything is complicated. This all feels like doing my income tax.
P.S. Snap! does have a search-for-blocks feature, namely the control/command-F thing that gives you a palette of blocks with the characters you type in their names. That's where I stole the code that I modified to end up with the above.
Oh. Yes. We know we need that as a debugging aid. But it's not the problem I was trying to solve in that other thread (as you know!), where the situation is that I know a block exists and I want to use it, but all I have is its name, not the reified block itself.
I must say that to me the JS block is very peculiar of Snap and I would be really sad if this won't be there anymore before replacing it with a safe strategy.