Worklets: Security considerations? #92

Open
mikewest opened this Issue Dec 10, 2015 · 3 comments

Comments

Projects
None yet
4 participants
@mikewest
Member

mikewest commented Dec 10, 2015

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 bfgeek added the worklets-1 label Dec 11, 2015

@bfgeek

This comment has been minimized.

Show comment
Hide comment
@bfgeek

bfgeek Dec 11, 2015

Contributor

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.
Contributor

bfgeek commented Dec 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mikewest

mikewest Dec 11, 2015

Member

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

Member

mikewest commented Dec 11, 2015

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

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Apr 5, 2017

Member

This seems overdue?

Member

annevk commented Apr 5, 2017

This seems overdue?

bfgeek added a commit that referenced this issue Apr 7, 2017

[worklets] Fill in privacy and security sections of worklets.
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?).

@tabatkins tabatkins added the ready label Apr 7, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment