Reverse-Engineering Google Nest Devices • Hacker News Board

Re: Reverse-Engineering Google Nest Devices

#21

Post by Animats » Mon, Jan 25, 2016, 7:55 PM UTC

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

Re: Reverse-Engineering Google Nest Devices

#22

Post by yalogin » Mon, Jan 25, 2016, 8:10 PM UTC

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.

Re: Reverse-Engineering Google Nest Devices

#23

Post by ljk » Mon, Jan 25, 2016, 8:27 PM UTC

kuschku wrote: post #11

> […] 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. Thi…

Precisely - https://twitter.com/internetofshit

Re: Reverse-Engineering Google Nest Devices

#24

Post by dguaraglia » Mon, Jan 25, 2016, 8:35 PM UTC

Animats wrote: post #21

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…

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)

Re: Reverse-Engineering Google Nest Devices

#25

Post by afandian » Mon, Jan 25, 2016, 8:44 PM UTC

dguaraglia wrote: post #24

Animats wrote: post #21

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…

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)

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)

Re: Reverse-Engineering Google Nest Devices

#26

Post by kapitalx » Mon, Jan 25, 2016, 8:56 PM UTC

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.

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.

Re: Reverse-Engineering Google Nest Devices

#27

Post by bhauer » Mon, Jan 25, 2016, 8:57 PM UTC

dguaraglia wrote: post #24

Animats wrote: post #21

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…

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.

Re: Reverse-Engineering Google Nest Devices

#28

Post by magicalist » Mon, Jan 25, 2016, 9:01 PM UTC

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…

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

Re: Reverse-Engineering Google Nest Devices

#29

Post by pfarnsworth » Mon, Jan 25, 2016, 9:05 PM UTC

dguaraglia wrote: post #24

Animats wrote: post #21

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…

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)

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

Re: Reverse-Engineering Google Nest Devices

#30

Post by dguaraglia » Mon, Jan 25, 2016, 9:06 PM UTC

afandian wrote: post #25

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)

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…

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.