- From: Devdatta Akhawe <dev.akhawe@gmail.com>
- Date: Mon, 2 Jun 2014 08:41:37 -0700
- To: Ryan Sleevi <rsleevi@chromium.org>
- Cc: Anne van Kesteren <annevk@annevk.nl>, Mike West <mkwst@google.com>, palmer <palmer@chromium.org>, Daniel Veditz <dveditz@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Tanvi Vyas <tanvi@mozilla.com>, Brad Hill <bhill@paypal.com>
Hi > HSTS from a site operator is a clear indicator that all resources should be > HTTPS, and thus failures to adhere to that policy are bugs by the author > that UAs should not try to cover up. 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. I think HSTS is indication that all resources, even if URL says HTTP, should be accessed over HTTPS. By the explanation above, an anchor link is also a bug that the UA should not cover up. But, if I am not wrong, neither browsers nor spec mandate showing any warnings for that. For complicated, big applications, there isn't a single "author." There is a big team of developers, who might screw up and type http once in a while in some corner of the application. There is also a whole team of security engineers. HSTS is an indicator that the security team requires all fetches to be over HTTPS. I think we should show some empathy for the security engineers and developers at awesomesauce email application :) 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. Also, consider the state that the specs will end up at: If app.com has HSTS, <img src=http://app.com/foo.png> will show a mixed content warning. But, add a CSP 'img-src https://*', the warning goes away! cheers Dev
Received on Monday, 2 June 2014 15:42:24 UTC