<story><title>Subresource Integrity</title><url>http://githubengineering.com/subresource-integrity/</url></story><parent_chain></parent_chain><comment><author>bsimpson</author><text>What about caching?  If the HTML and the JS are both updated, but the browser receives the new version of one and the old version of another, this will break your page.  (Since you&amp;#x27;d now have to update the integrity attribute for every JS change, it means you run this risk every time you update your JS.)&lt;p&gt;To be fair, running a mismatched version of the JS could already break things if the changes are big enough, but for minor updates, the user often won&amp;#x27;t notice the difference.  Now, these cases are hard failures.  That&amp;#x27;s not necessarily a bad thing, but I wonder if there&amp;#x27;s a path here to tell the browser &amp;quot;you have an old version of the content; go get the new version.&amp;quot;&lt;p&gt;CDNs and invalidations can be tricky, and it sounds like this could lead to things being broken more often if you&amp;#x27;re caught in the window where one piece updates before the other.</text></comment>
<story><title>Subresource Integrity</title><url>http://githubengineering.com/subresource-integrity/</url></story><parent_chain></parent_chain><comment><author>diafygi</author><text>Would love for the next generation of SRI to include signatures as an option (e.g. integrity=&amp;quot;ed25519-&amp;lt;public_key&amp;gt;&amp;quot;).&lt;p&gt;Hashes means you have to specify an exact version, so there&amp;#x27;s not an easy way to add integrity to things like Google&amp;#x27;s CDN for jQuery that has latest minor version update links for the major API versions of jQuery.&lt;p&gt;Of course, that means also adding a signature to the payload response (maybe an &amp;quot;Integrity: &amp;lt;hash&amp;gt;-&amp;lt;sig&amp;gt;&amp;quot; header?). So it&amp;#x27;s understandable why signatures weren&amp;#x27;t in scope for the first release.</text></comment>