Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wyze security incident update

forums.wyze.com

Post reply on HN
Print view View original

21–30 of 161 posts

Re: Wyze security incident update

#21

Post by darkwater »

Twirrim wrote: post #12
twisteriffic wrote: post #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…

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

#22

Post by LeafItAlone »

sneak wrote: post #4

Nobody should ever be surprised that sending video to someone else’s computer (ie “the cloud”) results in third parties viewing that video.

It’s 2024. Everything is connected to the internet. Dropbox, Google, and Apple all offer multiple terabyte level plans. The default today is to store in the cloud. We are all storing data in someone else’s computer.

Instead of blaming the users, we must hold the companies responsible. Data privacy laws must be stricter and these incidents must be taken more seriously.

Re: Wyze security incident update

#23

Post by 15457345234 »

tgsovlerkhgsel wrote: post #8
twisteriffic wrote: post #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…

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,…

> I'm also curious what the actual bug was

Hardware. Rowhammer-type effects occurring accidentally under sudden load spikes. The hardware has just got too dense.

(I should clarify this is speculation, but reading the recent article included here on sudo using special maximum-distance bitfields to hold state internally (https://news.ycombinator.com/item?id=39165342)... it must be a problem that's being observed in the wild)

Re: Wyze security incident update

#24

Post by tripdout »

jasongill wrote: post #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 E…

Well obviously, and I think people can figure that out.

I actually appreciate the more specific details on how the private pictures and videos were actually viewed using terminology from the Wyze app.

Re: Wyze security incident update

#25

Post by jasonjayr »

LeafItAlone wrote: post #22
sneak wrote: post #4

Nobody should ever be surprised that sending video to someone else’s computer (ie “the cloud”) results in third parties viewing that video.

It’s 2024. Everything is connected to the internet. Dropbox, Google, and Apple all offer multiple terabyte level plans. The default today is to store in the cloud. We are all storing data in someone else’s computer. Instead of blaming the users, we must hold the companies responsible. Data privacy laws must be stricter and these incidents must be taken more seriously.

And if the companies do not want to be responsible, empower the users to run things on their own without lockin.

Re: Wyze security incident update

#26

Post by tgsovlerkhgsel »

15457345234 wrote: post #23
tgsovlerkhgsel wrote: post #8

Earlier 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,…

> I'm also curious what the actual bug was Hardware. Rowhammer-type effects occurring accidentally under sudden load spikes. The hardware has just got too dense. (I should clarify this is speculation, but reading the recent article included here on sudo using special maximum-distance bitfields to hold state internally ( https://news.ycombinator.com/item?id=39165342 )... it must be a problem that's being observed in t…

I can't imagine that happening with a sufficient frequency. A system making such mistakes so often would just be too unstable to keep an uptime >1h.

Re: Wyze security incident update

#28

Post by avg_dev »

tgsovlerkhgsel wrote: post #16

This 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…

Wow. That is decidedly not a good trend. Once is definitely bad enough, but twice…

Re: Wyze security incident update

#29

Post by NathanKP »

mistrial9 wrote: post #17
pylua wrote: post #6

Earlier quoted context omitted.

Device id and user ids are non unique?

hash collisions?

I'd bet it's this, plus something even stupider like hashing a connection timestamp millisecond as the "uniqueness" of the hash. I've seen a lot of terrible code implementations that assume that there will never be two clients connecting in the exact same millisecond

Re: Wyze security incident update

#30

Post by t8sr »

A little off topic, but how is it possible that a tech startup named itself “Wyze” and didn’t get sued by Google over the “Waze” trademark? In some accents it sounds exactly the same, and they’re sort of in an adjacent product space.
Post reply on HN