[SRI] Some questions regarding the current spec.

# Alexander Forbes (16 days ago)
Contact us to advertise here
# Devdatta Akhawe (16 days ago)

inline:

  1. 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.

  1. 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.

  1. 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.

  1. 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.

# Alexander Forbes (16 days ago)
# Luke W Faraone (16 days ago)

Alexander,

On 4 May 2017 at 13:13, Alexander Forbes <axeforbes@uk.ibm.com

axeforbes@uk.ibm.com> wrote:

> The spec supports multiple hashes so this should just work, iirc. Can
you test? I might be wrong.

My confusion here came from the spec stating ..."the user agent will
choose the strongest hash function in the list, and use that
metadata to validate the response". Basically:  "more
collision-resistant hashes must always supersede weaker ones". This
ends up with some not-very-well-defined  behaviour when you have
multiple hashes (e.g. having one of each  sha512 and sha384 where
each represents a different version of the sub-resource). Only the
strongest should be checked in this case.

I think, in general, you should use some sort of cache-busting / versioned URL, since the version of a JavaScript resource you are loading will probably depend on versions of all the other resources. Otherwise, you're approaching a world of non-determinism and bugs.

Could you provide an example use case that would benefit from the freedom you describe?

Want more features?

Request early access to our private beta of readable email premium.