4 ms·

Agreed. Even beyond the monetary aspect, it'd be an absolute headache to have to replace this stuff with any frequency. The biggest reason I'm a skeptic though

Agreed. Even beyond the monetary aspect, it'd be an absolute headache to have to replace this stuff with any frequency. The biggest reason I'm a skeptic though is the incredibly carefree and reckless approach I've seen used by many IoT devices. The Nest is a great example - I was shocked to discover there's no division between the part that directly controls the furnace/AC/etc and the rest of the device. That should've been a no-brainer, because first and foremost the device shouldn't cause harm, and when the "smart" portion inevitably has a problem (even if temporary), a user shouldn't wake up to a frozen or overheating home. This stuff needs a higher level of safety and guarantee, and treating them like smartphone apps is going to end very poorly.

Natanael_L 10y ago
Like I've written before, I want a segmented IoT chip design. http://www.metzdowd.com/pipermail/cryptography/2016-March/028666.html http://www.metzdowd.com/pipermail/cryptography/2016-March/02... It should be possible to split up the functionality across a trusted controller with hard safety limits (only accepting signed updates) from a powerful CPU providing the IoT logic and control functions, with all the I/O components wired such that the trusted controller has the ability to disconnect them. Ideally they'd also have all traffic routed through a home server acting as a firewall (and would ONLY work while firewalled after "firmware expiration").
- bigiain 10y ago
  I was involved with a hardware/IoT startup a few years back - we built Christmas tree lights (so nothing _nearly_ as big a deal if it broke tha your thermostat or door locks,,,) - but even for that our hardware design had baked into it the "do not ruin Christmas" design principle - while it required the Linux half of the controller to allow wifi connection to your phone and all the other "connected" stuff - there was also a microcontroller directly driving the lights, which all on it's own (in the absence of the Linux half coming up) could at least do some minimal blinky light patterns, so that the nearest thing we had to "critical functionality" could be delivered even if(/when) the most-complex-by-far piece failed. (It did, though, add enough to our BOM cost that I have very little doubt that if we'd got to the "get enough investment to find a production run of 100,000" part of our plan, the requisite "adult supervision" that investment would have brought along with it would have fought tooth and nail to reduce our unit costs by a dollar or two, at the expense of all the reliability/redundancy we'd engineered in there...)

Natanael_L 10y ago

Like I've written before, I want a segmented IoT chip design. http://www.metzdowd.com/pipermail/cryptography/2016-March/028666.html http://www.metzdowd.com/pipermail/cryptography/2016-March/02... It should be possible to split up the functionality across a trusted controller with hard safety limits (only accepting signed updates) from a powerful CPU providing the IoT logic and control functions, with all the I/O components wired such that the trusted controller has the ability to disconnect them. Ideally they'd also have all traffic routed through a home server acting as a firewall (and would ONLY work while firewalled after "firmware expiration").

bigiain 10y ago
I was involved with a hardware/IoT startup a few years back - we built Christmas tree lights (so nothing _nearly_ as big a deal if it broke tha your thermostat or door locks,,,) - but even for that our hardware design had baked into it the "do not ruin Christmas" design principle - while it required the Linux half of the controller to allow wifi connection to your phone and all the other "connected" stuff - there was also a microcontroller directly driving the lights, which all on it's own (in the absence of the Linux half coming up) could at least do some minimal blinky light patterns, so that the nearest thing we had to "critical functionality" could be delivered even if(/when) the most-complex-by-far piece failed. (It did, though, add enough to our BOM cost that I have very little doubt that if we'd got to the "get enough investment to find a production run of 100,000" part of our plan, the requisite "adult supervision" that investment would have brought along with it would have fought tooth and nail to reduce our unit costs by a dollar or two, at the expense of all the reliability/redundancy we'd engineered in there...)