Open Richienb opened 4 years ago
The problem is that Scratch Team actually doesn't like restriction by age. Currently, third party extensions are sandboxed - but the sandbox is too strict for general use; on a Worker without runtime access, the most complex thing it could make is probably case-sensitive operator.
The sandbox itself is good because untrusted extensions can barely damage the stuff (aside from potential abuse of fetch()
). However, to make it work more efficiently the Scratch Team should actually add a way to load unsandboxed extensions that are trusted - or maybe add a community submissions for extensions.
Extensions aren't sometimes enough. To add more complex mechanics, we need to modify code in other places, which extensions cannot.
After taking a look at the Extension Development subform on the Scratch forums, most of the extensions work fine with the Worker restrictions. It's just a question of adding support to run said extensions.
Why not just whitelist extensions which could be submitted in a forum topic or something? Then they could be loaded with a url or even just be placed in the extension libary.
The Scratch 3 editor should provide some way to use custom third-party extensions.
It has come to my concern that security and child-friendliness are major standpoints that block this from moving forwards whatsoever. To fix this, we could use a library system like ScratchX but with more lenient regulations as to not discourage extension development. For users who have enabled a (possible age-restricted) option in their profile settings, they would be able to load extensions from URLs to help speed up development.
To prevent malicious use of Web API, a permission system could be enforced where the
getInfo()
function must return any additional permissions (for example to make web requests) required by the extension which is then shown to the user and is restricted to accordingly.