3 ms·

I’m hoping eventually we’ll have some form of true content-addressable storage for the web - so browsers cache content by hash instead of address. That way we w

I’m hoping eventually we’ll have some form of true content-addressable storage for the web - so browsers cache content by hash instead of address. That way we wouldn’t be re-downloading jQuery-3.0.6-min.js for each website we visit (that isn’t using a CDN), but only once - the same could be done with WebAssembly - assuming it doesn’t require monolithic statically linked blobs.

wongarsu 8y ago
Browsers have the option to do this for javascript: with subresource integrity [0] you can add the sha256 hash of the script to a script tag. The browser could check that hash against its cache, in case it's yet another copy of jQuery-3.0.6-min.js. No browser does this because it opens up a huge data leak: I can simply add some script to my website, claim it has the hash of the javascript used by PornHub and measure the loading time of the script (or simply whether the integrity check fails) to find out if you visited PornHub. 0: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
- SlowRobotAhead 8y ago
  News to me, but yea that’s an excellently described reason that why that isn’t used. The natural inclination would be to say “well, we just need a central repository of shared libs” but now you move to a familiar spot of the big wheel of problems we keep trying to fix.
- DaiPlusPlus 8y ago
  It would only be for widely distributed scripts - not site-specific resources for that reason. Think things like jQuery, Angular, Vue.js and RxJS. This would be especially useful for heavier frameworks like Angular because browsers could then have the entire full-fat edition available in-cache so then smaller Angular sites could make use of more features without making their entire site a slow download.
SlowRobotAhead 8y ago
>so browsers cache content by hash instead of address. Are you trying to encourage investment in hash collision technologies? ;)

wongarsu 8y ago

Browsers have the option to do this for javascript: with subresource integrity [0] you can add the sha256 hash of the script to a script tag. The browser could check that hash against its cache, in case it's yet another copy of jQuery-3.0.6-min.js. No browser does this because it opens up a huge data leak: I can simply add some script to my website, claim it has the hash of the javascript used by PornHub and measure the loading time of the script (or simply whether the integrity check fails) to find out if you visited PornHub. 0: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

SlowRobotAhead 8y ago
News to me, but yea that’s an excellently described reason that why that isn’t used. The natural inclination would be to say “well, we just need a central repository of shared libs” but now you move to a familiar spot of the big wheel of problems we keep trying to fix.
DaiPlusPlus 8y ago
It would only be for widely distributed scripts - not site-specific resources for that reason. Think things like jQuery, Angular, Vue.js and RxJS. This would be especially useful for heavier frameworks like Angular because browsers could then have the entire full-fat edition available in-cache so then smaller Angular sites could make use of more features without making their entire site a slow download.

SlowRobotAhead 8y ago

>so browsers cache content by hash instead of address. Are you trying to encourage investment in hash collision technologies? ;)