Re: [SRI] review note 2

On 27/05/15 13:20, timeless wrote:
>> 3.2.2 Priority
> 
>> User agents must provide a mechanism of determining the relative
> priority of two hash functions and
> 
>> return the empty string if the priority is equal.
> 
> What's the justification for this?
> 
> What should this function do for "hash functions" of unknown strength?
> 
> Is this function accessible to content, or is it an algorithm detail?

No, that's an implementation detail that may not even exist in this form
in the user agent.

I've filed a bug to clarify this:

  https://github.com/w3c/webappsec/issues/387

>> 3.3.5 Does resource match metadataList?
>> If resource’s URL’s scheme is about, return true.
> 
> About isn't always trusted content...

We are discussing whether to take it out entirely or just whitelist
about:blank:

  https://github.com/w3c/webappsec/issues/319

>> 3.6 The integrity attribute
> 
>> In order for user agents to remain fully forwards compatible with
> future options, the user agent must ignore all unrecognized
> option-expressions
> 
> Missing period.

Good catch, I've prepared a pull request for it:

  https://github.com/w3c/webappsec/pull/388

>> 3.8 Handling integrity violations
> 
>> NOTE
>> On a failed integrity check, an error event is thrown.
>> Developers wishing to provide a canonical fallback resource (e.g. a
> resource not served from a CDN, perhaps from a secondary,
>> trusted, but slower source) can catch this error event and provide an
>> appropriate handler to replace the failed resource with a different one.
> 
> Shouldn't this mention how one can recognize the unhappy node? (A
> forward link is fine)

What do you mention exactly here? An unsuccessful load will trigger an
error which you can catch in JavaScript by hooking into "onerror". Is
there something you think we should clarify here?

>> 5.1 Non-secure contexts remain non-secure
> 
>> Integrity metadata delivered to a context that is not a secure context,
>> such as an only protects an origin
> 
> This doesn't make sense.

Can you expand on this? If you're serving a page over HTTP and you add
metadata to protect the integrity of sub-resources, a network attacker
could simply modify the expected hash values in your page.

Francois

Received on Wednesday, 27 May 2015 02:22:07 UTC