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.

I'm not sure I like the idea of "you have to wait 48 hours now for sideloading in case you are an idiot". Most idiots will then have sideloading on after 48 hours and still get hit with the next scam anyway.

You can sideload, I mean INSTALL, software on any linux desktop. Yet there are still tons of people saying that desktop linux has gotten good enough for most of everyone's grandma to daily-drive.

When everyone's Grandma is running Linux then the Indian scammers will know how to trick Grandma into thinking dmesg spam is "a virus" and just install this totally-not-malware, just like they do with the windows event viewer.

In other words, it's not any quality of Linux other than how niche it is.

The actual stopping power here is that any grandma who uses a Linux desktop has a family member (or other contact) who helps with technical matters. They've been educated about internet & phone scams, and will immediately call their technical contact when anything is suspicious.

It's an excellent example of the fruitlessness of technical solutions to people problems. Some people are just destined to get scammed, and it isn't worth throwing away General Purpose Computing to try to help them. Be present in Grandma's life and she won't be desperate to trust the nice man on the phone just to have someone to talk to. If it weren't this it would be iTunes gift cards, or Your Vehicle's Extended Warranty, or any number of other avenues.

These two solutions wouldn't work for me. My phone is covered, I use a custom ROM, but I like being able to help people install cool stuff that's not necessarily on the Play store, organically, without planning.

> which could only be activated from the setup / onboarding screen

Yea no. Now companies have to supply two phones, one for dev and one for calling. It is hard enough to get one...

> more competent than their 80-year-old nontechnical self can worry about cybersecurity

80-year-old nontechnical self can easily operate machines and devices that are much more complex and easily more dangerous than a smartphone.

And yet we're here pretending that those same people will install apps without even thinking about it.

Careless people are careless, we know that, we don't make them safer by treating everyone else like toddlers with a gun in their hands.

This becomes a problem when someone asks me for help with their phone and I want to point them to some apps from F-Droid to reduce their exposure to surveillance marketing.

Of course that's a side effect Google probably wouldn't be sad about.

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 :(

"Android" is really a lot of different code but most of it is the Apache license or the GPL. Google Play has its own ToS, but why should that have to do with anything when you're not using it?

Google doesn't own AOSP. We don't need any google apps on an andoid phone for it to function.

I agree, but I don't see why Google gets more critical attention than the iPhone or Xbox.

iPhone has always been that way (try installing an .ipa file that's not signed with a valid apple developer certificate). For Google forced app verification is a major change. Xbox I don't know..

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.

> Yeah, let's ask the Debian team about installing packages from third party repos.

Debian already is sideloaded on the graciousness of Microsoft's UEFI bootloader keys. Without that key, you could not install anything else than MS Windows.

Hence you don't realize how good of an argument it is, because you even bamboozled yourself without realizing it.

It gets a worse argument if we want to discuss Qubes and other distributions that are actually focused on security, e.g. via firejail, hardened kernels or user namespaces to sandbox apps.

"Debian already is sideloaded on the graciousness of Microsoft's UEFI bootloader keys. Without that key, you could not install anything else than MS Windows."

This is only true if you use Secure boot. It is already not needed and insecure so should be turned off. Then any OS can be installed.

I agree with you and run with it disabled myself, but some anti-cheat software will block you if you do this. Battlefield 6 and Valorant both require it.

This is the real malware that people should be protected from.

Now tell me how

Turning off UEFI secure boot on a PC to install another "unsecure distribution"

vs.

Unlocking fastboot bootloader on Android to install another "unsecure ROM"

... is not the exact same language, which isn"t really about security but about absolute control of the device.

The parallels are astounding, given that Microsoft's signing process of binaries also meanwhile depends on WHQL and the Microsoft Store. Unsigned binaries can't be installed unless you "disable security features".

My point is that it has absolutely nothing to do with actual security improvements.

Google could've invested that money instead into building an EDR and called it Android Defender or something. Everyone worried about security would've installed that Antivirus. And on top of it, all the fake Anti Viruses in the Google Play Store (that haven't been removed by Google btw) would have no scamming business model anymore either.

"... is not the exact same language, which isn"t really about security but about absolute control of the device.

The parallels are astounding, given that Microsoft's signing process of binaries also meanwhile depends on WHQL and the Microsoft Store. Unsigned binaries can't be installed unless you "disable security features".

My point is that it has absolutely nothing to do with actual security improvements."

I agree. It is the same type of language.

While it's possible to install and use Windows 11 without Secure Boot enabled, it is not a supported configuration by Microsoft and doesn't meet the minimum system requirements. Thus it could negatively affect the ability to get updates and support.

> It is already not needed and insecure so should be turned off.

You know what's even less secure? Having it off.

The name “Secure Boot” is such an effective way for them to guide well-meaning but naïve people's thought process to their desired outcome. Microsoft's idea of Security is security from me, not security for me. They use this overloaded language because it's so hard to argue against. It's a thought-terminating cliché.

Oh, you don't use <thing literally named ‘Secure [Verb]’>?? You must not care about being secure, huh???

Dear Microsoft: fuck off; I refuse to seek your permission-via-signing-key to run my own software on my own computer.

Agreed.

Also Secure boot is vulnerable to many types of exploits. Having it enabled can be a danger in its self as it can be used to infect the OS that relies on it.

Could you elaborate? This is news to me?

> Dear Microsoft: fuck off; I refuse to seek your permission-via-signing-key to run my own software on my own computer.

No one is stopping you from installing your own keys, though?

I do not want to be in the business of key management. This is not something that needed encryption. More encryption ≠ better than.

I also dual-boot Windows and that's a whole additional can of worms; not sure it would even be possible to self-key that. Microsoft's documentation explicitly mentions OEMs and ODMs and not individual end users: https://learn.microsoft.com/en-us/windows-hardware/manufactu...

> This is not something that needed encryption. More encryption ≠ better than.

Securing the boot chain protects against a whole range of attacks, so yes, it is objectively better from a security POV.

Name a single prevented bootkit that wasn't able to avoid the encryption and signature verification toolchain altogether.

Malware developers know how to avoid this facade of an unlocked door.

Users do not.

That's the problem. It's not about development, it's about user experience. Most users are afraid to open any Terminal window, let alone aren't even capable of typing a command in there.

If you argue about good intent from Microsoft here, think again. It's been 12 years since Stuxnet, and the malware samples still work today. Ask yourself why, if the reason isn't utter incompetence on Microsoft's part. It was never about securing the boot process, otherwise this would've been fixed within a day back in 2013.

Pretty much all other bootkits also still work btw, it's not a singled out example. It's the norm of MS not giving a damn about it.

> This is only true if you use Secure boot. [...] so should be turned off. Then any OS can be installed.

You can only turn off Secure Boot because Microsoft allows it. In the same way Android has its CDD with rules all OEMs must follow (otherwise they won't get Google's apps), Windows has a set of hardware certification requirements (otherwise the OEM won't be able to get Windows pre-installed), and it's these certification requirements that say "it must be possible to disable Secure Boot". A future version of Windows could easily have in its hardware certification requirements "it must not be possible to disable Secure Boot", and all OEMs would be forced to follow it if they wanted Windows.

And that already happened. Some time ago, Microsoft mandated that it must not be possible to disable Secure Boot on ARM-based devices (while keeping the rule that it must be possible to disable it on x86-based devices). I think this rule was changed later, but for ARM-based Windows laptops of that era, it's AFAIK not possible to disable Secure Boot to install an alternate OS.

A small number of countries now. The rest of the world in 2027 and beyond.

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.

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.

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

I don’t have any personal links but know that there is a constant cat-and-mouse game of cracking Widevine devices for their L1 keyboxes and using them on high-value content (as mentioned).

That’s why a lot of low end Android devices often have problems playing DRMed content on the Web: their keyboxes got cracked open and leaked wide enough for piracy that they got revoked and downgraded down to L3.

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?

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.

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

This. Some ways back I actually purchased bluray recording device only to learn that its firmware is deliberately crippled to accommodate someone's business model. There are people who do the unsung hero work, but those types of skills are not exactly common and a business asshole is a dime a dozen any century you want to pick.

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.

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.

Shizuku[0][1] already exists, it would certainly suck but it wouldn't be the end of the world.

Of course I would be much happier if I didn't need to use Shizuku in the first place.

[0]: https://play.google.com/store/apps/details?id=moe.shizuku.pr...

[1]: https://shizuku.rikka.app/

That uses a workaround based on WiFi debugging even though it's all local. It doesn't run if you're not connected to a trusted WiFi network, you have to set it all up when connecting to a new network, etc.

Not only users are not connected to WiFi all the time, but in many developing countries people often have no WiFi at home and rely on mobile data instead. It's a solution, but not a solution for everyone or a solution that works all the time.

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.

But the ecosystem exists, regardless of what the absolute number is, and it would be bad to lose it. If the platform was more open like Windows the ecosystem would grow, if it was less open like iOS it would die.

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

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

If they're going to reduce me to a user, iOS is the better choice. I had an iPhone before and it's a picture taking, instagram, social media machine with iMessage—bringing the console wars to normies since inception.

Because the hardware is so constrained an iphone lasts forever compared to a similar android. My two year old pixel is slow now, but I know people completely happy with a five year old iphone. Pause, I checked and the oldest iphone that receives updates is an iphone 11, which is the exact model I had before going back to android.

I have multiple generations of pixel phones and could not tell the difference in performance between them in basic tasks. Maybe because i installed GrapheneOS which makes both stock android and ios feel like a bloat and spyware riddled toy.

I have a Pixel 7 and it's ridiculously slow so I've been thinking about GrapheneOS.

The only reason for me to get a pixel is GOS. I never want to get back, it makes other mobile os feel icky.