- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Fri, 6 Mar 2015 09:11:08 +0100
- 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. -- https://annevankesteren.nl/
Received on Friday, 6 March 2015 08:11:36 UTC