- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 2 Jun 2014 17:19:04 +0200
- 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