Comment by Lammy
3 months ago
Google have their own reasons too. They would love to kill off YouTube ReVanced and other haxx0red clients that give features for free which Google would rather sell you on subscription.
Just look at everything they've done to break yt-dlp over and over again. In fact their newest countermeasure is a frontpage story right beside this one: https://news.ycombinator.com/item?id=45898407
I can easily believe that Google's YouTube team would love to kill off such apps, if they can make a significant (say ≥1%) impact on revenue. (After all, being able to make money from views is an actual part of the YouTube product features that they promise to “creators”, which would be undermined if they made it too easy to circumvent.)
But having seen how things work at large companies including Google, I find it less likely for Google's Android team to be allocating resources or making major policy decisions by considering the YouTube team. :-) (Of course if Android happened to make a change that negatively affected YouTube revenue, things may get escalated and the change may get rolled back as in the infamous Chrome-vs-Ads case, but those situations are very rare.) Taking their explanation at face value (their anti-malware team couldn't keep up: bad actors can spin up new harmful apps instantly. It becomes an endless game of whack-a-mole. Verification changes the math by forcing them to use a real identity) seems justified in this case.
My point though was that whatever the ultimate stable equilibrium becomes, it will be one in which the set of apps that the average person can easily install is limited in some way — I think Google's proposed solution here (hobbyists can make apps having not many users, and “experienced users” can opt out of the security measures) is actually a “least bad” compromise, but still not a happy outcome for those who would like a world where anyone can write apps that anyone can install.
I would like a world where buying something means you get final say over how it operates even if you might do something dangerous/harmful/illegal.
I would like a world where I have the final say over whether I should have a final say.
One way to achieve this is to only allow sideloading in "developer mode", which could only be activated from the setup / onboarding screen. That way, power users who know they'll want to sideload could still sideload. The rest could enjoy the benefits of an ecosystem where somebody more competent than their 80-year-old nontechnical self can worry about cybersecurity.
Another way to do this would be to enforce a 48-hour cooldown on enabling sideloading, perhaps waived if enabled within 48 hrs of device setup. This would be enough time for most people to literally "cool off" and realize they're being scammed, while not much of an obstacle for power users.
9 replies →
You’re still proving the point above, which is ignoring the fact that the restriction is specifically targeted at a small number of countries. Google is also rolling out processes for advanced users to install apps. It’s all in the linked post (which apparently isn’t being read by the people injecting their own assumptions)
Google is not rolling this out to protect against YouTube ReVanced but only in a small number of countries. That’s an illogical conclusion to draw from the facts.
Its my device. Not google's. Imagine telling you which NPM/PIP packages you can install from your terminal.
Also, its not SIDE loading. Its installing an app.
Well... it would be good if this was true, but read the ToS and it looks more like a licence to use than "ownership" sadly :(
2 replies →
I agree, but I don't see why Google gets more critical attention than the iPhone or Xbox.
3 replies →
Yeah, let's ask the Debian team about installing packages from third party repos.
I'm not on the side of locking people out, but this is a poor argument.
15 replies →
The countries that go after Google are the first wave, they're applying these restrictions globally not much later.
The linked post is full of fluff and low on detail. Google doesn't seem to have the details themselves; they're continuing with the rollout while still designing the flow that will let experienced users install apps like normal.
A small number of countries now. The rest of the world in 2027 and beyond.
yt-dlp's days are fairly numbered as Google has a trump card they can eventually deploy: all content is gated behind DRM. IIRC the only reason YouTube content is not yet served exclusively through DRM is to maintain compatibility with older hardware like smart TVs.
Youtube already employs DRM on some of their videos (notably their free* commercial movies). if you try to take a screenshot, the frame is blacked out. this can be bypassed by applying a CSS blur effect of 0 pixels, permitting extraction; detection of DRM protection and applying the bypass is likely trivial for the kinds of people already writing scripts and programs utilizing yt-dlp. the css method of bypass has been widely disseminated for years (over a decade?), but programmers love puzzles, so a sequel to current DRM implementation seems justified. YT could also substantially annoy me by expiring their login cookies more frequently; I think I have to pull them from my workstation every month or two as-is? at some point, they could introduce enough fragility to my scripts where it's such a bother to maintain that I won't bother downloading/watching the 1-3 videos per day I am today -- but otoh, I've been working on a wasm/Rust mp4 demuxer and from-scratch WebGL2 renderer for video and I'm kind of attached to seeing it through (I've had project shelved for ~3 weeks after getting stuck on a video seek issue), so I might be willing to put a lot of effort into getting the videos as a point of personal pride.
the real pain in the butt in my present is Patreon because I can't be arsed to write something separate for it. as-is, I subscribe to people on Patreon and then never bother watching any of the exclusive content because it's too much work. some solutions like Ghost (providing an API for donor content access) get part of the way to a solution, but they are not themselves a video host, and I've never seen anyone use it.
> this can be bypassed by applying a CSS blur effect of 0 pixels, permitting extraction
That's not real DRM then. The real DRM is sending the content such that it flows down the protected media path (https://en.wikipedia.org/wiki/Protected_Media_Path) or equivalent. Userspace never sees decrypted plaintext content. The programmable part of the GPU never seen plaintext decrypted content. Applying some no-op blur filter would be pointless since anything doing the blur couldn't see the pixels. It's not something you can work around with clever CSS. To compromise it, you need to do an EoP into ordinarily non-programmable scanout of the GPU or find bad cryptography or a side channel that lets you get the private key that can decode the frames. Very hard.
Is this how YT works today? Not on every platform. Could it work this way? Definitely. The only thing stopping them is fear of breaking compatibility with a long tail of legacy devices.
Something I've never understood about DRM is, if the content is ultimately played on my device, what stops me from reverse engineering their code to make an alternative client or downloader? Is it just making it harder to do so? Or is there a theoretical limit to reverse engineering that I'm not getting? Do they have hardware decryption keys in every monitor, inside the LCD controller chip?
in short and simple terms, those parasites colluded with hardware manufacturers and put a special chip in your computer and monitor that runs enslavement software
without opening it up physically there is no way to make it stop or get the raw stream before it's displayed
1 reply →
Yes, the decryption happens in hardware. For your OS (and potential capturing software running on it) the place where you see the video is just an empty canvas on which the hardware renders the decrypted image.
All levels of Widevine are cracked, but only the software-exclusive vulnerabilities are publicly available. It's only used for valuable content though (netflix/disney+/primevideo), so it might still work out for YouTube as no one will want to waste a vulnerability on a Mr. Beast slop video.
The reason they have different levels is that the DRM pitchmen got tired of everyone making fun of their ineffective snake oil, so they tried to make a version that was harder to break at the cost of not supporting most devices.
Naturally that got broken too, and even worse, broken when it's only supported by a minority of devices and content, because the more devices and content it's used for the easier it is to break and the larger the incentive to do it.
If you tried to require that for all content then it would have to be supported by all devices, including the bargain bin e-waste with derelict security, and what do you expect to happen then?
Do you have any link? All the things I can find are about the 2019 L3 crack
1 reply →
Too bad that I'm going iPhone if Google removes sideloading and now I know about revanced so they aren't getting any more than the zero dollars that youtube and youtube music are worth from me
If I'm going to live in a walled garden it's going to the fanciest
I still don't get this mindset - all is lost, I am not going to do anything aboit that AND I will punish them by going with the even worse option!
If neither does what you want, you'll use other metrics, which often make ios a better choice. Simple as that
4 replies →
You would still be able to adb installs them. They wouldn't die.
Developers of these apps would have little motivation if the maximum audience size was cut down to the very few who would use adb. The ecosystem would die.
Or someone comes up with an easy adb wrapper and now it becomes the go-to way to install apps.
2 replies →
And how do you estimate the audience that even cares about those issues?
I think number of people caring about alternative app stores, F-droid or whatever is very similar to the number of people willing to use adb if necessary, so rather small.
1 reply →
Somehow I think having to use ADB instead of something like F-Droid with automatic updates would put a damper on things.
how many people ll do this though? i would expect sub 1% conversion from existing users if they had to do that