- From: Peter Eckersley <pde@eff.org>
- Date: Mon, 16 Mar 2015 03:14:09 -0700
- To: Mike West <mkwst@google.com>
- Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Eric Mill <eric@konklone.com>
On Mon, Mar 16, 2015 at 10:26:39AM +0100, Mike West wrote: > On Mon, Mar 16, 2015 at 10:11 AM, Peter Eckersley <pde@eff.org> wrote: > > How? Without an explicit signal (from the server or the client), it's not > clear to me how you'd choose which users you could safely send to HTTPS for > a given resource. Could you spell this out in a little more detail? Sorry for the confusion. In reply to your point 3, I was just saying that sites could perform HTTP -> HTTPS rewrites for subsets of their users or resources, to evaluate the consequences, not that there was a magical way to know which subsets to target. So to be clear, I agree that dkg's proposal (which we could call "upgrade-insecure-by-default") will require some kind of client -> server compataibility signalling mechanism. In fact I think I said that here: https://lists.w3.org/Archives/Public/public-webappsec/2015Mar/0030.html Probably that should be a header, "Prefer: https" is okay, "Prefer: tls" is even shorter :) > (As an aside: I don't at all think that Daniel's proposal runs counter to > the UPGRADE spec. I think we can evaluate how to make aspects of that spec > default behavior in parallel to shipping it as an opt-in.) Yes, I agree that these efforts are closely aligned. -- Peter Eckersley pde@eff.org Technology Projects Director Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993
Received on Monday, 16 March 2015 10:14:44 UTC