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
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:
Possibly even correctly!

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

And elsewhere as well:

> > 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
(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.4.0 : Friday, 17 January 2020 18:54:47 UTC