They do though:
1) They are distributing executables to their users over a MITM-able channel. That is not acceptable.
2) A bunch of their users will have a much tougher time downloading their drivers when Chrome stops supporting FTP.
The drivers are cryptographically signed so the MitM-able channel is absolutely irrelevant.
The users will just have to stop using Chrome. Supporting Google software is always just a pain in the ass (and I've gotta know as developer of Android apps)
Actually a MitMable channel makes the "it's just cryptographically signed" thing into a heap more trouble.
Bad guys can now replay old drivers, which were cryptographically signed, as the latest drivers.
So then you need to build cryptographically signed metadata structures, so that you can tell that these were the latest drivers as of some recent moment. You need to have this idea of freshness, and a mechanism to ensure it's kept up to date.
There's a period of several years where Linux distros split into two camps: One camp used HTTPS and so it was fine, and the other camp would have a bug where bad guys could cause something unexpected with a MitM attack, and they'd patch it, and then some new bug would be found, and they'd patch that and repeat...
It isn't _impossible_ to get there, Fedora can safely update over insecure protocols today as far as we know. Or, you can skip all that noise and just do HTTPS as RHEL itself had been doing for many years by that point.
Drivers have versions in them, it's part of the driver itself and therefor cryptographically signed.
People like to cargo cult TLS as if it's the only option but it's really not, even debian doesn't use https (and gets quite a bit of backlash despite understanding very well their security model): https://whydoesaptnotusehttps.com/
I'm not sure if you remember, but soon after that site hit the HN frontpage several CVEs where discovered in the way APT uses http that would have been mitigated if they used HTTPS.
The CVE mentioned at the beginning of the page you linked is one of the reasons why TLS is still nice to have, security-wise. Saying that TLS is the only option may be an overstatement, but saying that it definitely provides some benefits is not.
I've seen a lot of naive designs where signed data is downloaded via an unsigned control channel. At the very least, they are vulnerable to replay attacks. Beyond that, it enables more selective blocking/filtering to prevent clients from accessing specific data.
Let's not forget the lost "confidentiality" aspect of TLS either. Your request for HP_Drivers_2019_Update.exe is now broadcasting to the Internet: "Hey I'm running a vulnerable, unpatched device! Last chance to hack me!"
Sure. You can't easily replace the driver with a self-written, malicious driver without exploiting some sort of deep Windows vulnerability. However, executable code can perform all manner of mischief without being a driver. Anyway, I don't think HP's TechOps underachievement is going to convince anyone to switch their browser. Instead, HP'll just have someone spend a week or two setting up an HTTPS file server and everyone will move on. It's better for their users and it's less effort than trying to have a battle to defend FTP of all things.
