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

51–60 of 85 posts

Re: Reverse-Engineering Google Nest Devices

#51

Post by supergeek133 »

dguaraglia wrote: post #50
supergeek133 wrote: post #42

Earlier quoted context omitted.

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

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

Re: Reverse-Engineering Google Nest Devices

#52

Post by xg15 »

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)

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/

Re: Reverse-Engineering Google Nest Devices

#53

Post by lazaroclapp »

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…

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.

Re: Reverse-Engineering Google Nest Devices

#54

Post by arthur_pryor »

dguaraglia wrote: post #37
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…

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.

Re: Reverse-Engineering Google Nest Devices

#55

Post by dguaraglia »

xg15 wrote: post #52
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)

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…

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

Re: Reverse-Engineering Google Nest Devices

#56

Post by Lammy »

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…

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

Re: Reverse-Engineering Google Nest Devices

#57

Post by dguaraglia »

lazaroclapp wrote: post #53
dguaraglia wrote: post #48

Earlier quoted context omitted.

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…

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

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

Re: Reverse-Engineering Google Nest Devices

#58

Post by gohrt »

Retric wrote: post #6
jimktrains2 wrote: post #4

Earlier quoted context omitted.

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

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.

But don't pass on the salt! https://en.wikipedia.org/wiki/Salt_(cryptography)

Re: Reverse-Engineering Google Nest Devices

#59

Post by gohrt »

jimktrains2 wrote: post #9
Retric wrote: post #6

Earlier quoted context omitted.

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

Re: Reverse-Engineering Google Nest Devices

#60

Post by toomuchtodo »

dguaraglia wrote: post #55
xg15 wrote: post #52

Earlier quoted context omitted.

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…

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…

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.

Post reply on HN