[ohazi]

There's a fundamental problem here, and I don't know how it should be addressed. I agree that manufacturers should be able to silently patch firmware for security holes. But I decidedly do not want them silently adding, removing, or changing functionality.

I find this practice absolutely infuriating, and it's a big reason why I abhor the current IoT ecosystem. Sometimes I get busy and don't have time to read a changelog, and I don't want to have to do this on someone else's schedule.

There seems to be no technical way to allow manufacturers to provide transparent security updates without also allowing them to pull the rug out from under you when you least expect it. I think we need some sort of social contract for this, but unfortunately my view seems to be a minority one, given the amount of bullshit that the public seems to tolerate from self-updating devices and apps.

[aeronautic]

Very good point. Even requiring the user to specify a maintenance window can ruin the experience.

Some patches should be able to be made "hot", but that takes extra ram which is often squeezed to a premium in a device.

I would recommend:

- We not put devices on the internet that do not have a core, hard requirement to be on the internet. This rules out toothbrushes, toilets, pillows etc.

- Devices do not open listening ports and only connect out. This eliminates a whole class of shodan visible attacks.

- Devices give users some option of when an update is required and when the user can apply it. If the device can be managed via a HomeKit or Phone UI - these options can be made pretty usable. Alternatively a yellow light on the front of the device if suitable to indicate an update is available.

Regardless, the current path of listening devices on the internet and not being patched is untenable.

[viraptor]

What you seem to propose is a separate stream of updates and security fixes. For this to work the way you describe would mean the company releasing all security fixes for every revision of updates. That's a lot of work in testing, release management, and support, and I don't expect any small sized company to bother.

Actually, I don't know of any project that does this - you may get fixes for a number of supported releases, but the expectation is that you upgrade at some point, or its eol for your product.

[solatic]

If you compare to the Linux ecosystem, you can see why IoT upgrades are broken. In the Linux ecosystem, software releases are typically independent from packaging, as well as from package managers and their update configurations, allowing users the freedom of being somewhere on the spectrum from completely unstable rolling release distributions to highly stable releases like Debian Stable. Software which auto-updates itself, instead of relying on the package manager to update it, is widely considered to be an anti-pattern.

IoT needs a packaging ecosystem to protect the freedom of its users, instead of allowing IoT devices to independently connect upstream to the manufacturer to get updates. Of course, auto-updates should be the default, because most users won't pay attention, but the user's freedom should be protected and preserved.

[veli_joza]

The packaging system is only a part of puzzle. I can control what happens with my Linux laptop, but it's much harder when 10+ devices around you are constantly updating. There's also the thrust issue - we all want exploit patches to be applied automatically while feature changes are different thing altogether (remember when Sony pushed update to PS3 that disabled OtherOS support).

Maybe a good legal solution would be to allow automatic updates, but only if user is informed about changes and she can downgrade/revert at any time. Also, the stuff that Microsoft does with Win 8/10 upgrading should be punishable.

[petra]

You could get your operating system from one vendor, while the application code be inside of an isolated container from the product vendor, with you easily controlling changes to each one. Same could go for the cloud.

I think Android things is built around this idea, with manufacturers having no control on security updates.

For simple, standalone features, this could work well. But when your features are dependent on interacting in some way with other people's connected products, this might not work.