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