Dictionary partitioning in browsers without tripled-keyed HTTP cache

[annevk]

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 whatwg/fetch#1035 for some background and further pointers on triple-keyed HTTP cache.

[pmeenan]

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.

[yoavweiss]

Can this be closed?