4 ms·

I use uMatirx and it’s given me a pretty good lesson on how much stuff sites load from 3rd-parties. Many sites need me to play whack-a-mole to get them to disp

I use uMatirx and it’s given me a pretty good lesson on how much stuff sites load from 3rd-parties. Many sites need me to play whack-a-mole to get them to display - which 3rd party sites do I need to allow to get the content to show up. I’m really torn by this sort of thing. On one hand, when many sites use jQuery (for example), there’s huge benefits (bandwidth, speed, etc) in having it loaded from one location relatively infrequently and cached for many pages. This is exactly the promise of shared libraries, just on a much wider scale. On the other hand, why aren’t web site operators delivering all of the code that is needed for the site to function? If they want all their users to execute that code, why aren’t they willing to serve it themselves? I’m not sure what the right answer is, but this incident is a pro for pulling in all of your dependencies. The limited data plans that a lot of people have are a big pro for hosting libraries centrally.

amenghra 9y ago
The right answer is to specify a HMAC when serving js from third parties. CSP/SRI already enables this. Ideally you should be able to serve content from your own domain + specify the hash, and let browsers optimize things by re-using cached content from another domain. There’s no easy/standardized way of doing that today.
- greglindahl 9y ago
  I think you can already do a browser extension that intercepts loads and gets things with script integrity from a cache, another domain, ipfs, whatever. Decentraleyes is an example of an existing codebase you could use: https://github.com/Synzvato/decentraleyes https://github.com/Synzvato/decentraleyes
- Scott_Helme_ 9y ago
  There is/was discussion in the standards body of using the SRI hash for exactly this purpose. It sounds really promising but iirc there was a privacy kink to work out.
  - sago 9y ago
    You could potentially tell whether someone has been to a third-party site. Person goes to a porn site, get's file #A. Spying site, offers file #A, but never delivers it. If a person already has #A (i.e. doesn't request it), spy site knows they've been to porn site.
    - deleted 9y ago
      [deleted]
    - stordoff 9y ago
      Could you limit it to widely used libraries? e.g. browser ships with the last N versions of jQuery etc., and avoids the request if it's a known hash. If it's widely used, it seems like the amount of information leaked would be low, and if the browser _always_ ships with it (rather than caching on first use), it would only identify the browser and not browsing history anyway. As a bonus, developers could use it knowing that there is much less likely to be a performance hit from fetching it.
jakobegger 9y ago
Near the end of the post, the author suggest using SRI to prevent the compromised CDN problem. However, that only works for linking to static files (eg. a specific version of a JS library). More info on SRI: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
tetha 9y ago
> On one hand, when many sites use jQuery (for example), there’s huge benefits (bandwidth, speed, etc) in having it loaded from one location relatively infrequently and cached for many pages. This is exactly the promise of shared libraries, just on a much wider scale. This is an interesting comment. So, packing all the JS into one file + optionally removing unused symbols would be similar to statically linked binaries. If optimized well, this would be the smallest amount of code / binary a system has to load to execute the program, but if you have multiple binaries, you might load the same library code multiple times. And security updates of libraries require you to recompile everything. But, in this context, you have to trust basically one JS-file from the host you're accessing. On the other hand, dynamic libraries minimize the bandwidth / memory required to hold the code for a set of binaries, because libc/jquery/... just gets loaded once, instead of once per application. And, technically, shared libraries simplify security updates - update openssl, restart services, and hope that RHEL tested well so you don't end up with a mess. This would be really cool, if you think about it. Depend on magic-js-provider.acme.org/jquery/2.1.x.js, and get security fixes like that. Except the testing would be a nightmare.
oldcynic 9y ago
> which 3rd party sites do I need to allow to get the content to show up This is a game I'm increasingly unwilling to play. The number of domains has got out of hand and are increasingly vaguely named - whether it's a CDN, ads or tracking is often almost impossible to judge. Life's too short now sites are frequently calling out to 15 or more domains for me to jump through hoops just to get some text to display. Images I'm usually happy to dispense with. So I increasingly favour sites that don't need these games. There's still more than enough - for now at least!
aepc2 9y ago
The Firefox extension decentraleyes promises to cache common libraries locally. Thus making you, your own CDN.
- kardos 9y ago
  Which, incidentally, exposes an info leak. Timing the load time for a cached script reveals if you've loaded that script before. Value low for extremely common libraries, higher for less common libraries.
foepys 9y ago
> On one hand, when many sites use jQuery (for example), there’s huge benefits (bandwidth, speed, etc) in having it loaded from one location relatively infrequently and cached for many pages. Does it really decrease bandwidth usage and load times? Is there a study that looked at that specifically in recent months or is it just a assumption? I'm getting the feeling that including common JS libraries is on the decline and more and more developers are using node.js packages that are built into their frontend code. Not to mention that there are quite a few CDNs that are basically providing the same service for the most common frameworks and are thus detrimental to this theory.
- Mister_Snuggles 9y ago
  I’ll admit that it’s not something I’ve verified, just an argument I’ve seen in favour of thise practice elsewhere, but it makes sense. If a browser already has https://code.example.com/blah.1.0.0.js https://code.example.com/blah.1.0.0.js in cache, wouldn’t it just use that instead of loading it again? Edit: This post from StackOverflow lists a number of benefits, most of which will result in better perceived performance when using Google’s CDN vs hosting jQuery yourself: https://stackoverflow.com/questions/2180391/why-should-i-use-googles-cdn-for-jquery https://stackoverflow.com/questions/2180391/why-should-i-use...
- hyperpape 9y ago
  Load times, I believe yes, unless you have your own CDN. But you’re right that the odds that any particular version is in the user’s cache are low. I gathered some links on the subject a while ago: http://justinblank.com/notebooks/browsercacheeffectiveness.html http://justinblank.com/notebooks/browsercacheeffectiveness.h....
alexgvozden 9y ago
it's kind of a huge benefit and then first image that gets displayed is unoptimized 200-300kb png

amenghra 9y ago

The right answer is to specify a HMAC when serving js from third parties. CSP/SRI already enables this. Ideally you should be able to serve content from your own domain + specify the hash, and let browsers optimize things by re-using cached content from another domain. There’s no easy/standardized way of doing that today.

greglindahl 9y ago
I think you can already do a browser extension that intercepts loads and gets things with script integrity from a cache, another domain, ipfs, whatever. Decentraleyes is an example of an existing codebase you could use: https://github.com/Synzvato/decentraleyes https://github.com/Synzvato/decentraleyes
Scott_Helme_ 9y ago
There is/was discussion in the standards body of using the SRI hash for exactly this purpose. It sounds really promising but iirc there was a privacy kink to work out.
- sago 9y ago
  You could potentially tell whether someone has been to a third-party site. Person goes to a porn site, get's file #A. Spying site, offers file #A, but never delivers it. If a person already has #A (i.e. doesn't request it), spy site knows they've been to porn site.
  - deleted 9y ago
    [deleted]
  - stordoff 9y ago
    Could you limit it to widely used libraries? e.g. browser ships with the last N versions of jQuery etc., and avoids the request if it's a known hash. If it's widely used, it seems like the amount of information leaked would be low, and if the browser _always_ ships with it (rather than caching on first use), it would only identify the browser and not browsing history anyway. As a bonus, developers could use it knowing that there is much less likely to be a performance hit from fetching it.

jakobegger 9y ago

Near the end of the post, the author suggest using SRI to prevent the compromised CDN problem. However, that only works for linking to static files (eg. a specific version of a JS library). More info on SRI: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

tetha 9y ago

> On one hand, when many sites use jQuery (for example), there’s huge benefits (bandwidth, speed, etc) in having it loaded from one location relatively infrequently and cached for many pages. This is exactly the promise of shared libraries, just on a much wider scale. This is an interesting comment. So, packing all the JS into one file + optionally removing unused symbols would be similar to statically linked binaries. If optimized well, this would be the smallest amount of code / binary a system has to load to execute the program, but if you have multiple binaries, you might load the same library code multiple times. And security updates of libraries require you to recompile everything. But, in this context, you have to trust basically one JS-file from the host you're accessing. On the other hand, dynamic libraries minimize the bandwidth / memory required to hold the code for a set of binaries, because libc/jquery/... just gets loaded once, instead of once per application. And, technically, shared libraries simplify security updates - update openssl, restart services, and hope that RHEL tested well so you don't end up with a mess. This would be really cool, if you think about it. Depend on magic-js-provider.acme.org/jquery/2.1.x.js, and get security fixes like that. Except the testing would be a nightmare.

oldcynic 9y ago

> which 3rd party sites do I need to allow to get the content to show up This is a game I'm increasingly unwilling to play. The number of domains has got out of hand and are increasingly vaguely named - whether it's a CDN, ads or tracking is often almost impossible to judge. Life's too short now sites are frequently calling out to 15 or more domains for me to jump through hoops just to get some text to display. Images I'm usually happy to dispense with. So I increasingly favour sites that don't need these games. There's still more than enough - for now at least!

aepc2 9y ago

The Firefox extension decentraleyes promises to cache common libraries locally. Thus making you, your own CDN.

kardos 9y ago
Which, incidentally, exposes an info leak. Timing the load time for a cached script reveals if you've loaded that script before. Value low for extremely common libraries, higher for less common libraries.

foepys 9y ago

> On one hand, when many sites use jQuery (for example), there’s huge benefits (bandwidth, speed, etc) in having it loaded from one location relatively infrequently and cached for many pages. Does it really decrease bandwidth usage and load times? Is there a study that looked at that specifically in recent months or is it just a assumption? I'm getting the feeling that including common JS libraries is on the decline and more and more developers are using node.js packages that are built into their frontend code. Not to mention that there are quite a few CDNs that are basically providing the same service for the most common frameworks and are thus detrimental to this theory.

Mister_Snuggles 9y ago
I’ll admit that it’s not something I’ve verified, just an argument I’ve seen in favour of thise practice elsewhere, but it makes sense. If a browser already has https://code.example.com/blah.1.0.0.js https://code.example.com/blah.1.0.0.js in cache, wouldn’t it just use that instead of loading it again? Edit: This post from StackOverflow lists a number of benefits, most of which will result in better perceived performance when using Google’s CDN vs hosting jQuery yourself: https://stackoverflow.com/questions/2180391/why-should-i-use-googles-cdn-for-jquery https://stackoverflow.com/questions/2180391/why-should-i-use...
hyperpape 9y ago
Load times, I believe yes, unless you have your own CDN. But you’re right that the odds that any particular version is in the user’s cache are low. I gathered some links on the subject a while ago: http://justinblank.com/notebooks/browsercacheeffectiveness.html http://justinblank.com/notebooks/browsercacheeffectiveness.h....

alexgvozden 9y ago

it's kind of a huge benefit and then first image that gets displayed is unoptimized 200-300kb png