Earlier quoted context omitted.
The primary use case for a camera watching something that might get stolen is to provide proof of theft for insurance. In some cases it can provide clear evidence of what exactly was stolen, and in some cases information about who stole it. Unless the camera has lasers, it isn't very good at stopping said theft. ;)
Why would your insurance require a proof of the theft? That is not how insurances work usually.
Wyze security incident update
51–60 of 161 posts
Re: Wyze security incident update
#52Earlier quoted context omitted.
The primary use case for a camera watching something that might get stolen is to provide proof of theft for insurance. In some cases it can provide clear evidence of what exactly was stolen, and in some cases information about who stole it. Unless the camera has lasers, it isn't very good at stopping said theft. ;)
Why would your insurance require a proof of the theft? That is not how insurances work usually.
Re: Wyze security incident update
#53> The incident was caused by a third-party caching client library that was recently integrated into our system. This client library received unprecedented load conditions caused by devices coming back online all at once. As a result of increased demand, it mixed up device ID and user ID mapping and connected some data to incorrect accounts. That seems like enough of a line of bullshit to steer me away from ever using…
Re: Wyze security incident update
#54First of all, google "Wyze RTSP firmware". It's the official firmware from the vendor that enables the RTSP protocol. Now you can enable RTSP via the app and give the camera a fixed IP address in your DHCP server.
RTSP is a pretty standard protocol, so you can now view the feed via VNC player, record it 24/7 via ffmpeg, use tools like motion, etc.
The camera will still try to connect to cloud, but you can move it to a local-only Wi-Fi network, or outright block it from reaching the outer world on the router side.
And if you want advanced stuff (multiple streams, organized recording, etc), there is a plethora of free/open-source security camera tools (iSpy for instance). It all takes time to learn and configure, but you can have your own fully closed-circuit surveillance network, while still using the Wyze's rather cheap hardware.
Re: Wyze security incident update
#55Wyze cameras can actually be used very securely, as long as you bother to jump through some hoops. First of all, google "Wyze RTSP firmware". It's the official firmware from the vendor that enables the RTSP protocol. Now you can enable RTSP via the app and give the camera a fixed IP address in your DHCP server. RTSP is a pretty standard protocol, so you can now view the feed via VNC player, record it 24/7 via ffmpeg,…
Re: Wyze security incident update
#56Earlier quoted context omitted.
How so? I've seen caching clients exhibit some really weird behaviour under heavy load. It's not beyond the pale that, eg, the caching library doesn't do proper locking before writing, resulting in writes stomping all over each other. Caching is normally read heavy, not write heavy, so it's plausible it wouldn't be something you'd see much under typical operation. After an outage, they'd be dealing with a thundering…
Yes but either the library is seriously bugged (like, expecting writes to be ordered and screwing up things if it gets too many writes for different objects at the same time) or there was some serious bug in their implementation. Anyway the attitude and the message passed in the communication seems like handwashing to me. I might be too cynic, though.
Re: Wyze security incident update
#57This is the sort of thing that makes me salty that Unifi Protect is basically cloud locked in. No direct IP connection with "local" account support on the mobile app.
Re: Wyze security incident update
#58> The incident was caused by a third-party caching client library that was recently integrated into our system. This client library received unprecedented load conditions caused by devices coming back online all at once. As a result of increased demand, it mixed up device ID and user ID mapping and connected some data to incorrect accounts. That seems like enough of a line of bullshit to steer me away from ever using…
sounds like a hashing function with insufficient entropy. "increased demand" would lead to a higher likelihood of hash collisions.
Re: Wyze security incident update
#59Earlier quoted context omitted.
Do you think the issue was something else? "People randomly see other people's content" is an issue that would immediately make me think some issue with caching is the culprit. Given their openness in the rest of the communications, I don't see why they would make this part up. Edit: Of course, I'm also curious what the actual bug was. A discussion below is suggesting several plausible ways (e.g. concurrency issues,…
> Do you think the issue was something else? No, I'm not questioning whether or not it was a caching issue. I'm taking exception to the lack of accountability. They chose the library. They (probably) chose to ignore a documented or common failure mode of caching systems through either poor choice of key or lack of synchronization. They've obviously designed their infrastructure in a way that isn't resilient to its cu…
"As a result of increased demand, it mixed up device ID" - no, it mixed up IDs as a result of some sort of a concurrency bug. I don't understand the point of deflecting this far.
Re: Wyze security incident update
#60This is one of the reasons why you want end-to-end encryption wherever possible. Even a bad implementation with cloud-synced encryption keys (which defeats most of the benefits of e2e) would have stopped this. The response in this case (notifying customers and specifically stating whether they were affected or not) is excellent, but this seems to be a repeat of a previous incident from September 2023: https://www.the…
I wonder how many people would continue to so casually use these services if they understood that, for the most part, there is rarely proper end-to-end encryption of their data with these services. It is awfully disingenuous when these companies' marketing materials describe their services as "encrypted" when it usually just means there are two independent TLS pipes, which both terminate in their "cloud"; this surely…
Responses typically range from "I'm not that interesting" to "I really don't care". I think it's too abstract of a threat for most people to take seriously before it happens to them.