Scratch-gui: Define Experimental Extension Policy

[kyleplo]

With the adding of many new extensions, I think it would be a good idea to reconsider the experimental extension policy. I am proposing 3 options:

1.

Maybe you could display a warning when viewing projects with experimental extensions.

2.

Add a way to submit extensions to make them official

3.

Allow users to enable experimental extensions in account settings.

[thisandagain]

Thanks for raising this @kyleplo! We will absolutely be rethinking how this works for Scratch 3.0.

[davidaylaian]

How about in settings you can choose to enable extensions (similar to option 3), but you can decide which ones you want individually?

[Kenny2github]

Perhaps also make extensions more readily accessible (like maybe an “explore” tab for extensions)?

[kyleplo]

@davidaylaian I like that idea, except that there are so many experimental extensions that it would be hard to choose. But I guess, it could work like Chrome's permissions:

1. A project requests to use an experimental extension
2. If the user has never used that extension before, it will be blocked, but a warning will appear like this:
   
3. If the user has blocked the extension, no warning will appear and the extension will not run. They can re-enable it in their account settings.
4. If they select "Run once", the extension will run that time, and the warning will display again the next time
5. If they select "Run always", the extension will always run, unless they disable it with account settings

[kyleplo]

@Kenny2github I like that idea too!

[davidaylaian]

@kyleplo couldn't a malicious Scratch project trick people into installing a malicious extension, similar to how websites do with Chrome extensions? (Example) (Another Example)

These kinds of attacks are very common, and if adults fall for them, I can imagine kids programming on Scratch would accidentally install malware on their parents' computers. At the very least, I think that the run extension dialogue should only come up while the project isn't running.

[TheBrokenRail]

You could sandbox the extensions so they can only access certain things like util and args and not document and xmlhttprequest

[CosmicWebServices]

How about a review process for extensions and if the extension is not reviewed then it has that box to avoid people having to learn how to have a fallback when using extensions because people are to cautious to add an extension but still keep people safe.

[kyleplo]

In my opinion, the ideal solution would be:

• Developers could submit their extensions to be reviewed
• Once they were reviewed, they would be allowed to be imported with their URL
• There would also be a page that lets you find them, like an explore page
• If someone who has already been known to submit safe extensions submits a new extension, review will not be required, but a warning will appear until it is reviewed (see this)
• Developers could test their non-reviewed extensions on scratchx.org

[CatsAreFluffy]

How will running a block from a blocked extension work? Will it simply do nothing?

[kyleplo]

@CatsAreFluffy I think doing nothing might be the best option. Maybe giving users the choice of letting creators run their project without extensions would help, especially if the project required extensions. Then, users would be warned that the project needed extensions, but they weren't enabled.

[hedgehog125]

Maybe users could confirm that the extensions are safe and also flag them for the Scratch Team to review?

[hedgehog125]

I agree with @TheBrokenRail but don't forget: eval, webworkers, popups and alert, prompt ect.

[hedgehog125]

What if a project using an extension got onto the front page (excluding recently shared)? Maybe the extension would have to be reviewed first?
Edit:
Maybe the extensions could have a "popularity" score, it could gain points in these ways:

• When a user who hasn't visited the project that uses the extension visits it: +1 popularity
• When a user who hasn't used the extension before in a project uses it: +10 popularity (a user that hasn't used it to reduce the risk of users getting their extensions popular by using another account)
• When a project that uses it is front paged: Full popularity

When it reaches max popularity (Not sure how many points it would need) it goes onto a list for the Scratch Team to review, if there are front paged project(s) using it they won't be shown until the extension has been reviewed and confirmed safe)

[TheBrokenRail]

My idea is to sandbox the extension so the extension can't use prompt, eval, alert, XMLHttpRequest, WebSocket, document, location and pretty much everything in window. This could be done with a web worker.

[Mrcomputer1]

@TheBrokenRail But XMLHttpRequest and WebSocket are useful to some extensions (like sending a request to a server on the user's computer to control a robot or doing cool things with external APIs like seeing if a Minecraft server is online (like one of my ScratchX extensions)).

[hedgehog125]

@Mrcomputer1 Hmm... maybe you could use XMLHttpRequest and WebSocket as long as they weren't accessing the scratch website? But maybe GET requests are allowed?

[hedgehog125]

Maybe projects should have a way of detecting if the extension was allowed? So it can display a message if the project needs it?

[hedgehog125]

Maybe it could also display a similar message to when the 'username' block is used. Just make sure that when they log out all the cookies are cleared. Although prompt, eval, alert, document and webworkers would still have to be blocked.

[hedgehog125]

Maybe it could be given a score of how dangerous it is? Based on how many of these features it uses and there could be a button to report it?

[hedgehog125]

Hmmm... the problem with blocking these things is then it reduces the possibilities. If you were allowed iframes you could make a mini web browser or something.

[hedgehog125]

Maybe there could be a way of putting elements on top of the canvas though? Then maybe a custom controller could be returned? (So that you can't move it off the canvas and to make it harder to trick the user into thinking it was created by the Scratch Team)

[kyleplo]

@hedgehog125 I think extensions should have a permissions array (like Chrome extensions) that provides a list of all the objects the extension needs to access. Users will get a warning based on the specific permissions:

• alert, confirm, prompt: "Show popup dialogs"
• document: "Modify the scratch project page"
• XMLHttpRequest and fetch: "Access data on other sites"
• window: "Do most things that websites can do"
• location and history: "Read and change the website you're on"
• navigator: "Access external features such as camera and USB devices"
  These would show in dialogs like this, but listing the permissions.

[hedgehog125]

@kyleplo hmmm, it's still not ideal though. Especially for younger kids.

[TheBrokenRail]

Allowing window would basically allow the extension to do anything like window.document and although using document would allow customization, you would easily be able to use it to change all links to a ad website for example and accessing history and location would server no purpose other than a redirect which could redirect to a fake website but otherwise great idea!

[thisandagain]

I'm going to lock this topic for now until we have time to discuss and develop a proposal. Thanks for all the input.