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 16:28:44 +0100
Message-ID: <CAKXHy=f9h0H-UTCgaX-g11YnjemLz3SYooHvBicsjXWeapKodA@mail.gmail.com>
To: Alex Russell <slightlyoff@google.com>
Cc: Yves Lafon <ylafon@w3.org>, Tanvi Vyas <tanvi@mozilla.com>, Daniel Appelquist <appelquist@gmail.com>, T Guild <ted@w3.org>, Peter Eckersley <pde@eff.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Jeff Hodges <Jeff.Hodges@kingsmountain.com>
On Fri, Mar 6, 2015 at 4:21 PM, Alex Russell <slightlyoff@google.com> wrote:

> Per Anne's thought, it'd be great if the example discussed HSTS and how
> these work together to make transitioning a large site less painful. In
> particular, talking about how reporting can help the site fix issues over
> time (in the early examples) would help.
This is discussed to some extent in
https://w3c.github.io/webappsec/specs/upgrade/#relation-to-hsts. How would
you suggest bringing the concepts up into the examples? It seems a bit
difficult to do so without conflating the two headers' properties, as
they're clearly quite related.

> Also, in example 2, why is Megacorp skittish about HSTS?
Potentially for the reasons Peter lays out in
https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0029.html. I
don't personally consider those to be terribly _good_ reasons to avoid
HSTS, but I can totally understand why a Megacorp sysadmin would want to
avoid the potential breakage.


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 15:29:38 UTC

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