22 ms·

I think I'd start by removing, at the hardware level, the ability of the IoT devices to do general computing and networking. They accept authenticated external

by jprete 3y ago

I think I'd start by removing, at the hardware level, the ability of the IoT devices to do general computing and networking. They accept authenticated external control instructions, they execute the instructions, they physically cannot do more. Most likely there would be no updates at all. There would also be a physical off switch. My idea is that, if you limit the IoT device - say, a thermostat or a smart bulb - to only have the exact capabilities it is supposed to have, then the damage from any external hack is limited to messing with the user's house. And, if the user has the ability to turn it off, the damage of the hack is limited to "the device doesn't do anything anymore". I figure this is much better than the possibility that breaking the security enables the IoT device to spy on the user's network traffic, or their house, or be part of a botnet, or a bounce point for hacking attempts. EDIT: I recognize there are good real-world reasons why IoT companies don't do it this way. If we actually valued security, then there would be an incentive for someone to build up the systems to facilitate this kind of limited-attack-value design.

AlotOfReading 3y ago
Given how utterly trivial it is to accidentally achieve turing completeness, I suspect any reasonable subset you could come up with would also be capable of general computation. Moreover, such a design would be inherently expensive and inefficient, because it can't achieve the economies of scale modern uCs do, nor can it do anything without an external (presumably networked) command for every single operation.
Mister_Snuggles 3y ago
The challenge is that even a minimal implementation requires quite a lot of functionality. Take a Wifi-based smart outlet, for example. The functionality is literally a single output that drives a relay. But in order for that to work, it needs to join a Wifi network - that means that you need some way to get an SSID and password onto the device and it needs a DHCP client to get an IP address. There also needs to be a way for the controller to discover the device's IP address, which means there's now likely an mDNS implementation on the device. Then there needs to be a way for the device to receive commands, so now we've got an HTTP server. If you want out-of-home access, which I suspect most people do, there's even more work required. Usually this means a central server that the device connects to since most regular people don't have a VPN connection back home. Another option is HomeKit, which is explicitly about local control with all of the remote access magic handled by Apple. But HomeKit is yet more stuff to run on the device, and only works if you've bought into the Apple ecosystem. This is a ton of scope creep for a pretty minimal device. A Zigbee or Z-Wave based outlet would be better, but that really just moves all of that scope creep from the individual device to the hub.
- AnthonyMouse 3y ago
  > A Zigbee or Z-Wave based outlet would be better, but that really just moves all of that scope creep from the individual device to the hub. This is actually fine as long as the hub is open source software running on a general purpose computer, because then you're not reliant on the hardware vendor to support it. The fundamental problem is that the hardware vendors (1) don't provide what's necessary for anyone but themselves to support the hardware, and then (2) don't adequately support it themselves. Far better to address (1) than (2).
ilyt 3y ago
The configuration is a problem here. You can do exactly what you propose, right now, with stuff like ESPhome. You pre-bake what device does and which WiFi network it uses into image, burn it in, and you're done. But that's for "us" Normal user needs a way to get the box to configure to his needs, and do it easily. So suddenly you can "log" onto device and edit its config, and you need to find a way to make sure only legit user does it etc. And now it is a big blob of code and you DONT, UNDER ANY CIRCUMSTANCE want to have big blob of code that's hard to update in the wild.

by jprete 3y ago

AlotOfReading 3y ago

Given how utterly trivial it is to accidentally achieve turing completeness, I suspect any reasonable subset you could come up with would also be capable of general computation. Moreover, such a design would be inherently expensive and inefficient, because it can't achieve the economies of scale modern uCs do, nor can it do anything without an external (presumably networked) command for every single operation.

Mister_Snuggles 3y ago

The challenge is that even a minimal implementation requires quite a lot of functionality. Take a Wifi-based smart outlet, for example. The functionality is literally a single output that drives a relay. But in order for that to work, it needs to join a Wifi network - that means that you need some way to get an SSID and password onto the device and it needs a DHCP client to get an IP address. There also needs to be a way for the controller to discover the device's IP address, which means there's now likely an mDNS implementation on the device. Then there needs to be a way for the device to receive commands, so now we've got an HTTP server. If you want out-of-home access, which I suspect most people do, there's even more work required. Usually this means a central server that the device connects to since most regular people don't have a VPN connection back home. Another option is HomeKit, which is explicitly about local control with all of the remote access magic handled by Apple. But HomeKit is yet more stuff to run on the device, and only works if you've bought into the Apple ecosystem. This is a ton of scope creep for a pretty minimal device. A Zigbee or Z-Wave based outlet would be better, but that really just moves all of that scope creep from the individual device to the hub.

AnthonyMouse 3y ago
> A Zigbee or Z-Wave based outlet would be better, but that really just moves all of that scope creep from the individual device to the hub. This is actually fine as long as the hub is open source software running on a general purpose computer, because then you're not reliant on the hardware vendor to support it. The fundamental problem is that the hardware vendors (1) don't provide what's necessary for anyone but themselves to support the hardware, and then (2) don't adequately support it themselves. Far better to address (1) than (2).

ilyt 3y ago

The configuration is a problem here. You can do exactly what you propose, right now, with stuff like ESPhome. You pre-bake what device does and which WiFi network it uses into image, burn it in, and you're done. But that's for "us" Normal user needs a way to get the box to configure to his needs, and do it easily. So suddenly you can "log" onto device and edit its config, and you need to find a way to make sure only legit user does it etc. And now it is a big blob of code and you DONT, UNDER ANY CIRCUMSTANCE want to have big blob of code that's hard to update in the wild.