Over a million developers have joined DZone.

The Internet of Stupid Is Alive and Well

DZone 's Guide to

The Internet of Stupid Is Alive and Well

Should you connect all your devices? Probably not. Let's see what lessons can be learned when IoT devices fail at the worst time.

· IoT Zone ·
Free Resource

Anyone who’s traveled widely before the days of connected smart phones and GPS knows the pain of travel plans going awry. You might even end up at your place of accommodation only to find yourself locked out in the middle of the night.

It’s the stuff nightmares are made of and a thing of the past until this week, when hundreds of Internet-connected locks became inoperable. It's a problem lock makers Lockstate attributes to a faulty software update that resulted in a fatal system error. Lockstate’s RemoteLock 6i is a worldwide partner of Airbnb, meaning that many hosts were unable to remotely control their locks.

The problem occurred when RemoteLock6i’s were sent a firmware update intended for RemoteLock7i’s and subsequently the former was unable to be locked or receive over-the-air updates.

A letter was sent to all those affected  — over 500 customers — instructing that they can either return parts to be fixed by Lockstate, with a turnaround time of five to seven days, or they could request a replacement lock, taking 14 to 18 days. In the meantime, homeowners are instructed to use a physical key — but what if you were out without your key when the crash happened or lived some distance away from the rental property?

I spoke to Yann Leretaille, CTO at Berlin company 1aim who build, develop, and produce access control systems that enable users to open doors with mobile phones. All of their hardware, software, and IT-Infrastructure is created in-house, and I had the pleasure of using their product upon visiting their office. According to Leretaille, the use of Wi-Fi in such scenarios is ill-advised:

“At its core, the debacle at Lockstate reflects one of our major issues with IoT products today – simply placing a Wi-Fi chip inside of an existing product (in this case, a code lock) and referring to it as ‘smart’ doesn’t mean that it actually is. Generally, we feel that it is dangerous to expose a device like a lock over WiFi, as an attacker could brick all the locks in the system, or reset the codes to be the same. This is why our access management system does not use Wi-Fi.”

Leretaille further questions the absence of backups in anticipation of product failure:

“We also see that there was no backup strategy or fail-safes in place for such an issue, which a hacker might also replicate successfully. We allow our users to store two versions of our firmware on the same device, so if one does not operate correctly, they can revert to the other. If companies in this segment continue to treat security as an afterthought, it is inevitable that a script-kiddie will one day unlock thousands of doors at once from afar for fun.
Too many companies do not care about long-term support, reliability, or security, and this creates distrust in society. It casts a long shadow on the market. Almost every ‘smart lock’ we have seen has had big security flaws, and is easily compromised.”


The scenario reminds me of the woes for numerous pet owners last year when connected company PetNet experienced difficulties with their automated pet feeder. The Petnet is a smart pet feeder with features including “intelligent sensor technology, learning algorithms, and processing power that assesses the dietary requirements of a pet” and a custom feeding schedule via a corresponding app with alerts to pet owners when their pet has been fed and reminders when food supplies are running low.

Unfortunately last August, Petnet’s third-party server service that the company rented from Google, was down for around 10 hours and did not have redundant backups. This situation resulted in outraged pet owners, especially those who were away from home at the time.

Inherent with connected hardware design are possible failure scenarios like problems with Internet connectivity, Wi-Fi, a residential blackout, remote updates, or the system needing a reboot/restart. Surely the possibility of product failure should have been anticipated in the design phase? Or does it negate the point of the connected product in the first place?

Let’s face it, a lockbox with a pin code that houses a physical key would be a lot less stressful for everyone concerned. Technology will never be infallible and these kinds of scenarios do little to compel products to the mainstream.

iot ,connected devices ,backup ,wi-fi

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}