[worklets] Fill in privacy and security sections of worklets. #379
Conversation
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?).
worklets/Overview.bs
Outdated
| useful functionality. | ||
|
|
||
| Worklets are allowed to be used outside <a>SecureContexts</a> as specifications which extend/use | ||
| worklets may be allowed to used outside <a>SecureContexts</a>. |
There was a problem hiding this comment.
I'm not sure that's really good rationale. Ideally all new features just require secure contexts and certainly any specifications which wish to use worklets could do the same.
There was a problem hiding this comment.
Right - I don't think we have consensus as user agents yet that this is the case for all new features, which is why I worded it this way.
I've changed it to
"Specifications which use worklets should decide if their worklet(s) should be allowed outside SecureContexts". instead?
worklets/Overview.bs
Outdated
| The behaviour of loading scripts can be restricted by using <a>child-src</a> [[CSP]] directive. Each | ||
| specification which extends this specification <em>must</em> provide a <a | ||
| for=request>destination</a> which is sent along with requests in the <a>Fetch a module worker script | ||
| graph</a> algorithm. |
There was a problem hiding this comment.
Actually, worklets should be guarded by the script directive. But also, I'm not sure that needs to be mentioned in this section.
There was a problem hiding this comment.
I've removed this section.
| useful functionality. | ||
|
|
||
| Specifications which use worklets should decide if their worklet(s) should be allowed outside | ||
| <a>SecureContexts</a>. |
There was a problem hiding this comment.
I'd much rather we just limit them to secure contexts. No real reason to have new globals without it I think.
There was a problem hiding this comment.
@bfgeek: Have y'all thought about this feedback? Seeing the intent to ship threads for various worklet types without this fundamental question being answered worries me a bit.
There was a problem hiding this comment.
I've bought this up on blink-dev. I linked to the HoudiniTF discussion there and there wasn't a clear conclusion.
https://lists.w3.org/Archives/Public/www-style/2017Mar/0023.html
I still err towards the side that it should be the decision of downstream specifications to decide this, but the concrete question that we need to answer at the moment is if the CSS Paint API should be available only on secure contexts or not.
There was a problem hiding this comment.
I don't see why this should be decided downstream. It's a complex new feature and it can be trivially restricted. There's no good reason to expose it insecurely.
(As for the concerns around paint worklet. If there's no media query for secure contexts, just add one.)
There was a problem hiding this comment.
I think there are good reasons to expose it insecurely. But since the argument is not about CSS Paint specific concerns, but rather all new features, I commented on the relevant TAG issue. w3ctag/design-principles#75 (comment)
|
No, I don't think we should. These days I think security and privacy should be directly addressed in the relevant algorithms. |
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?).