This is exactly one reason why using "Cloud" services for long-living things, like Hardware, is a great risk.
When Google shuts down Google Reader, we can all migrate to an alternative easily.
When Google shuts down Nest, people are left with non-working thermostats, and have to spend money and rebuild their systems to continue on.
Even worse, if just the internet goes down – not that rare in areas in the US only served by one ISP which doesn’t have to fear competition – one is even left without heating.
The reaction of the people on the recent case where Nest went down itself, and people were left without heating, fits well as context for the following excerpt from "The Sorcerers Apprentice" (1797, Johann Wolfgang von Goethe):
Herr, die Not ist groß! Sir, my need is sore.
Die ich rief, die Geister Spirits that I've called
werd ich nun nicht los. My commands ignore.No, they are left with a normal programmable thermostat with a nicer interface than most.
> Even worse, if just the internet goes down – not that rare in areas in the US only served by one ISP which doesn’t have to fear competition – one is even left without heating.
This is not true. The Nest operates perfectly fine without internet.
> The reaction of the people on the recent case where Nest went down itself, and people were left without heating
That's not exactly what happened. What happened was there was a bug in the software that had an issue when their server became unavailable. But this could happen with any device that is controlled by software. And even if they had a totally open and accessible API right on the device, this problem still would have happened.
I don't like the fact that they lock up the data, but we should probably try to stomp out the myth that the device is totally useless without their servers.
If you bought a Nest, and never connected it, that problem would have never impacted you.
Absolutely not. This kind of lazy, defeatist attitude towards failure is a huge problem in the software world.
There should have been checks that handled when the server (or anything else) became available with a contingency already in place to fail safely. Ideally, some of those checks should have been outside the area affected by software updates, such as in hardware.
As software moves into more and more areas that are traditionally thought of as hardware developers need to realize that in some areas bugs are not acceptable. Ever.
// sigh - do we need to get the terac-25 report out again?
Not devices that are designed to be independent and tested for proper function when disconnected.
I'll bet that's not true.
All of the QA and QC of the product goes into its fully functional, online mode and the ability to function offline is ignored at best and at worst, intentionally allowed to decay and malfunction.
I have a good example of this:
Sonos music systems, on paper, can run without an Internet connection. This makes good sense - why wouldn't they play local music shares connected over LAN, even when Internet access is missing, right ?
But go ahead and try it sometime ... it doesn't work at all. No doubt some infinite retry connecting to the license server or the auto-update system ... some wait state or blocking that nobody ever notices since they always have Internet.
The point is, it doesn't work. You should be very suspicious of the ability for any of these things to work without Internet.
Ehh... I don't think the Nest Thermostat is completely programmable from the hardware itself. You can definitely set temperatures and toggle between heat/cool, heat, and cool; but I don't think you can edit the schedule. Even if you could, I don't think I'd want to. The hardware's UI is beautiful but UX leaves much to be desired.
"The telescreen received and transmitted simultaneously. Any sound that Winston made, above the level of a very low whisper, would be picked up by it; moreover, so long as he remained within the field of vision which the metal plate commanded, he could be seen as well as heard. There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time. but at any rate they could plug in your wire whenever they wanted to. You have to live - did live, from habit that became instinct - in the assumption that every sound you made was overheard, and, except in darkness, every movement scrutinized." - "1984", Orwell
"Video and audio signals and data: When you enable the recording or streaming features of your Nest Cam, we may record and process video and/or audio recordings from the device, subject to your configuration and settings. This may include capturing and emailing to you portions of this data as part of a notification or analyzing the data to identify motion or other events. We may process information from your Nest Cam so that we can send you alerts when something happens. In addition, if you have the recording features enabled, we will capture, process and retain video and audio data recordings from your device for the duration of your recording subscription period (for example, 10 or 30 days) and you will be able to access those recordings using the Services during that time." - NestCam privacy policy, Google
Well, there's the rub, right? I think what those of us who consider themselves self-hosting partisans would say is that we'd prefer a device that allows us to send its signals to a server we own and operate. The recording and image recognition would then occur on that server.
In my ideal world, Dropcam (and later Nest) would have provided software I could install on my own server (located either on my home network or at a data center). I know that sounds like a far-fetched dream, but that's the ideal I want, and I will pay twice as much or more for devices that recognize the emergent demand for self-management.
I have a Dropcam, and I enjoyed using it for a while. But I stopped using my Dropcam about a year ago because I grew increasingly unhappy with the idea of its video stream being sent to an untrusted third-party (Dropcam and later Google/Nest). Since there is no "self-service" mode for Dropcams, it has become a decoration in my house.
Your question seems to suggest a sentiment like "there isn't any other way to do this, can you think of one?" but there is, and it's not to do it at all.
(I'm not taking a position on the Nest device, but this comment just seemed a little like a cognitive bias similar to anchoring)
- 24/7, continuous 1080p HD streaming
- Motion alerts
- Sound alerts
- Night Vision
- Talk & Listen
- Clear Zoom
- Quick, easy setup
- Nest App
- Software updates over Wi‑Fi
With exception of the HD streaming, Talk & Listen and the app, all of those are pretty basic features which I imagine could be run on the camera hardware itself.
Streaming and Talk & Listen could be implemented such that the video stream is directly routed to the app and the cloud only brokers the connection.
So, I don't understand, why operating a Nest Cam needs a cloud-based service with image recognition at all.
Nest Aware adds a recording service, which makes more sense in a cloud setting. But again, it's not clear to me why this is the only option and there is no way to store the stream, e.g. on a NAS instead.
As far as I can see, the page doesn't mention image recognition. Nest Aware supports face detection, but as far as I know, that's a feature that middle-class smartphones and digicams can do on local hardware. I don't see why you'd need a cloud service for that.
As well, the "customer suggestion" part of the Nest community board is a graveyard of suggestions and goodwill. It's literally a waste of time because nothing has been addressed, like simple things like access to year-over-year data instead of 10 days back which is worthless.
Signed,
An unhappy owner of 3 Dropcams
It's totally reasonable to transmit a password in clear if it's being transmitted inside of an SSL tunnel (which it is in this case).
Most if not all techniques that would allow for not transmitting the password in a server-decryptable fashion would require the password or a password equivalent to be stored in clear on the server.
In case of a breach, that would be devastating.
That's not true at all! SRP[1][2] allows the server to not have the plaintext password ever, even during account creation.
Kerberos' KDC doesn't know the plain-text password either[3].
Even HTTP Digest didn't require the password to be stored in plain text [4]. [Edit: though if you leaked HA1 that effectively becomes the credential]
Moreover, client TLS certificates would also fit the bill, as the client key is never transmitted.
Don't spread FUD if you aren't sure. If you don't know, don't say anything or say you don't know.
[1] http://srp.stanford.edu/ [2] https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco... [3] http://security.stackexchange.com/questions/15849/does-the-k... [4] https://en.wikipedia.org/wiki/Digest_access_authentication
As I understand it, it would still be required to store something that, if leaked, would allow anyone to create valid authentication responses? "HA1" effectively becomes the password, in that leaking it is as bad as leaking the password.
But if you directly check if the client transmits Y then Y is just the new password.
At a minimum you should be hashing whatever the client sends and comparing that with the hashed password.
PS: Not that most developers should do this by hand.
https://en.m.wikipedia.org/wiki/Secure_Remote_Password_proto...
This should say *remotely. I know it does in the paragraph before, but sometimes people only read bullets.
So is the complaint here I can't find out what data the device is sending back to Nest in whole? And contrary to the post, their Public API is pretty extensive.
Seems to me this is just another person with a concern around no local control/data retrieval. There is at least one other thermostat that has that.
It's really irritating to use a Nest thermostat with no connection, either, since you can't set or control your heating/cooling schedule.
As far as the thermostat, people don't edit their schedules that often really. Plus at least with the v3 you can do it on the thermostat. I don't know about the others, I assume not based on the comments.
Plus for others (Honeywell for instance) you can do it locally as well as remotely.
That being said, scheduling interfaces are SUPER hard to build where people understand them and it does what they want.
Am I missing something? The article does not mention about any software tampering on the device itself.