Re: "Mixed Content" draft up for review.

On Mon, Jun 2, 2014 at 3:15 PM, Ryan Sleevi <rsleevi@chromium.org> wrote:

> 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.
>
Hrm. So we consider loading `http://a.com/script.js` inside `https://a.com/`
to be mixed content, even if `a.com` has flipped the HSTS flag?

I suppose that makes sense, given where mixed content checking is
implemented in Blink, though it's non-intuitive. The page itself _is_
secure; no mixed content loaded.

> 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.
>
Tanvi, where did Mozilla end up on this?

> 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.
>
That makes sense.

> Is that what you were looking for, Mike?
>
Well, no. I was looking for you to tell me that I was right. But this is
good too, I suppose. :)

-mike