> http:// is just legacy baggage we should work toward getting rid of.
I, the server, should decide what protocol to use, not the client i.e. some software provided by two of the largest World corporations, which are also, by sheer accident I suppose, American.
I can send encrypted content over that insecure channel that only some receiver could decrypt and read.
It's none of Google's or Apple's business like it wasn't Microsoft's business to impose their browser and their standards on all of us.
> I can send encrypted content over that insecure channel that only some receiver could decrypt and read.
We've tried this approach with email and has not resulted in a world where I can easily send secure emails to anyone I know.
Even setting aside the problem of inconsistent clients, you're asking for a world where every server re-invents wheels & you haven't even begun to think about solving for authentication (which is a very hard problem even with TLS)
I'm simply saying that HTTP is perfectly fine and it's not legacy.
Of course it's easier to pay for a certificate from a certification authority that maintains the infrastructure, and no, Letsencrypt is free only on the issue side, but maintaining HTTPS has its warts (for example: renew the certs every 3 months!)
but the problem is not HTTP, HTTP in the hands of people who know what they are doing is completely okay, if browsers ban HTTP I predict an explosion of protocols like Gemini or something similar
A lot of low power devices don't need or can't handle HTTPS and there's no problem if what they do doesn't need security nor identity verification.
Meanwhile it's baffling that we are pushing for internet non-public non-state-run identity authorities, while in UK, Japan, Russia, USA and many other countries such an authority don't even exist for real people...
> it's baffling that we are pushing for internet non-public non-state-run identity authorities, while in UK, Japan, Russia, USA and many other countries such an authority don't even exist for real people...
This I'm fully onboard with. We absolutely need to be more active in moving away from this approach of centralised authorities - there's unfortunately no rreal candidates for this outside of the blockchain space. I think we're stuck in an awkward time where many "I need an alternative to centralised systems" innovators end up turning to blockchain, which inevitably leads to vapourware. Hopefully that tendency disappears soon.
Otherwise though, you seem to be avoiding the elephant in the room with HTTP.
> there's no problem if what they do doesn't need security
The fundamental problem is that users need security, and implementers are tasked with making this decision on behalf of users (users don't "choose" to use an unencrypted protocol on the web). Implementers have historically not been the best stewards of user needs. IOW: there are far too many cases of things that do need security where implementers don't believe it does.
I, the server, should decide what protocol to use, not the client i.e. some software provided by two of the largest World corporations, which are also, by sheer accident I suppose, American.
I can send encrypted content over that insecure channel that only some receiver could decrypt and read.
It's none of Google's or Apple's business like it wasn't Microsoft's business to impose their browser and their standards on all of us.