8 ms·

There are numerous logistic issues with this approach. How would you implement a feature where users could log in to view the footage while away from home? They

by tensor 7y ago

There are numerous logistic issues with this approach. How would you implement a feature where users could log in to view the footage while away from home? They would need the decryption key, and if the server doesn't have it how would they get it? The only secure option is from the device itself, which is a pretty big UX challenge. However, worse, features that use AI to detect movement/people/etc can't be implemented without access to the underlying video stream. The only remotely viable way would be via homomorphic encryption, which has serious limitations still. It's far easier to do what they did, and just limit root access to a very small number of trusted people.

jerf 7y ago
"How would you implement a feature where users could log in to view the footage while away from home?" The "decryption key" can be a password-like object rather than an AES key, though that does require some security, and browsers are, if not quite ready to decrypt a stream and then render it as a video file, getting pretty close to that. However, any client provided to the user by the video company itself, web or app, has the risk of exfiltrating the key back up to the video company, and I don't think the market will support a video company where you have the inconvenience of being required to get a third-party client to use it. "However, worse, features that use AI to detect movement/people/etc can't be implemented without access to the underlying video stream." The hardware to do this locally isn't that expensive, but again, the market would have a hard time standing for it, because this is inevitably going to be more expensive than the competition.
- aratakareigen 7y ago
  The market can be easily scared by the thought of random employees spying on them. I'd easily pay $50 for that peace of mind.
- jahlove 7y ago
  > The hardware to do this locally isn't that expensive Wyze cams do "edge detection" AI in-camera, and those cameras are only $20-25. It seems to work pretty well to me. Although, the company that developed the AI is pulling out of the contract with Wyze. Nonetheless, it shows that it can be done cheap.
defanor 7y ago
> They would need the decryption key, and if the server doesn't have it how would they get it? Either carry it with them or enter a passphrase (for use with a key derivation function; I guess/hope that Ring requires some passphrase to view video via their website anyway). That's a rather common problem. As for "AI", depending on what you mean by that, it can be implemented in the device itself (unless it's something particularly fancy, requiring more resources than viable to dedicate there). It's indeed easier and slightly more convenient to not care about security, but that's also a general/common case.
ocdtrekkie 7y ago
Keybase seems to have a pretty good strategy for passing encryption keys between devices without Keybase itself having access to the keys. (I feel like this would be a great market for them to insert themselves into, possibly licensing their platform to IoT vendors.) But yeah, I imagine you'd have a passphrase/key that can be found on a new device, perhaps via a QR code, and then signing into a new client device would require you have access to the old device to approve it/allow the private keys to transfer between the two, etc.

by tensor 7y ago

jerf 7y ago

"How would you implement a feature where users could log in to view the footage while away from home?" The "decryption key" can be a password-like object rather than an AES key, though that does require some security, and browsers are, if not quite ready to decrypt a stream and then render it as a video file, getting pretty close to that. However, any client provided to the user by the video company itself, web or app, has the risk of exfiltrating the key back up to the video company, and I don't think the market will support a video company where you have the inconvenience of being required to get a third-party client to use it. "However, worse, features that use AI to detect movement/people/etc can't be implemented without access to the underlying video stream." The hardware to do this locally isn't that expensive, but again, the market would have a hard time standing for it, because this is inevitably going to be more expensive than the competition.

aratakareigen 7y ago
The market can be easily scared by the thought of random employees spying on them. I'd easily pay $50 for that peace of mind.
jahlove 7y ago
> The hardware to do this locally isn't that expensive Wyze cams do "edge detection" AI in-camera, and those cameras are only $20-25. It seems to work pretty well to me. Although, the company that developed the AI is pulling out of the contract with Wyze. Nonetheless, it shows that it can be done cheap.

defanor 7y ago

> They would need the decryption key, and if the server doesn't have it how would they get it? Either carry it with them or enter a passphrase (for use with a key derivation function; I guess/hope that Ring requires some passphrase to view video via their website anyway). That's a rather common problem. As for "AI", depending on what you mean by that, it can be implemented in the device itself (unless it's something particularly fancy, requiring more resources than viable to dedicate there). It's indeed easier and slightly more convenient to not care about security, but that's also a general/common case.

ocdtrekkie 7y ago

Keybase seems to have a pretty good strategy for passing encryption keys between devices without Keybase itself having access to the keys. (I feel like this would be a great market for them to insert themselves into, possibly licensing their platform to IoT vendors.) But yeah, I imagine you'd have a passphrase/key that can be found on a new device, perhaps via a QR code, and then signing into a new client device would require you have access to the old device to approve it/allow the private keys to transfer between the two, etc.