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

Re: "Mixed Content" draft up for review.

From: Mike West <mkwst@google.com>
Date: Mon, 2 Jun 2014 17:26:22 +0200
Message-ID: <CAKXHy=cBDhmLRE+qqQN2Gd5gwd8imK7ZGJ35MXsOqie7D7KY+Q@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Dan Veditz <dveditz@mozilla.com>, palmer@chromium.org, Brad Hill <bhill@paypal.com>, Tanvi Vyas <tanvi@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Ryan Sleevi <rsleevi@chromium.org>, Devdatta Akhawe <dev.akhawe@gmail.com>
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:26:51 UTC

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