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

61–70 of 85 posts

Re: Reverse-Engineering Google Nest Devices

#61

Post by toomuchtodo »

nitrogen wrote: post #20
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…

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?

Re: Reverse-Engineering Google Nest Devices

#62

Post by nitrogen »

arthur_pryor wrote: post #54
dguaraglia wrote: post #37

Earlier quoted context omitted.

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.

Re: Reverse-Engineering Google Nest Devices

#63

Post by nitrogen »

toomuchtodo wrote: post #61
nitrogen wrote: post #20

Earlier quoted context omitted.

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.

Re: Reverse-Engineering Google Nest Devices

#64

Post by dguaraglia »

nitrogen wrote: post #62
arthur_pryor wrote: post #54

Earlier quoted context omitted.

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

Re: Reverse-Engineering Google Nest Devices

#65

Post by Animats »

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)

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.

Re: Reverse-Engineering Google Nest Devices

#66

Post by detaro »

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…

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.

Re: Reverse-Engineering Google Nest Devices

#67

Post by detaro »

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

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.

Re: Reverse-Engineering Google Nest Devices

#68

Post by JustSomeNobody »

bhauer wrote: post #33
magicalist wrote: post #28

Earlier quoted context omitted.

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

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.

Re: Reverse-Engineering Google Nest Devices

#69

Post by SideburnsOfDoom »

dguaraglia wrote: post #64
nitrogen wrote: post #62

Earlier quoted context omitted.

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

Re: Reverse-Engineering Google Nest Devices

#70

Post by pdkl95 »

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…

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.

Post reply on HN