5 ms·

There is a thing in HTML5 called Subresource Integrity (https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.or

by sanbor 10y ago

There is a thing in HTML5 called Subresource Integrity (https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...). It looks like this: <script src="https://example.com/example-framework.js" integrity="sha384-oqVuAfXRKap...." crossorigin="anonymous"></script> I wonder if browsers could keep a cache with those hashes as keys and whenever the integrity hash has a match, then it can take the JS from the cache. That would save huge amounts of bandwidth and pages would be so much faster to load. Probably right now we're fetching the same version of jquery hundred of times from 20 different domains a day.

sangnoir 10y ago
> There is a thing in HTML5 called Subresource Integrity It piqued my interest, but I was disappointed to discover that it's only supported by Gecko & Blink[1] - not supported by Safari or IE/Edge. Javascript is currently unavoidable for offline apps. 1. http://caniuse.com/#search=integrity http://caniuse.com/#search=integrity
- digi_owl 10y ago
  JS + offline apps? thanks for making me feel old.
- robin_reala 10y ago
  It’s a progressive enhancement. Browsers that don’t understand the integrity attribute will just load the JS regardless, but at least Firefox and Chrome will get a safer experience.
woogley 10y ago
Currently, SRI is not enough for browsers to implement content-addressable storage as you describe here, because it is subject to cache poisoning. See https://news.ycombinator.com/item?id=10311020 https://news.ycombinator.com/item?id=10311020 - basically, the browser can't know if a script can actually be loaded from the claimed domain without requesting it. This can be used to violate CSP. Though it would be nice for the browser to cache it for domains that have delivered the script previously. It wouldn't be that different from a normal cache except the timestamp doesn't matter.
- sanbor 10y ago
  Thank you for the info! I imagined that there must be some technical issue as having hashes for content would make caching so easy. Anyway, at least using that hash for the same domain would save some requests, as browsers do requests to the server to see if the file hash matches in order to prevent sending the whole thing again.
nateberkopec 10y ago
At least on HTTP/1 sites, most people are bundling their libraries together, so subresource integrity can't save you there. I want to say there's a security concern with re-using these libraries, but I guess the possibility of a hash collision would be extremely small.
cramforce 10y ago
They won't unfortunately implement that caching scheme, because that leaks the sites you have visited to attackers.
r1ch 10y ago
It's not really bandwidth that causes the issue. Javascript is just really slow, both in parsing and execution. According to Chrome dev tools, parsing jquery takes 20ms on my 4.4 GHz desktop CPU. Now imagine how long that takes on a mid-range smartphone. Then add in a dozen other javascript libraries and shims and polyfills and the site is barely usable.
- codedokode 10y ago
  jQuery is a large library. If it were modular and developers used only the code they need it would be faster to parse. But I doubt the bottleneck is JS code. The problem is that web sites are not optimized (some frontend developers think that writing a CSS stylesheet for narrow screen is enough) and they include a lot of resources (including trackers, advertisement, spying social network buttons I never click). Some of the widgets create an iframe (which is like a separate tab in your browser) and load a separate copy of jQuery there, make AJAX requests etc. And even worse, some advertisement networks can create nested iframes 2 or 3 levels deep (for example when a network doesn't had own ads, they can put Google Adwords block). So when you load a page with 10 iframes it loads the CPU as 10 separate tabs. Decoding images is not free too, especially if it is thousand pixel wide heavily compressed JPEG or PNG image. The real optimization would be cutting away (or making lazily loadable by user request) everything except content. As website developers are not going to do it, it is better to do the optimization on client side. I wish standard mobile browser allowed disabling JS, web fonts (which are just a waste of bandwidth) and loading images on request. Mobile networks usually have high latency so reducing the number of requests needed to display a page could help a lot.
  - hilop 10y ago
    You can download a custom bundle of jquery from the source. But then it won't be shared with other websites. The solution is for browsers to cache common libraries and not try to load these resources per page.
codedokode 10y ago
There are ways to cache responses defined in HTTP standard since first version. No fancy HTML5 features is required for that. (And if you meant using hashes to use cache for resources from different domains - there probably will be many misses because every website can use different library versions, they can compress or bundle libraries etc).

by sanbor 10y ago

sangnoir 10y ago

> There is a thing in HTML5 called Subresource Integrity It piqued my interest, but I was disappointed to discover that it's only supported by Gecko & Blink[1] - not supported by Safari or IE/Edge. Javascript is currently unavoidable for offline apps. 1. http://caniuse.com/#search=integrity http://caniuse.com/#search=integrity

digi_owl 10y ago
JS + offline apps? thanks for making me feel old.
robin_reala 10y ago
It’s a progressive enhancement. Browsers that don’t understand the integrity attribute will just load the JS regardless, but at least Firefox and Chrome will get a safer experience.

woogley 10y ago

Currently, SRI is not enough for browsers to implement content-addressable storage as you describe here, because it is subject to cache poisoning. See https://news.ycombinator.com/item?id=10311020 https://news.ycombinator.com/item?id=10311020 - basically, the browser can't know if a script can actually be loaded from the claimed domain without requesting it. This can be used to violate CSP. Though it would be nice for the browser to cache it for domains that have delivered the script previously. It wouldn't be that different from a normal cache except the timestamp doesn't matter.

sanbor 10y ago
Thank you for the info! I imagined that there must be some technical issue as having hashes for content would make caching so easy. Anyway, at least using that hash for the same domain would save some requests, as browsers do requests to the server to see if the file hash matches in order to prevent sending the whole thing again.

nateberkopec 10y ago

At least on HTTP/1 sites, most people are bundling their libraries together, so subresource integrity can't save you there. I want to say there's a security concern with re-using these libraries, but I guess the possibility of a hash collision would be extremely small.

cramforce 10y ago

They won't unfortunately implement that caching scheme, because that leaks the sites you have visited to attackers.

r1ch 10y ago

It's not really bandwidth that causes the issue. Javascript is just really slow, both in parsing and execution. According to Chrome dev tools, parsing jquery takes 20ms on my 4.4 GHz desktop CPU. Now imagine how long that takes on a mid-range smartphone. Then add in a dozen other javascript libraries and shims and polyfills and the site is barely usable.

codedokode 10y ago
jQuery is a large library. If it were modular and developers used only the code they need it would be faster to parse. But I doubt the bottleneck is JS code. The problem is that web sites are not optimized (some frontend developers think that writing a CSS stylesheet for narrow screen is enough) and they include a lot of resources (including trackers, advertisement, spying social network buttons I never click). Some of the widgets create an iframe (which is like a separate tab in your browser) and load a separate copy of jQuery there, make AJAX requests etc. And even worse, some advertisement networks can create nested iframes 2 or 3 levels deep (for example when a network doesn't had own ads, they can put Google Adwords block). So when you load a page with 10 iframes it loads the CPU as 10 separate tabs. Decoding images is not free too, especially if it is thousand pixel wide heavily compressed JPEG or PNG image. The real optimization would be cutting away (or making lazily loadable by user request) everything except content. As website developers are not going to do it, it is better to do the optimization on client side. I wish standard mobile browser allowed disabling JS, web fonts (which are just a waste of bandwidth) and loading images on request. Mobile networks usually have high latency so reducing the number of requests needed to display a page could help a lot.
- hilop 10y ago
  You can download a custom bundle of jquery from the source. But then it won't be shared with other websites. The solution is for browsers to cache common libraries and not try to load these resources per page.

codedokode 10y ago

There are ways to cache responses defined in HTTP standard since first version. No fancy HTML5 features is required for that. (And if you meant using hashes to use cache for resources from different domains - there probably will be many misses because every website can use different library versions, they can compress or bundle libraries etc).