Reverse-Engineering Google Nest Devices
experimental-platform.tumblr.com
experimental-platform.tumblr.com
"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
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)
You can either have a camera that keeps a safe copy of your video in the cloud and detects unexpected activity happening in front of your camera, or you can have one that is 100% private and doesn't upload video to the cloud. You can't have both. At least not without having a huge setup in a secured room inside your home.
I understand the privacy concerns, I just argue that you can't have the ideal service without getting over them. At least not with current technology, and probably not without the right economic incentives to build a stand-alone system.
Just think how much money Nest would save in server time with such a setup :)
But it's very good to know this is a technological issue (as opposed to a business issue). Well, hope you smart folks solve this. Meanwhile, I'll keep tinkering with my raspberry pi and raspberry pi camera :)
I was wondering if you or anyone in your team has come across any work on privacy-preserving encrypted audio/image/video processing? I assume this is a very hard problem, but I imagine someone has tried looking into it.
For full privacy, buy our turn-key home server!
(optional video display available)
If you're the DIY technical types who already
runs a home server, may prefer our inexpensive
software package that provides most of the features
at much lower cost (some assembly required).
The idea that a remote network is somehow a requirement is patently absurd.
Providing these "geek-to-geek" options (term isn't mine) looks like a great business idea when all your friends would use it. But again, the financial incentive is not there if it takes equivalent (or even less) effort to design something that can be used by millions of people instead of hundreds of thousands.
Does Woodland count? I'll ask a few people.
/me steps outside
Well, my landlady and a few neighbors know what they are. You'll have to wait until tomorrow for Sacramento, but I've talked to a lot of people in that area too and very few would have had a problem with my addon server.
If you treat people like idiots, they will respond in kind.
> "geek-to-geek" options
I may have included a geek option (the source code), but a turn-key server isn't any harder to setup than Nest's current devices.
You think people can buy and install Nest's current thermostats, but won't be able to install a turn-key local server that needs literally the same WiFi information?
> the financial incentive is not there
Is this a euphemism for "cannot monetize their data"?
I find it fascinating that people keep obsessing on how Nest is "monetizing the user's data" through Google.
I won't go into details, but believe me when I say there's way more effort being put in guaranteeing customer privacy than in integrating Nest data into Google's platform. In fact, if you Google around you'll find press announcements describing, in much more detail than I could go here, the kind of arrangement Google and Nest arrived at when the acquisition happened. The data separation clause was a huge part of it. Nest wasn't acquired for the consumer data they could bring over, but rather because... you know, biggest company in the (then booming) IoT sector. Investments on projected revenue are made all the time, but when Google makes one people cook up all kinds of theories about nefarious purposes ¯\_(ツ)_/¯
So, no. What I meant is there wouldn't be enough people buying this "expert" versions of Nest Cams to justify building them. That's all. If you have solid research to the contrary, I'm sure our PMs would love to talk to you.
> If you treat people like idiots, they will respond in kind.
That's a big assumption you are making about how I treated potential customers of my own startup that I put over a year and a half of effort in. It's not about "idiocy", it's just not the same crowd you have in the Bay Area, were store owners will gladly try anything to attract more customers. Leaflets and "neighborhood bulletins" are still a thing there, even when it gives you 0 visibility on how effective they are as a marketing tool and it costs thousands of dollars per month. Anyway, if you want the details, we can discuss them offline.
> You think people can buy and install Nest's current thermostats, but won't be able to install a turn-key local server that needs literally the same WiFi information?
It's not just the server, then you have to setup the camera to point it to the server, provide some rigging to make the video consumable, create credentials in the server if you want any kind of protection against MitM/Spoofing, etc. etc. etc. The very reason Dropcam was founded was because the CEO's dad, an EE, couldn't figure out how to setup one of those "expert" systems. Greg Duffy saw the potential business opportunity and went for it.
I understand if it's not the product you want. We don't pretend to be the perfect product for everyone. My personal opinion - not reflecting Nest's policy on this opinion at all - is that I'd rather sacrifice a 5% increase in sales than increase engineering/operations/marketing/sales effort a 15%. It's just bad business.
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.
There are lots of cameras that do that. You can even mix and match software and hardware making for real options, not just some vertically integrated service.
So is the rub that you think that such a device just shouldn't exist for anyone?
No. I apologize if that's what you took from my statement.
I hope the future sees technological evolution that makes it easier for common people to self-manage their devices. Presently, doing so requires more time and thought investment than traditional "cloud" options. For example, it took me a bit of time to set up a self-hosted NVR with a network of IP cameras. But in an ideal world, Dropcam-like devices would exist and provide an option during setup: "Do you want to use our video hosting service or run your own? If you choose your own, you'll need to install some software on a computer..." The Dropcam software is really well designed, it's just a shame I can't run it on my own server.
Like I said, it's idealistic wishful thinking. But if people want to use services hosted by third-parties, I don't want to take that option away.
There simply aren't enough of us who want control of our own data to make a difference.
The storage is slightly more expensive though.
1) http://blog.snapdragon.cc/2012/07/16/using-raspberry-pi-for-...
Don't get me wrong, every one of those aspects is a lot of fun to tackle on your own, but ultimately would you trust your home to something you can throw together in a few weekends? After seeing the amount of work these guys put, I probably wouldn't.
With respect to the massive engineering effort, and acknowledging you probably didn't even realize you were doing so, I have to point out that this is an example of the extremely distasteful emotional manipulation too often used by security-related companies, and it needs to stop. Advertisements with lines of the form, "Would you trust your family's safety with anything less," or, "Nothing is too good for your children's safety," contribute to the general paranoia of society, not to mention the gross misallocation of capital based on manipulation instead of merit.
Politics aside... it's your prerogative to buy or build any system you want. I was just clarifying why, in my personal opinion, if you really have a need for a security system, choosing a hobbyist project over a system built by a team of professionals is probably a bad idea (again, look for the article I linked before about how easy it is to "hack" into streaming baby monitors.)
More than I trust it to something that sends it over the internet to someone else's cloud over insecure channels, yes.
"trust your home" is somewhat misleading. The house won't fall down if the surveillance cameras are off. I've been in that home for years now without surveillance cameras and it's fine; I'd be a bit happier with some video feeds in various places but it will contribute to additional security: It's not all or nothing.
Also, wi-fi isn't the only or necessarily the best option to hook it up. I did mention that storage is harder that image capture now, but I believe that a Synology NAS or similar is the preferred approach. Multi-Terabyte HDs have gotten affordable.
The truth is that most of those come with the remote access features disabled, and when they are carelessly enabled by someone who doesn't know what they are doing this will happen.
But like I said, many of those systems out of the box only broadcast to the DVR locally.
EDIT: Since I see you're a Nest/Dropcam person, I'm a Honeywell guy. Haha. We can still be friends. :-)
From what I've seen there is a) fully cloud-enabled stuff, b) cheap china crap with security holes and c) "enterprise" solutions with prices and hardware demands to match. No-one makes something with the features of b), proper security and the price+polish of a).
There is quite a few "IoT" devices I want to like, but they come with (to me) unacceptable limitations.
Just to make it clear, I understand that this has similar development effort and Nest probably couldn't have done both at the same time. I just wish there were a few companies outside of the as-cheapest-as-possible spectrum that made "boring" consumer devices.
Unrelated, but I had a similar issue when trying to find a "dumb" TV: most of the high-end screens come attached to crappy software that you know will stop receiving updates 2 years down the road, and the cheap ones were super low quality. I got lucky in the end, but it took a few weeks of research to find the right balance.
I've only got minimal experience with Zoneminder but I've used iSpy (https://www.ispyconnect.com/) fairly extensively running on desktop computers and, later, on an old laptop repurposed as a NVR.
Later on I started using the "Surveillance Station" package that came with my Synology NAS. That's closed source and the version I'm familiar with came with licenses for two cameras and the ability to pay to enable more. However, if someone is less interested in extensive setup or doesn't have a suitable computer free for that use, it's a decent option, as are similar packages on other NAS platforms.
I guess in terms of finding a market with adequate demand, the NAS solution would be a good one. There are already models that are geared and pitched toward use as network media servers. I'd be curious if one of the bigger NAS companies might come up with a model that's targeted as a NVR.
The cameras are cheap and plentiful enough but many current consumer-grade network cams are either sold as "cloud" only or involve lots of potential security issues. Several offer DDNS routing as a way to check your camera feeds from outside the LAN but don't adequately explain the risks in opening a port to a device that may have several exploits available. Others tout their easy setup and compatibility with mobile apps but neglect to stress that you need to access them via a desktop application or web interface on a non-mobile computer in order to see the security settings, change default passwords, or otherwise configure them properly.
The end result is thousands of network cameras easily accessible to anyone with the right Google or Shodan search terms. Restricting a device to "cloud" only may solve these issues for many people who would rather pay a monthly fee to let someone else handle their data but I think there's a place for something in between.
A basic NAS with some storage and software similar to what we've mentioned offers the ability to connect multiple network cameras, store and manage recordings locally, keep actual cameras inside the LAN with no outside access, and also serve as a location for home backups and file server duties.
I'm honestly surprised that a hardware-oriented company, whether a NAS company or something more like Apple, hasn't marketed a line of simple home NASes with IP cameras as additional options for purchase. By selling their own branded cameras they would get more add-on sales from people preferring to get everything of the same brand and more enterprising users could easily add their own IP cameras as long as they use one of the common protocols.
It's nothing you can't set up already but people seem to like turnkey systems and I'd imagine there's a segment between "just pay a monthly cloud subscription and forget about it" and "I'll just set up this old PC in the closet and configure some open source NVR software".
I guess the question is whether people would even bother since the initial cost is higher than some Dropcams or even a dedicated CCTV system like they sell in electronics stores.
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
Please let them know that the "Product Suggestion" portion of the Nest Community site is an absolute insult to their customers. They should just shut it down instead of collecting years of requests and completely ignoring them.
Both responses are enough that I no longer recommend the Nest ecosystem for anyone. They clearly don't care about support, which is troubling for a company that's in the services business.
I'm really sorry about the bad experience.
(I'm not trying to be nasty to the employee who is being kind enough to post here, just pointing out that all too often, this seems to be the only mechanism to reach a useful human support contact for pretty much any Google service...)
- 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.
Have you considered the engineering effort that'd go in providing two different behaviors for the camera?
Let's say we decide to support the simplest case: FTP to your local NAS. How do you format the video for it to be consumable by a normal user? Filling your hard drive with thousands of small video files is not a great experience, so that's a problem. We could buffer as much as we can in-camera and then FTP a biggish (200mb) video file. Now that introduces a delay, because you can't really watch the video until you are done buffering, so no real-timish stream. So you have to come up with a third alternative that provides every other feature the online camera has, because users will complain if their offline experience is different.
Then again, your local NAS might be stolen by the same burglars that broke into your house, and the whole exercise was a waste of everyone's time.
Multiply that for each other possible combination ("I want Dropbox support!", "I want my files to be in an AVI container instead of MP4!", "I want the camera to have a SIM slot so it can send me SMS messages when there's a notification!") and you have a recipe for disaster. You get featuritis, lots of technical effort, and no actual financial incentive to do any of this work. Unless we sell a $700 camera, and nobody wants that.
As a small company, Dropcam had to draw the line somewhere. We didn't want to be the product that provided a solution for every requirement that came our way (and believe me, we've seen all of these before), but rather a good product for people that were happy with:
1) a product that worked as advertised (one day, a group of us were trying to setup a competitor's product: it took 4 engineers over half an hour before we gave up. This was supposed to be a "5 minute setup")
2) a product that evolved over time: running features in the cloud allows you to give new value to device owners without requiring a new device
3) trusting the company to have strict internal processes to avoid unintentional or malicious access to anyone's video (this was not treated lightly: a single case of anyone snooping on someone's stream could completely ruin the trust the users put on us.)
If people based their product's features on product/market fit research from Hacker News threads, nothing would ever sell.
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.
https://en.m.wikipedia.org/wiki/Secure_Remote_Password_proto...
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.
> At a minimum you should be hashing whatever the client sends and storing that.
That's a very narrow view of how to authenticate. SRP and client certs certainly don't work that way.
The point was what the client sends should not be what's in the database or easily reversible from what's in the database. I guess the larger point was you can't trust clients in any way shape or form.
In SSL/TLS, the data is transmitted using a one-time pad of some kind, so that intercepting a transmitted token gives you nothing that you can use to authenticate in a future connection (but you might be able to hijack the connection you intercepted, if you spoofed the server into thinking you are the intended client)
They are not working for end users, because no browser ever cared about those (UI/UX-wise), but I don't see any reason to not use those for automated access by IoT stuff. Generate keypair on-device, send a CSR, ask user to open browser and check if device's theirs (by comparing a conveniently formatted fingerprint - as a picture and/or series of dictionary words, not hex digits), sign and use if everything's good.
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.
I don't know if it's always been this way, but my V1 Nest let's me fiddle with the schedule on the thermostat. Kind of a pain with a rotating ring as your input device, but it can be done. (Assuming a firmware update hasn't broken this feature; haven't used the feature in well over a year.)
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.
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.
But scheduling interfaces are hard.
Second time I've seen this in this thread, so I walked over and checked our V1 Nest: yup, you can edit it on the device. And I rescind my earlier comment on usability: it's actually not that bad. Certainly easier than the programmable thermostat it replaced.
From my perspective it is pretty bad. While I could edit an entry in the schedule (e.g. move it, change temp range), I had no way to add or remove an entry in the schedule, had no idea what the original values were, how to cancel/undo, or know what I was editing without making a change. It was frustrating at best.
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.
Also, the Sonos can work without an internet connection. It requires a Wifi router, but not an internet connection once it has been registered.
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?
Am I missing something? The article does not mention about any software tampering on the device itself.