Re: CfC: Mixed Content to PR; deadline July 6th.

On Mon, Jul 6, 2015 at 11:28 PM, Tanvi Vyas <tanvi@mozilla.com> wrote:

>  Hi Brad,
>
> On 7/6/15 1:55 PM, Brad Hill wrote:
>
> Tanvi,
>
> 1) upgrade-insecure-requests does not cascade to child browsing contexts
> like iframes.  So if I want to guarantee that, e.g. an advertisement served
> in an iframe could never "break the lock" of the parent page (a common
> request from many resource operators)
>
> upgrade-insecure-requests does cascade per
> http://www.w3.org/TR/upgrade-insecure-requests/#nesting.  Firefox has
> implemented this and it's close to landing.  Mike, does Chrome's
> implementation enforce upgrades on nested contexts?
>

You're correct, Tanvi. `upgrade-insecure-requests` is inherited into nested
frames and workers, as per the section you noted.

> 2) upgrade-insecure-requests also doesn't mandate that
> optionally-blockable mixed content be blocked if an upgrade fails.
>
>   I don't see any language in the spec distinguishing between blockable
> and optionally-blockable content.  Firefox's implementation treats them
> both the same.  If the upgrade fails, the resource doesn't load.  Mike, can
> you comment on Chrome's implementation
>

Correct again. The spec doesn't distinguish at all between types of
resource requests, nor does it mandate any fallback mechanism to load a
resource that didn't end up being available over HTTPS.


> I think we could make the semantics of upgrade more strict, but they're
> really targeting different things.  "Upgrade" is really targeted to a
> resource I control with "hard-coded" links to other resources I'm pretty
> sure are available over https.  "Strict" is targeted for making sure that
> even 3rd party content I don't control, may not know about in advance, and
> which may not have secure equivalents available, can never will make an
> http request in the context of my resource or its child contexts.
>
>   Given the above, I think upgrade meets the use case you describe for
> strict - it ensures that 3rd party content can never make an http request
> in your context.
>

In that sense, strict mode and upgrade are very similar. However,
`block-all-mixed-content` prevents network requests outright, which has a
few interesting implications which I think are differentiating enough to
justify the existence of both:

1. `upgrade-insecure-requests` relies on `http://example.com/resource`
being _the same_ as `https://example.com/resource`. Forbes is a nicely
canonical example of that not being the case, and it's certainly
conceivable that upgrade could accidentally include a resource which had
negative impact on the page in which it's embedded because of this
difference. Strict mode, on the other hand, would block the request
entirely, which is safer.

2. A page's `load` event only fires after subresources are loaded.
`upgrade-insecure-requests` could delay that significantly in the case
where a server fails to respond to an upgraded request. Strict mode cancels
the request before it hits the network.

3. Note also that `upgrade` effects more than subresource requests:
same-origin navigational requests are upgraded as well, which might or
might not be something that a site can opt-into. Again, to abuse Forbes: `
https://forbes.com/` links off to `http://forbes.com/` from the navbar at
the top of the page. It could not do so if it was upgrading requests, but
can do so via strict mode.

-mike

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)