4 ms·
This follows the same origin rules as cookies and caching, so it is not useful for tracking anymore than those already are. As the when this is useful there ar
by SahAssar 2y ago
This follows the same origin rules as cookies and caching, so it is not useful for tracking anymore than those already are.
As the when this is useful there are many examples:
* Map tiling (like OSM, mapbox, google maps, etc.) often have many repeated tokens/data but the tiles are served as individual requests
* Code splitting of CSS/JS, where they share a lot of the same tokens but you don't want to have to load the full bundle on every load since much of it wont be used
* Any site where the same terms and/or parts are recurring across multiple pages (for many sites like IMDB or similar I'd guess 80% of the HTML is non-unique per request)
This has been tried before with SDCH which unfortunately died, hopefully this goes better.
- patrickmeenan 2y agoFWIW, this addresses the BREACH/CRIME issues that killed SDCH by only operating on CORS-readable content. It also solves the problem that SDCH had where the dictionary would be forced on the response and the client would have to go fetch it if it didn't have it before it could process the response. The tooling for generating dictionaries is also WAY better than it was back in the SDCH days (and they are a much cleaner format, being arbitrary byte strings that Brotli and ZStandard can back-reference). Lots of people involved in working on it were also involved with SDCH and have been trying to find a workable solution since it had to be turned down.