An article at The Electronic Frontier Foundation goes over a recent decision by the home automation company Nest to disable some of its customers' devices in May:
The Hub debuted in 2013 and was discontinued after Nest acquired Revolv in late 2014. One selling point was that the one-time payment of $300 included a "Lifetime Subscription," including updates. In fact, the device shipped without all of its antennas being functional yet. Customers expected that the antennas would be enabled via updates.
Customers likely didn't expect that, 18 months after the last Revolv Hubs were sold, instead of getting more upgrades, the device would be intentionally, permanently, and completely disabled.
The article also highlights the legal grey area for customers who attempt to keep their own hardware functional, due to "conflicting court decisions about the scope of Section 1201" (of the DMCA).
The EFF article links to a medium.com posting which goes over the experience of a user of the hardware in question:
On May 15th, my house will stop working. My landscape lighting will stop turning on and off, my security lights will stop reacting to motion, and my home made vacation burglar deterrent will stop working. This is a conscious intentional decision by Google/Nest. [...] Google is intentionally bricking hardware that I own.
Originally spotted at Hacker News.
Previously: Google Shows us the Future of Cloud-Dependent Home Automation
(Score: 2) by urza9814 on Friday April 08 2016, @03:07AM
Isn't that part of what UPnP is supposed to do? It's got protocols that allow a device to set up port forwarding for example. Although it has some pretty big problems too...
(Score: 2) by theluggage on Friday April 08 2016, @07:40PM
Isn't that part of what UPnP is supposed to do?
As I understand it, UPnP is just a helper for conventional port-based connections & has the disadvantage that the computers on your private network have to be able to configure your router/firewall, and it can be blocked by intermediate firewalls that you don't control.
What I was thinking of was more of a cloud-based message-passing & cacheing service (maybe with some cloud storage) that both "mobile" and "base station" applications initiated connections to via HTTP. I.e. similar technique as these server-dependent products use anyway, but with the "server" part general-purpose (so it could be an ISP service) and the application-specific logic on the base station.