> Every Nanit user is uploading video and audio of their home/baby live to Nanit without any E2EE. It's a hot mic sending anything you say near it to the cloud.
Your way of phrasing it makes it sound like it would be fine to upload the video if it were end-to-end-encrypted. I think this is worth clarifying (since many don’t really understand the E2EE trade-off): E2EE is for smart clients that do all the processing, plus dumb servers that are only used for blind routing and storage. In this instance, it sounds like Nanit aren’t doing any routing or (persistent) storage: the sole purpose of the upload is offloading processing to the cloud. Given that, you can have transport encryption (typically TLS), but end-to-end encryption is not possible.
If you wanted the same functionality with end-to-end encryption, you’d need to do the video analysis locally, and upload the results, instead of uploading the entire video. This would presumably require more powerful hardware, or some way of offloading that to a nominated computer or phone.
Exactly. There is no video analysis if the video is encrypted and they cannot decrypt it. If there is E2EE and you expect them to do the video analysis, they need to be able to decrypt the video. Alternatively, you do it locally, but then why bother uploading anything at all, encrypted or not? So ultimately E2EE would not help here at all.
It's true. But nanit only gives you things like sleep insights if you buy their $200 stand and pay for a bigger subscription. Many users aren't making use of this. They do provide motion alerts, but those could happen on device.
Apple has done some interesting this with privacy-centric cloud processing. Might be some way to eventually get the benefits of cloud based detections without revealing your video.
also my other gripe is they also store audio. Which personally I feel like is even more sensitive. Wish their was an option to allow live audio listening but not store any audio in the cloud.
Then you’d have to trust that the option does what it says on the tin. My default for companies besides Apple is not to, too many scumbags have poisoned the well.
Technically there are two clients: The camera and whatever device is used to access the feed.
I can absolutely imagine an architecture where video can be streamed in an encrypted manner, or stored in encrypted time-stamped blobs, allowing the server to provide rough searching, and then the client can perform fine-grained scanning.
This obviously doesn't enable any kind of processing of the video data on the server side, and doing it on the receiving client would require the feed to be active This means that any kind of processing would almost necessarily have to happen on the sending device, which would probably increase the power and compute requirements by a lot.
Yeah, the entire point of this seems to be "we'll watch your baby monitor and provide alerts if something happens". That requires either processing on a server (as they do), processing on the uploading client (the camera), or having a receiving client which is constantly receiving that data and analyzing it to provide alerts.
The third option is unreliable because if that "client" (a desktop app, a phone app, etc.) dies, then the process stops working completely. The second option is unreliable because if you increase the cost of the camera then most users will buy the other camera because everyone is financially constrained these days.
That basically just leaves the first option as the only practical one at an appealing price point.
No, this doesn't get at the point of end-to-end encryption. Better to look at it in terms of the parties involved -- E2EE implies that there are two or more parties, and that only some of those parties should have unencrypted access.
In the case in point, the parent (camera owner) is one party and Nanit is another party. (Prior to the work in the linked post, AWS S3 was another party). The goal of E2EE is to deny plaintext access to some of these parties. So, in an E2EE deployment, Nanit (and AWS) would not have unencrypted access to the video content, even though they're storing it.
As chrismorgan pointed out, if Nanit did not have access to the unencrypted data, they could not do server-side video processing.
(Also, FWIW, there are multiple clients in this scenario -- the parents' phones are clients, and need unencrypted access to the video stream.)
(As an aside, where I used to work, we did some cool stuff with granting conditional access to certain server-side subsystems, so that the general data flow was all end-to-end encrypted, but customers could allow certain of our processes to be "ends" and have key access. This was really elegant; customers could dial in the level of server-side access that we had, and could see via the key authorization metadata which services had that access.)
> The video is privately analyzed by your home hub using on-device intelligence to determine if people, pets, or cars are present.
You can use a cloud provider's infrastructure without giving it access to your material. My devices generate the content, my devices do the processing and analysis, I consume the content. The cloud just coordinates the data in flight, and stores it at rest, all encrypted. It's possible but most companies don't bother because they have to put effort and their "payoff" is that they can't monetize your data anymore.
Your way of phrasing it makes it sound like it would be fine to upload the video if it were end-to-end-encrypted. I think this is worth clarifying (since many don’t really understand the E2EE trade-off): E2EE is for smart clients that do all the processing, plus dumb servers that are only used for blind routing and storage. In this instance, it sounds like Nanit aren’t doing any routing or (persistent) storage: the sole purpose of the upload is offloading processing to the cloud. Given that, you can have transport encryption (typically TLS), but end-to-end encryption is not possible.
If you wanted the same functionality with end-to-end encryption, you’d need to do the video analysis locally, and upload the results, instead of uploading the entire video. This would presumably require more powerful hardware, or some way of offloading that to a nominated computer or phone.