- From: Jacob Hoffman-Andrews <jsha@twitter.com>
- Date: Mon, 24 Mar 2014 18:48:20 -0700
- To: "public-webappsec@w3.org" <public-webappsec@w3.org>
One of the key use cases for SRI is this: > Compromise of the third-party service should not automatically mean compromise of every site which includes its scripts. Content authors will have a mechanism by which they can specify expectations for content they load, meaning for example that they could load a specific script, and not any script that happens to have a particular URL. This sounds great! There are a handful of scripts that are very broadly used on the web, and could compromise a large number of users if their hosts (or their DNS) were hijacked. However, I don't think it will work. Off the top of my head, the most common scripts are probably: Google Analytics, Facebook / Twitter social widgets, and jQuery. Of those, only jQuery can be explicitly versioned. It would be great if, e.g. Twitter could include an SRI hash by default in its code snippets. But Twitter depends on being able to update the code that runs its with its widgets, to fix bugs, deploy new features, and keep up to date with internal display styles. It will also be very difficult for individual page authors to unilaterally pin scripts that they include. Unless the third-party host is cooperating, the content could change at any time, breaking pages that depended on it. Also, unless the script is designed with integrity in mind, it may choose to load other resources that are not protected by hashes. I think SRI only makes sense to pin content that the page author controls, but chooses to host with a third party.
Received on Tuesday, 25 March 2014 01:51:46 UTC