Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reverse-Engineering Google Nest Devices

experimental-platform.tumblr.com

Post reply on HN
Print view View original

41–50 of 85 posts

Re: Reverse-Engineering Google Nest Devices

#41

Post by supergeek133 »

yalogin wrote: post #22

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.

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.

Re: Reverse-Engineering Google Nest Devices

#42

Post by supergeek133 »

bhauer wrote: post #27
dguaraglia wrote: post #24

Earlier quoted context omitted.

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 (lo…

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.

Re: Reverse-Engineering Google Nest Devices

#44

Post by supergeek133 »

eitally wrote: post #40
supergeek133 wrote: post #8

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

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.

Re: Reverse-Engineering Google Nest Devices

#45

Post by mikestew »

supergeek133 wrote: post #44
eitally wrote: post #40

Earlier quoted context omitted.

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, s…

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

Re: Reverse-Engineering Google Nest Devices

#46

Post by joosters »

dguaraglia wrote: post #39
banana_giraffe wrote: post #38

Earlier quoted context omitted.

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 acce…

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

Re: Reverse-Engineering Google Nest Devices

#47

Post by mikestew »

cptskippy wrote: post #18
jedberg wrote: post #12

Earlier quoted context omitted.

> 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 n…

> 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 desir…

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.

Re: Reverse-Engineering Google Nest Devices

#48

Post by dguaraglia »

bloomingfractal wrote: post #32
dguaraglia wrote: post #30

Earlier quoted context omitted.

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 with…

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

Re: Reverse-Engineering Google Nest Devices

#49

Post by bloomingfractal »

dguaraglia wrote: post #48
bloomingfractal wrote: post #32

Earlier quoted context omitted.

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 Ne…

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

Re: Reverse-Engineering Google Nest Devices

#50

Post by dguaraglia »

supergeek133 wrote: post #42
bhauer wrote: post #27

Earlier quoted context omitted.

> 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 (lo…

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...
Post reply on HN