Regarding:
 
> 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 have tested Firefox and Chromium and observed the following:
This behaviour seems like the most reasonable but it might be worth formalising it in a future revision: i.e. ..."although multiple digests can be provided, only those in the most collision-resistant set for which the user-agent has an implementation will be used for validation."
 
As to the rest:  thanks for your thoughts. If I get time I might see about testing what effect SRI has on low-power or power-limited devices.. Like you say, I don't expect it would be a factor of any relevance (given how hardware is so efficient and the benefits may easily compensate for the trivial added computational cost), but might be worth some time to actually test.
 
Regards,

Alexander Forbes
-------------------------------------------------------

Alexander Forbes
IBM X-Force Red

 
 
 
----- Original message -----
From: Devdatta Akhawe <dev.akhawe@gmail.com>
To: Alexander Forbes/UK/IBM@IBMGB
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Subject: Re: [SRI] Some questions regarding the current spec.
Date: Thu, May 4, 2017 6:10 PM
 
Hi Alexander
 
 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.
 
cheers
Dev
 
 
 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU