- From: Daniel Veditz <dveditz@mozilla.com>
- Date: Mon, 02 Jun 2014 10:35:32 -0700
- To: Devdatta Akhawe <dev.akhawe@gmail.com>, Ryan Sleevi <rsleevi@chromium.org>
- CC: Anne van Kesteren <annevk@annevk.nl>, Mike West <mkwst@google.com>, palmer <palmer@chromium.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Tanvi Vyas <tanvi@mozilla.com>, Brad Hill <bhill@paypal.com>
On 6/2/2014 8:41 AM, Devdatta Akhawe wrote: > Interesting. The key difference seems to be that you want HSTS to be a > mechanism to protect against user mistakes (only) while I want it to > also cover developer mistakes. I don't see what we win by only > limiting HSTS to protect against user mistakes. If both the developer and user are perfect in their use of HTTPS there is still a real risk of MITM sslstrip without HSTS. Perhaps even more danger because the developer may not have bothered with the "secure" flag on their cookies if they think they've done it perfectly and don't even have an http server on port 80. > I think HSTS is indication that all resources, even if URL says HTTP, > should be accessed over HTTPS. For that domain. It doesn't mean the author would never want to include other-domain non-SSL content. What are you going to do about the common case of viewing embedded images in secure GMail? > Further, since showing the mixed content dialog is bad UX, I think "we > will not show mixed content dialog if HSTS is on" is a great carrot to > encourage HSTS adoption, which is what we all want. I agree, there's no point warning the user about something that hasn't happened. We should still spit out a message on the console, of course. -Dan Veditz
Received on Monday, 2 June 2014 17:36:01 UTC