- From: Daniel Veditz <dveditz@mozilla.com>
- Date: Mon, 15 Dec 2014 10:58:52 -0800
- To: Mike West <mkwst@google.com>, Brian Smith <brian@briansmith.org>
- CC: Michael Cooper <cooper@w3.org>, David Walp <David.Walp@microsoft.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On 12/15/14 3:10 AM, Mike West wrote: > On Mon, Dec 15, 2014 at 3:46 AM, Brian Smith <brian@briansmith.org > 2. In [2] and [3], it was noted that the way that HSTS is dealt with > in the Fetch and Mixed Content draft standards does not match how > Chrome and Firefox actually do mixed content blocking. [...] > > This is currently step 1 of https://fetch.spec.whatwg.org/#fetching, and > it doesn't match reality in any browser I know of. We've heard from > Chrome folks (Ryan and Adam) who are uninterested in changing Chrome's > implementation to match that spec. It would be useful to get similar > opinions from the responsible folks at Mozilla. If they're similarly > disposed, changing Fetch seems like a reasonable resolution. HSTS is strictly a feature of HTTP headers; I'm not sure it makes logical sense to apply it before knowing you have an HTTP(s) origin. In practice I don't see Mozilla hoisting that logic out of the HTTP protocol handler to a higher level as implied in the Fetch spec. In addition there is apparently a logic layer above Fetch because Fetch only handles data:, about:, http: and https: urls -- everything else gives a network error. Whatever layer handles all the other possible protocols (ftp, mailto, feed, etc) is the one that CSP needs to run at, not step 4 in the middle of Fetch. -Dan Veditz
Received on Monday, 15 December 2014 18:59:19 UTC