disabling HSTS

> Seriously, this seems so obvious: there are two questions that TLS is trying to answer at once. I want to know
>
> A) is the transport between me and the other party secure? and sometimes
> B) is the other party who he or she claims to be?
>
> For most traffic (where even a verified A isn't particularly trusted), A is the much more important question, and hand-wringing about B has prevented widespread adoption of simple techniques to solve A. Establish a secure channel, and we can then use that to negotiate authenticity.

You can't solve A without solving B. If you don't know whether the other party is who they claim to be, you don't know whether you are talking to the other party or to an eavesdropper. That is, if Alice can't authenticate Bob, she can't know whether the connection is going A -> B or A -> E -> B, where Eve is talking to Alice as if she were Bob, and talking to Bob as if she were Alice, repeating (and possibly modifying) the messages between them.

> Funny, I don't know of a single browser that complains about a plaintext connection, despite the fact that it's strictly worse than an HTTPS connection with a problematic certificate. Kind of makes the whole certificate verification paranoia seem like so much theater.

I know of one: recent versions of Firefox complain about plaintext connections with password form fields. The reason for not complaining is historical (plaintext connections came first and are still very widespread), but that's slowly beginning to change. Also, once users start trusting the "https://" as the sign of a "safe" connection, it becomes important to warn or block the connection in case it's compromised.