there should be a button in the top - right or left on the player that enables/disables js blocks (should alert like: Are you sure that you want to enable js?)
Yeah, I agree, you shouldn't have to switch to the editor to enable JSFunction.
Also, could you add a < is JavaScript on? > block?
Also, it would be nice for a block that asks the user for permission to use JSFunction.
So will all the library with javascript blocks inside (Made using making your block) will not work. This is sad but security problem is fixed. Then what can a person do in the project page to enable javascript in the online project pages is the solution made.
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.
Malware? I just heard about this. I am now working in almost 100% JavaScript, so I am very surprised what has happened here.
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]
I think there is still some difficulty even when the user is logged out, although the risk is lower. It's true that the project can no longer access session information so can't steal any data. However, it has control over the page's content and so can make a very realistic looking prompt asking for the user to log in (or, to use the existing login form but intercept the credentials entered). There may also be risks of browsers or password managers autofilling credentials if the JavaScript block were to create an input field - without any user interaction at all - but I'm not sure about this.
A possible fix, one which allows a lot of JS block use-cases without exposing the rest of the Snap! page, is to put the Snap! project player and editor into an iframe on a different subdomain to Snap!, thus relying on the browser's built in Same-Origin Policy. This is how other services that allow user-generated JavaScript to be run by others is implemented, e.g. https://jsfiddle.net/
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.