Comment by landr0id | Hacker News Reader

Comment by landr0id | Hacker News Reader

This looks more like negligence than malice. In order to send the push notification you have to send the content to a server that then gets pushed down through say Apple's Push Notification Service. The doorbell cannot talk directly to your device. The notification contains the image and whatever other text and metadata shown.

I'd imagine that what they mean by "planning to encrypt" this content is to E2EE the content and register a notification extension (something like: https://developer.apple.com/documentation/usernotifications/...) that transforms the content once received by the client.

As most people probably know, E2EE isn't a simple problem to do in a user-friendly way. Perhaps when setting up the app/doorbell the doorbell could have some certificate that the app is aware of that's used for encrypting the data before it leaves the doorbell, and decrypted using the app's private key but this obviously isn't something provided out of the box.

Obviously a warrant could be served to Apple/Google/Eufy for notification content, but I don't take this as being particularly nefarious.

It genuinely wouldn't surprise me if other offline doorbells like Ubiquiti's UniFi line were also affected.

*I should probably mention I wrote this comment after reading a different article/video but didn't catch that their marketing mentioned that everything is E2EE. So yeah, seems like a pretty glaring lie in that regard.

The issue is that Anker said the footage was e2e encrypted. If they needed to be able to decrypt it to send notifications, they shouldn't have advertised it as providing end-to-end encryption.

If something is E2EE it is deeply inconvenient and fragile. If something is easy to use, it cannot be E2EE.

Another fairly good rule of thumb is that any product specifically marketed based on privacy fears is probably snake oil.

Not sure how that changes much here. You know this, I know this, the average Joe without much tech knowledge does not.

> If something is E2EE it is deeply inconvenient and fragile. If something is easy to use, it cannot be E2EE.

The only difficult part of E2EE is establishing trust. As in: how do I securely exchange encryption keys with this other entity in a way I know isn’t being spoofed?

The online banking I do all the time is E2EE from my device to my bank and it’s convenient and not fragile at all. I message friends over iMessage and there’s nothing inconvenient or fragile about that.

If a developer can’t put together a solution that’s convenient and robust, it’s likely due to lack of experience, not anything inherent to E2EE.

I respectfully disagree.

E2EE is often difficult because it involves 2 or more parties at either end. You must exchange keys in some secure way and that should occur over a P2P/alternate channel. That is really hard to do when you're not in physical proximity.

In this case, you own both sides _and_ it's likely that both devices will be on the same network to connect P2P. Many of these wifi devices handle initial setup with a device2device connection that then does the Wifi hand-off.

You can exchange keys securely over an untrusted channel.

https://en.m.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_e...

That doesn't solve the problem of knowing if the other end is who they say they are. That's why we have CAs, but those are an extra entity you need to trust.

IoT companies lie all the time, and when they don’t lie they fail to implement proper security by some omissions or sloppy engineering. Either way, my opinion is that IoT as the industry is a complete clusterfuck.

Just an anecdote. I’ve reverse engineered a cat feeder with a camera some months ago. It did not claim any local storage, but it happily claimed all the standard bullshit about having the “military-grade” secure encryption. As a matter of fact, for whatever reason, they chose to not encrypt P- and B-frames, only I-frames (and audio). I’m not really an expert on video encoding but even I immediately understood that this is absolutely a bad idea, as all the motion vectors are right there in plain for whoever has access to the recording in the cloud (or wherever the appliance is told to upload, any S3-compatible storage works). Still, I don’t think it was malicious, just some engineer somewhere being very ignorant or not caring about the product (or probably both). They’ve been told to throw in encryption, they ticked that box.

Now, the thing is, it seems to be based on a couple SDKs (a mix of Tyua and Goke stuff) that’s used by millions of devices - not just pet feeders but security and nanny cameras too. And while I don’t know for sure because it’s the only device with a camera I’ve worked on, I kinda doubt it’s a design error unique to my particular device or vendor.

And I’m very sure it’s not an isolated incident. I had RE’d other devices that were using other SDKs and while none of the devices had any PII (like a video feed) because it was mostly lights - I have seen a lot of very sloppy engineering. Just that blast radius of a smart light is smaller so I had cared less.

I wouldn’t trust any camera on the market unless it’s either vouched for by some hacker, or if manufacturer would explicitly recommend setting up a dedicated isolated VLAN for it, in a way it is never able to talk to anything outside my LAN.

It might be difficult, but it's possible to send encrypted push notifications as you mention, and you don't get to make the E2EE claims until you actually do it. I don't think UniFi or most other cameras claim anything like Eufy did.

Fair point that their marketing explicitly says this stuff is end-to-end encrypted. Seems like an obvious gap in validation/coverage of their network comms.

Reply on news.ycombinator.com