Reports from Nest Secure customers who are unable to arm/disarm or lock/unlock
twitter.com
twitter.com
Edit: typo
https://www.avclub.com/guy-reviews-his-offices-terrible-new-...
THE FUTURE
EDIT! fixed URL: https://imgur.com/f5evsOe
That being said, without the internet you do lose functions that obviously rely on the cloud like using your phone to adjust your thermostat, phone alerts that your house is burning down, unlocking your door from your phone, or disabling your alarm from your phone.
I'm split about if that's good or bad though. If they functioned without the cloud then the App would need to determine if it were on the local network or remote before attempting to initiate communication. There would probably also need to be an extra layer of host and client authentication.
The way the Thermostat and Smoke detector appear to work is by polling a remote service periodically for commands. This permits them to go into a sleep and preserve battery.
You could remove the cloud dependence by introducing a local hub that they could talk to instead which would permit the devices to remain unchanged but would introduce the added support complexity of a new device.
Alternatively you could have the devices remain awake listening for incoming client requests in addition to polling the cloud but that would be detrimental to their battery life.
The lease complex and most efficient way route is having the devices connect to the cloud.
I get that the internet is used for controlling the device remotely, but those of us that don’t need that feature still have to pay the price of bandwidth waste and round trip latency. Mind bogglingly bad design.
So you think the primary use case of a dropcam is for local live stream viewing? I would argue that's a boundary case at best.
I think there are pros and cons to both local and remote storage.
Streaming to the cloud is a much simpler solution. The device doesn't need local storage. The device doesn't need to run as a host to serve up streaming video to multiple clients. By removing storage and reducing processor needs and software complexity, you can make a much simpler and more reliable product.
By keeping storage remote, you're better preserving evidence from tampering or destruction.
AFAIK from reading the Twitters last night, you could still punch the numbers into your home locks and get inside. So the things just took us back a few years in terms of smart phone access, but the core device still works.
With Hue bulbs, if you can't control them due to not having your phone handy or LAN issues, you can always just flip the lightswitch off and back on to get them back at "normal" brightness and color. Again, it's not something that I run into often but if someone else is visiting and doesn't care if the lights are dimmed blue or whatever for movie watching, they can still use the lights as normal lights.
Got a window AC in a small room that I can control via LAN but again, it still has a regular remote and buttons on the front if that fails or I want to disable it.
The only things I typically run across in the consumer space that don't work this way are IP security cameras that depend on remote servers in order to work. The ones that won't just send an h.264 or MJPG stream over the LAN are forever off my list for this reason (as well as a dislike of recurring bills). But I at least understand why many people don't want to set up a NAS or spare computer running software to receive the feeds over their LAN so I get why they exist. I just don't particularly like them. I'll stick to IP cams on a separate local network that I can access remotely via VPN into my home network. If nothing else, I don't have to depend on anyone else's service and I don't need to expose some backdoor-ridden device to the WAN.
These choices Nest has made simplifies the SW stack, UX & provides for better security at the cost of mandating a physical fallback rather than a LAN fallback. You may see things differently but that doesn't mean these aren't valid engineering tradeoffs.
Well it sounds like tradeoffs that make the engineer's life easier.
Maybe they should actually tackle the harder challenge of getting their supposedly smart devices to work in a heterogenous networking environment.
That would be a real innovation.
I'm also unclear why you are claiming the only gains are in maintenance. Security is a real end-user benefit & having devices not allow arbitrary incoming network connections is a security choice. Similarly, arbitrating everything through the web results in a simpler, more reliable, enrolment process & makes it easy to add customer features like family control more easily, securely & reliably. These are all customer-facing advantages.
2 hours out of a year is still 3, almost 4, 9s of uptime. That's probably better than your home network/ISP.
I get it. You personally would prefer they traded off for supporting direct connection to your phone. However, that doesn't invalidate that there are legitimate engineering reasons someone might choose other tradeoffs.
I could totally understand why the Nest team wouldn't view it as a compelling product requirement. You need the cloud anyway because people regularly control the thermostat outside their home (e.g. to pre-warm/pre-cool when they're heading home). It's all the same infrastructure that's leveraged to run products beyond the thermostat (doorbell, security) that also have a compelling remote use-case. The isolated LAN approach could still require a cloud component for managing access. The C&C UX could become quite confusing trying to support both isolated LAN & cloud. If the cloud part fails you're no worse off than if you had a non-smart thermometer/doorbell with a good UX.
Now you could obviously have remote abilities without the cloud but the UX story becomes even trickier because you need to figure out how to rendezvous & punch through a wide variety of firewall configurations. These are all things technical users could solve given the appropriate settings exposed (eg. dynamic DNS) but it's totally unnecessary for the less technically minded users Nest is targeting (or even technical-minded users who don't want to care about managing every single smart device on their network).
The only reason these "smart" devices can exist is because the market hasn't matured and customers don't know any better.
A bit off topic, but I am hoping one day the always-on in-home server takes off for the average user so that my ability to expose my in-home server to the public internet is no longer a minority skill.
For the equivalent effort to implement, most customer's revealed preferences are for new/better features rather than robust local intelligence.
This kind of event just doesn't happen very often.
While it may not happen very often, I wonder how many customers (like me) they lose because the customers do not want their devices to even have internet access but still want local remote control (and are willing to sacrifice non-local remote control).
I guess ideally they would utilize a more localized protocol when you're nearby and then fall back to control->remote server->device when you're not.
(In case it's not clear, many of the reasons devices use cloud rendezvous have to do with NATs and firewalls and the difficulty of doing direct node-to-node communication in today's very fragmented Internet. Not all - some are security and complexity.)
Instead of your apps having to detect if they're local or remote to the device and then implementing a different protocol based on locality, they instead just always call out to a cloud based location.
They don't have to devote resources to maintaining 2 APIs for every product and can instead focus on reliability and robustness of the one interface.
> it's just a crap design from a usability standpoint.
I would argue the opposite. By having to support both cloud and local communication, you're introducing complexity and the possibility that APIs could diverge in functionality and reliability.
Either a cloud app is going to go out, or my home internet is going to go out. I don’t expect 100% uptime because I’m realistic, and expecting non-cloud infra devices with no time commitment is a pipe dream.
Plus, if your batteries run out, then you wouldn't be able to change the temperature anyway. You have far bigger problems than the device being online only.
I believe that's how Apple does it. The local host device is either an AppleTV, or an iPad.
All it takes is for Snake Farm to pay to find out how many times your smoke detector goes off. Or even if it doesn't fully go off, how often it senses anything.
With your thermostat data, it's possible to build a profile of when you're home and away. Hmmm... he seems to work an overnight shift. Better jack up his premium!
So in your case, better buy that smart device.
Companies already do: https://www.progressive.com/auto/discounts/snapshot/
In this case, Progressive gives you a discount in exchange for monitoring you.
But I've seen articles where other insurance companies (often in the UK for some reason) raise rates for things as seemingly innocuous as posting the wrong thing, or being "friends" with the wrong people on social media.
i don't necessarily care that much about that, but i do want such a product to work perfectly fine whether there's a connection to their servers or not.
Local connectivity seems to present all sort of silly issues that make the user experience a bit inconsistent. Heck, look at Chromecast, it works great about 90-95% of the time. That 5-10% of the time it doesn't work, it becomes a complete pain.
The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.
That said, were they... really not monitoring their service?
If only somebody told us that would happen!
An example(hypothethical) SmartFishtank which dispenses food to fish with pre-programmed schedules and monitors/adjust water temperature. Its connected to internet and can be monitored remotely. Users can even upload new feeding schedules. What happens if its hacked? Fish can be boiled, starved or overfed because SmartFishTank has control over the whole device.
In another corner there is a electronic fish tank with mechanical feeder that is set to one of 3 feeding modes. The fish tank monitors temperature and acidity, but cannot adjust it and only send a audible alarm or a SMS message. However whatever happens to the electronic components, they cannot harm the fish inside because its purpose is to just receive data.
I like automating or wiring up my home with connected devices, this outage is making me thing twice.
I have a few of these "smart" devices in my home, and they are assigned to an IP block that has absolutely no internet access. They have to be controlled internally, and are not allowed to phone home.
One of my next projects will be an open-source Alexa-like that runs completely in the LAN (unless you specifically ask for things like the weather).
It's definitely wise to think twice before making your home's basic functionality, like allowing the owner to unlock doors, depend on systems that require an internet connection.
I would just say to be careful whose devices you use. Do your research and understand that you're implicating not just your privacy, but your physical security, when you put remotely-controllable locks, blinds, etc., in your home. That's a position of high trust, and most home automation providers (possibly including Nest, but they're by no means the worst) aren't worthy of it.
A house burglar could effectively use these tweets as push notifications telling them to go rob some smart™ homes in their local rich neighborhoods.
For a night it turned into a regular lock.
My workplace was across the street from my house though so I had trouble with the GPS stuff on ifttt when I tried it a few years ago. Bah.
- Best case, even with a responsible implementation, you're introducing more variables than are necessary into a supposedly secure system. If one of your dependencies fucks up, your lock is exploitable.
- Worst case, you have a typical IoT device, where the "S" stands for "security."
- In _either_ case, you're likely still going to include a physical lock mechanism for keys as a backup -- so you're basically just increasing the attack surface (significantly, I should add) by doing this.
Smart locks are currently high-risk appliances, and I'm fairly confident that most others with a security background will agree with me on that.
Look at the Brinks CompuSafe hack in 2015. Anything which increases the attack surface of a device reduces the security. In that case, a USB port.
And that wasn't even made by the lowest bidding startup.
I know people that don't lock their doors because they don't want to deal with keys, or they forget to lock their doors all the time, or leave a key under a rock in front of their house.
For them, even a fairly insecure "smartlock" will be an improvement if it means they will actually use it.
Time and time again it's been shown that if you design systems that are hard to correctly secure or make significant compromises in the name of "security", they end up being insecure because people just won't use them or will actively seek ways around them.
You can't just handwave away issues like usability and pretend that you've designed the "perfect" system or something.
If you design a good/secure keypad lock but it doesn't give people an easy way to let their family member in the house when they are away, they are just going to give out the code, leading to less security overall. If you design a secure keypad lock without a tumbler, the first time the batteries die and the user is locked out of their house they are going to replace it with something that won't lock them out.
Usability needs to be a core aspect of secure engineering. And oftentimes a "technically less secure" option is better, because it's actually usable by normal people in most cases.
A 5-point harness is safer than your average seatbelt, but we don't use them because forcing every car to have a 5-point harness would just end up with fewer people using them.
These are all problems we have solved for years before without the technology so there are established ways of handling the situations. Adding complexity and a different way of doing things actually makes it harder and riskier.
Coordinating how to use a smart lock between two people is harder than it looks.
On many occasions I was able to get a call from a family member to let them in, and there were many hundreds of times that I was able to lock or ensure the door was locked after I left the home.
I really feel layering is the ideal way to achieve this, as it means that any "smart" capability is easily disabled if found to be a problem, and we know that the underlying system is sound.
In my case I use a deadbolt that has a keypad, and they separately sell a zwave plugin for it that gives me local control, then I layer on an open source "gateway" that gives me control and notifications when away from the house.
If the gateway fails or is untrustworthy, I turn it off and the rest still works. If the zwave is found to be faulty, I pull it out and still have a functioning lock.
And until major vulnerabilities are found in any part of the "smart" add-ons, or until my lock starts unlocking on its own, it has greatly increased the security of our house, as well as increased my quality of life. No more getting out of bed at night to check that the door was locked, no more turning around to lock the door because I forgot when I left, and it was great when I was showing my last house as I could enable/disable the codes when I wanted, and get notifications when people came and left.
I'm not saying all new tech is good, just that this fear that "smart" (read "connected") is a bad thing inherently, and that the "traditional" ways of doing things, while perfectly fine for many, are not a panacea which can't be improved upon. The steam engine was great, the ICE was better, today's hybrid extremely-efficient engines are still better. Sure it's gotten more complex, but also significantly safer, easier, more resilient, and more powerful. In other words, complexity should be managed, not forbidden.
In the end, it's your decision, but the OP's comment stands fully: all the same attack vectors still exist, along with a bunch of new ones at the expense of convenience.
Only if you distribute the “do not duplicate” key, but the whole point is to not do that.
https://www.homedepot.com/b/Hardware-Door-Hardware-Door-Lock...
AFAIK, most code-based locks include a physical lock cylinder as a backup.
While this isn't an indicator of the quality of newer brands specifically, I believe it's reflective of the state of the industry as a whole -- in that digital physical security as a whole is still immature and shouldn't be trusted to keep bad guys (determined adversaries) at bad.
A lock that can be bumped isn't very secure. A lock that can be bumped or it's code discovered via some kind of power-monitoring attack isn't any less secure. But one without a keyway that can be attacked via power-monitoring is more secure in my opinion.
Everything is tradeoffs, and physical security is no different. Don't let perfect be the enemy of good here. If you are in the security industry, you should know that "bad" security that people will use is better than "good" security that people won't.
If a "smart lock" means I forget to lock my door less, I can monitor and record those who go into my house, and I can get alerts if the door is opened via any method, I'd call that a win even if there were pretty significant vulnerabilities that allowed an attacker physically present to get in.
There are some gotchas (make sure you get a zwave-plus lock that incudes the AES security stuff), and you need a dedicated "hub" to communicate with it, but they are rock solid in my experience
The Nest thermostat would still be an attractive, interactive thermostat with a color screen and tons of features. Without an internet connection, the $250 thermostat doesn't turn into a brick, it turns into a $150 non-connected thermostat.
The Nest Protect smoke detector still alerts you to fires or carbon monoxide, with voice warnings, and a lighted path at night. Without an internet connection, the $120 detector doesn't turn into a brick, it turns into a $40 non-connected talking smoke/CO alarm.
The Nest smart deadbolt still lets you lock and unlock your door with either a key or a PIN code. Without an internet connection, the $280 smart deadbolt doesn't turn into a brick, it turns into a $100 keypad deadbolt.
People lose their internet connections for all kinds of reasons, and the majority of smart home devices you can buy continue to be premium devices in that state, better than the basic thermostat/detector/lock/light/etc they likely replaced.
Home assistant is open source, written in Python, has a web based UI, and integrates with everything under the sun and is VERY welcoming to new components from outside people.
I've contributed 2 so far, and I hope to have another that adds in daily electricity monitoring from my local power company ready soon.
Hass is quite possibly the best run open source project I've ever been involved in.
That being said, I think regular passcode locks without internet connectivity do add a convenience since you don't have to carry a key.
I prefer to create users, authorize, delete them than rekeying the lock every once in a while.
403 Your client does not have permission to get URL / from this server. (Client IP address: 84.131.XXX.XXX)
(That is a standard German Telekom IP, usually Google only acts up when I do anything funny.)
[0] https://news.ycombinator.com/item?id=17091962
(I got google to translate, still no luck with translate.google.de )
On the other hand, it's probably no more inconvenient than locking yourself out, something that happens every now and again for anyone. Except you don't have yourself to blame, but Nest.
I'm also looking at Alexa and the stupid plug someone got me for a gift. Sure, I use it "Alex turn on the lamp" but I know that the system is totally unnecessarily dependent on the internet and two distinct companies for that to work. I would never have purchased such nonsense for myself.
People in tech have strange ideas about what it means for something to work acceptably.
> On the other hand, it's probably no more inconvenient than locking yourself out...
It looks like local control (i.e., with physical access) wasn't affected, so the only convenience lost was remote access. Not great when you've bought the product specifically for that feature of course, but still much better than locking yourself out.
But yes, that's the risk of relying on a system as unreliable as the internet for such a task.
Meanwhile I have never regularly used a web service that didn’t have at least one outage.
It's just annoying that there's no middle ground between "hold my hand with a cloud service" and "I want to spend a little effort to not be 100% reliant on external services"
Google could decide to fold Nest service entirely (luckily there aren't signs of that) and at this point you'd have thousands of thousands of devices in a landfill. It's so irresponsible. Historically you could have a CCTV setup running for 10-20 years without huge issues.
>I suspect there are now modern, IP cameras that aren't cloud reliant
It's surprisingly limited and still a bit expensive. Foscam/Hikvision have been getting better, but it still feels a few years behind when it comes to firmware... and the notification and advanced "human detection" are obviously better with a cloud service.
Still, this is the problem with all cloud based home automation platforms.