W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: CfC to publish FPWD of "Upgrade Insecure Resources"; Deadline Feb 17th.

From: Mike West <mkwst@google.com>
Date: Wed, 11 Feb 2015 10:53:04 +0100
Message-ID: <CAKXHy=crKaqJRLNKCLmLBWBs8fA0yvqjGJGUo-q-JbTUNMvhYQ@mail.gmail.com>
To: Crispin Cowan <crispin@microsoft.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Brad Hill <hillbrad@gmail.com>, Dan Veditz <dveditz@mozilla.com>, Wendy Seltzer <wseltzer@w3.org>, Peter Eckersley <pde@eff.org>, yan zhu <yan@mit.edu>
On Tue, Feb 10, 2015 at 7:10 PM, Crispin Cowan <crispin@microsoft.com>

>  I made a suggestion a while back that got one positive response, but
> then seemingly ignored.

Hi Crispin! Sorry I ignored you, that certainly wasn't my intent!

That there should be a “strict” mode e.g. for banks that want absolutely
> all traffic encrypted, and a “slack” mode e.g. for mashup web sites that
> want to encrypt all of their own content, but not that coming from some
> other web sites that they are pulling from.
> The doc proposes 3 modes:
> ·        “Enforced upgrade”: this is pretty much exactly what I meant by
> “strict”
> ·        “Monitored upgrade”: I didn’t address this J
> ·        No upgrade: seemingly implicit in the absence of directives.
> I suggest adding a 4th mode:
> ·        “Local upgrade”: upgrade all content coming from this
> origin/server, and don’t attempt to upgrade stuff coming from other servers
I felt like your suggestion wrapped up into the similar suggestion that we
move to a more granular `*-src` mechanism. I added that to the document as
issue #1 (

Assuming an `upgrade-src` directive (or something more clearly named), my
proposal maps to `upgrade-src *`, and your "local upgrade" proposal maps to
`upgrade-src 'self'`. If we have those to, I don't see why we wouldn't also
want `upgrade-src 'self' http://my-totally-awesome-cdn.com/`.

My concern is that that would be overly complex, both for authors and user
agents to implement, and for authors to maintain on their sites.

Local is basically saying “upgrade stuff that can be upgraded, but
> explicitly tolerate mixed content.” Clearly that is less secure. But it is
> more secure than no upgrade, which is where people using mixed-source
> content will be forced to go.

I think we need to get some feedback from developers to understand where
the pain points actually lie.

My suspicion is that most developers care about two things:

1. Scripts, XHR, etc. "stop working" when they migrate to HTTPS.
2. The address bar breaks in some way (yellow triangle, shield icon, etc)
and scares their users.

It's not clear to me that there's much value in providing a solution that
doesn't consistently solve those problems (and, as Jim notes, still leaves
you vulnerable to the Bad Things that mixed content doesn't yet mitigate).
But I may be misinterpreting the feedback from EFF and W3C folks. Maybe
something more granular really would be helpful. If it is, we should
absolutely put it into the document.


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
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Wednesday, 11 February 2015 09:53:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:46 UTC