- From: Peter Eckersley <pde@eff.org>
- Date: Mon, 2 Feb 2015 16:42:31 -0800
- To: Mike West <mkwst@google.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, WebAppSec WG <public-webappsec@w3.org>, Ryan Sleevi <sleevi@google.com>, Adam Langley <agl@google.com>
On Mon, Feb 02, 2015 at 04:47:38PM +0100, Mike West wrote: > On Mon, Feb 2, 2015 at 4:39 PM, Anne van Kesteren <annevk@annevk.nl> wrote: > > > Equivalent, but not identical. My proposal would be to upgrade in > > Fetch similar to HSTS so that any scripts are not affected by URLs > > changing. > > > > Hrm. So the result would be the same as a redirect? The document would have > an insecure URL, but we'd end up making a secure request? > > I don't think this is a terrible idea, and it avoids some of the concerns > Adam and Ryan (CC'd. Hi Adam and Ryan!) raised in the past regarding HSTS's > request-order-dependent behavior. > > That said, I'm not sure it actually solves W3C's concern, as it would leave > legacy clients out in the cold. The only way to support clients that don't > support the thing we haven't implemented yet would be to alter the links at > the source. I totally understand that that's difficult, but it seems > essential. It seems like you're saying that a security mechanism can't be allowed to help new clients upgrade to HTTPS if it doesn't also help old ones? That's an extreme position; wouldn't it make more sense to say that the mechanism shouldn't break or downgrade the experience that old clients were getting? And that old clients should then join the fold through security patches? If you really meant that new clients can't have a safe experience unless old ones do, then we'd be stuck using serverside proxies to parse and upgrade rewrite HTML and JS on the fly, which is a terrible design. The normal situation is that security features get deployed in new clients and then spread from there; why is this case different? -- Peter Eckersley pde@eff.org Technology Projects Director Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993
Received on Tuesday, 3 February 2015 09:31:24 UTC