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.
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!
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.
If a browser already has 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...
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.
More info on SRI: https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
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.
Decentraleyes is an example of an existing codebase you could use: https://github.com/Synzvato/decentraleyes
when visiting the ICO website
That is... amusingly ironic.
SRI is good for use with a CDN, where the same entity controls both the HTML that references the JS and the JS being referenced. In that case it keeps someone who subverts the CDN from being able to XSS the site.
Want to know how you can easily stop this attack? What
I've done here is add the SRI Integrity Attribute and
that allows the browser to determine if the file has
been modified, which allows it to reject the file.
This is a product that works by running a script on your page to make changes. There's no option for defense in depth here: either you trust that their processes are secure enough that they're not going to XSS you, or you shouldn't run their code on your site at all.
The bar for including javascript from other sites should be a high one, but there are times when the tradeoff is reasonable. For example, I have Google Analytics [1] on my site, and I trust them to handle this responsibly.
[1] Disclosure: I now work for Google
Yes, but that's not how most developers think these days. Try browsing the Web with NoScript and you will routinely witness dozens of domains in the block list.
>but that's not how most developers think these days.
The decision to include third party javascript is sometimes not even up to developers these days.
"A deal has been signed with company X, put their widget on the site" is something I've now heard a few times.
Arguments about the third party code greatly increasing page load time, page size, introducing security vulnerabilities etc then fall on deaf ears. High developer turnover seems to co-occur in these environments.
I don't. And I don't appreciate people injecting Google beacons on their website. Same thing with Facebook, Twitter, Disqus and all the other shit-scripts.
Would be a useful data point for a "tech stack" web crawler to monitor.
It's a shame this isn't more popular, I'd love to build a browser add-on that uses the integrity hash as the name of the script, and load them from ipfs or something.
Top sites: gov.uk, nhm.ac.uk, change.org, blogs.worldbank.org, handbrake.fr, army.mil, genome.gov, ...
0: SRI - Subresource Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
Wouldn't this negate one of the benefits of a 3rd party hosted SaaS? Otherwise, you have to redeploy everytime your provider updates their lib?
Sure. 3rd party libs your code uses directly.
Haven't seen it too much with 3rd party service providers code that are somewhat outside your code boundaries. Taking 2 different popular 3rd party SaaS that are included as JS in sites as an example.
Google Analytics uses url of https://www.google-analytics.com/analytics.js [1]
Stripe uses url of https://js.stripe.com/v3/ [2]
< Do you want a 3rd party provider to have access to hot deploy to your website?
Clearly not. Nor was this inferred.
[1] https://developers.google.com/analytics/devguides/collection... [2] https://stripe.com/docs/stripe-js/reference
How many hacks like these will we need before people stop to rethink the fundamental security model underpinning the Web? It's clearly crumbling.
Ad-tech is a giant security hole that can't be fixed without burning it all down, but BrowseAloud could be fixed.
In the previous event the code disappeared. This time it isn't what you wanted.
Given that the majority in the JS community probably have it enabled by default in their browsers, probably never...
3rd party in relation to the site. As in <script src="https://someone.elses.domain/something.js">
No. It. Won't. The issue isn't PoW/PoS but the loading of infected code into browsers. PoS may stop the need for this particular JS code to get inserted. However, PoS will hinder no other JS from being inserted.
I think you missed an opportunity to engage your parent comment more productively.
Too bad this can be abused by marketing parasites.
The author of the article is biased as he made a SaaS product for CSP reporting.
CSP reporting should be for local debugging only.
for instance, maybe the default is that an external script can read the DOM but needs extra permissions to write/modify it?
I also don't think it's a great trade-off for a variety of reasons (environment impact, possible wear and tear on user's machines, battery life on mobile devices etc.).
All your hard coded hashes fail and your 3rd party analytics, chat, etc all stop working. Is there a solution to that?