[cycomanic]

This is an honest question to these arguments, but as a consumer (and as an extension the FCC protecting them) why should I care? Would you accept the same arguments from your car manufacturer, "sorry we can't fix your broken brakes, our supplier uses a process that isn't supported by new brake standards so just don't brake"?

I suspect not, so why not because the car is more expensive?

I would argue that the purpose of regulation is exactly to root out this sort of practice. If it was cheap and effortless to do this we likely wouldn't need regulation.

[AnthonyMouse]

The issue is that it's currently not a regulatory requirement. So when you go to the chip maker and demand that their chip have drivers in the Linux kernel tree so it will continue to support newer kernel versions, they turn you down. Most of their customers don't care about this and they would have to pay a developer to produce drivers of the quality that would be accepted by the Linux kernel maintainers. Then you're stuck using what you can get.

If you had a rule saying that device makers have to produce security updates, now the device makers will all demand this because they need it to satisfy the regulatory requirement, and not be willing to take no for an answer.

[cycomanic]

I don't understand your argument, are you agreeing with me that regulation will cause this to happen? So why is that an argument against regulation?

[AnthonyMouse]

It's an argument for getting the regulation right.

For example, one of the obvious ways around these requirements is you set up Sell To Retailers, LLC which nominally does the final assembly, is responsible for the update requirement and then files for bankruptcy whenever anyone tries to enforce it against them.

The bad way to get around that is to try to hang the requirement on some kind of larger entity, like the retailer. Then every retailer bans every kind of smaller device maker who might not be around to make updates in ten years and you have a rule that unintentionally causes catastrophic market concentration.

The good way is to require that the customer can flash custom firmware to the device and the hardware has sufficient published documentation for a third party to make drivers for it (the easiest way to satisfy which would be to publish open source drivers and firmware).

That way if the manufacturer goes bust, as some of them will even independent of trying to get out of the requirement, someone else can still patch the device. And that someone will be more likely to exist, because communities like DD-WRT will have already produced custom firmware for the device and be there to patch serious vulnerabilities even if the manufacturer is gone.

[svnt]

The same thing happened to my car — they discontinued support for the cellular module it shipped with. I had to bring it in (and I believe pay something) to have the module updated. I did not and now it no longer has the online functionality.

Brakes are not internet-connected, but where the line is between features or functions that might be lost and those that represent the core of the product is an interesting question.

[TeMPOraL]

That's the thing though: most IoT devices shouldn't be Internet-connected, and most definitely should not depend on a vendor cloud (or increasingly, a cloud of a different vendor that sold white-label IoT solution to the "vendor" you you bought the device from). It's an unnecessary limitation, a combination of laziness (going over cloud is easier than figuring out local-first and standardizing on some VPN solution) and abusive business (the cloud on the other side of the world is holding your Internet-connected air conditioner hostage, better play nice).

If brakes are not Internet-connected, that's mostly because they were established before Internet - and given the trends in car manufacturing in general, it's only a matter of time.

(In some sense, we're already there - if you have cloud-connected self-driving, and that self-driving can override your command to apply brakes, then your brakes are de-facto Internet-connected, even if connectivity isn't a hard dependency in all cases just yet.)

[rollcat]

Brakes are fundamentally both a safety-critical system, and one that is both relatively well isolated from other systems, and dead simple in principle (a bike has simple mechanical brakes and a 3yro could explain why they work).

The issue with software OTOH, is that a security hole in one trivial component (e.g. resize images to make thumbnails) can often lead to a full system compromise. Even if you don't get full root, you can still use a compromised system to your advantage: steal personal data, use it in a botnet, serve malware, mine proof of waste, etc.

On top of that, adding a dependency is often made very easy by modern package managers, and as the number goes up it gets rather difficult even to vet your direct dependencies, let alone transitive. Installing brakes in a vehicle doesn't automatically pull in a kitchen sink, but in the software world it's widely accepted, almost inevitable. You can spend your time removing the 90% of that library that you don't need, and rewriting the remaining 10%, or you do the "reasonable" thing and just ship.