On 2017-03-02 02:59, Alex Jordan wrote:
Here's the basic problem: say I want to include jQuery in a page. I
have two options: host it myself, or use a CDN.
Not to be overly pedantic but you might re-evaluate the need for jquery and other such frameworks. "HTML5" now do pretty much the same as these older frameworks wit the same or less amount of code.

The fundamental issue is that there isn't a direct correspondence to
what a resource's _address_ is and what the resource _itself_ is. In
other words, jQuery 2.0.0 on my domain and jQuery 2.0.0 on the Google
CDN are the exact same resource in terms of content, but are
considered different because they have different addresses.
Yes and no. The URI is a unique identifier for a resource. If the URI is different then it is not the same resource. The content may be the same but the resource is different. You are mixing up resource and content in your explanation. Address and resource is in this case the same thing.

2. This could potentially be a carrot used to encourage adoption of
Subresource Integrity, because it confers a significant performance
This can be solved by improved webdesign. Serve a static page (and not forget gzip compression), and then background load the script and extra CSS etc. By the time the visitor has read/looked/scanned down the page the scripts are loaded. There is however some bandwidth savings merit in your suggestion.

...That's okay, though, because the fact that it's based on a hash guarantees 
that the cache
matches what would've been sent over the network - if these were
different, the hash wouldn't match and the mechanism wouldn't kick in.

Anyway, this email is long enough already but I'd love to hear
thoughts about things I've missed, etc.
How about you miss-understanding the fact that a hash can only ever guarantee that two resources are different. A hash can not guarantee that two resources are the same. A hash do infer a high probability they are the same but can never guarantee it, such is the nature of of a hash. A carefully tailored jquery.js that matches the hash of the "original jquery.js" could be crafted and contain a hidden payload. Now the browser suddenly injects this script into all websites that the user visits that use that particular version of jquery.js which I'd call a extremely serious security hole. you can't rely on length either as that could also be padded to match the length. Not to mention that this is also crossing the CORS threshold (the first instance is from a different domain than the current page is for example). Accidental (natural) collision probabilities for sha256/sha384/sha512 is very low, but intentional ones are higher than accidental ones.

While I haven't checked the browser source codes I would not be surprised if browsers in certain situations cache a single instance of a script that is used on multiple pages on a website (different url but the same hash). This would be within the same domain and usually not a security issue.

It might be better to use UUIDs instead and a trusted "cache", this cache could be provided by a 3rd party or the Browser developer themselves.

Such a solution would require a uuid="{some-uuid-number}" attribute added to the script tag. And if encountered the browser could ignore the script url and integrity attribute and use either a local cache (from earlier) or a trusted cache on the net somewhere.

The type of scripts that would benefit from this are the ones that follow a Major.Minor.Patch version format, and a UUID would apply to the major version only, so if the major version changed then the script would require a new UUID.

Only the most popular scripts and major versions of such would be cached, but those are usually the larger and more important ones anyway. It's your jquery, bootstrap, angular, modernizer, and so on.

Roger Hågensen,
Freelancer, Norway.

Reply via email to