Re: [w3ctag/design-reviews] Incubation: Connection Allowlists (Issue #1173)

mikewest left a comment (w3ctag/design-reviews#1173)

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](https://github.com/WebKit/standards-positions/issues/583), [2](https://github.com/mozilla/standards-positions/issues/1322)], 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. :)

> 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](https://github.com/WICG/connection-allowlists/?tab=readme-ov-file#why-build-this-when-we-already-have-content-security-policy) (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)](https://www.w3.org/TR/design-principles/#do-not-expose-use-of-private-browsing-mode))

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.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1173#issuecomment-3872546610
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1173/3872546610@github.com>