Worklets: Security considerations?

[mikewest]

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!

[bfgeek]

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:

• use child-src for worklets
• allow worklets for non-secure contexts
• a worklet inherits its documents base uri, to urls etc are loaded relative to this.

[mikewest]

Happy to review, let me know when there's something concrete to sift through. :)

[annevk]

This seems overdue?

[annevk]

Worklets have moved to HTML recently and the way this is addressed is by spelling out the security properties in the various worklet-related algorithms. Any specific security or privacy considerations would have to be written for the various worklet types as they can change the properties quite a bit.