Re: [SRI] require-sri-for: missing integrity metadata? same-origin loads?

I also agree with Sergey.

On 12 September 2016 at 00:01, Sergey Shekyan <shekyan@gmail.com> wrote:

> On Fri, Sep 9, 2016 at 12:19 AM, Frederik Braun <fbraun@mozilla.com>
> wrote:
>
>> Hi list,
>>
>> the SRI editor's draft defines an experimental CSP directive
>> "require-sri-for" that is followed by tokens (script or style)[1] to
>> mandate that the web page requires integrity metadata or for those
>> loads. It was added in this pull request[2]
>>
>> Firefox has an experimental implementation, which lead to some good
>> feedback. For example, we've had a bug report that suggests we should
>> block importScript(), since there is no way to supply integrity metadata
>> with importScript().
>>
>> This inadvertedly leads to follow-up questions:
>> 1) What should require-sri-for do for other methods that do not allow
>> fetch-options (e.g. @import and url() in CSS)?
>
>
>> 2) What should require-sri-for do for same-origin resources (Workers,
>> importScripts etc. can not load cross-origin)?
>
>
>>
>> My thoughts so far:
>>
>> re 1) I don't think there's anything we can do besides blocking, if we
>> want require-sri-for to be a security feature that websites rely on.
>>
>
> In `require-sri-for` implementation in Chrome [1], the goal was to require
> integrity
> metadata for all possible mechanisms of loading scripts and styles,
> including preloads and prefetches.
>
> Most of those mechanisms do not provide a way to specify integrity
> metadata today, and the hope is
> that eventually those ways will be covered in the next iteration of SRI
> spec. I would expect that when new
> mechanism to load resources is invented, browsers will ship it with a way
> to provide integrity metadata.
>
>
>> re 2) I've been thinking about this myself and would consider allowing
>> same-origin loads without integrity metadata. It just does not fit the
>> use case of not having to trust a CDN.
>>
>
> I agree with others that same-origin resources should not be treated
> differently from cross-origin
> ones.
> [1] https://www.chromestatus.com/feature/5635811978510336
>
>>
>>
>>
>> Looking forward to hearing your input!
>> Freddy
>>
>>
>>
>> [1] I am thinking about changing the syntax, see other email.
>> [2]
>> https://github.com/w3c/webappsec-subresource-integrity/pull/
>> 32#issuecomment
>>
>>
>