I hate this idea that software "rots" all by itself when it's just left on a device and is impossible to keep working. I would at the very, very least expect my device to work exactly as it did on day one, for the next 50 years, assuming I don't change the software. It's bits on a flash drive! It doesn't rot, outside some freak cosmic ray from space flipping a bit.

If you're saying the software stops working because the backend it talks to goes away, well that's a deliberate choice the company is making. All they have to do is have a proper versioning system and do not touch the backend service, and it also should work forever.

I certainly hate that idea as well, but I also accept a pretty decent amount of that because of interactions with the greater world outside of one company’s direct control.

For instance, suppose a streaming service starts requiring a new login method. They have to update their apps to use this new API. If there are and have been over a dozen different distinct smart television operating systems in the past 15 years, and there will be a dozen more in the next 15 years, it’s unreasonable to expect that even companies the size of say, Netflix, are going to reach far enough back in their history to update all those apps. They probably don’t have developers who understand those systems anymore.

And also, the software distribution mechanisms for each of those platforms are probably no longer intact either in order to receive an update. While it’s true that my Panasonic Blu-ray player that I bought in 2009 is still perfectly functional, and has a Netflix app, I assume it doesn’t work and that Panasonic would be hard pressed to distribute me a working updated app.

The only way things would be much different would be if technology progressed at a far slower pace, so there had been no need to adopt any breaking changes to how the app is built, how the apps and firmware was distributed, etc.

There are several examples I've seen of firmware on devices failing because of bit rot, so that's not true. We used to design devices so that the bootloader was pulled from NOR instead of NAND because of this. Then the device could be recovered using a USB stick.

Most people don't encounter it because their device was updated at least once. People should be less trusting in flash drives than they are, I recently pulled three USB flash sticks out of storage and two of the three are now unhappy.

There's a strong argument that consumer electronics should be able to be more incrementally upgraded. Including things like baseline upgrades for certificates. One of the things about TVs and these systems is that they are usually running on something like OverlayFS to avoid corruption of the base OS and enhancing security/integrity. They focus on replacing the underlying image, which is often security signed as well. If you screw something up with a device that's in a customers home then you're going to be spending a lot of money fixing it, the manufacturers have their war stories in this regard, so they're very risk adverse.

As for freezing the backend, you can't. Your API will evolve and for example if your database changes then your backend services will need to be touched. That database will change, some metadata or label will need to change. Even if you keep the API the same you'll need to maintain the legacy backend. Then you need that service running, consuming compute, for years even if there's hardly anyone using it and it's costing money. Then you need security patches for the backend service because the framework needs upgrading or the OS needs upgrading. Eventually the backend framework will be EoL/EoS and so you need to spend to upgrade. It's like saying we'll keep a Java backend running on a public facing API well beyond it's life, log4j anyone?

Certificates expire.

Google learning this the hard way with the recent chromecast outage[0]

[0]: https://www.googlenestcommunity.com/t5/Streaming/Regarding-a...

I think there is a strong argument to simply not checking certificate expiry dates in embedded hardware.

Just keep using the expired certificate forever.

Sure - that means if someone leaks the private key that everyone worldwide needs to do a firmware update to get security.

But that's probably less user harm than everyone worldwide needing to do a firmware update to replace an expired cert, and having a dead device otherwise.

1) You can't pass a PCI-DSS audit if you have expired certificates. 2) You can't always tell the CDN providers what to do with certs. 3) We've seen examples of new root certificates that mean devices don't know about things like LetsEncrypt

At the very least the user should be able to override the failing certificate check. So much "security" cargo culting is intentionally planned failure.

99% of consumers don't understand what that means and if we normalise the average consumer bypassing certificate checks that's definitely a bad thing.

So don't burn CA pubkeys into your binaries without means for user override. If the software can persist a user-specific analytics ID it can support user certs. This is a solved problem.

Yeah but how many people would do that? You, me, and maybe thousand other people here and similarly minded. That's sadly fart in the wind for such companies and not worth creating more friction and risk (ie folks hack their under-warranty tvs till they stop working and then come back asking for free replacements and tarnishing the brand).

I wish there was some trivial real-life applicable solution to this that big companies would be motivated to follow, but I don't see it. Asking for most users to be tinkering techies or outright hackers ain't realistic, many people these days often don't accept basic aspects of reality if it doesn't suit their current comfy view, don't expect much.

But we could do it for our friends and families. A repair shop could do it too. Instead of a full brick.

Here in South Korea, everyone who uses online banking has to renew and reissue banking certificates every year. While I'm not convinced the certificate process is 100% safe, using certificates is one good concept in the sh*t show of Korean online "security" malware users are required to install.

You can add as many user-defined, custom trust anchors as you want, they’re not going to make an expired server TLS certificate work.

Don’t get me wrong, allowing users to add their own trust anchors is absolutely a good thing. But it wouldn’t change anything if the vendor did what GP suggested, which is that the vendor "[does] not touch the backend service." Because one day, their TLS certificate would expire, and they would technically no longer be able to deliver security updates even if the user wanted them.

Not my problem as a buyer. Build the infrastructure to make certificates and everything else work for a reasonably long time. Service is part of the contract.

That's the point, there are no substantive contracts between you and the OS. If we want apps to be responsible for root certs that's interesting, but then the app needs some roof of trust with the OS anyway.

> Not my problem as a buyer.

Mentioning that certificates expire was directed against GP’s unreasonable demand that the vendor "do not touch the backend service." This doesn’t have to do anything with the buyer.