Re: "Mixed Content" draft up for review.

On Jun 2, 2014 5:35 AM, "Mike West" <mkwst@google.com> wrote:
>
> I believe that both Chrome and Firefox currently implement the opposite
of what's specced here (e.g. mixed content happens, then HSTS happens). I
think that the relevant folks consider that a bug, but I'd invite Ryan and
Chris to weigh in (Hi Ryan and Chris, who I just added to CC!). If I've
misinterpreted things, I'm happy to change that piece.
>

Correct. Mixed content detection is performed over the URLs as written in
the source. If you (the author) say to load something over HTTP, while the
active document is sourced from HTTPS (possibly due to HSTS), then we treat
that as mixed content.

That's because even though the fetch will (probably) be secured via HSTS,
you attempted to fetch insecurely.

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.

With respect to where does HSTS fit within Fetch, as implemented within
Chrome, it is treated as a synthetic redirect, "as-if" a 301 was received.
We do not rewrite the content in situ, since any programmatically induced
loads also need to evaluate HSTS policy. Further, at any point during a
fetch of a subresource, the HSTS policy may be invalidated (max-age of 0),
further supporting the unconditional treatment of things as mixed.

Additionally, there has been debate about where and how to handle extension
rewriting. Tools like HTTPSEverywhere currently get the same
treatment/behaviours as HSTS, meaning mixed content signalling, whereas
they would like to be able to suppress that, since it is not/was not the
author's intent to load over HTTPS, rather something the extension did. The
desire here is to allow mixed content to be based on the 'effective' URL
(or first non-synthetic URL). However, that has not been implemented yet in
Chrome.

Is that what you were looking for, Mike?