Continuing the discussion from Dialog boxes don't display body text on project page
What would that include and exclude?
I did mention that Jens was thinking about allowing JSF in Snap! instances you host yourself (so no cloud access).
https://snap.berkeley.edu/snap/snap.html
https://snap.berkeley.edu/project
https://snap.berkeley.edu/embed
Oh I see, you're saying to blacklist snap.b.e rather than whitelist localhost. Maybe...
As for cloud security, the "URL" block with "Web services access" library is almost as dangerous as JS.
"Referer" is based on server hostname. Pretending Snap! is running from the whitelisted domain is a piece of cake with the use of local "hosts" file or custom made proxy.
Scratch solved this problem with ScratchX.org domain for experiments.
To allow JS for the official libraries some form of code-signing can be used.
From the Dialog boxes don't display body text on project page - #19 by bh
It's exactly the problem, and why I consider JSFunction as a "freedom".
Also "should" is an important concern here.
Yes.
Let me make clear that I know less than nothing about security. I always used to tell our intro CS students that there are two things they should never try to program themselves, but should hire an expert instead: security and floating point computation.
So I don't expect to have much to contribute to the technical aspects of securing the Snap! environment.
I grew up in the Arpanet days, when everyone on the net knew everyone else on the net, and sites all had guest accounts without passwords so that people from elsewhere could use the software they developed. At MIT-AI, you couldn't have a password even if you wanted one; the feature just didn't exist. (Years later, ARPA made them implement passwords, at which point RMS chose the empty string as his password.) I hate security. I wish we didn't have passwords on Snap!.
But this isn't that world any more. Of all the billion people on the net, 49% of them are selling porn, 49% want to give you a million dollars from the Nigerian oil ministry, and the rest of us, in the remaining 2%, want to do good stuff but need bodyguards to protect us against the 98%.
(And yeah, don't get me wrong, I understand that the cost of the safe feeling of the Arpanet was that only CS professors and the military had access, and not even most of the CS professors. I support the democratization of the Internet, although nowadays it's democratic as long as you're Facebook or Google. But I miss the safety, too.)
Even on ScratchX, you have to be blessed by the ST to develop extensions.
If someone develops a great solution that lets us keep our users secure, but still lets everyone experiment with modding Snap! in JS, great!
(But our users are much too eager to mod Snap! before they've actually learned it.
Imho. And also, much too convinced that more blocks makes it better.)
(Actually, we don't think that's true about our users in general, just the ones that hang out on the forum. It's as if our entire forum is the equivalent of the AT category on the Scratch forum. One of our goals is to get more people onto the forum.)
There is only a security threat when logged in to Snap!. Otherwise it as secure as any other website. E.g. github will host it on github.io automatically.
When faced with a similar problem many years ago I chose to provide support for users with Google Drive or DropBox accounts to use their personal accounts to save (and to optionally share in a read-only mode) all projects. True that someone could still load a malicious Snap! project that used JavaScript to mess with someone's Google Drive - though it isn't hard to limit the damage to single folder devoted to saving Snap! projects.
Relying upon the users' cloud storage (or the school's?) also means there is no issue about illegal content in projects (e.g. breaking copyright or hate laws).
I hope that JS functions remain in Snap! and suggest that they not be allowed when logged in.
Also @bh considers it a failure if Snap! (i.e. lambda) can't provide the expressivity needed. But there is I/O, access to the GPU, etc. that one needs JS in order to experiment with.
Yes, we've talked about that as a possible solution. But I don't think users will thank us for turning a threat against their Snap! account into a threat against their Drive or Dropbox!
That's not quite what I meant to say. What I meant, and thought I said, is that it's lambda, not JSF, that makes Snap! an interesting and expressive environment. By definition, JSF doesn't make Snap! any more expressive than JS. I do understand that there are issues about physical I/O, but instead of just throwing up our hands about that and telling users to write it in JS, we should have a USB library (I just recently saw one that someone wrote...) so users can do the I/O stuff in Snap!.
PS And yes, I get that that's dangerous too, if you have an external hard drive. :~(
how are those 2 related?
This is giving me Panther vibes and I don't like it.
JSFunction can be a threat for Snap! cloud because the user-supplied JS pretends to be from a trusted source. But this trust relationship is only valid for services hosted by Snap servers (cloud API). For any other services (Dropbox, hard drive), it's meaningless. Snap! has no special privileges as compared to any casual web page.
So, when the user asks to save to the third party site, do they have to provide a password each time? Or does the site make a session cookie or something, in which case I think it'd be the same threat, no?
Is there some piece of Panther history I'm missing? Did it have security issues too?
The files block category.
Just..
No
Might as well name it ViraBlock.
Oh yeah I forgot about that. At least it pops up a warning box.
I wonder how many people clicked ok on the warning box, and buried in the project was
+---..........---------------------------------------------+
| clear ( C:\Windows\System32 )...................|
+---..........---------------------------------------------+
It's a pretty intense warning. But anyway, yes, we have roughly the same issue.
what does that do?
A partial solution and we'll have to wait for it to move from experimental status. And I'd like to hear from those working with robots if this would cover all their needs. What about Bluetooth?
But USB is only part of the I/O universe that browsers offer that Snap! is missing. E.g. text-to-speech and speech-to-text.