5 ms·
Anything like this is going to need a mandatory Cache-control header that indicates whether the content can be shared cross-domain. Otherwise you can just probe
by __alexs 14y ago
Anything like this is going to need a mandatory Cache-control header that indicates whether the content can be shared cross-domain. Otherwise you can just probe the cache for arbitrary resources, similar to stuff like the a:visited browser history attack.
Or have we just given up trying to deal with all the privacy leaking side-channels in browsers these days?
Another way to do this would be to allow multiple alternative src urls for a resource. Then the browser could pick the best (for as yet undetermined values of best) source the resource.
This has the extra bonus of advantage of looking mostly like a normal <link> or <script> tag and doesn't introduce yet another way to probe across domains.
- alexchamberlain 14y agoI'm sure you're right, but I'm not sure I understand. It would only apply to scripts you add the `sha256` attribute to and you would probably only do this for public libraries.
- __alexs 14y agoI can add whatever SHA I want to the tag though. This means I can tell if you've viewed specific images or other resources on 3rd party domains that wouldn't otherwise by in my browser history. Unless the original content source has opted into this kind of behaviour this seems like a privacy leak to me.
- SoftwareMaven 14y agoOnly links with a hash initially get put in the addressable cache. So if I download foo.js without a hash in the script tag, it is effectively a different document than foo.js with the script tag. The cache address hash would include the file hash, if you will. This would effectively mean the person serving the files gets to determine if you are succeptible to this. If I serve you foo.js and don't want others to know you've seen it, I just make sure not to put a hash. Although, overloading the hash this way sounds wrong. I'd rather see a "shared_cache='public|domain|none' property. I still like the consuming HTML being responsible for deciding that, though.
- ZoFreX 14y agoI think it would actually make more sense for the sha256 to be in the headers for setting it. It seems a bit weird for a property on a link tag pointing at a file to determine what we think the hash of that file is (not to mention quite un-fun to maintain). Of course, that means without duplicating it you would still need a request similar to If-Modified-Since - something like If-Hash-Differs: <sha256 hash>, but still better than downloading the whole file. I've thought about this exact problem before and one nice way to solve it would be through some kind of signing process - so you instead tell the browser "I need com.jquery.1.7.2" and there would be some way of verifying that a given instance of that file was legitimate, and could thus be cached across multiple URIs.
- SoftwareMaven 14y agoI agree the thing serving foo.js should be setting its sha hash in the headers. The client can validate that the header hash and the actual contents match, if it so desires. On the web application side, by putting a "sha" tag in the script tag, the app is saying, "Fail if foo.js isn't the one I expect, regardless of where it comes from." By putting a "shared_cached" in the script tag, the app is telling the client where it is allowed to look for and to put foo.js. Finally, a client should be able to ignore any shared cache requests and make everything private at the user's request.