My guess: At some point in the past, a firmware was developed without plans to include firmware update functionality. The team that did this was later burned when the client tried to use a new certificate that the hardcoded, unchangeable system didn't recognize.
Angry meetings occurred, developers were chastised, and someone realized they could avoid that problem by fetching an updated root CA on demand. They did it over HTTP to avoid a chicken and egg problem.
In hardware manufacturing, everything is about crossing items off the list of problems. A problem was raised, someone came up with an idea to solve that problem, and it was implemented. The practice might have spread to other products because it became institutional knowledge about how to avoid a problem that made a customer angry once.
This is from my experience in the consumer hardware industry. If you're not watching the outsourced development closely, they will take the easiest route to solve the problem in front of them and nobody will consider any other consequences.
There is nothing wrong with downloading a certificate over HTTP. In fact, that's how PKI is designed and if you look at the AIA field of this very site you will see the certificate chain is meant to be served over HTTP.
What IS wrong is implicitly trusting an untrusted certificate. Whether it came over HTTPS or HTTP is irrelevant. But no one is talking about that.
I'm more puzzled why someone would buy a complicated IoT purifier for a drafty Bay Area house that probably has knob and tube wiring.
My most reliable air purifiers have a dumb, physical on/off switch. I bought them deliberately for that feature.
1) Others knowing knowing exactly which package you are downloading could give them a very clear way to fingerprint and target services you are running
2) HTTPS could allow you to potentially reduce your risk surface in a case where there is a bug in Steam's signature checker itself and someone sends a crafted payload instead of game files. Server validation would have prevented that. This has actually happened with apt before: CVE-2019-3462.
Odds are small, but I believe in DiD. I could imagine an attacker with nothing better to do could get up to this on say, a Uni's network.
And before you come at me with I should be using a VPN to protect against these scenarios, I do that already. This is about HTTPS being a sane default when possible.
The default for package upgrades on PCs should be HTTPS (as it already is on Arch, Alpine, NixOS, Flatpak, and Homebrew) since it reduces risk with minimal performance impact for most users.
Or they could connect to the service.
> Server validation would have prevented that
No it wouldn't have. HTTPS does not ensure a server's contents are trustworthy.
> And before you come at me with I should be using a VPN to protect against these scenarios, I do that already
So you protect yourself from unlikely, irrelevant threats by... deliberately paying strangers to MiTM your traffic?
You publicly demonize something long enough and otherwise intelligent people start believing HTTPS is a magic invisibility cloak or the Good Housekeeping seal of approval for the web.
It is a tool in the toolbox and nothing more. Wearing safety goggles while making spaghetti is equally stupid.
Solution: ignore security in 1st party code outside 3rd party library that tries to prevent ignoring security.
As far as I know, most of this cheap crap is basically supply chain management companies that contract a factory to manufacturer and contract a software development/IoT/chip company to write software. Everything is waterfall-style locked in with no ongoing support or funding after the production run is done. The software company doesn't care insomuch as it "works" and working to the SCM company is "powers on and functions", not "is secure". As such, there's not much accountability. If the endeavour gets bad publicity, they just close up shop and spin up a new brand.