Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
There's no "security considerations" section in the document, but I hope you'll consider writing one.
Creating a new execution context in which JS executes is certainly interesting from a security standpoint. I'd like to see explicit discussion of the origin in which that code executes, and the privileges it ought to have. It would also be helpful to have a list of considerations that other authors should consider when determining whether a particular feature ought to be enabled for Worklets' "reduced API surface".
Likewise, how is the Worklet's script fetched? What Content Security Policy directive ought to apply? Should Worklets be available to non-secure contexts? Etc.
Thanks Mike, yup I'll definitely put it together in the coming weeks.
Do you mind reviewing anything we come up with here?
A lot of this will depend on the children specifications and what they require/expose API wise. For Houdini worklets specifically my initial thoughts are to:
Fixes #92. (better late than never? ;) Broadly speaking worklets should be allowed in non-secure contexts as downstream specs may want to use them there. CSP wise this should work the same as workers, using the "child-src" directive. I've filed issue #378 to allow each downstream spec to use a unique destination, e.g. "paintworklet", "audioworklet", etc. The CSP spec should probably be extended to have a "worklet-src" directive (as there is now a "worker-src" directive now?).