[SRI] reporting (Was: [SRI] require-sri-for syntax and additional SRI/CSP interaction

Splitting this into a different thread for reporting.

On 09.09.2016 11:50, Mike West wrote:
> On Fri, Sep 9, 2016 at 9:28 AM, Frederik Braun <fbraun@mozilla.com
> <mailto:fbraun@mozilla.com>> wrote:
> 
>     Hi,
> 
>     (This e-mail is assuming you are familiar with require-sri-for in the
>     latest editor's draft at
>     <https://w3c.github.io/webappsec-subresource-integrity/#parse-require-sri-for
>     <https://w3c.github.io/webappsec-subresource-integrity/#parse-require-sri-for>>.)
> 
>     People have asked for SRI reporting, SRI report-only. I suggest we bake
>     all SRI/CSP interaction into a single CSP directive.
> 
> 
> What would this reporting entail? I recall us being intentionally wary
> of reporting whether or not a cross-origin endpoint returned data that
> matched a given hash if that endpoint hadn't also opted-in via CORS
> headers. Can I assume that you'd only report "This endpoint didn't
> opt-in.", and not the resource's hash, in those scenarios?
>  

We can report integrity mismatches, but yes, I am aware that we can not
report the hash of the offending resource. What we can report is the
desired resource and the expected hash.
We should also consider reporting a failed fetch due to the response not
being cors-enabled.



>     Thus, I am suggesting we rename the require-sri-for directive into e.g.,
>     "sri-options". For now, the directive would understand the tokens
>     'require-script' and 'require-style' [1]
> 
> 
> Are there any other options you're interested in adding? That is, it's
> not clear to me that you need 'sri-options' if 'require' is the only
> thing you're optioning. Given the current `require-sri-for`, you can
> simply start sending reports if `sri` isn't present, using the existing
> policy's `report-uri` with a `violated-directive` of `require-sri-for`.
> 
> That latter bit of granularity is actually a good reason to split things
> up: getting two reports whose violated-directives are both `sri-options`
> wouldn't be very helpful if two distinct options were violated.

Fair point.

>  
> 
>     CSP tokens in -src: directives that aren't URLs are quoted.
>     Referrer-Policy is debating whether things should be quoted or not.
>     I'd personally find it less confusing to have everything in quotes that
>     is not a URL. Not all directives seem to follow this approach though
>     (sandbox, reflected-xss, referrer).
> 
> 
> For CSP, we've traditionally wrapped things in single-quotes that aren't
> URLs, iff the directive also accepts URLs. We should probably keep doing
> that, even though we'd probably do things differently if we were
> inventing CSP's syntax today.
> 

Ah, thanks for the clarification.

Received on Friday, 9 September 2016 10:16:49 UTC