Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Worklets: Security considerations? #92

Open
mikewest opened this issue Dec 10, 2015 · 3 comments · May be fixed by #379
Open

Worklets: Security considerations? #92

mikewest opened this issue Dec 10, 2015 · 3 comments · May be fixed by #379
Assignees
Labels

Comments

@mikewest
Copy link
Member

@mikewest 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
Copy link
Contributor

@bfgeek 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
Copy link
Member Author

@mikewest mikewest commented Dec 11, 2015

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

@annevk
Copy link
Member

@annevk annevk commented Apr 5, 2017

This seems overdue?

bfgeek added a commit that referenced this issue Apr 7, 2017
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
@tabatkins tabatkins removed the ready label Jun 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

5 participants
@mikewest @tabatkins @bfgeek @annevk and others
You can’t perform that action at this time.