Optimization

Feature Requests Snap! Feature Requests
,
1

2 things we really need are the ability to order the blocks alphabetically, and the ability to "Uncompile" code to run projects more smoothly like scratch or turbowarp.

unlike scratch and turbowarp, projects on snap can pretty easily begin to lag when complicated code or a large amount of code is run at the same time and this is more than likely because of compilation. this is why i request we at least have the option to disable compilation like how we have the option to enable javascript. and about that, there definitely needs to be a way to enable javascript without looking inside the project.

2

That might come.

I don't think Snap! compiles its scripts.

That won't happen.

3

I don't think Snap*!* compiles its scripts.
it does. im sure of it

4

I know you could (the block doesn't show anymore when you do this) compile code by shift-clicking the Settings menu, then selecting "JIT compiler support", then you'd have a COMPILE block in Operators, but that was experimental.

BTW 
[quote="warped_wart_wars, post:2, topic:11219"]
I don't think Snap<i>!</i> compiles its scripts.
[/quote]
it does. im sure of it

it does. im sure of it

5

I'm pretty sure you don't know what compiling means. Compiling code makes the code know what functions to run, before it gets to the line of code. Uncompiled reads the code line by line, and it has to figure out which function to run. It's also easy to spot uncompiled code, when you can edit the code live (where you add code while it's running, and it'll run the new code without pressing the green flag). That is also one reason why snap runs slowly, because it always checks to see if the code changed while running.

also,

that has nothing to do with optimization.

6

Why not? I would like a warning similar to the Scratch one for the username block being used. It could say 'This project uses Javascript which allows the author to include malicious code. By default Javascript is disabled for your safety, but you can choose to enable it here'

7

I believe the current method was chosen to prevent people who just click on links in the project collections from running possible malicious scripts

A person casually browsing (especially a young person in a school) is quite likely to say yes to such a question and just carry on.

By making it a multi-step process, it helps in preventing this from happening.

8

That is very true. Just wish websites had the same thought when deciding on how to implement cookies (or moreso that they wouldn't sacrifice this for profit)

9

Your browser can protect you from websites if you enable it. Snap could use iframes to protect the account from the project, but this is better. Actually sandboxing javascript within the page would be difficult and would probably have exploits.

10

I do understand especially since most (I think) users of Snap! are children in the classroom, so the Snap! team can't assume they have any security measures beyond whatever is industry standard.

11

They designed it this way for security reasons.

12

Yeah.

Something very bad happened for this change to be taken. Unless they find another solution, you have to go inside the project.

13

Browsers always sandbox domains, so javascript in one domain cannot access cookies from another domain or a subdomain, although they can access cookies that they are a subdomain of. This means that snap.berkeley.edu can access cookies from berkeley.edu but not cloud.snap.berkeley.edu or google.com. All browsers do this. Snap could use an iframe, so that even if a malicious project affects the iframe, the options for accounts are outside it.
Optionally, your browser can remove cookies from certain websites, protecting you from tracking. Of course, there are other methods like fingerprinting, ip address, and cache.

14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.