Re: [SRI] Some questions regarding the current spec.

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