Wyze security incident update
forums.wyze.com
Wyze security incident update
1–10 of 161 posts
Re: Wyze security incident update
#2> 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 wyze.
Re: Wyze security incident update
#3> We’ve identified your Wyze account as one that was affected. This means that thumbnails from your Events were visible in another Wyze user’s account and that a thumbnail was tapped. Most taps enlarged the thumbnail, but in some cases it could have caused an Event Video to be viewed.
Kudos to Wyze for doing the things noted in the thread like being honest and prompt with notification etc, but "thumbnails from your Events were visible... and that thumbnail was tapped" is a pretty mealy-mouthed way to say "another person saw your private pictures and videos taken with your Wyze cameras"
Re: Wyze security incident update
#4Nobody should ever be surprised that sending video to someone else’s computer (ie “the cloud”) results in third parties viewing that video.
Re: Wyze security incident update
#5There's a bunch of things in here that don't really make sense:
> 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.
What? How does load on the system affect correctness?
> The outage originated from our partner AWS
What does this mean? Was there an AWS outage for a service they use, or was this just a normal loss of an instance?
It's interesting that they blame external entities for the root causes of the incident and don't take responsibility for what is ultimately on them.
Re: Wyze security incident update
#6> 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…
Device id and user ids are non unique?
Re: Wyze security incident update
#7> 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…
Yeah I would very much likely to know what caching library has a failure mode of returning content for the wrong keys, that seems pretty bad if not a highly suspect explanation
Re: Wyze security incident update
#8> 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…
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, insufficient entropy in some key) how a problem could happen under load (although many of these would also lead to the problem happening with less load, just much less often).
Re: Wyze security incident update
#9I would have liked them going more into the details of the caching issue. It sounds like they think the cache library was responsible for the issue, but a more technical analysis of what exactly went wrong within that library would be great.
Re: Wyze security incident update
#10There's a bunch of things in here that don't really make sense: > 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. What? How doe…
> What? How does load on the system affect correctness?
Seen this happen quite often with code that is not multi-thread safe, especially in languages like c# and java, such as using a static class property for data that should be request-scoped, or not using the appropriate concurrent collection classes etc.