[worklets] restrict worklets to SecureContexts

[jeisinger]

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]

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

[nhiroki]

Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=779938

[css-meeting-bot]

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]

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