Re: Security / Technical feedback on subresource integrity specification

Thanks Frederik for the pointer to the non-implemented feature. Looks
vaguely like what I was thinking of.

https://www.w3.org/TR/2014/WD-SRI-20140318/#the-noncanonical-src-attribute-todo-1

Francois, certainly issues to be explored by developers using any such
feature, though I imagine both the integrity checked and canonical
resources could be hosted separately to the main website (e.g. a public vs
private CDN).

The advantage I see of a fall back is that the feature could begin to be
used by sites that would not consider using a public cdn without knowing
that all user agents are safe and they are not exposed to unnecessary risk
from the CDN.

* Performance for modern clients that can securely use a CDN and perform
integrity checks.
  + pre-cached by user agent (browser local cache shared amongst many sites)
  + first time visitors get a fast experience
  + client side caching still applies for a HTTPS CDN.

* Secure fall back to private CDN (or "main website host")
  + slow first time load of site, but fast from there on
  + no degradation of security for user agents which don't understand
feature

Of course, hashes should match on both URLs to the resource, after all, it
should be the same resource. I believe the spec also allows for multiple
hashes now anyway.

So the updated example is, from a page at www.mysite.com:

script src="http://cdn.mysite.com/scripts/googleX.v1.9.3.js"
  noncanonical-src="http://cdn.google.com/googleX.v1.9.3.js"
  integrity="hashAlg-hash"...

Maybe something for v1.x :)

Regards,
Mhano