The editor's draft includes several features that no one has shipped.

[mikewest]

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.

[mikewest]

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).

#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.

[mikewest]

@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.

[annevk]

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.)

[mikewest]

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.

[yoavweiss]

@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.

[noamr]

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.

[domenic]

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.

[mikewest]

#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.

[noamr]

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 #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.

[dveditz]

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.

[annevk]

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.

[eligrey]

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.

[noamr]

See #582 for a prefetch-src alternative.