Re:Compression efficiency with shared dictionaries in Chrome
by lukevp on Wednesday March 06, 2024 @06:21PM
(#39623058)
This seems so ludicrous to me when all we really need is a way to share a resource reference across sites. Like “I need react 18.1 on this page, and the SHA should be abcdefghi “. If you don’t have it, I can give it to you from my server, or you can follow this link to a CDN, but the resource itself can be deduplicated based on the hashed contents instead of the URI. Why isn’t this a thing when basically everything uses frameworks nowadays? This shared dictionary seems like a more obtuse and roundabout way to solve these. If there was caching by hashes, browsers could even preload the latest versions of new libraries before any sites even referenced them.
[ Parent
| on HN ]
Re:Compression efficiency with shared dictionaries in Chrome
by ColonelPhantom on Wednesday March 06, 2024 @07:01PM
(#39623416)
One potential issue is tracking. By sharing caches across websites it becomes possible to use timing attacks to track different users. This is why browsers are working to isolate caches per site: https://developer.chrome.com/blog/http-cache-partitioning
Re:Compression efficiency with shared dictionaries in Chrome
by kevinventullo on Thursday March 07, 2024 @03:34AM
(#39626602)
Couldn’t a dedicated actor use IP address or other fingerprinting techniques to do the same thing more easily?