Hacker News Reader

Comment by ChuckMcM | Hacker News Reader

An interesting read, a bit more inflammatory than I find informative but the points are pretty solid. Realizing a new device, especially a safety critical device, is something to be done with care (he rants about the Nest smoke detector). And it is "easy" to get irrationally exuberant about adding a computer to things that don't really need them. But I'd diverge a bit on claiming the practice flawed rather than simply the application of it in this case.

View on HN

That's what bothers me about IoT projects - little consideration of failure modes. Nest thermostats have failed in modes that resulted in houses having no heat, and the user couldn't override it locally.[1]

Combine this with active attacks, and it looks really bad. Over three weeks after the attack, Maersk Lines is still struggling. Their big ports didn't achieve close to normal operation until about last Monday. Their big automated port in Rotterdam is running again, after being totally shut down for two weeks, but there's much more manual paperwork than usual, and billing is completely down, so they have zero revenue.[2] LA and Elizabeth NJ are finally back up. Some customer-facing functions were completely re-implemented with simpler web sites. Container tracking is still down. This is the world's largest shipping line, 24 days after the event.

[1] https://www.nytimes.com/2016/01/14/fashion/nest-thermostat-g... [2] http://www.maersk.com/~/media/20170629-operational-update/20...

The Nerves project (http://nerves-project.org) is an IoT OS which basically boots a device into Elixir, and benefits greatly from the battle-tested Erlang BEAM VM which is extremely fault-tolerant.

Do you have a link to the Maersk story? My dad used to work in shipping.

Also, my original Nests decided out of the blue one day that their power wires were both disconnected (which is impossible); is this bug related?

Also, my original Nests decided out of the blue one day that their power wires were both disconnected (which is impossible); is this bug related?

Probably. The problem resulted in Nest units not charging, but continuing to run until their battery was dead. Bringing them back up required a recharge via their USB port, followed by a firmware update to keep them from doing it again.

Both Erlang anr Elixir, while safer than C/C++, are still far from ideal for any critical system, since they lack any kind of static typing.

Citation needed, especially since 95% of the time your code is just dealing with some combination of lists (arrays in OO langs), maps, strings, ints, and symbols/atoms, and is easily unit-tested

It's interesting that you ask for a citation, and then immediately proceed to essentially make stuff up ("95%", "easily unit-tested"). Maybe you could provide a citation for these?

There is a long-running trend in the industrial sector to use statically-typed languages in large and/or critical projects, so there must be reasons for dynamic languages to be quasi non-existent there, and a change would require more than "just easily unit-test it", no? (To be fair Erlang is in fact the one notable exception, although it's -- as far as I know -- only used in the telecom industry)

The problem is that the device is the result of a flawed process. If the process isn't fixed to be more conservative, it will continue to produce flawed devices.

Given that even the 'premium' end of IoT things we have so far range from insecure to dangerous, I think the onus is on those attempting to sell them to demonstrate that their product isn't literally worse than useless.

After that, they can make the case of being better non-connected devices.

And, never say never, but there are some classes of devices of which I will never buy IoT versions, or if I have to, I will cripple the connectivity. Frankly, house locks are one of those - the dangers are far greater than any convenience for me. That reduces to one's threat models, of course, and I totally get that others may differ. (I live alone in an urban environment; having eight kids and house staff in the 'burbs would be entirely different.)

The key thing that this hits on is that it is bad engineering to replace a simple system with a vastly more complex system for the same task.

The correct approach, which the author points out, is to leave the simple system in place and then layer the more complex system with its additional features on top in a way that when it fails it does not break the base level system.

On the same topic, it might be good to keep POTS around, just in case we ever want to make an analog phone call again.

Agreed. A bit ranty - but still a good analysis of what constitutes bad design when "disrupting".

I read the article as:

"Move fast and break things" is great for a giant clickbait system, but in some industries it can kill people.

Move fast and break things is childish culture for childish projects. Think of all the people who live life like that.

"Don't move fast and break things when the things are people."

Reply on news.ycombinator.com