- What was the reasoning as to why <img>, <object>, etc. tags were left out (well, any element with an 'src' attribute)? It seems unreasonable to think such a point was not considered (indeed, there is even the following in the SRI spec: ..."A future revision of this specification is likely to include integrity support for all possible subresources, i.e., a, audio, embed, iframe, img, link, object,"... so I'm interested to find out why only <link> and <script> tags were included initially.
Ease of spec'ing and implementation, that's all. This is v1 of the spec. It was felt that scripts, styles were the key resources implementors and applications were interested in securing. We want to support more tags in the future.
- Has any work been done to assess the impact of SRI with regard to mobile devices? If SRI attains wide-spread adoption, does the added load of calculating and comparing hashes have a noteworthy effect on battery life or responsiveness of popular devices such as smart-phones and tablets?
Not that I am aware of. I am dubious the added load of calculating sha will be much. SRI lets you also deploy resources closer to the user (since you don't have to trust the CDN as much) so it might actually improve network latency, which I suspect is the far bigger battery/responsiveness overhead. Also worth noting that there are proposals on using SRI to improve caching of common resources like jquery which should also help a lot.
- By my understanding, there is a one-to-one mapping between the integrity attribute and the sub-resource. This implies pages and sub-resources must always be updated in-sync. By allowing multiple integrity attributes (i.e. multiple cryptographically validated versions of a sub-resource), there is the (very low) risk that an attacker has more options for a collision, but it would permit developers and administrators a freedom which makes implementing SRI vastly more practical. Again, I presume this issue will have been thought about, and I'm interested in why such a capability is missing (see *1 below for an example use case).
The spec supports multiple hashes so this should just work, iirc. Can you test? I might be wrong.
Application authors have not asked about this much: usually, the page knows what version of the resource it wants.
- Are there any 'practical' guidelines or recommendations for web developers implementing SRI in applications? E.g. should it only be used for non-origin hosted resources, should developers provide multiple (or only one) hash in each integrity attribute (they can use many, what should they do?), is it recommended to limit SRI use in pages expected to have a large mobile-device audience (e.g. always for JS, optional for css) etc.. etc.
I think there are a few resources available online but not anything official.