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

Re: "Mixed Content" draft up for review.

From: Anne van Kesteren <annevk@annevk.nl>
Date: Mon, 2 Jun 2014 17:19:04 +0200
Message-ID: <CADnb78jVCjPWxsT77FciA7cy8xVeF8BxHGNxzchFngK7FJ14ig@mail.gmail.com>
To: Ryan Sleevi <rsleevi@chromium.org>
Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, Mike West <mkwst@google.com>, palmer@chromium.org, Daniel Veditz <dveditz@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Tanvi Vyas <tanvi@mozilla.com>, Brad Hill <bhill@paypal.com>
On Mon, Jun 2, 2014 at 5:13 PM, Ryan Sleevi <rsleevi@chromium.org> wrote:
> While the UI treatment may be out of scope, it does seem important to know
> what Fetch will return for an HTTP URL within an HTTPS document, for which
> an HSTS policy exists.
>
> My view is "default secure" and "consistency is king", and to block/taint
> the fetch as Mixed.
>
> HSTS from a site operator is a clear indicator that all resources should be
> HTTPS, and thus failures to adhere to that policy are bugs by the author
> that UAs should not try to cover up.

I think this makes sense actually. For resources not controlled by the
document it might depend on HSTS caching (did we visit that domain at
some point) whether or not we would block/taint which seems extra
weird.

Mike, should we update Fetch / Mixed Content so that blocking happens
before any HSTS updates to the URL? What about CSP?


-- 
http://annevankesteren.nl/
Received on Monday, 2 June 2014 15:19:31 UTC

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