Re: "Mixed Content" draft up for review.


> 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

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 has
HSTS, <img src=> will show a mixed content
warning. But, add a CSP 'img-src https://*', the warning goes away!


Received on Monday, 2 June 2014 15:42:24 UTC