Re: "Mixed Content" draft up for review.

On Jun 2, 2014 8:03 AM, "Devdatta Akhawe" <dev.akhawe@gmail.com> wrote:
>
> > I believe that we have debated with Mozilla on this in the past as to
> > whether this was bug or feature. Our (Chrome) view is that its feature,
and
> > that it is more important to warn authors about the potential
mixed-content
> > than it is to have users relying on HSTS. Mozilla was debating whether
or
> > not the mixed content checking should happen based upon the effective
> > transport.
>
> I agree that we should warn authors. But, the current Chrome (and
> Firefox?) design warns the user in addition to the author. This has 2
> disadvantages: first, and probably most important, is warning fatigue.
> A number of researchers have suggested that showing fewer warnings
> actually improves efficacy of warnings when we do end up showing them.
>
> Second, imagine you are the security engineer for awesomesauce social
> network. You fought the good fight and turned on HSTS but now every
> time some developer writes HTTP by mistake, the user is shown a
> warning despite the fact that the user was never vulnerable.Now your
> manager is angry at you: if we really needed train developers to write
> HTTPS every where, what was the huge fuss about turning on HSTS?
>
> I am not sure what the solution is, nor am I sure whether it is in the
> purview of this spec to talk about the UI shown to the user.
>
>
> cheers
> Dev

I think this captures the debate between Chromium and Mozilla fairly well -
should the mixed content indicator be applied based on the URL the
author/script requested, or should it be based upon what was fetched from
the network, respectively.

As it applies to HSTS, if treated as 'actual network load', then the mere
act of reloading the page (for which mixed content was signalled) MAY have
the effect of clearing the mixed content status, as HSTS policies MAY have
been delivered by an unrelated, non-mixed subresource.

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.