Open mikewest opened 1 year ago
The three that come to mind are navigate-to
(which we should clearly remove), webrtc
and prefetch-src
. I don't know of any implementation activity around the former. The latter is implemented in Chromium, and seems like it might be uncontrovercial (modulo concerns about how prefetch generally is specified).
https://github.com/w3c/webappsec-csp/pull/564 removes navigate-to
. We should either collectively decide to ship the latter two, or I'll put patches up to remove them as well.
@domenic (and @annevk, who also expressed concerns about this at TPAC): Is this the set of unshipped things you were pointing to, or are there others I missed?
Given your interest in prefetch-src
(and related bits like DNS/preconnect), would you prefer we drop it to work out your concerns around the spec, or keep/improve it (which I think @noamr and/or @yoavweiss were looking into)?
Same question for WebRTC. It would be ideal to understand what WebKit (@annevk?) and Mozilla (@ckerschb? @dveditz?) would like to do here.
WebRTC support was a very recent addition. I think we should give that a bit more time to gain traction.
(The concern I expressed at TPAC is that there are many open issues still, of which there's several that I know to be substantive.)
WebRTC support was a very recent addition. I think we should give that a bit more time to gain traction.
Ok, thanks.
(The concern I expressed at TPAC is that there are many open issues still, of which there's several that I know to be substantive.)
Yup. I heard that.
@noamr made some progress on specifying prefetch's processing model, and I can see how prefetch-src can be better defined as part of that. At the same time, I wouldn't expect a ton of progress on that front in the next few months, as he's on leave.
The current spec PR doesn't change the meaning of prefetch-src
, which is already defined in fetch. I think though that if it's not implemented, we should not implement it and instead do this - make it so that resource hints (prefetch/dns-prefetch/preconnect) fall back to the least restrictive matching directive in the policy, without introducing a new directive for them.
That list seems good to me!
Very excited to see the removal of navigate-to. The amount of mental energy I've spent trying to figure out how that integrates with various features I work on has been... high.
prefetch-src would probably benefit from some clarification as to what WebAppsSec would like it to apply to. In particular, there are many different technologies under the "pre-" name:
<link rel=dns-prefetch>
<link rel=preconnect>
<link rel=preload>
(a way of loading subresources into a per-document memory cache)<link rel=prefetch>
(not fully specced, but slated to become a way of priming the current HTTP cache partition with either a subresource or a navigational resource, potentially for future same-partition navigations)<link rel=prerender>
(not specced at all; Chrome-only; there it does some sort of partition-violating prefetch-with-subresources of a navigational resource)Our conservative approach so far has been to lump all of these under the control of prefetch-src
, I believe. But this is not principled. And it might be better to do something totally different, at least for the subresource cases, as @noamr points out. Or, we might want to split it up into multiple features, or give it a more generic name so that people realize it applies to more than just <link rel=prefetch>
...
But overall, to tell what the right path is, I think we need some background on what people want to use it for, and why it was introduced. If you have that handy, I'd love to read up.
https://github.com/w3c/webappsec-csp/issues/107 was the original discussion around prefetch-src
.
At a high level, folks expect CSP to give them control over requests that a given page initiates, with the goal of preventing unexpected/unwanted data exfiltration. That's not an unreasonable expectation, but not one that CSP meets today.
That list seems good to me!
Very excited to see the removal of navigate-to. The amount of mental energy I've spent trying to figure out how that integrates with various features I work on has been... high.
prefetch-src would probably benefit from some clarification as to what WebAppsSec would like it to apply to. In particular, there are many different technologies under the "pre-" name:
<link rel=dns-prefetch>
<link rel=preconnect>
<link rel=preload>
(a way of loading subresources into a per-document memory cache)<link rel=prefetch>
(not fully specced, but slated to become a way of priming the current HTTP cache partition with either a subresource or a navigational resource, potentially for future same-partition navigations)<link rel=prerender>
(not specced at all; Chrome-only; there it does some sort of partition-violating prefetch-with-subresources of a navigational resource)- Speculation rules prefetch/prerender (targeted at navigational document resources and their subresources, with partition-respecting semantics)
Our conservative approach so far has been to lump all of these under the control of
prefetch-src
, I believe. But this is not principled. And it might be better to do something totally different, at least for the subresource cases, as @noamr points out. Or, we might want to split it up into multiple features, or give it a more generic name so that people realize it applies to more than just<link rel=prefetch>
...But overall, to tell what the right path is, I think we need some background on what people want to use it for, and why it was introduced. If you have that handy, I'd love to read up.
I addressed the above cases in https://github.com/w3c/webappsec-csp/issues/542.
The idea is that for regular subresources we already have the type-specific CSPs, and for resource hints (prefetch, preconnecy, dns-prefeth) the thing we want to prevent is exfiltration, and the least-restrictive policy would suffice for that without introducing a custom prefetch-src
.
Speaking up to add a Mozilla voice, but I strongly agree with Anne that webrtc
should be dropped until there's more discussion around it. A binary on/off switch seems to fit better with Permission Policy or Document Policy, and I worry adding it to CSP opens the doors to adding all kinds of other feature switches to CSP.
We're also happy to see navigate-to
and prefetch-src
removed for now so that we can get a published working draft that aligns better with what multiple browsers have shipped or are actively working on shipping.
Note that I was opposed to dropping webrtc
. In part because it largely seemed like a volunteer effort that over a significant amount of time managed to get agreement between implementers and got them converged on a solution. It's worth looking at the various PRs involved to see how much effort went into it.
Can someone link to the security-related rationale behind navigate-to's removal? It appears that the Navigation API is capable of handling the use cases addressed with navigate-to
and doesn't have any associated security issues preventing its use for navigation egress control.
See https://github.com/w3c/webappsec-csp/pull/582 for a prefetch-src
alternative.
As @domenic noted in our meeting at TPAC, a few features exist in the editor's draft that aren't shipped anywhere, and don't have substantial agreement. We should remove them to avoid confusion.