Hey folks, we're likely going to be starting up an Origin Trial in Chrome in the somewhat near future based on a partial implementation we're working through. It would be helpful to get your feedback on some of the fundamentals sooner rather than later so we can incorporate it along with whatever we hear from developers that poke at it. :)

Hey Mike!

A few comments:

1. This is great!! Thanks for working on this!
2. I'm assuming the feature is supposed to work in workers, and its HTML integration suffers from https://github.com/whatwg/html/issues/11316, so it's not necessarily well-defined.
3. For dns-prefetch leaks, it seems like this should also integrate with https://html.spec.whatwg.org/#link-type-dns-prefetch. Similarly, there's https://html.spec.whatwg.org/#link-type-preconnect

1. This is great!! Thanks for working on this!

🥳

2. I'm assuming the feature is supposed to work in workers, and its HTML integration suffers from WorkerGlobalScope policies not fully converted to policy containers whatwg/html#11316, so it's not necessarily well-defined.

The assumption is that we'll do the same thing for workers that CSP does; each worker will have its own policy, and local-scheme workers will inherit from their creation context. So, yes. It depends on Policy Container working, and if it isn't wired up, we should add some wires.

3. For dns-prefetch leaks, it seems like this should also integrate with https://html.spec.whatwg.org/#link-type-dns-prefetch. Similarly, there's https://html.spec.whatwg.org/#link-type-preconnect

Both of those end up routing through Fetch (Step 4 of https://html.spec.whatwg.org/multipage/links.html#link-type-dns-prefetch and step 8 of https://html.spec.whatwg.org/multipage/links.html#preconnect), so I think the integration is already well-defined. There are absolutely bits of the platform that aren't defined through Fetch (WebRTC as a standout example), and we'll certainly need to update the spec and implementation as we run into them. I haven't done that work yet, mostly hoping that folks can provide feedback on the mechanism in itself, assuming that we do reasonable integrations along the way.

Both of those end up routing through Fetch (Step 4 of https://html.spec.whatwg.org/multipage/links.html#link-type-dns-prefetch and step 8 of https://html.spec.whatwg.org/multipage/links.html#preconnect), so I think the integration is already well-defined.

Missed this!! Great to see it defined

Hi @mikewest,

The goal looks good, and the proposal is generally sensible, but we have several concerns:

• There is no position from other stakeholder. We encourage you discuss it with them to clarify their position.
• The explainer or the spec could contain more examples to show more explicitly the interactions.
• Regarding reporting, could it be possible to explain the context of the connection? The explainer, point 3 in justification for this spec, mentions CSP does not cover DNS prefetch, WebRTC (most probably WebTransport and WebSocket as well) in the threat model. Would it be possible to log the intended usage of this protocols in the report?
• You have pointed out there are plenty of possible side channels. TAG agrees with that; however, we suggest the proponents address a couple of the more important ones. We pointed the following: Is there any noticeable distinctive behaviour in parsing allow-list compared to (1) the CSP permission model (2) the various communication protocols in origins (regarding a range of side channels, including timing, CPU allocation, memory tracing and caching)?
• TAG could not find any point you discuss the private mode behaviour. We want to double-check that you're not planning for this feature to behave differently in private mode. (As per web platforms design principles (section 2.9))
• Potential leak: TAG acknowledges the single-origin feature of this spec as "A document's (or worker's) asserted policy governs only requests initiated by that context. If a framed document asserts a distinct policy, so be it". However, there is a question about possible leaks via the reporting system. If the reporting endpoint is malicious, cross-origin data could be exfiltrated by generating blocked URLs containing said data and sending reports via the reportingAPIEndpoint. Can you please elaborate on that?
• Is there any evidence that average developers (not just sophisticated developers) actually want to use this spec?

Thanks for taking a look, @toreini!

There is no position from other stakeholder. We encourage you discuss it with them to clarify their position.

Certainly, I'm interested as well.

Neither Apple nor Mozilla have formally replied to the standards position requests I opened up after TPAC last year [1, 2], but there were some productive side conversations there with folks associated with those vendors. I was somewhat hopeful that your discussions in the TAG might be a spark for folks associated with those vendors to weigh in one way or the other. :)

I'm similarly hopeful that an Origin Trial we run in Chrome can help us obtain a broader set of feedback from a larger number of developers as they start kicking the tires a bit.

The explainer or the spec could contain more examples to show more explicitly the interactions.

Could you be more specific about the interactions which should be more explicitly shown?

Regarding reporting, could it be possible to explain the context of the connection? The explainer, point 3 in justification for this spec, mentions CSP does not cover DNS prefetch, WebRTC (most probably WebTransport and WebSocket as well) in the threat model. Would it be possible to log the intended usage of this protocols in the report?

I'm not sure I understand the request. Could you clarify what you'd like to see in the report? It shouldn't be too hard to label a violation as being associated with Web Transport or WebRTC or DNS or etc... is that what you mean?

You have pointed out there are plenty of possible side channels. TAG agrees with that; however, we suggest the proponents address a couple of the more important ones. We pointed the following: Is there any noticeable distinctive behaviour in parsing allow-list compared to (1) the CSP permission model (2) the various communication protocols in origins (regarding a range of side channels, including timing, CPU allocation, memory tracing and caching)?

I'm not sure I understand the question here. Can you help me out regarding the potential mismatch you see between parsing allowlists and CSP's permission model?

Regarding side channels, though: I think one of the main reasons to introduce something like this proposal is the ability to spell out a clear and explicit threat model, which we can then evaluate both on its own merits and use in the future to make decisions about the set of features the header should support. To that end, I've sketched this proposal as handling network connections and ~nothing else, as that's a very clear and defensible boundary. That model puts your (2) explicitly out of scope, which seems reasonable to me: URL-based allowlists seem particularly poorly-suited to handling the ~system level global oracles they represent.

TAG could not find any point you discuss the private mode behaviour. We want to double-check that you're not planning for this feature to behave differently in private mode. (As per web platforms design principles (section 2.9))

Yup, there's no reason this would behave differently in private mode. I didn't mention that in the spec as it seems like the default assumption in the absence of a claim otherwise, but I can do so if you'd find it helpful.

Potential leak: TAG acknowledges the single-origin feature of this spec as "A document's (or worker's) asserted policy governs only requests initiated by that context. If a framed document asserts a distinct policy, so be it". However, there is a question about possible leaks via the reporting system. If the reporting endpoint is malicious, cross-origin data could be exfiltrated by generating blocked URLs containing said data and sending reports via the reportingAPIEndpoint. Can you please elaborate on that?

Reporting depends on the same delivery mechanism as the policy itself. The server needs to send a reporting-endpoints header specifying a set of endpoints that Connection Allowlists will then depend upon (see https://w3c.github.io/reporting/#examples for similar examples). You're correct that it's possible for such a header to specify an endpoint which might handle data in an unprotected way. Doing that maliciously would require control over the HTTP response which I'd consider outside the threat model of a mitigation which itself is delivered via an HTTP response header. :)

Is there any evidence that average developers (not just sophisticated developers) actually want to use this spec?

Folks have been asking for CSP to provide some sort of exfiltration hardening for quite some time now. We made some effort in that direction in response to magecart-like attacks in the past that developers across a reasonably-broad spectrum seemed to want.

Today, the folks I hear asking for something like this are generally interested in using something like this as part of a sandboxing approach, particularly for agent-generated, untrusted content (see e.g. https://aifoc.us/the-browser-is-the-sandbox/ and OpenAI's Apps SDK for example). Microsoft and Google are explicitly interested in that angle.