Re:Wyze security incident update
by quatrefoil on Monday February 19, 2024 @12:24PM
(#39432280)
It's not even that: the quoted language doesn't even blame the library - it appears to blame increased load.
"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
by matthewcford on Monday February 19, 2024 @12:48PM
(#39432553)
Likely to be a multi-threading issue; my bet is the cache client wasn't thread-safe. I've seen this in some apps before and the solution was to turn off multi-threading while we debug the library that was causing the issue.
This is the answer!
> I'm taking exception to the lack of accountability.
I'll bet money that their statement was run through legal and stripped of all possible blamey statements.
> They could have chosen to own that, but instead they blamed everyone else. That's not a sign of a trustworthy service provider.
I agree. Companies need to own up to their fuckups, even with legal tells them that it can hurt. Because all companies will fuck up; how they handle it is the differentiator.
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 current level of usage (cold start is a normal part of software's lifecycle).
They could have chosen to own that, but instead they blamed everyone else. That's not a sign of a trustworthy service provider.