I'm also curious about this, and didn't see an explicit answer. If a user interacts with Snap not by logging in, but always exporting projects to local xml files and re-uploading, is the risk eliminated?
Seems like a reasonable and sensible approach. Thanks for taking the time to do this.
One reason not to do that is that the user should actually read the JS in the project before enabling it!
The project we found started by displaying a dialog box saying that you have to enable Adobe Flash to use Snap! (not true!) with a button to click. If you haven't run a project like that, then no.
fishing your passwords and open local files via flash
THATS NOT SPAM!!!ITS A SECURITY PROBLEM!!!
Could you make it so that it saves if you enable JSF for a project so you don't have to go to editor every time you open a project that uses JS.
[offtopic]Is the version after 6.9 7.0?[/offtopic]
But when I try to run JS in my projects it says JS blocks are disabled.
Ok so from what I understand JS is coming back but before a user can run it they have to enable it and it alerts them that it is a security risk? Seems pretty good I just want JS back cause 50% of my projects do not work now.
Edit: Is it already out? If so how do I enable it because when I try to run projects with JS editor or normal it says 'JS functions are turned off'
Same thing happens when in editor. (for all JS projects)
But that is for extensions what about our projects that have our own JS or others?
Edit: Like for my intros I use a custom block on some of them that is ran by JS but is not an extension. Is this what jens was talking about in enabling JS that we can use our own JS but users have to enable it and it alerts them a security notice? Is this a go or is it already out or is it coming in 7.0 or rumored 6.10?
You can do phishing without JS, and you can't infect anything without the user downloading and running an executable., The only big problem here is session hijacking, which can be done with the HTTPS library (is that whitelisted or not?) and the URL block. You could solve this with
I'm not a security expert, but the guy's github account included JS code to load a URL whose name suggests it's intended to get root access in MacOS. I don't know if that was part of the Snap! project or not. (I sent off an email to Github about it.) I don't know exactly what Jens is thinking, but finding that little snippet of code is what made me extra worried.
Again, if you didn't run this project, you have nothing to worry about, as far as damage to your system from Snap!.
There might be a way as there are custom blocks created that can use usernames which could be re created to be used for passwords if someone changes the JS a little.
This is why the creation of a fake snap.berkeley.edu site is worrisome.
That's not possible unless the admin explicitly gave root access through something like sudo or another suid executable, or the user runs as root. Both are unlikely considering the restrictions schools put on computers. If it was a oversight, it's a security vulnerability in the operating system itself. And what school system buys Macs when there are better things to spend their money on?
Look, just try it! Load a project with JSF blocks and see what happens.
How did they convince the users to download and run it if it was part of the project?