W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2014

Re: MIX: Exiting last call?

From: Daniel Veditz <dveditz@mozilla.com>
Date: Mon, 15 Dec 2014 10:58:52 -0800
Message-ID: <548F2F6C.6020708@mozilla.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:08 UTC