Note that I am only arguing this for HSTS, which is a clear signal of opt-in by the server operator, and for which the primary purpose is to hide 'user' mistakes (forgetting the scheme in the URL bar) rather than 'author' mistakes. Yan's point about extensions is certainly understood and appreciated. Chrome is not WontFix on that, more like Pri3/Patches Welcome (for the extension case), since the user, not the author, has made the intended opt-in. In that regard, the extension might be conceptually viewed as a filter applied to the document, prior to any Fetch invocations. Note that Safari has also implemented HSTS, and it would be good to know at what point in the processing model. I genuinely don't know, as the HSTS support is still fairly new. On Jun 2, 2014 8:26 AM, "Mike West" <mkwst@google.com> wrote: > I defer to Ryan on this, but I'm curious about whether Mozilla is going to > push for the alternate interpretation. If not, then yes, both Fetch and the > mixed draft should change. > > Also: I think it's well in scope for the mixed spec to mandate UI in broad > strokes. It shouldn't mandate what shade of green the lock icon should be, > but forcing a distinction between mixed content and a secure context seems > eminently reasonable. > > -mike > On Jun 2, 2014 5:19 PM, "Anne van Kesteren" <annevk@annevk.nl> wrote: > >> 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:40:19 UTC