Then perhaps the problem is open APs? There are still legitimate uses for HTTP including reading static content.
Say we all move to HTTPS but then let’s encrypt goes away, certificate authority corps merge, and then google decides they also want remote attestation for two way trust or whatever - the whole world becomes walled up into an iOS situation. Even a good idea is potentially very bad at the hands of unregulated corps (and this is not a hypothetical)
> There are still legitimate uses for HTTP including reading static content.
This can still be MITM'd. Maybe they can't drain your bank account by the nature of the content, but they can still lie or something. And that's not good.
Or more problematically, inject a bunch of ads that lead users on to scams.
It would be ideal if people only browsed from trusted networks, but telling people "don't do the convenient, useful, obvious thing" only goes so far. Hence the desire to secure connections from another angle.
> Say we all move to HTTPS but then let’s encrypt goes away
Just switch to ZeroSSL - it's the default certificate provider for the acme.sh script now.
> Then perhaps the problem is open APs?
The problem in the above was not actually caused by the AP being open, nor is it just limited to APs in the path between you and whatever you're trying to connect to on the internet. Another common example is ISPs which inject content banners into unencrypted pages (sometimes for billing/usage alerts, other times for ads). Again, this is just another example - you aren't going to whack-a-mole an answer to trusting everything a user might transit on the internet, that's how we came to HTTPS instead.
> There are still legitimate uses for HTTP including reading static content.
There are valid reasons to do a lot of things which don't end up making sense to support in the overall view.
> Say we all move to HTTPS but then let’s encrypt goes away, certificate authority corps merge, and then google decides they also want remote attestation for two way trust or whatever - the whole world becomes walled up into an iOS situation. Even a good idea is potentially very bad at the hands of unregulated corps (and this is not a hypothetical)
There are at least 2 other decent sized independent ACME operators at this point, but say all of the certificate authority corps merge but we planned ahead and kept HTTP support: our banking/payments, sites with passwords, sites with PII, medical sites, etc is in a stranglehold but someone's plain text blog post about it will be accessible without a warning message. Not exactly a great victory, we'll still need to solve the actual problem just as desperately at that point.
.
The biggest gripe I have with the way browsers go about this is they only half consider the private use cases, and you get stuck with the rough edges. E.g. here they call private addresses out to not get a warning, but my (fully in browser, single page) tech support dump reader can't work when opened as a file:/// because the browser built-in for calculating an HMAC (part of WebCrypto) is for secure contexts only, and file:/// doesn't qualify. Apart from being stupid because they aren't getting rid of JavaScript support on file:/// origins until they just get rid of file:/// completely and it just means I need a shim, it's also stupid because file:/// is no less a secure origin than localhost.
I'd like for every possible "unsecure" private use case to work, but I (and the majority of those who uses a browser) also has a conflicting want to connect to public websites securely. The options and impacts for these conflicting desires have to be weighed and thought through.
I understand why file:/// is limited in the files it can load, but yeah I have no idea why so many functions are gated off.
At least mongoose will serve stuff in 100KB.