search

WICG / compression-dictionary-transport

Other
92 stars 8 forks source link

Dictionary partitioning in browsers without tripled-keyed HTTP cache #36

Open annevk opened 1 year ago

annevk commented 1 year ago

It might well make sense that this is layered on top of the HTTP cache as @pmeenan suggests, but not all implementations have a tripled-keyed HTTP cache at this point. Is that a pre-requisite for this feature?

See https://github.com/whatwg/fetch/issues/1035 for some background and further pointers on triple-keyed HTTP cache.

pmeenan commented 1 year ago

No, a triple-keyed HTTP cache shouldn't be a pre-requisite but it's likely there are requirements for the dictionary metadata to be partitioned if the cache is not.

Fundamentally, the dictionary allows for setting the equivalent of a cookie (the hash) and the cache state of the dictionary (the presence of the hash and the reduced-size responses) on a pattern of URLs that are same-origin as the dictionary.

If cookies are partitioned more aggressively than the cache for a given browser then the dictionary metadata should be as well.

If both cookies and the HTTP cache are double-keyed (top-level document site + URL) then the dictionaries may not leak data that wouldn't otherwise also have been leaked.

Since this is new metadata that is being stored, it feels like the right path is to require triple-keying on the dictionary metadata so we're not adding to the privacy debt that's already there.