Given that CDNs are used on many different sites, it's easy for people running CDNs to track other people around the internet.
There are also security issues: if you're referencing some JavaScript from a CDN, you're trusting the people running the CDN to actually serve the JavaScript you request.
To be fair SRI is brand new and doesn't exist yet in most browsers (just went live in chrome in the last..month?). It isn't realistic to expect most people to already be using it..
You can check a particular browser for SRI support using https://ejj.io/sri/
Despite minimal browser support, it's still nice to start seeing projects like this that make it very easy to implement SRI (for Wordpress users, in this case):
So Integrity checking it just that, checking that the code is actually what you have uploaded. Having worked closely with the great people have made the SRI specification(www.w3.org/TR/SRI/) I can guarantee any CDN supporting integrity checking want to ensure you get the correct content.
If they didn't care about delivering the correct content they would be pushing back against the specification / using it.
This is why I have pushed bootstrap to start using integrity checking to prevent this form of code injection. But yeah there isn't a requirement for you to use this with a CDN either (I get whilst the browser support isn't there on a bank site it wouldn't perhaps be ideal - this has always been the case unless you are in charge of the CDN content) what it does do it inform me that they won't be delivering variable content of any kind whatsoever as SRI would break that code if they tried to load malicious content.
Justin who has also replied to this message works closely with developer outreach at MaxCDN and cares greatly about their product 'doing the right thing'™
Let me know if you have any further questions about SRI as I can probably answer then for you.
Here's the W3C spec on SRI -- http://www.w3.org/TR/SRI/ -- if you still prefer not to use it, you can opt to remove the 'integrity' attribute, it's being provided as a convenience.
Subresource integrity keeps CDNs honest. If a CDN is "incompatible" with subresource integrity, they're doing a MITM attack on your users and your site.
as @ejcx said it is Sub Resource Integrity (SRI) and we (BootstrapCDN/MaxCDN) should be more clear on what SRI is so it doesn't cause any panic. Thanks for the feedback. If you have any questions or concerns you or anyone can email me jdorfman at maxcdn .com
> There are also security issues: if you're referencing some JavaScript from a CDN, you're trusting the people running the CDN to actually serve the JavaScript you request.
In the HTTP/2 world, it will likely be better to not do this.
The old tricks of relying on it being in browser cache already doesn't forego the fact that the connection to the server is expensive and HTTP/2 gives you a nice open connection to your server already... I would bet that a site is faster by taking as many third-party or other domain assets and putting them back on the same domain and same server.
> I would bet that a site is faster by taking as many third-party or other domain assets and putting them back on the same domain and same server.
There are other advantages to using a CDN beyond 'optimizing' browser cache usage: getting assets closer to your users reduces latency (and therefore increases throughput), which can be a noticeable benefit if you're hosting in San Francisco and serving Oceania/SE Asia.
HTTP/2 won't change that: it will just mean distributing assets over multiple domains (to circumvent browser pipelining limits) will make less sense, but putting one asset domain behind a CDN will still be beneficial.
Ah, I should clarify... if you already have your whole site on a CDN, and that CDN supports HTTP/2, then you are probably best not sending request to lots of other domains if you are able to serve the request from your own domain.
The connection overhead of DNS + connection + TLS is still significant... and HTTP/2 means you'll already have a connection to your server, and the assets could already be being pushed to you, but at the least you'll be able to grab them from the same open connection.
True, but not all of those JS CDNs do this (or provide full versioning in paths), and because you're not serving it you have no control over it or ability to configure it.
Are there many CDNs that serve static content without good caching headers? I haven't seen that myself, except in the case of the automatic latest version feature that some have/had.
crossorigin='anonymous' solves the privacy issue, SRI will solve the security issue. If you use JS blocking like NoScript, which doesn't appear to support per-site access restrictions, I'd suggest you switch to something like ublock origin's advanced mode, which allows you to allow individual sites to access specific CDNs.
