141–150 of 268 posts
I see this as pretty much only a positive thing.
But in every case by the way, we kinda trust the makers of this software. They can easily ship backdoors to specific users. Same with crypto wallets etc.
Earlier quoted context omitted.
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 unregulat…
> 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…
At least mongoose will serve stuff in 100KB.
Prediction: Wifi captive portal vendors will not react to this until after 90% of their customerbase has their funding dry up. It is incredibly common for public wifi captive portals to be built on a stack of hacks, some of which require the inspection of HTTP and DNS requests to function. *Yes better tools exist, but they dont arent commonly used, and require Portal, WAP and Client support. Most vendors just tell pe…
http://www.slackware.com/ is probably the biggest website I'm aware of that does not serve encrypted traffic[1]. but there are a few other legitimately useful resources that don't encrypt. [1] (Except on the arm subdomain for some reason)
My first distro was Slackware. Good memories. The ARM subdomain looks drastically more maintained, posts from 2025. Don't ever view source on slackware.com
Https really sucks for our intranet. Every little web app and service needs certificates and you can't use letsencrypt.
Maybe everything .local will already be allowed.
> What's worse, many plaintext HTTP connections today are entirely invisible to users, as HTTP sites may immediately redirect to HTTPS sites. That gives users no opportunity to see Chrome's "Not Secure" URL bar warnings after the risk has occurred, and no opportunity to keep themselves safe in the first place. What is the risk exactly? A man-in-the-middle redirect to a malicious https site?
Security theatre is all it is. Protect us from petty thieves but let our employers and the gov MITM our comms.
Even picking the most dismissive wording you can, you contradict yourself.
Earlier quoted context omitted.
It’s static while you control it. Soon as I MIIT your content it will look to your users like you updated your site with a crypto miner and a credit card form. You can publish your site with a self-signed key if you’d like and only depend on your ISP/web host provider, DNS provider, domain registrar, and the makers of your host OS and web server and a few dozen other things.
> MIIT Man in in the?
> One year from now, with the release of Chrome 154 in October 2026... Wait a minute, how do they know what version Chrome will be at a year from now?
Earlier quoted context omitted.
Depend on one less third party, you still depend on the DNS Root servers, your ISP / hosting, domain registry, etc.
Host an onion website at home using solar energy, and the only third party your website will depend on is your internet provider :)