W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2016

Re: webappsec-ACTION-216: Examine fetch refs for stability

From: Wendy Seltzer <wseltzer@w3.org>
Date: Mon, 2 May 2016 17:54:55 -0400
To: Web Application Security Working Group <public-webappsec@w3.org>
Message-ID: <5727CCAF.2090401@w3.org>
On 04/20/2016 12:19 PM, Web Application Security Working Group Issue
Tracker wrote:
> webappsec-ACTION-216: Examine fetch refs for stability

Here's my argument supporting that stability for SRI[1]:

References to Fetch are made to address the question whether a
sub-resource can safely be integrity-checked or the check's result
safely returned to the requesting origin.

* 3.3.2 Is response eligible for integrity validation[2], where SRI
operates only if the response is in the enumerated list, "basic, cors or
default"; and

* 3.7 Handling integrity violations[3]: "The user agent will refuse to
render or execute responses that fail an integrity check, instead
returning a network error as defined in Fetch."

SRI uses the Fetch response type[4] and network error[5]. These elements
have been present in the Fetch spec for more than a year, and reflect
Fetch's goal, comparable to SRI's, to avoid cross-origin information
leakage. They are therefore unlikely to change in any way that affects
the referring spec or implementations of SRI.

Accordingly, I believe it is appropriate to make normative reference[6]
to Fetch as the SRI spec goes to Proposed Recommendation.


[1] https://w3c.github.io/webappsec-subresource-integrity/
[4] https://fetch.spec.whatwg.org/#concept-response
[5] https://fetch.spec.whatwg.org/#concept-network-error
[6] https://www.w3.org/2013/09/normative-references

> http://www.w3.org/2011/webappsec/track/actions/216
> Assigned to: Wendy Seltzer

Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office)
Policy Counsel and Domain Lead, World Wide Web Consortium (W3C)
https://wendy.seltzer.org/        +1.617.863.0613 (mobile)
Received on Monday, 2 May 2016 17:54:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:56 UTC