W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2014

Re: "Mixed Content" draft up for review.

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Mon, 2 Jun 2014 08:41:37 -0700
Message-ID: <CAPfop_2UT5OX3OWqoQGtvNujrd3A4o_ic2RXcpMjF2qr72xULg@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:05 UTC