- From: Frederik Braun <fbraun@mozilla.com>
- Date: Fri, 9 Sep 2016 12:16:12 +0200
- To: Mike West <mkwst@google.com>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
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