The primitive block basically runs a function from the caller if it exists. You can explore many things here. I decided to use the primitive block to do this:
even though it doesn't show in the primitives list.
And it works! Do you know why?
It's because of Morphs, the thing that Snap! uses for everything. From the buttons, to the logo, and even the stage and sprites! Morphs have some special functions that some new Morphs inherit, and they can be run from the primitive block. So, here's an example of the width block!
Sigh. I've been waiting for somebody to figure this out. Now I need to disable it. Gosh, I hate this forum and all the overly eager wanna-be devs in here. Why can't you just make nice things? Why do y'all crave the admiration of the likes of you in that you can turn Snap into something else, why don't you make something original yourself? I don't understand it. Luckily I've already got the code lying around that is going to prevent you from these kinds of security loopholes. See, it's people like you with things like this why we can no longer have beautiful features like the JS function block inside projects for all. I hate this. I mean, honestly, we're trying to attract artists, athletes, musicians, and math-fobes to computing, but we're only successful with the usual crowd of narcissistic hackers on the spectrum. I hate my life.
Really, Maybe I'll take out the whole metaprogramming API again, this community is turning to s#*t, what began as a forum for Powerful Ideas has degraded into the Tik-Tok of code snippets. What am I doing here anyway?
I am not trying to do anything! I simply just want to find some things. And besides, with this, I don't think it's even possible to hack anything with a simple "width" block.
I also don't really think it's possible to find a variable of the Morph without having a function, like width(). But I assume this is for the best. I sincerely apologize.
We've been crunching through server logs for days and days to hunt down all the various attacks, and the evidence always pointed to exactly this: Some kid messing with js, often even some kid on this forum.
I'll make this impossible by tomorrow morning my time. Geez.
Adding powerful stuff like meteprogramming will naturally bring in users who will try to pick it apart, there's no way around it. I personally believe that no matter what is added to any programming language, there will always be users who do stuff with it that were unintended.
Honestly I feel this way as well. I wish we could go back to those simple times (and there is a new user here that has posted a couple projects that give me hope that'll come back at some point in some form).
really, we just want to have fun. there isnt anything we could do to exploit this, and snap is meant to have "no ceiling." why do you want to add one? its times like this, like the rejection of an unevaluated? checkbox, something that has no downside, and now deleting a unintended cool feature for no particular reason, that make me really confused as to what the point of this is. we are finding ways to use programming in ways we like, yet you just reject it. now, @bh is probably going to make a post replying to you too, so I dont want to say too much that he might also say. and now this isnt even working anymore. really sad. limitations without reason.
As stated in the first post, this exploit is being able to run any js function on a morph, which is, in fact, a security issue. You should not be able to do this without explicitly turning on javascript extensions. I'm with jens in removing this unintended behavior, due to it's possible security issues.
I mean, how would doing a function on a morph do anything bad? maybe make it so that only functions done on a morph will work? because I know the stretchy stage thing would be able to work in really creative ways :)
I'm not too sure what morph is running the functions, I just know that snap uses some system to be able to call functions from a function name in a string. If I played around with this a bit more, I could probably figure out how this all works, but I'm probably not gonna say anything, because it's going away in the next snap update, and if you don't understand what we're talking about, then you don't have to bother with it.
C'mon, Jens. Don't hate your life because kids find things to do with your work other than the thing you want them to do. That's the nature of kids! If you want to build a different kind of user community, we should take positive steps to promote it, like the Scratch cards with little technical tips and examples. And perhaps make some projects that do the kind of things you think newcomers can/should/would enjoy, instead of just really hard ones (which I also do, but I don't complain that the forum kids are ruining my life).
They don't want to turn Snap! into something else. The only one who wants to do that is Stefano, who wants to turn it into C++, and he isn't even a kid. :~) What the kids want to do is understand your work, and the way you understand a large software system is by poking at it.
Oh wait, no, there's also Paul's group at EDC. They do want Snap! to be something different, namely, a restricted language. And, somewhat to my surprise, you're fine with that!
I don't think our support of users should entirely revolve around hackers, but I do think that hackers are a valuable part of any community. It's not their fault if we're not attracting the users you want.
I mean, the whole reason you made BYOB and then Snap! was to support kids using advanced techniques. We thought that Scratch, because of deliberate design choices, wasn't good enough for teenagers. For kids to do things we didn't anticipate them doing is good. Even that phishing project might have been funny if it'd been intended that way, rather than intended to be evil.
Do I have to tell the story about Ken Thompson's hacked C compiler to hack login?
I'm reminded that Scratch got started at the Computer Clubhouse project. So, along with building Scratch itself, they were very consciously pouring a ton of effort into building the community. We haven't done anything like that. Instead, we're relying on schools to bring kids to us.
I agree with this. If kids find ways to change some of the properties of morphs, that's not a problem. Imho.
As for metaprogramming, I think that a side issue about how people are using it is that some of us disagree with a few of your design decisions (such as about the scope of script variables) and have found ways to use metaprogramming to get Snap! to do what we want, and that offends you. To which all I can say is that you need to develop a thicker skin. Everybody isn't going to agree with you about everything, every time. And that's okay.
The problem with this hack was - I've disabled it now, sigh - that the title already says it let you run almost arbitrary JS code but by abusing the "primitive" block via metaprogramming to specify any named function in the system, including attacking (e.g. deleting, modifying, corrupting) projects in the cloud. I tried to disable this before by only providing a catalog of safe-to-use functions in the primitive block's dropdown menu and by making the input slot read-only. The attack described here used metaprogramming to construct an instance of the "primitive" that had JS function names outside of the catalog in its "read-only" slot. Fiddling the layout and width of the stage was a rather harmless example, I guess because the user didn't yet grasp the full capabilities of their exploit.
It took me a few hours to address this issue, luckily I had already anticipated it last year, as I was designing the new "primitive" mechanism. I guess I should have built the guards in back then, but there was a lot of other things to fix and develop, and there's only so much time. So I didn't anticipate our community to actively seek ways to attack Snap itself. Alas, I should've known better.
I'm disappointed beyond telling that this community - not all of it, but a significant "vocal" part here in this forum - keeps revolving around exploiting such designs to modify and deface Snap's microworld and IDE for obviously pure vanity and boasting reasons.
I feel like them finding the "hack", and reporting it was a good thing, because no one can abuse it now that you've fixed it. Although I do feel like this should've been in a github issue instead, so the rest of the forum doesn't see this, and get confused on what is actually happening (and so you don't have to explain why it's a security concern).
I only wanted to share just a simple discovery, I didn't think that it would piss you off... I guess I'll share only what I have.