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] restrict worklets to SecureContexts #505

Closed
jeisinger opened this issue Nov 3, 2017 · 4 comments
Closed

[worklets] restrict worklets to SecureContexts #505

jeisinger opened this issue Nov 3, 2017 · 4 comments

Comments

@jeisinger
Copy link
Member

Blink decided to restrict CSS Paint to secure contexts for now, amongst other reasons because of the worklets.

E.g. the Web Audio WG also looked at this, and decided to just do whatever worklets does.

Opening this issue to track whether the worklet spec should be restricted to secure contexts, or whether the individual APIs should have this restriction.

/cc @annevk @mikewest

@hoch
Copy link

hoch commented Nov 3, 2017

AudioWG issue: WebAudio/web-audio-api#1436

@nhiroki
Copy link
Contributor

nhiroki commented Nov 6, 2017

@css-meeting-bot
Copy link
Member

The Working Group just discussed Restrict worklets to secure contexts.

The full IRC log of that discussion <TabAtkins> Topic: Restrict worklets to secure contexts
<TabAtkins> Github: https://github.com//issues/505
<TabAtkins> iank_: this is an fyi of what we're currently doing
<TabAtkins> iank_: INternally we've decided to limit Paint API to secure contexts only
<TabAtkins> dimitri: Primarily because we want everybody in the future to use https by default
<TabAtkins> dimitri: and this is a carrot/stick to encourage that
<TabAtkins> dimitri: debated this for a long time,a nd most of us are still pretty ambivalent about it, not sure about right decision, but
<TabAtkins> dimitri: putting the https tax on devs, vs the benefit of steering devs toward https, is a hard balance and we're just using our intuition at this point
<TabAtkins> dimitri: Strong support from Anne on doing securecontext-only for *all* new features - wasm, modules, etc
<TabAtkins> dimitri: There's also hesitation because that does put a tax on devs.
<TabAtkins> dimitri: If a framework wants to use a new feature, I'll hesitate, knowing that some customers might not be able to use it.
<TabAtkins> dimitri: That might impede adoption, or create situations that don't work according to dev expectation.
<TabAtkins> dimitri: So we ultimately decided to limit Paint to just securecontext, but then the question immediately arises about what to do for other worklets?
<TabAtkins> dimitri: So that's where we are now. Would love your thoughts
<TabAtkins> iank_: Question for Moz - are y'all serious about all new features in securecontext?
<TabAtkins> dbaron: As of today, it's probably in-between, but I'd expect it to get firmer in the next few months.
<TabAtkins> TabAtkins: And to be clear - that applies to, say, adding a new value to a property?
<TabAtkins> dbaron: That's a little more in the air.
<TabAtkins> dbaron: Question of what constitutes a new feature.
<TabAtkins> iank_: So llike paint API does add paint() value - we'd have to plumb that.
<Rossen> q?
<TabAtkins> TabAtkins: Alternately, you can just allow paint(), but in http you can't reigster any contexts for it
<TabAtkins> fremy: But then you can't te3st for that in pure css
<TabAtkins> dbaron: I think strongly that it should be plumbed into the parser to at least th elevel of properties, so you can use supports()
<TabAtkins> dbaron: For values..
<TabAtkins> iank_: That's the question here
<TabAtkins> dbaron: I don't think it would be too much harder. Unsure about Servo parser.
<TabAtkins> smfr: Webkit doesn' thave same opinion
<TabAtkins> smfr: Happy to limit features when we think they have privacy/security implications
<TabAtkins> smfr: But don't think it should be fractured by limiting a more arbitrary set of things to new contexts.
<TabAtkins> smfr: Worklets are tricky - it's an underlying feature that many things could depend on.
<TabAtkins> iank_: So we're planning to ship like this, but we're happy to keep discussion open for the moment.
<TabAtkins> dimitri: And I said *if* we agree to do this in an organized way, that would result in a spec change.
<TabAtkins> dimitri: We'll do something unilateral today, but later, specs will specify it explicitly.
<TabAtkins> astearns: So to be comfortable with a spec change, you'd want a demonstrated privacy/securtiy concern with the API
<TabAtkins> smfr: Yes. (but we don't think that exists, as it's the same as canvas)
<TabAtkins> dbaron: I could get into this argument, but I don't think we want to right now.
<TabAtkins> Rossen: So this is an fyi right now - you're implementing it this way, no spec change yet. Just seeing how th eepxeriment goes.
<TabAtkins> dimitri: And we are looking for signals - that feedback from Apple is great. Would love MS signaling.
<TabAtkins> dimitri: The decision is very not clear for us, scales very balanced right now.
<TabAtkins> Rossen: I think we're closer to Apple's decision right now.
<TabAtkins> Rossen: We're not even ready to release worklets yet, tho, so it's not as interesting yet.
<dbaron> s/features in securecontext?/features in securecontext? Is that just one person or is it a Mozilla position?/
<TabAtkins> dimitri: Formulated differently: if I brought this as a proposal today, you wouldn't back it?
<TabAtkins> Rossen: Yes, I'd push strongy for it to be a SHOULD, not a MUST.
<TabAtkins> smfr: SHOULD feels a little strong for me, even.
<TabAtkins> iank_: Good feedback.
<TabAtkins> plinss: Discusse din t he TAG - not strong opinion yet, but general feedback is that all new detectable features should be secure, and if it's not secure, you better have a good reason why.

domenic added a commit to whatwg/html that referenced this issue Oct 16, 2020
Closes w3c/css-houdini-drafts#1000.

This provides a baseline by porting over all the existing text from
https://drafts.css-houdini.org/worklets/, modernizing and restructuring
it along the way. It does not yet fix many of the open logged issues
(although it does fix some; see below).

Notable changes from that document:

* Rearranged sections to better match workers, and my sense of flow.

* Moved worklet script fetching to be siblings with all the other script
  fetching algorithms.

* Improved clarity and guidance on what specifications that define
  worklets should do, including fleshing out the fake worklet example.

* Changed "create a WorkletGlobalScope", which took one set of
  arguments, to "create a worklet global scope", which just takes a
  Worklet instance. This appears to match better how the algorithm is
  used, e.g. in
  https://drafts.css-houdini.org/css-paint-api/#draw-a-paint-image step
  10.

* Updated "report an error" to bail out for non-EventTarget globals,
  like WorkletGlobalScope. Closes #2611.

* Updated worklets to only be exposed in secure contexts. Closes
  w3c/css-houdini-drafts#505.

* Makes the lifetime of creating and terminating WorkletGlobalScopes
  more explicit. Closes
  w3c/css-houdini-drafts#224. Closes
  w3c/css-houdini-drafts#389.

* Explicitly start and stop the event loop for a given
  WorkletGlobalScope upon creation/termination. Closes
  w3c/css-houdini-drafts#843.
  Closes w3c/css-houdini-drafts#318 for real.

* Fixes creation of new worklet global scopes to only run the top-level
  module scripts added via addModule(), which will automatically run
  their dependencies. Previously it would run all module scripts loaded
  into the worklet, so dependencies would be run in the order they were
  fetched, not as part of the top-down module evaluation process. Closes
  w3c/css-houdini-drafts#264.
@domenic
Copy link
Contributor

domenic commented Oct 16, 2020

With whatwg/html#6056, we can close this. The HTML Standard reflects implementation reality wherein worklets are restricted to secure contexts.

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

No branches or pull requests

6 participants