Re: [w3ctag/design-reviews] Expose contentEncoding in resourceTiming (Issue #1064)

martinthomson left a comment (w3ctag/design-reviews#1064)

There are so many potential side-channels in the platform, I'm not sure that we have a design principle template that we could use that would catch them all.  What threat model are we operating under again?

Let me see if I understand the constraints that lead to the restriction and - from that - why the defense is effective.  Because it is not obvious to me that it is save to reveal `gzip` vs. `identity`/nothing but then unsafe to reveal a higher-entropy signal like a custom coding. The same for content types.

The [list of redacted values](https://w3c.github.io/resource-timing/#sec-cross-origin-resources) doesn't list either type or codings, but the [opaque report construction](https://fetch.spec.whatwg.org/#create-an-opaque-timing-info) looks like it removes both.  If both are erased in the cross-origin case, what is the problem with revealing higher-information otherwise?

If the case we're talking about is where the content of the response is isolated with CORS (`no-cors`), but `Timing-Allow-Origin` (TAO) is set to release timing information.  I guess the question is whether content codings are information that is not part of the timing information that the site is willing to release, or expecting to have released.

So is this all because content type existed from the definition of resource timing and content encoding is new?  That is, we might expect sites to understand that TAO implies access to content type information, but they might not expect the same for content codings?

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

Message ID: <w3ctag/design-reviews/issues/1064/2942426788@github.com>