Hacker News new | past | comments | ask | show | jobs | submit login
Reverse-Engineering Google Nest Devices (experimental-platform.tumblr.com)
115 points by jelveh on Jan 25, 2016 | hide | past | favorite | 84 comments



Then there are the Nest cameras, reporting everything you do to Google.

"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


I'm curious. How else would you implement a cloud-based recording service with image recognition? (EDIT: full disclosure, I work for Nest through the Dropcam acquisition)


> a cloud-based recording service

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.


> we'd prefer a device that allows us to send its signals to a server we own and operate

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?


> [Do] 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.


Definitely wishful thinking. Anything consumer oriented will be forced to the cloud and use proprietary protocols.

There simply aren't enough of us who want control of our own data to make a difference.


I don't know why the comment is being downvoted. There is a bunch of people that want what you want, it's just that, as you are saying, is a bit of a pipe dream right now. The way technology is progressing, it might be feasible in a few years.


why is it a technology issue? not that there's never gray area, but this looks like more of a business issue than a technology issue. what's desired there (sending video to a server instance the user controls, instead of a third party vendor's servers) seems entirely feasible with current technology, though not necessarily profitable (or perceived as profitable) by the people willing to sell the equipment.


It's not just feasible, it's existed for decades and is used by security cameras that record to (usually on-premises) DVRs. There have been open source apps that do basically the same thing (detect motion, save video around events, etc.). With modern mobile GPUs you have ample processing power for running over-the-top machine learning algorithms. There is no technical need to violate privacy by default.


Right, it's the price point that changes a bit. You can make an argument that given enough money, you don't need to sacrifice privacy at all :)


The price point is fairly low if you are prepared to make a hobby of it: You can do the image capture with Raspbery Pis. (1)

The storage is slightly more expensive though.

1) http://blog.snapdragon.cc/2012/07/16/using-raspberry-pi-for-...


The problem with the hobbyist approach (and this is coming from someone who owns multiple Raspberry Pis) is that you most hobbyist don't really have the resources to tackle every engineering aspect of building a reliable camera. We have people dedicated to fine tuning the WiFi drivers in the device, writing scalable and secure video storage/streaming services, figuring out the thermal profile of every component in the cameras, minimizing noise in the camera CMOS and the WiFi antennas, making embedded software that will reliably reboot itself after a catastrophic crash... etc, etc, etc.

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.


...ultimately would you trust your home to something you can throw together in a few weekends?

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.


I'm the last person you'll hear using the "but think of the children!" tactic. American paranoia has been exploited for nefarious purposes long enough (I'm glad to say, I'd be surprised if you found any such message in the Nest Cam advertising campaign.)

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.)


> but ultimately would you trust your home to something you can throw together in a few weekends?

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.


It sounds like you want Zoneminder: https://zoneminder.com/


Depending on what you want to pay, what hardware/platform you want to use, and whether you're concerned about open source and other licensing, there are several options for NVR.

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.


There are those AIO DVR/Camera solutions that are fairly cheap and popular. All data is stored locally on the DVR and you can see it remotely via DynDNS or something similar.


Don't mean to be dismissive, but you should be careful about that kind of setup. A lot of those companies haven't taken security seriously. This article is a stark reminder of that: http://arstechnica.com/security/2016/01/how-to-search-the-in...


I bet quite a few people would be less annoyed about Nest and others if someone made a good alternative.

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.


I agree. The problem is that "boring" won't make money and "great" is too expensive. So "boring" has to be cheap (read: crappy) to work for the manufacturer.

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.


Yes, it generally seems that "dependable" isn't a very good value proposition for consumer devices anymore. And in the speicific example, the enthusiast market, that might care about having things locally, is a) small and b) seems to prefer to get the cheap stuff and fiddle with it


That's true, and the risk of providing that DIY.

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. :-)


Oh! Nice, I actually know a guy who works for Honeywell out of MN. He's in the Aerospace division though (just found out he's kind of a big deal... weird, I know him through my girlfriend's family and had never checked his LinkedIn page.)


That's kind of like saying "how would you make a car without wheels?". It could be that inherent in the idea of making object X are privacy concerns. The fact that the privacy concerns are intrinsic to the object just means that you have to call the whole object X into question when discussing them.

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)


Exactly! And I'm OK with people taking the stance "if it's not 100% private and my video needs to be sent over the internet, then I don't want the camera".

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.


What about doing all processing locally and storing only end-to-end encrypted data in servers?


Not really an option right now. The current generation of cameras out there are basically a Raspberry-Pi level computer with a better camera and a hardware h264 encoder. The moment you start doing something fancy, like running any non-trivial motion-detection algorithm, you are bound to run into performance or thermal (read: overheating) issues. Let's not even talk about machine learning.

Just think how much money Nest would save in server time with such a setup :)


My intuition says we are not anywhere near there yet, but do you know if any video processing algorithms exist that can reasonably be executed on encrypted data? Basically, I know fully-homomorphic encryption is ridiculously inefficient in the general case. At the same time, I know of specialized homomorphic encryption algorithms that can operate on encrypted data of specific formats. There are efficient-ish algorithms for encrypted (social-network-type) graphs, and encrypted vote ballots.

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.


I'm not really the person to answer that (I'm a lowly software engineer keeping the cogs greased m'lord!) I know at some point Larry (https://github.com/lwneal) was looking into that, at least cursorily. I'll refer to him as the authority on anything encryption-related at Dropcam (or anything, in general. Brilliant guy!)


Isn't HN supposed to be a forum popular with entrepreneurs? You sell the high-computation device as an optional extra.

    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).
(or something like that)

The idea that a remote network is somehow a requirement is patently absurd.


People overestimate the size of the hobbyist/geek market. Sure, in the Valley everyone and their dog can configure a NAS using a terminal from their latest generation iPad, but that's not the case outside of the Bay Area. I'd suggest you go to Sacramento and ask people on the street if they even know what a NAS or home server is (I once was dumb enough to start a startup there... you are one hour out of SF, but when it came to adversity to technology you might as well be in rural Alabama. This is the capital of California we are talking about!)

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.


> I'd suggest you go to Sacramento and ask people on the street if they even know what a NAS or home server is

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"?


> 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.


I see, Thanks for the insightful answer! Regarding machine learning it would be nice to be able do the training in your desktop/laptop when it's idle or something like that.

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 :)


Can you share any reference on what the Nest servers actually do that a smartphone chipset isn't capable of? Various apps manage (from my limited knowledge about the field) quite impressive things.


Can't really discuss specifics, but training machine learning models that share data between all your cameras would be pretty difficult, for example. Also, the lifespan of the processor would be highly reduced if you were constantly hammering it (thermal implications, etc. etc.) Again, in a few years that might not be an issue anymore :)


According to the Nest Cam website [1], the camera (without Nest Aware) offers the following features for customers:

- 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.

[1] https://nest.com/camera/install-and-explore/


Mea culpa: I used the term "image recognition" very haphazardly. What I meant to say was "the service provides a lot of features that are only possible through heavy analysis of the video."

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.)


Happy Dropcam/Nest owner here; y'all are doing a fine job.

If people based their product's features on product/market fit research from Hacker News threads, nothing would ever sell.


Thanks! We are constantly working to make the experience better. Of course there are issues every now and then, and we are still working on fully integrating all of the Dropcam technology into the Nest family of products, but we'll get there.


Recognition needs to be local (possibly in a box that plugs into a wall outlet and has one of the better ARM chips). Recording can be remote, but should be encrypted, with the key unknown to the cloud service provider. You set the encryption key by having your phone generate it, and your phone displays a QR code, which is shown to the camera once. You now have a shared private key, and can view video from your phone. You can only view video from your phone, or from other phones which have been paired in this way.


As a Nest employee can you confirm that Dropcam has been essentially abandoned by Nest? In the 2+ years since the acquisition, nothing significant has been released, and the Nest App is far inferior to the Dropcam app.

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


I can't really talk publicly about our roadmap (I'd love to, believe me.) I'll try to engage some of the marketing folks and point them to this thread.


Please do. My interaction with support has been laughably bad. I have a Dropcam that sends me a monthly warning that my account that's paid up for a year is due. I also have a Nest Protect that can no longer see my network because I have two APs broadcasting the same SSID. For the first one, customer service told me "ignore the emails". For the second one, customer service told me "permanently remove one of your access points"

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.


Please e-mail me on the account listed in my profile. I should be able to help with the first one (at least forward it to the right people.)

I'm really sorry about the bad experience.


Classic Google Support: Expect utterly rubbish service until you find the magic insider who can wake up the workers who care.

(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...)


Thank you.

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.


> with email and plaintext password

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.


> 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.

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


> Even HTTP Digest didn't require the password to be stored in plain text

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.


Right, edited.


If password X is hashed to Y, and you store Y that seems ok.

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.


I don't understand your point. Even if the client sends HASH(password), that effectively becomes the credential. That's where HTTP Digest is less successful (as was pointed out by a sibling and I went D'oh for not remembering).

> 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.


Salt.

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)

https://en.wikipedia.org/wiki/Forward_secrecy


Yes, there are many many more secure schemes out there. By minimum I meant minimum.

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.



Speaking of HTTP Digest, I like its concept, easy to implement and supported by all major browsers. Unfortunately MD5 is broken, I wonder whether there is a newer standard using SHA2 or BCrypt for example.


TLS client certificates are even easier, don't require consuming party (the server) to know private key at all, and are reasonably secure.

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.


HTTP Digest also makes HA1 (hash stored on the server) the credential, so if it were leaked, then you could still authenticate as the user.


SRP does not require the server to store either a password or a password equivalent.

https://en.m.wikipedia.org/wiki/Secure_Remote_Password_proto...


> you cannot operate the camera or switch your thermostat’s settings without Internet connection

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.


Well, you can't operate the camera without an internet connection. The only thing you can do is unplug it & plug it back in.

It's really irritating to use a Nest thermostat with no connection, either, since you can't set or control your heating/cooling schedule.


The camera is one thing... but from their perspective I could understand why they don't want it working locally.

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.


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.

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.)


> […] creating a walled garden around the user’s own data is a shady move. All of my private data should be easibly accessible to me though open API without any gimmicks. In its press release Nest promised introducing a public API[,] however [it] seems limited in many ways compared to the internal API used by Nest mobile app - and to add insult to injury - many of its features require an active Nest subscription.

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.


> When Google shuts down Nest, people are left with non-working thermostats, and have to spend money and rebuild their systems to continue on.

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.


Yeah I'm not sure where/how that started. A firmware update broke the battery charging, device died, and cut off the heat. That's a software problem, not a thermostat problem.

If you bought a Nest, and never connected it, that problem would have never impacted you.


> But this could happen with any device that is controlled by software.

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?


But this could happen with any device that is controlled by software.

Not devices that are designed to be independent and tested for proper function when disconnected.


I'm sure all of your code is bug free, right?


My code certainly doesn't rely on being able to contact an outside service to continue operating.


"This is not true. The Nest operates perfectly fine without internet."

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.


It's true. I have a Nest and it works without the 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.


> No, they are left with a normal programmable thermostat with a nicer interface than most.

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 I don't think you can edit the schedule.

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.


I just checked my v1 and I was able to edit the schedule but I have no way of knowing if I was editing my weekly schedule or making a 1-off correction. I'm guess it's the later and not the former because the change isn't reflected in the App.

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.


You can edit the schedule from the thermostat (at least v3 I think).

But scheduling interfaces are hard.


The Nest thermostat actually works without an internet connection. You just can't control it remotely without one (or get updates). If Nest vanished, we'd just have what many people currently have, a disconnected thermostat that is never updated.



I am surprised the Nest devices allow themselves to be man-in-middle'ed like this. Why are Nest devices accepting a random (valid) certificate? One would think they will only accept a valid Google certificate, signed by the Google root certificate.

Am I missing something? The article does not mention about any software tampering on the device itself.


This is a man in the middle on the mobile app, which relies on the certificates on the phone. You just need to add your phony certificate to the OS's trust store. It's an attempt to find any private APIs that the APP is using, rather than reverse engineering the protocol between Alphabet and the nest device.


I've also done something similar with Wireshark and a hotspot off my laptop to find out what API calls an Echo is sending to Amazon. I believe I could see the endpoints, but not the content.


The nest thermostat seems to use firebase.com API from my research.




Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: