Re: An HTTP->HTTPS upgrading strawman. (was Re: Upgrade mixed content URLs through HTTP header)

On Wed, Feb 4, 2015 at 9:13 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>
> I think there are three:
>
> 1. As is. Mixed Content is not touched.
>
> 2. Upgrade. Mixed Content URLs will be altered to use HTTP over TLS.
>
> 3. Block. All Mixed Content results in a network error.
>
> We recently added 3. We already have 1 (just do nothing). This adds 2.
> We might want to make the syntax a bit more related, but I'll leave
> that up to Mike.
>

For clarity, #3 is
https://w3c.github.io/webappsec/specs/mixedcontent/#strict-checking. The
expectation is that sites who do the work to migrate to HTTPS fully can
lock in that behavior, and ensure that neither first- nor third-party
content can screw it up.

I suppose we could change the name from `upgrade-insecure-requests` to
`upgrade-all-mixed-content`, but that would conceptually preclude using the
directive on HTTP sites (as the content wouldn't actually be mixed).
Perhaps that's not a bad thing, but since CSP itself works over HTTP, I
don't think there's a good reason to deny this particular feature.

(Non-form top-level navigation needs to be excluded as Mixed Content
> does not touch that. Links would break.)
>

As I noted in another thread, I'm also worried about navigational upgrades.
I think excluding them from the initial pass is the right thing to do.

-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.)