Hardware companies by and large don't get software. They just don't understand it. Their world is sourcing parts and assembly and packaging. They look at software like any other line item in the BOM: Like a screw or gasket. You source it from the cheapest supplier, and spoon it onto the product somewhere on the assembly line. These companies simply don't care about their software, and their requirements to their supplier amount to "make something work." The quality bar is literally "customer should not return the product."

> Anyone care to guess why someone would make this choice?

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.

Everyone (including the author) is as per usual focused on the wrong thing.

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.

did firmware a long time. had two PIs try to force this on me for an IoT device. i pushed back and we missed a deadline. but it uses aws iot certs correctly in a secure element. the customer knew better and thanked me later, lead to 1099 work

3rd party SDK requires TLS and it's not easy to bypass. Development contract doesn't allow long-term support where they can push updates if/when proper CA bundle changes.

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.

Probably something like “What if the cert expires?”

Control and $