News for hackers. Stuff that matters.
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.
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?
Re:Compression efficiency with shared dictionaries in Chrome by EE84M3i on Wednesday March 06, 2024 @07:00PM (#39623409)
Privacy issues.

You can use the presence of an item in the cache to correlate visits between sites.

Re:Compression efficiency with shared dictionaries in Chrome by miohat on Wednesday March 06, 2024 @08:47PM (#39624166)
LocalCDN can hijack requests for common static components