The only scripts I’ve seen still leave a giant empty box at the top… Are there any that fix this too?

Problem 2 also shows they have no double checks on access to private video feeds. Mixing up what’s being requested at any step and not reverifying anywhere after that point just reveals fucking terrible security practices.

No, this does actually sound like a solution. But it’s a solution that should be scattered all throughout the process, and checked at multiple steps along the way. The fact that this wasn’t here to begin with is a bigger problem than the “client library failure” as it shows Wyze’s security practices are fucking garbage. And adding “one layer” is not enough. There should be several.

To give a bit better context, which I can only be guessing at by reading between the lines of their vague descriptions and my first hand experience with these types of systems…

Essentially your devices all have unique ids. And your account has an account/user ID. They’re essentially “random numbers” that are unique within each set, but there appear to be devices that have the same ID as a some user’s user ID.

When the app wants to query for video feeds it’s going to ask the server “hey, get me the feed for devices A, B, and C. And my user ID is X”. The server should receive this, check if that user has access to those devices. But that server is just the first external facing step. It then likely delegates the request through multiple internal services which go look up the feed for those device IDs and return them.

The problem that happened is somewhere in there, they had an “oopsie” and they passed along “get me device X, X, X for user ID X”. And for whatever reason, all the remaining steps were like “yup, device X for user X, here you go”. At MULTIPLE points along that chain, they should be rechecking this and saying “woah, user X only has access to devices A, B, and C, not X. Access denied.”

The fact that they checked this ZERO times, and now adding “a layer” of verification is a huge issue imo. This should never have been running in production without multiple steps in the chain validating this. Otherwise, they’re prone to both bugs and hacks.

But no, they clearly weren’t verified to view the events. Their description implies that somewhere in the chain they scrambled what was being requested and there were no further verifications after that point. Which is a massive issue.

It doesn’t even need to go that far. If some cache mixes up user ids and device ids, those user ids should go to request a video feed and the serving authority should be like “woah, YOU don’t have access to that device/user”. Even when you fucking mix these things up, there should be multiple places in the chain where this gets checked and denied. This is a systemic/architectural issue and not “one little oopsie in a library”. That oopsie simply exposed the problem.

I don’t care if I was affected or how widespread this is. This just shows Wyze can’t be trusted with anything remotely “private”. This is a massive security failing.

Source?

I’ve read a lot on this and never saw any conclusive claim here.

There were claims many years ago by Mozilla about this, and it had to do with slow APIs in Mozilla that YouTube was using…

There’s also been many known performance issues in a lot of the APIs/libraries Google/YouTube use on Mozilla for many years. And Mozilla just hasn’t been able to keep up.

I don’t see anything about this in recent history, because everything is just floods of people complaining about this round, with still no conclusive evidence that this is happening intentionally. YouTube is currently on a ad-block-blocker crusade and their code keeps changing and there’s nothing to conclusively indicate that this is malice and not just a bug in the way Mozilla performs.

So as much as everyone seems happy to burn the witch because of poor performance, I’m not ready to jump to that conclusion until there’s actually evidence of this being intentional. Especially when this smells a lot like a long standing different problem. “Someone said they are” is not going to convince me. Especially if you can’t even point to that someone saying that thing.

Yeah, I don’t think people understand quite how astronomical an undertaking it is to replace this shit. People like to quote things like AWS, but AWS is a) expensive and b) general purpose. As such, it might be able to solve the problem, but not nearly as efficiently. It would cost you proportionally WAY MORE than Google is paying to keep YT alive, so that gives you an extra giant hurdle on top of the other complexity.

Web hosting with low latency is hard. Huge data storage is hard. Transcodinf is hard. Constant uptime is hard. Search is hard. Recommendations are hard. Making it profitable is hard. Starting an ad service that isn’t googles is hard. Convincing content creators to move there is hard. Convincing consumers to look there is hard. Sure, any of these problems have remotely comparable analogs. But you have to solve all of them simultaneously to get anywhere near competing with YouTube. And since Google owns the whole “stack”, it’s much cheaper for them then it’ll be for you.

Kick probably makes a decent comparison here. But they’re A) solving a subset of the problem B) fighting against a company that has extremely clear problems (arguably much worse than YouTube) C) is in a tech savvy-er demographic D) is funded by mega-casinos with tons of money and a vested interest in the product E) fighting in a market with less inertia so viewers and creators can move easier F) fighting twitch instead if YT which is smaller and younger.

And they’re still not really all that much competition.

There’s been multiple posts pointing to some possibly “wait for ads to finish loading” type code. It’s quite possible that it’s just bugged in Firefox etc since browsers are horrendously inconsistent etc.

But that doesn’t make a cool headline so instead the “it’s Google being evil” story is the popular one.

A bunch of these are also utter bullshit. “Purchase history” sounds like they can go through and read your Amazon purchases or something - they can’t. Diagnostic data sounds scary, but I’d rather use an app collecting diagnostic data because the alternative is a buggy mess. Them tracking what you do in their app is way more help than it is dangerous. Stuff like device ids and such are also likely only pulled for that reason or to confirm your purchases with them, etc.

The features of Twitter vs mastodon is close to 1:1, but Godot vs Unity is not even close.

The amount of time to learn to use Twitter or Mastodon is a few minutes. The amount of time to learn Godot or Unity is months getting going, and years to become an expert.

Twitter is something people use for entertainment and communication. Unity and Godot are literally people’s livelihood.

This comparison is just fucking awful. Your lack of empathy for people who have literally put months of man hours into projects based on existing tooling, business models, and licensing agreements, only to have a massive rug pulled out from under them is just pathetic. If you don’t feel bad, you’re a fucking asshole and that’s on you. Stop trying to justify it.

It’s not Chrome and it’s not through sync.

It’s Google Collections. Read the post.

Wouldn’t change the rules of Google Collections?

This isn’t a Chrome thing…