...On the other hand, what happens when a company stops supporting a product but allows it to keep functioning afterwards...and at some point, the maintenance-mode device fails and hurts the user? One of the purported benefits of connected hardware is that a company can push out updates and fixes and users don't have to worry about paying attention (as much) to warnings and recalls when it comes to software.
When a product is initially released, users come to expect that support. If a company needs to shut down a product line and continued support...sure, ideally, users will pay attention and slowly migrate to new hardware when they can, just like people are still getting by with cars that have deadly airbags because they haven't had the time to leave their car at the shop...but as devices continue to have a feature set more dependent on the cloud and instant-push-updates...is there potential harm in letting a life-critical device function in zombie mode in such a way that it's good enough for months or even a year after the shutdown, but may be deadly sometimes afterward? The additional problem that connected devices add to the mix is that consumers have a hard time distinguishing between what features require the cloud and which features can work independently.
Obviously, there should never be the situation in which a critical device just dies as soon as the company shuts down its servers. Life-critical time-sensitive things, such as a heart pump, should thus be designed to operate independently, with connectedness being an optional feature.
But for other things, such as a smoke alarm...if a company designed it in such a way that connectedness is essential to its functionality, and that its usefulness in zombie mode can't be predicted a year down the road...can't it be argued that it's more responsible for the company to give the user a hard cutoff, rather than allowing the user the false comfort of zombie mode?
As someone in a different thread put it "It's not so much about the cost of the device as much as it's about the time invested in setting things up".
It's very poor form to sunset a product without offering users (your early adopters none the less) a easy migration path to another product. Had there actually been data standards for setup and captured data, I'd expect the ability to export my setup and data so that I can use it to configure an alternative product.
Oh no doubt, I think these instances are poor form, and in this young age of IoT, companies as big as Nest/Google should bend over a bit backwards for early adopters when it comes to sunset period and possibly even rebates...if nothing else than to treat them like loss leaders.
But later on, as always-on-devices are the norm...I do think it'll be more acceptable -- with the appropriate regulations and consumer protections -- to kill a device at the end of the cycle instead of designing it to operate as a zombie, in the same way that users accept that MMOs and other multiplayer-heavy games are heavily dependent on company servers...though in that case, it's easier to design a game to allow non-official servers so that the community can carry on after the official shut-off...but that's where the analogy of video game == important home device ends, of course.
You seem to be accepting the premise that these kinds of devices need to be connected or have ongoing software support in the first place. Why? A huge amount of Internet of Things junk seems to be normal equipment with an added dependency and a related added failure mode introduced for no apparent reason.
You're overlooking that bricking the device may be illegal. If it is to have an expiry date, it should be printed on the product - all radiation-based smoke detectors already have this.
Bricking the device remotely may be a criminal offence if it's not specifically permitted in the EULA. And if it is permitted in the EULA, that term may not be enforcable. And if it is enforcable, then all consumer reporting/review organisations should point advise you never to buy the product.
Certainly if one of my devices got remote-bricked I'd be taking legal action.
One problem with the IoT for consumers is that in many cases we're replacing devices that we're used to lasting many years, but vendors want them to have the lifetime of a smartphone.
We're still in an early adopter phase on a lot of it though, so it's hard to judge how it will play out.
Very strong point. so called dumb devices were designed to install and forget. A smart device will at least require soft/firmware updates. I fathom these will end with a lot of passive smart devices and a handful of active ones.
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.
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").
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...)
That's an excellent point. I have no problem purchasing a new phone every year, because I'm well-off and consider it a new toy (don't worry, I give to charity too!).
I recently replaced my old $15 thermostat with a $200 smart one. The old one lasted for a decade and a half (for $1/year), and is still completely functional; I really hope the new one lasts as long, but I really don't know that it will.
What I absolutely want to avoid is having to buy another smart thermostat in a year, or five years, or even a decade. Will I be able to avoid that? Probably not, but … we'll see.
I think the fundamental problem is that they are not really selling you a traditional product. They are actually selling you a service disguised as hardware with a one time fee.
You probably would think it'd be absurd if you had to pay your ISP $600 upfront for the 16MBit/s router model and then the ISP stopps the service after two years.
I'm working on building all of my own IoT (outlets, lights, sensors) using ESP8266's, Amazon Alexa, and a Raspberry Pi as the "hub". If Alexa gets deprecated, or I want to use some other voice control, I can (hopefully) easily swap her out with whatever is cool then.
Of course, this is cheaper in $$ but way more expensive in my own time. Fortunately I think of it as a hobby and not work.
Can you share more details on your work? I've wanted to build my own connected outlet for a while and if you have any pointers to resources on this, I'd love to see them.
This could be as simple as directly connecting ESP8266 GPIO to a solid state relay and programming ESP8266 to change the state of the pin in response to a HTTP post, e.g. [1]
Note that you should probably familiarize yourself with basic electrical safety rules when working with mains voltage, as well as fire safety. An intro to digital electronics would probably be a logical next step. Lastly, SSRs have an undesired feature of failing in connected state, so don't connect any loads that could overheat when plugged continuously.
I started down this route forever ago. Had a garage door opener with status and geofence, outlets, my own iOS app. It was fun but it was taking too long. I bought a bunch of z-wave outlets, switches, power strips, a thermostat, and a garage door opener. If my hub dies or the company goes the way of the dodo I can switch to another hub that supports z-wave.
Also, my hub has Echo integration for most things. I can't turn the heat up but I can turn off any light or light grouping.
In the end, everything works much better and I switched to building robots for the kids.
I really don't like all these IoT things. Modern software (except for Apple mobile devices) is full or bugs and vulnerabilities. So yesterday a hacker could break into your PC and see your files and tomorrow NSA or some bored teenager will be able to turn off the light and open the doors in your home.
And I don't like the idea of having critical parts of a device or infrastructure somewhere in a foreign country. Today "smart" phones, TVs or even cars send encrypted data over Internet to their manuacturers. How do you check they don't spy on you?
"Cloud" services have much in common with proprietary software: user cannot have full control over them.
> The key in doing so is communicating your decision to users in a clear manner... For example, [J Random Company] explained that customers’ devices would still work but would start losing functionality as partners, such as Pandora and Spotify, changed their code...
Which is it? "Communicating in a clear manner," or "keeping the servers running and not breaking people's stuff?" I would guess it's the latter, since Nest seems to have communicated pretty clearly that it's bricking people's Revolv devices. The lesson for "Internet of Shit" companies is completely clear: if you want happy buyers of physical devices, keep the servers running until the devices physically break. Yes, this will cost you a bit more money.
It seems the IoT community should push for manufacturers to provide up front guarantees that if they discontinue a device / platform they will open source the entire system for the community of users to continue as they wish.
That way first adopters will feel safe in their purchases no matter what the outcome.
29 comments
[ 3.6 ms ] story [ 88.6 ms ] threadAt the edges maybe a company disables a refrigerator -- or worse smoke alarms. At the core is bricking a medical device such as an insulin pump.
When a product is initially released, users come to expect that support. If a company needs to shut down a product line and continued support...sure, ideally, users will pay attention and slowly migrate to new hardware when they can, just like people are still getting by with cars that have deadly airbags because they haven't had the time to leave their car at the shop...but as devices continue to have a feature set more dependent on the cloud and instant-push-updates...is there potential harm in letting a life-critical device function in zombie mode in such a way that it's good enough for months or even a year after the shutdown, but may be deadly sometimes afterward? The additional problem that connected devices add to the mix is that consumers have a hard time distinguishing between what features require the cloud and which features can work independently.
Obviously, there should never be the situation in which a critical device just dies as soon as the company shuts down its servers. Life-critical time-sensitive things, such as a heart pump, should thus be designed to operate independently, with connectedness being an optional feature.
But for other things, such as a smoke alarm...if a company designed it in such a way that connectedness is essential to its functionality, and that its usefulness in zombie mode can't be predicted a year down the road...can't it be argued that it's more responsible for the company to give the user a hard cutoff, rather than allowing the user the false comfort of zombie mode?
It's very poor form to sunset a product without offering users (your early adopters none the less) a easy migration path to another product. Had there actually been data standards for setup and captured data, I'd expect the ability to export my setup and data so that I can use it to configure an alternative product.
But later on, as always-on-devices are the norm...I do think it'll be more acceptable -- with the appropriate regulations and consumer protections -- to kill a device at the end of the cycle instead of designing it to operate as a zombie, in the same way that users accept that MMOs and other multiplayer-heavy games are heavily dependent on company servers...though in that case, it's easier to design a game to allow non-official servers so that the community can carry on after the official shut-off...but that's where the analogy of video game == important home device ends, of course.
Bricking the device remotely may be a criminal offence if it's not specifically permitted in the EULA. And if it is permitted in the EULA, that term may not be enforcable. And if it is enforcable, then all consumer reporting/review organisations should point advise you never to buy the product.
Certainly if one of my devices got remote-bricked I'd be taking legal action.
This is the irresponsible part.
It's still not fixed.
We're still in an early adopter phase on a lot of it though, so it's hard to judge how it will play out.
Caveat: staunchly an IoT skeptic.
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.
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").
(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...)
I recently replaced my old $15 thermostat with a $200 smart one. The old one lasted for a decade and a half (for $1/year), and is still completely functional; I really hope the new one lasts as long, but I really don't know that it will.
What I absolutely want to avoid is having to buy another smart thermostat in a year, or five years, or even a decade. Will I be able to avoid that? Probably not, but … we'll see.
You probably would think it'd be absurd if you had to pay your ISP $600 upfront for the 16MBit/s router model and then the ISP stopps the service after two years.
Of course, this is cheaper in $$ but way more expensive in my own time. Fortunately I think of it as a hobby and not work.
Note that you should probably familiarize yourself with basic electrical safety rules when working with mains voltage, as well as fire safety. An intro to digital electronics would probably be a logical next step. Lastly, SSRs have an undesired feature of failing in connected state, so don't connect any loads that could overheat when plugged continuously.
[1] https://www.openhomeautomation.net/control-a-lamp-remotely-u...
Also, my hub has Echo integration for most things. I can't turn the heat up but I can turn off any light or light grouping.
In the end, everything works much better and I switched to building robots for the kids.
I know people have revived part of the network, I'm just too lazy to do all the work to revive it.
But I did run cat5 everywhere, and that has paid off nicely.
And I don't like the idea of having critical parts of a device or infrastructure somewhere in a foreign country. Today "smart" phones, TVs or even cars send encrypted data over Internet to their manuacturers. How do you check they don't spy on you?
"Cloud" services have much in common with proprietary software: user cannot have full control over them.
A search for "ios brick" suggests that your exception isn't much of an exception, unfortunately.
Which is it? "Communicating in a clear manner," or "keeping the servers running and not breaking people's stuff?" I would guess it's the latter, since Nest seems to have communicated pretty clearly that it's bricking people's Revolv devices. The lesson for "Internet of Shit" companies is completely clear: if you want happy buyers of physical devices, keep the servers running until the devices physically break. Yes, this will cost you a bit more money.
That way first adopters will feel safe in their purchases no matter what the outcome.