To be completely honest, this kind of counter-argument (not that you are advocating against HTTPS, but bear with we) always reads to me like "people forget passwords, and don't like having to type usernames, so we just rely on the honor system".

Yes, security has downsides, but in my opinion those downsides are well worth it for the benefits.

Personally i wouldn't mind it that much if the browser let me bypass the error but HSTS seems to mean "even if the site would work fine otherwise, keep it broken". There have been several cases where i couldn't bypass such an error in a site that i just wanted to read something and i was very surprised to see that Firefox didn't had any about:config option to indicate that "i know what i am doing, let me in". So much for taking back the web. Seems it was only temporary so we can hand it to Google.

If browsers allowed you to bypass HSTS, then it could be easily defeated by an attacker by breaking the traffic on port 443, forcing the user to disable SSL for the site. What would be the point over regular SSL? HSTS was designed as a response to programs like sslstrip, where the implementation of SSL may be attacked so the user is made vulnerable.

If a website puts out an HSTS header, they are telling the browser they need a higher bar of security than regular SSL.

And if I am a user of that website and am willing to accept the risks, why does Google force me to live with their opinion? HSTS should be bypassable with user consent.

Technically, HSTS is the website's opinion that you should not accept the risk, not Google's.

I get the distinction, but it's the browser that enforces the website's opinion, and I'm arguing that the browser should give the user absolute control for those users that want it.

Firefox: test.currentTimeOffsetSeconds

Chrome: type badidea

That very much depends on the circumstances doesn't it?

> Visit customers that have self signed certificates on their guest network, hello LTE to be able to do anything.

Visit customers that try to MITM you, get protected. That is, in fact, the point.

The point is delivering work, not spending billable hours messing with network configurations and having to pay LTE from my pocket.

Same here.

Similarly: I have a static site (no tracking, no PIIs) that's currently hosted on a friend's VPS. HTTPS is out, because they're already using it for something else, and Apache can't know which vhost the user is requesting in time to present appropriate certificate. Maybe there's a workaround for that, but neither I nor my friend know of any, we've both already spent few hours looking, and I do not feel like spending even more time figuring out, or moving it to a dedicated VPS with its own IP.

Basically, on the one hand I'm all happy. On the other hand, I totally do not want to do the work.

And beyond that, all the extra complexity introduced everywhere that you mention, and that I also had happen to me.

If I'm understanding your issue correctly (you have two or more domains on the same IP address), then Server Name Indication (SNI) has worked for a very long time and addresses this for you: https://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

Support is at about 97.9% globally: https://caniuse.com/#search=SNI - Effectively every browser released since 2010 plus IE 7 and 8 on Vista.

Thanks, I'll take a look at it tonight.