Chrome feature: Compression dictionary transport with Shared Brotli

Re:Chrome feature: Compression dictionary transport with Sha... by rasz on Friday September 22, 2023 @09:44AM (#37611983)

>The client will store a hash of the uncompressed response

>client will add ...request header as well as a sec-available-dictionary: <SHA-256>

loving it, another thing to track clients with

[ Parent | on HN ]

Re:Chrome feature: Compression dictionary transport with Sha... by pimterry on Friday September 22, 2023 @09:57AM (#37612125)

From the spec (https://github.com/WICG/compression-dictionary-transport#fin...):

> The existence of a dictionary is effectively a cookie for any requests that match it and should be treated as such:

> * Storage partitioning for dictionary resource metadata should be at least as restrictive as for cookies.

> * Dictionary entries (or at least the metadata) should be cleared any time cookies are cleared.

Given that, I think it offers no more client tracking possibilities than any other existing web tech (cookies, local storage, etc)..

[ Parent | on HN ]

Re:Chrome feature: Compression dictionary transport with Sha... by TonyTrapp on Friday September 22, 2023 @11:08AM (#37613047)

Maybe no more possibilities than regular cookies, but more stealthy for sure. Cookies are (somewhat) easily reviewable by the user through the web developer UI of most browsers; I doubt there will be any browser UI to managing compression dictionary.

[ Parent | on HN ]

Re:Chrome feature: Compression dictionary transport with Sha... by out_of_protocol on Friday September 22, 2023 @02:46PM (#37616022)

should be w3c dicts only and number of dicts and versions should be heavily limited. well, something like js,css,html/xml,json,common-web and new version every 5 years i think good enough for everyone

[ Parent | on HN ]