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

Re: [UPGRADE]: What's left?

From: Anne van Kesteren <annevk@annevk.nl>
Date: Fri, 6 Mar 2015 09:11:08 +0100
Message-ID: <CADnb78jPN89Y57z7Ax+47XxtpqN1asq7zNVWped4onCyUPmgBg@mail.gmail.com>
To: Mike West <mkwst@google.com>
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>
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.)

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

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

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

Received on Friday, 6 March 2015 08:11:36 UTC

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