Re: [whatwg/fetch] COEP:credentialless and the HTTP cache. (#1253)

Correct. NPKs are, seemingly, a best-effort privacy goal. If the intermediary cache is near the server (e.g. a CDN), then we’re saying we’re OK with the origin learning that someone is interested in a given URL. We’re also assuming that the timing difference of (edge cached) vs (edge cache empty, has to backhaul to origin) is an acceptable privacy leak/something the origin controls.

If the intermediary cache is near the client (e.g. a proxy), then NIKs are less likely to provide a hard privacy boundary, because competing origins can collude to prime the proxy cache state, because the proxy has no knowledge of NPKs. NPKs add some timing jitter, but we ultimately are saying the privacy leak is due to explicit local configuration.

This is, for brevity sake, ignoring the complexity of intermediary caches for HTTPS protected resources, which, due to TLS, are more likely to be closer to the origin than the client, at least in today’s networks.

However, @ArthurSonzogni mentioning there are security concerns is why I wanted to draw attention to the complexity. Specifically, whether or not we can meet the guarantee mentioned:

> With COEP:credentialless, we obviously don't want to request a resource without credentials and get a response with credentials. That would be a security issue.

The only way we can guarantee that, with today’s specifications at least, is to make that flag network observable so that any intermediaries can know and take appropriate precautions.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1253#issuecomment-891980131