Re: [Integrity] Comments/Questions on Subresource Integrity spec

Thanks Dev and Brad for your responses!  Two things I'd still like to 
discuss (perhaps during tomorrow's call) -
* why do we need separate fallback mode and a block modes?  If the 
website wanted to fallback, they would include a src and a noncanonical 
source, along with an integrity attribute.  If they did not want to 
fallback, they would just provide the src and the integrity attribute.
* if the non canonical source fails the integrity check, should we 
require that the actual source be retrieved over https?

~Tanvi

On 4/21/14 7:47 PM, Devdatta Akhawe wrote:
> Hi
>
> Thanks for all the feedback! Comments inline:
>
>> Here it says that fonts are covered, but I don't see anything about fonts in
>> the spec.
> I have filed https://github.com/w3c/webappsec/issues/17
> I imagine one of the editors will get around to it in a future round of edits.
>
>> We could allow mixed active content loads that pass an integrity check
>> (instead of blocking them) and use the UI for mixed display content in these
>> cases (instead of showing the lock).
> yeah. That was one of the possibilities. There are arguments against
> it too, but the spec is not trying to prescribe anything here.
> Personally, I think this is best left to the browsers and how they
> feel their users are best served.
>
>> 2.1 - Key Concepts and Terminology
>> "The SHA-256, SHA-384, and SHA-512 are part of the SHA-2 set of
>> cryptographic hash functions defined..."
>> Looks like SHA-384 isn't used anywhere in the spec.
> I believe RFC6920 allows for using SHA-384. The spec only mandates
> SHA-256 and SHA-512. It might make sense to remove mention of SHA-384,
> but I am not sure if it is doing much damage right now.
>
>
>> Was there a discussion that these restrictions came out of?  I understand
>> the need for them but am worried if about overly constraining the feature.
>> Are there common instances where a resource may not be publicly cachable but
>> wouldn't have any private data or leak information?
> There was a bunch of discussion a while back. Unfortunately, it is
> spread over two threads because the initial thread had too much
> happening. See http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0005.html
> and http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0018.html
> The examples Michal came up with were pretty scary, imo.
>
>
>> 3.5 Verification of HTML document subresources
>> "...a new integrity attribute is added to the list of content attributes for
>> the a, audio, embed, iframe, link, object, script, source, track, and video
>> elements."
>> images are missing from this list.
> thanks! fixed.
>
>
>> 3.5.2 - Noncanonical source
> [skipping these parts since Brad seems to have already answered these]
>
>
>> 3.5.4 - Handling integrity violations
>> Why have separate block and fallback modes?  If the site didn't want to
>> fallback, they wouldn't have included a noncanonical source.
> I believe this is for cases where they don't have the noncanonical
> source and the integrity is applied to the main source.
>
>> 3.5.5.1 - The a element
>> "If subject has an integrity attribute whose value is not the empty string,
>> then:..."
>> What does subject refer to here?
> I think this is defined in the HTML5 spec
> http://www.w3.org/TR/html5/links.html#following-hyperlinks
>
>
>> 'If response’s integrity state is corrupt and the document’s integrity
>> policy is report, the user agent MUST report a violation, and can continue
>> with the download.'
> fixed!
>
> thanks again!
>
> regards
> Dev