4 ms·

> Why would anyone use code.jquery.com, really? Because webmasters would rather compromise the security and integrity of their site, and the privacy of their u

• jobigoud 13y ago
  Having the hash would also be very valuable in case the CDN gets compromised so you don't inadvertently serve js malware to your users.
• al2o3cr 13y ago
  Sure, that sounds brilliant: allow anybody who can compute a hash collision to poison other sites' JS libraries. facepalm
  • 1stop 13y ago
    A slightly more sensible approach may be to allow script tags (or any external linking mechanism) to list multiple (trusted) sources, and fallback appropriately. That certainly feels more inline with how the internet in general was designed. <script src="googleapi/jquery,code.jquery.com/jquery,/my/own/version/jquery">
    • ufo 13y ago
      The point they were making is that googleapi and code.jquery.com don't count as trusted (at least not until you verify the hash)
      • nly 13y ago
        The domains are obviously trusted to a degree. The objective of the hash is just to allow a content addressed[0] clientside web cache, and avoid talking to them most of the time. Good for privacy, security and load times. [0] http://en.wikipedia.org/wiki/Content-addressable_storage http://en.wikipedia.org/wiki/Content-addressable_storage
  • jevinskie 13y ago
    If you can create arbitrary collisions with something cryptographically secure like SHA-256, malicious jquery is probably the least of our worries.
  • pornel 13y ago
    That's not hash collision, that's hash preimage attack. If you can perform hash preimage attack, then faking a JS library is aiming really low. • You could forge any SSL certificate. • You could forge any PGP/GPG message (public key crypto is not applied to whole messages, only hashes of them, same with certs). • You could maliciously modify Git repositories, even those with GPG signed releases like the Linux kernel. • You could inject malware into any package repository, MITM software updates for all OSes, etc. Basically security of the entire Internet and all secure software distribution depends on the fact that preimage attack against crypto hashes is impossible (i.e. time and/or energy required to perform a brute-force attack is literally astronomical).
• rmrfrmrf 13y ago
  I want to know what privacy concerns you have regarding static CDNs that you don't implicitly give up by accessing the Internet.
  • dictum 13y ago
    Not sending Referer headers to Google. (Yes, it becomes a problem when you use private browsing, since the cache is cleared when you end the session.)
    • codeonfire 13y ago
      This is what it's all about. These cdn sites exist not out of good will, but because they give tracking information.
    • rmrfrmrf 13y ago
      You have to do that at the end-user level if your goal is truly shielding yourself from Google. Wagging your finger at a few of the devs on a news website isn't going to change the millions of websites using client AND server-side Google Analytics, not to mention ads.
      • dictum 13y ago
        I do. Your comment, > I want to know what privacy concerns you have regarding static CDNs that you don't implicitly give up by accessing the Internet. implies that the privacy concerns for 3rd party JS library CDNs are null. They are only null if you don't already block or misdirect their other tracking methods.
  • nly 13y ago
    Tracking via 3rd party cookies and E-Tags, plus HTTP Referers as codeonfire said. There's also just the obvious risk of compromise, resulting in millions of sites running malicious code.
• anglebracket 13y ago
  > Perhaps it's about time we had a way to specify the hash of <script> source inline so browsers can serve files from cache even if they are from different origins A spec for just that was recently proposed[0], it even has support for a "canonical" script to be used in the event of that the hash check fails. The good news is a polyfill for this can probably be created today. If CDNs serve their JS with the proper CORS headers, you can request the JS with cross-domain XHR and check it against a hash before eval()ing the script. The bad news is that the polyfill would require you to allow `unsafe-eval` if you use Content-Security-Policy headers. Depending on your security model, it'd probably be best to host all your resources yourself. Not to mention that using a hash function written in javascript might negate any performance gains. [0]: http://w3c.github.io/webappsec/specs/subresourceintegrity/ http://w3c.github.io/webappsec/specs/subresourceintegrity/
  • deleted 13y ago
    [deleted]
  • nly 13y ago
    I see no reason to implement any of that in Javascript
    • anglebracket 13y ago
      The polyfill would need to be in javascript, this is just a candidate spec and isn't actually implemented anywhere yet. Obviously it wouldn't be needed if it was implemented natively. I'm just not sure if it makes any sense to, performance-wise.
• jowiar 13y ago
  This strikes me as something that, without a lot of thought, will expose a user's browsing history (similar to the old "check the visited link color" attacks). Insert script links with a hash, check to see if the browser makes a request.
  • cma 13y ago
    I think with JSONP you can already make a cross-site request, time the response, and determine whether it was cached or had to be fetched.
  • anglebracket 13y ago
    That was my thought too, the candidate spec for this[0] seems to have taken that into consideration by requiring the scripts to be served with an `Access-Control-Allow-Origin: <origin>` header. Since the server needs to grant you full cross-origin read permissions to even start the hash check, it's not likely that an attacker could use this to infer more about cross-origin resources than they already can. [0]: http://w3c.github.io/webappsec/specs/subresourceintegrity/ http://w3c.github.io/webappsec/specs/subresourceintegrity/