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

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

Thanks for clarifying, @toreini.

> CSP-only/Allowlist-only/CSP-allowlist mixture: Do these scenarios trigger distinct browser parsing behaviors? If so, clarifying these differences in the specification could enhance privacy analysis, particularly regarding side channel attacks.

I don't know what you mean by "browser parsing behaviors".

Currently, these are specified as distinct policies which are each checked against outgoing requests via the Fetch integration described in https://wicg.github.io/connection-allowlists/#fetch. In short, the change to step 7 described there provides an implicit ordering of checks, all of which are performed until one fails. So, in the mixed case you describe above, we'll check CSP to see if the request is allowed. If CSP blocks the request, we're done! If CSP allows the request, then we'll move on to check Connection Allowlists. If that blocks the request, we're done! If not, we continue down the line of checks to Integrity Policy, etc.

> Is there a risk that attackers could exploit reporting disparities to exfiltrate data (e.g., server configurations) when both mechanisms are deployed concurrently?

Requests will only be blocked once. If CSP blocks the request, CA will never be consulted. If CA blocks the request, it would have already passed through CSP.

Since both CSP and CA are comparing against the same URL (and both include that URL, stripped, in the report), I don't think there's a distinct set of information revealed if one report or the other is sent. CA's report should be a strict subset of CSP's, AFAIR.

Does that answer y'all's questions?

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

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