- HTTP access, insecure and some browser functionality is unavailable for pages/SPA's served over HTTP.
- HTTPS and tell the user (maybe in a previous HTTP page before a redirect) to dismiss the browser big warning.
- Custom iOS/Android/Desktop app to access it, using an encrypted protocol
There is a (defunct?) W3C group working on this problem:
It would be nice if they all came with a VTE that worked over bluetooth. Windows used to come with it's own VTE for dialing modems so obviously users can handle it.
> - HTTPS and tell the user (maybe in a previous HTTP page before a redirect) to dismiss the browser big warning.
That's not really true though, right? I think the options are actually:
- HTTP access, insecure and some browser functionality is unavailable for pages/SPA's served over HTTP.
- HTTPS, insecure and tell the user (maybe in a previous HTTP page before a redirect) to dismiss the browser big warning, but some more web APIs work.
Unless I'm mistaken with a self-signed cert you gain none of the actual security guarantees of https with a CA mostly stemming from the fact that there is no authenticity and MITM is trivial. I think it's a bad idea to pretend to a user that a connection is secure if it actually isn't. The solution I think would be to open up web apis to local http connections and create a verification system for self-signed devices like signal, matrix, and probably other systems have.
- "Not secure" for HTTP
- "Low security" for HTTPS encrypted but not authenticated (MITM still possible)
- "High security" for HTTPS encrypted and authenticated
So if Chrome wants to piss off the Alpha Geeks in an organization, the folks who decide what software is used, not allowing any kind of override is a good way to do it.
Training people to ignore warning messages is clearly worse than just using http and letting the browser respond by disabling some features for safety.