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

Re: [UPGRADE]: What's left?

From: Mike West <mkwst@google.com>
Date: Fri, 6 Mar 2015 10:14:57 +0100
Message-ID: <CAKXHy=duP1yfuWhiM1kWHPaObkHvsThr0VBi-K1UiatpDF4oVA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Jeff Hodges <Jeff.Hodges@kingsmountain.com>, Tanvi Vyas <tanvi@mozilla.com>, Peter Eckersley <pde@eff.org>, Yves Lafon <ylafon@w3.org>, T Guild <ted@w3.org>, Daniel Appelquist <appelquist@gmail.com>, Alex Russell <slightlyoff@google.com>
Thanks, Anne!

On Fri, Mar 6, 2015 at 9:11 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Fri, Mar 6, 2015 at 8:51 AM, Mike West <mkwst@google.com> wrote:
> > https://w3c.github.io/webappsec/specs/upgrade/
>
> In the section on "return=secure-representation" it might be nice to
> direct readers to the wonders of HSTS. (Section 7.2 does not seem to
> address the relationship to this request header.)
>

Good idea! I hope
https://github.com/w3c/webappsec/commit/2e3c42c0fcd320cd4e39a54ebe66d9eed9ae508c
addresses this.


> Should the section on "Policy Inheritance" address workers?
> Theoretically you can instantiate a worker from another worker though
> I've forgotten to what extent that is implemented. (The API you can
> make downgrade fetches with would be fetch(). Of course, it's somewhat
> questionable that any of that would be legacy content...)
>

Yes, it should. And now it does:
https://github.com/w3c/webappsec/commit/48d670bfc6ab4ed41211d88d92c68276fbecfa9d
Possibly even correctly!


> In "Fetching algorithm" (section 5) you want a lowercase "f".
>

And elsewhere as well:
https://github.com/w3c/webappsec/commit/d8bb40bc6812a7a5f77f2d79a4c8e284544d3b01


> > The only issue noted in the document is
> > https://github.com/w3c/webappsec/issues/184, which suggests changing
> from a
> > value-less directive to a whitelist of hosts. I can see how that would be
> > valuable, but it seems like a complicated thing to add if we don't
> actually
> > need it. Do folks here think it is necessary?
>
> I would prefer to start with the simplest possible thing. This
> directive is primarily about dealing with mixed content URLs in legacy
> content. And avoiding mixed content requires no http URLs.
>

Right. I agree.

The potential value I see is in allowing sites to continue serving
optionally blockable content (images, media) from an insecure source, as
that might be the only source they have available. Something like
`upgrade-insecure-requests 'self' my-awesome-cdn.info` might make sense.
It's not clear to me that that's _necessary_ but I can certainly see it as
nice to have.

(Note that adding such a thing in the future could be trivial; similar to
`sandbox`, we could simply map an empty `upgrade-insecure-requests` to the
most secure variant (`upgrade-insecure-requests *`), and allow developers
to layer something more granular from there.)

--
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.)
Received on Friday, 6 March 2015 09:15:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:11 UTC