From the very first announcement of this, Google has hinted that they were doing this under pressure from the governments in a few countries. (I don't remember the URL of the first announcement, but https://android-developers.googleblog.com/2025/08/elevating-... is from 2025-August-25 and mentions “These requirements go into effect in Brazil, Indonesia, Singapore, and Thailand”.) The “Why verification is important” section of this blog post goes into a bit more detail (see also the We are designing this flow specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer), but ultimately the point is:
there cannot exist an easy way for a typical non-technical user to install “unverified apps” (whatever that means), because the governments of countries where such scams are widespread will hold Google responsible.
Meanwhile this very fact seems fundamentally unacceptable to many, so there will be no end to this discourse IMO.
I don't buy this argument at all that this specific implementation is under pressure from the government - if the problem is indeed malware getting access to personal data, then the very obvious solution is to ensure that such personal data is not accessible by apps in the first place! Why should apps have access to a user's SMS / RCS? (Yeah, I know it makes onboarding / verification easy and all, if an app can access your OTP. But that's a minor convenience that can be sacrificed if it's also being used for scams by malware apps).
But that kind of privacy based security model is anathema to Google because its whole business model is based on violating its users' privacy. And that's why they have come with such convoluted implementation that further give them control over a user's device. Obviously some government's too may favour such an approach as they too can then use Google or Apple to exert control over their citizens (through censorship or denial of services).
Note also that while they are not completely removing sideloading (for now) they are introducing further restrictions on it, including gate-keeping by them. This is just the "boil the frog slowly" approach. Once this is normalised, they will make a move to prevent sideloading completely, again, in the future.
> Why should apps have access to a user's SMS / RCS?
It could be an alternative SMS app like TextSecure. One of the best features of Android is that even built-in default applications like the keyboard, browser, launcher, etc can be replaced by alternative implementations.
It could also be a SMS backup application (which can also be used to transfer the whole SMS history to a new phone).
Or it could be something like KDE Connect making SMS notifications show up on the user's computer.
> One of the best features of Android is that even built-in default applications like the keyboard, browser, launcher, etc can be replaced by alternative implementations.
When sideloading is barred all that can easily change. If you are forced to install everything from the Google Play Store, Google can easily bar such things, again in the name of "security" - alternate keyboards can steal your password, alternate browsers can have adware / malware, alternate launcher can do many naughty things etc. etc.
And note that if indeed giving apps access to SMS / RCS data is really such a desirable feature, Google could have introduced gate-keeping on that to make it more secure, rather than gate-keeping sideloading. For example, their current proposal says that they will allow sideloading with special Google Accounts. Instead of that, why not make it so that an app can access SMS / RCS only when that option is allowed when you have a special Google Account?
The point is that they want to avoid adding any barriers where a user's private data can't be easily accessed.
> Instead of that, why not make it so that an app can access SMS / RCS only when that option is allowed when you have a special Google Account?
Because then you still need a special Google Account to install your app when it needs to access SMS / RCS.
How about solving this problem in a way that doesn't involve Google rather than the owner of the device making decisions about what they can do with it? Like don't let the app request certain permissions by default, instead require the user to manually go into settings to turn them on, but if they do then it's still possible. Meanwhile apps that are installed from an app store can request that permission when the store allows it, so then users have an easy way to install apps like that, but in that case the app has been approved by Google or F-Droid etc. And the "be an app store" permission works the same way, so you have to do it once when you install F-Droid but then it can set those permissions the same as Google Play.
It's not Google's job to say no for you. It's only their job to make sure you know what you're saying yes to when you make the decision yourself.
If they are concerned about malware then one of the obvious solutions would be safe guarding their play store. There is significant less scam on iphone because apple polices their app store. Meanwhile scam apps that i reported are still up on google play store.
so no, it's not necessary at all. and many apps identify OTPs and give you an easy "copy to clipboard" button in the notification.
but that isn't all super widely known and expected (partly because not all apps or messages follow it), so it's not something you can rely on users denying access to.
> Note also that while they are not completely removing sideloading (for now) they are introducing further restrictions on it, including gate-keeping by them.
This blog post is specifically saying there will be a way to bypass the gatekeeping on Google-blessed Android builds, just as we wanted.
> But that kind of privacy based security model is anathema to Google because its whole business model is based on violating its users' privacy.
Despite this, they sell some of the most privacy-capable phones available, with the Pixels having unlockable bootloaders. Even without unlocking the bootloader to install something like GrapheneOS, they support better privacy than the other mass market mobile phones by Samsung and Apple, which both admittedly set a low bar.
> if the problem is indeed malware getting access to personal data, then the very obvious solution is to ensure that such personal data is not accessible by apps
Then you'd have the other "screaming minority" on HN show up, the "antitrust all the things" folks.
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 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’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.
> 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.
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.
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.
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.
It's not a separate problem, Google are actively suppressing any possibility of open mobile hardware. They force HW manufacturers to keep their specs secret and make them choose between their ecosystem and any other, not both. There's a humongous conflict of interests and they're abusing their dominating position.
> They force HW manufacturers to keep their specs secret
Spoken like someone who has never ever worked with any hardware manufacturers. They do not need reasons for that. They all believe their mundane shit is the most secret-worthy shit ever. They have always done this. This predates google, and will outlive it.
I suppose you have the right to do whatever you want with it, including zapping it in the microwave or using it as a rectal probe. I am not sure that right extends are far as forcing companies to deliver a product to your specifications (open software, hardware, or otherwise)
You’re still missing the point the comment is making: In countries where governments are dead set on holding Google accountable for what users do on their phones, it doesn’t matter what you believe to be your natural right. The governments of these countries have made declarations about who is accountable and Google has no intention of leaving the door open for that accountability.
You can do whatever you want with the hardware you buy, but don’t confuse that with forcing another company to give you all of the tools to do anything you want easily.
That's deflection, there's Google blocking users from installing apps and there's OP insinuating that it might be because of governments coercion but there's no evidence to support this. Scammers pay Google to show ads to install apps, that's what the governments are holding Google responsible and it won't change with blocking installing apps.
Malicious app delivery goes beyond Google ads. In Singapore, most scam app installs are from social engineering, e.g. install new app to receive payment, install new app to buy something for cheap.
I’m amazed at how gullible some people are but that’s how it is.
I don't think it's illegal to do whatever you want with your phone. That doesn't mean google legally is required to make it easy or even possible. That being said I ethically they should allow it, and considering their near monopoly status they should be forced to keep things open. In fact there should be right to repair laws too.
Oh, so you're good with everyone having the "natural right" to turn handguns into automatic weapons simply because they find themselves in possession of the correct atoms? How about adding a 3rd story on the top of your house without needing a permit or structural evaluation?
Note that adding "full stop" pointlessly to the end of sentences does not strengthen your argument.
Then let them do that for those countries. Not for everyone. I'm not in any of those autocratic countries. Or offer an opt out in the countries where this isn't a thing. Using adb is not really great for doing updates.
And also, I'm the owner of my device. Not my country.
> there cannot exist an easy way for a typical non-technical user to install “unverified apps” (whatever that means), because the governments of countries where such scams are widespread will hold Google responsible.
You can also view this as a "tragedy of the commons" situation. Unverified apps and sideloading is actively abused by scammers right now.
> Meanwhile this very fact seems fundamentally unacceptable to many, so there will be no end to this discourse IMO.
I get that viewpoint and I'm also very glad an opt-out now exists (and the risk that the verification would be abused is also very real), but yeah, more information what to do against scammers then would also be needed.
If nobody pushed back on anything we'd all be subjected to the laws of the worst country on earth, because big tech companies want to do business there, and putting an if/else around the user's country takes effort.
> there cannot exist an easy way for a typical non-technical user to install “unverified apps” (whatever that means), because the governments of countries where such scams are widespread will hold Google responsible.
What, the same way they hold Microsoft responsible for the fact that you can install whatever you want in Windows?
Obviously, there can exist an easy way for a non-technical user to install unverified apps, because there has always been one.
> because the governments of countries where such scams are widespread will hold Google responsible.
This is the unsurprising consequence of trying to hold big companies accountable for the things people do with their devices: The only reasonable response is to reduce freedoms with those devices, or pull out of those countries entirely.
This happened a lot in the early days of the GDPR regulations when the exact laws were unclear and many companies realized it was safer to block those countries entirely. Despite this playing out over and over again, there are still constant calls on HN to hold companies accountable for user-submitted content, require ID verification, and so on.
Yes. The same goes with payment processing. I hate visa/mastercard as much as the next person. But if the court says they're accountable for people who buy drug/firearm/child porn, then it seems to be a quite reasonable reaction for them to preemptively limit what the users can buy or sell.
The government(s) have to treat the middlemen as middlemen. Otherwise they are forced to act as gatekeepers.
These two things are not the same. The GDPR afforded rights to common people. Those companies that would pull out are the ones that were abusing data that was never theirs and could no longer do so.
It's not possible to provide a path for advanced users that a stupid person can't be coerced to use.
Moreover, it's not possible to provide a path for advanced users that a stupid person won't use by accident, either.
These are what drive many instances of completely missing paths for advanced users. It's not possible to stop coercion or accidents. It is literally impossible. Any company that doesn't want to take the risk can only leave advanced users completely out of the picture. There's nothing else they can do.
Google will fail to prevent misuse of this feature, and advanced users will eventually be left in the dust completely as Google learns there's no way to safely provide for them. This is inevitable.
Android could have, for example, a 24 hour "cooling off" period for sideloading approval. Much like some bootloader unlocking - make it subject to a delay.
That immediately takes the pressure off people who are being told that their bank details are at immediate risk.
The people gullible enough to fall for a scam like that are also gullible enough to follow more instructions 24 hours later. I think if you could force a call to the phone and have an agent or even AI that talks to user and makes sure no scam is involved then gives an unlock code based on deviceID or something. But that would cost money and scammers would work around it anyway.
> Android could have, for example, a 24 hour "cooling off" period for sideloading approval.
And, to prevent the scammer from simply calling back once the 24 hours are gone, make it show a couple of warnings (at random times so they can't be predicted by the scammer) explaining the issue, with rejecting these warnings making the cooling off timer reset (so a new attempt to enable would need another full 24 hours).
> the governments of countries where such scams are widespread will hold Google responsible.
This argument is FUD at this point.
Sovereign governments have ways to make clear what they want: they pass laws, and there needs to be no back deal or veiled threats. If they intend to punish Google for the rampant scams, they'll need a legal framework for that. That's exactly how it went down with the DMA, and how other countries are dealing with Google/Apple.
Otherwise we're just fantasizing on vague rumors, exchanges that might have happened but represent nothing (some politicians telling bullshit isn't a law of the country that will lead to enforcement).
This would be another story if we're discussing exchanges with the mafia and/or private parties, but here you're explicitely mentionning governments.
That's a disingenuous argument though: they are in that position because they chose to make themselves the only way that a 'normal' user is able to install software on these devices. If not for that these governments wouldn't have a point to apply pressure on in the first place.
No, then the results of many google web searches would not put scam sites at the top over the official sites. Google is fine with people being scammed. As long as they get their cut. Large corporations don't have empathy.
Meta ads too. It’s bonkers the type of ads they approve, straight up scams or obvious misinformation (some prominent figure is in jail! Click here to find out!)
From what I've seen, millions lost to scams are with social engineering; through cold calls masquerading as the authorities, phishing, pig butchering; plenty of scam apps on the Play store harvesting data as well, but not a single real life instance of malware installed outside the officially sanctioned platform.
This is the worst of both worlds, you can spread your malware as a sideloaded apk just fine, but when it's so big that you're probably burned anyways, then you need to verify your account.
I think a better compromise would have been for google to require developer verification, but also allow third party appstores like f-droid that don't require verification but still are required to "sign" the apks, instead of users enabling wide-open apk sideloading. that way, hobbyists can still publish apps in third party stores, and it is a couple of more steps harder for users to fall for social engineering,because they now have to install/enable f-droid, and then find the right malicious app and download it. The apk downloaded straight from the malicious site won't be loaded no matter what.
Google can then require highlighting things like number of downloads and developer reputation by 3rd party appstores, and maybe even require an inconsistent set of steps to search and find apps to make it harder to social engineer people (like names of buttons, ux arrangements, number of clicks,etc.. randomize it all).
What frustrated me on this topic from the beginning is that solutions like what I'm proposing (and better ones) are possible. But the HN prevailing sentiment (and elsewhere) is pitchforks and torches. Ok, disagree with google, but let's discuss about how to solve the android malware problem that is hurting real people, it is irresponsible to do otherwise.
It's not super clear from the post, but if I read it correctly there are two modifications suggested.
- 1: Separate verification type for "student and hobbyist"
- 2: "advanced flow" for "power users" that allows sideloading of unverified apps - I imagine this is some kind of scare-screen, but we'll see.
What you describe as "worst of both worlds" is about point 1.
I'm not sure point 2 is powerful enough to suppor things like f-droid, but again, we'll see.
Edit: be sure to read geoffschmidt's reply below /edit
The buried lede:
> a dedicated account type for students and hobbyists. This will allow you to distribute your creations to a limited number of devices without going through the full verification
So a natural limit on how big a hobby project can get. The example they give, where verification would require scammers to burn an identity to build another app instead of just being able to do a new build whenever an app gets detected as malware, shows that apps with few installs are where the danger is. This measure just doesn't add up
Oh! I thought I had found the crucial piece finally after ~500 words, but there's indeed better news in the section after that! Thanks, I can go sleep with a more optimistic feeling now :)
Also this will kill any impetus that was growing on the Linux phone development side, for better or worse. We get to live in this ecosystem a while longer, let's see if people keep damocles' sword in mind and we might see more efforts towards cross-platform builds for example
Yes, but it's often just "a W" or simply "W" in response to something good or seen as a "win."
There is also the same thing with L for loss/loser. "that's an L take", "L [person]", "take the L here", etc.
They are pretty straightforward in their meaning, basically what you described. I believe it comes from sports but they are used for any good or bad outcome regardless of whether it was a contest.
This isn't a "W", but I am finding my own "W" from this by seeing others distrust Google, and remembering to continue supporting and looking for open alternatives to Google.
That doesn't say that you can just build an APK and distribute it. I suspect this path _still_ requires you to create a developer console account and distribute binaries signed by it... just that that developer account doesn't have to have completed identity verification.
That's not fine at all. A developer who doesn't want to (or can't) distribute through the Play Store will now need to teach their users how to enable developer mode and toggle a hidden setting. This raises the barrier a bit more than the current method of installing outside the Play Store.
A simple yes/no alert box is not "[...] specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer". In fact, AFAIK we already have exactly that alert box.
No, what they want is something so complicated that no muggle could possibly enable it, either by accident or by being guided on the phone.
The angry social media narratives have been running wild from people who insert their own assumptions into what’s happening.
It’s been fairly clear from the start that this wasn’t the end of sideloading, period. However that doesn’t get as many clicks and shares as writing a headline claiming that Google is taking away your rights.
I don't think this section is actually the same as the present state just with a new alert box.
I suspect they mean you have to create a android developer account and sign the binaries, this new policy just allows you to proceed without completing the identity verification on that account.
> The angry social media narratives have been running wild from people who insert their own assumptions
There may have been exaggerations in some cases but these hand wavy responses like "you can still do X but you just can't do Y and Z is now mandatory" or "you can always use Y" is how we got to this situation in the first place.
This is just the next evolution of SafetyNet & play integrity API. Remember how many said use alternatives. Not saying safetynet is bad but I don't believe their intentions were to stop at just that.
> The angry social media narratives have been running wild from people who insert their own assumptions into what’s happening.
No, until this post, Google had said that it wouldn't be possible to install an app from a developer who hadn't been blessed by Google completely on your device. That is unacceptable. This blog post contains a policy change from Google.
Sorry what? Their original plan absolutely was the end of sideloading on-device outside of Google's say so. That's what the angry social media narratives were that you seem upset about. Anyone being pedantic and pointing out that adb install is still an option therefore sideloading still exists can fuck off at this point.
What are you talking about? This change for "experienced users" was only just announced and not part of any previous announcement. It has not been clear from the start at all.
Let me guess, a warning box that requires me to give permission to the app to install from third-party sources? Is that not clear enough confirmation that I know what I'm doing? /s
> Keeping users safe on Android is our top priority.
I highly doubt this is your "top" priority. Or if it is then you're gotten there by completely ignoring Google account security.
> intercepts the victim's notifications
And who controls these notifications and forces application developers to use a specific service?
> bad actors can spin up new harmful apps instantly.
Like banking applications that use push or SMS for two factor authentication. You seem to approve those without hesitation. I guess their "top" priority is dependent on the situation.
> And who controls these notifications and forces application developers to use a specific service?
Am I alone in being alarmed by this? Are they admitting that their app sandboxing is so weak that a malicious app can exfil data from other unaffiliated apps? And they must instead rely on centralized control to disable those apps after the crime? So.. what’s the point of the sandboxing - if this is just desktop level lack of isolation?
Glossing over this ”detail” is not confidence inspiring. Either it’s a social engineering attack, in which case an app should have no meaningful advantage over traditional comms like web/email/social media impersonation. Or, it’s an issue of exploits not being patched properly, in which case it’s Google and/or vendor responsibility to push fixes quickly before mass malware distribution.
The only legit point for Google, to me, is apps that require very sensitive privileges, like packet inspection or OS control. You could make an argument that some special apps probably could benefit from verification or special approvals. But every random app?
> Are they admitting that their app sandboxing is so weak that a malicious app can exfil data from other unaffiliated apps?
An app can read the content of notifications if the appropriate permissions are granted, which includes 2FA codes sent by SMS or email. That those are bad ways to provide 2FA codes is its own issue.
I want that permission to exist. I use KDE Connect to display notifications on my laptop, for example. Despite the name, it's not just for KDE or Linux - there are Windows and Mac versions too.
yes, they're admitting that their APIs are powerful enough to build accessibility tools (which often must read notifications) and many other useful things (e.g. Pushbullet) that are not possible on iOS.
powerful stuff has room for abuse. I didn't really think there's much of a way to make that not the case. it's especially true for anything that you grant accessibility-level access to, and "you cannot build accessibility tools" is a terrible trade-off.
(personally I think there's some room for options with taint analysis and allowing "can read notifications = no internet" style rules, but anything capable enough will also be complex enough to be a problem)
BINGO! Google doesn't care at all about user security.
- Just yesterday there was a story on here about how Google found esoteric bugs in FFMPEG, and told volunteers to fix it.
- Another classic example, about how Google doesn't give a stuff about their user's security is the scam ads they allow on youtube. Google knows these are scams, but don't care because they there isn't regulation requiring oversight.
> Just yesterday there was a story on here about how Google found [a security vulnerability that anyone running `ffmpeg -i <untrusted file> ...` was vulnerable to] in FFMPEG, and told [the world about it so that everyone could take appropriate action before hackers found the same thing and exploited it, having first told the ffmpeg developers about it in case they wanted to fix it before it was announced publicly]
Fixed that for you. Google's public service was both entirely appropriate and highly appreciated.
Yes, but it was a public service not a service for the maintainers, and as a member of the public who like anyone who had run `ffmpeg -i <thing I downloaded from the internet>` was previously exposed to the vulnerability I highly appreciate their service.
I'd highly appreciate even if the maintainers never did anything with the report, because in that case I would know to stop using ffmpeg on untrusted files.
So you were using untrusted video files that required the LucasArts Smush codec?
Again, if YOU highly appreciate their service, that's great, but FFMPEG isn't fixing a codec for a decades old game studio, so all Google has done is tell cyber criminals how to infect your Rebel Assault 2. I'm glad you find that useful.
No, I was running on normal untrusted video files. The standard ffmpeg command line would happily attempt to parse those with the LucasArts Smush codec even though I'd never heard of it before.
See the POC in the report by google, the command they run is just `./ffmpeg -i crash.anim -f null /dev/null -loglevel repeat+trace -threads 1` and the only relevant part of that for being vulnerable is that crash.anim is untrusted.
Edit: And to be clear, it doesn't care about the extension. You can name it kittens.mp4 instead of crash.anim and the vulnerability works the same way.
Making money and complying with the law. They are obligated to do both. In many countries laws are still enforced.
Protecting their app store revenues from competition exposes them to scrutiny from competition regulators and might be counter productive.
Many governments are moving towards requiring tech companies to enforce verification of users and limit access to some types of software and services or impose conditions requiring software to limit certain features such as end to end encryption. Some prominent people in big tech believe very strongly in a surveillance state and we are seeing a lot of buy in across the political spectrum, possibly due to industry lobbying efforts. Allowing people to install unapproved software limits the effectiveness of surveillance technologies and the revenues of those selling them. If legal compliance risks are pushing this then it is a job for voters, not Google to fix.
Complying with the law is just another way of protecting your money. I have no doubt if they would break laws if they judged it better for the bottom line --- in fact I have little doubt they're already doing so. On the flip side, if there were ruinous penalties for their anticompetitive behaviors (i.e., in the tens or hundreds of billions of dollars) they might change course.
Certainly voters need to have their say, but often their message is muffled by the layers of political and administrative material it passes through.
this is an absurd rant. they invest, like, billions into security. It's not as perfect as you want it to be but "completely ignoring" is a joke. if you've got actual grievances you should say what they are so that we can actually get on your side instead of rolling our eyes
They absolutely eo completely ignore many security and privacy things because they're very selective in what they focus on, particularly around how those things might impact their ad revenue.
How much they spend is no indicator of how and where they spend it, so is hardly a compelling argument.
Some security is better than no security. It already took years to even get some of these backwards-thinking companies and services to adopt SMS OTP and it's simple for non-technical users to intuit. Also, believe it or not, some people don't have smartphones, and they will riot if you try to make them switch to any other MFA method...
Of course, I'm not saying we shouldn't push to improve things, but I don't think this is the right reaction either.
> we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified. We are designing this flow specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer. It will also include clear warnings to ensure users fully understand the risks involved, but ultimately, it puts the choice in their hands.
As long as this is a one-time flow: Good, great, yes, I'll gladly scroll through as many prompts as you want to enable sideloading. I understand the risks!
But I fear this will be no better than Apple's flow for installing unsigned binaries in macOS.
Does this allow unsigned binaries like today? Or is this now requiring you have a binary signed by a android developer account but just one without full identity verification.
The key question for me is whether this "advanced flow" will allow the practical use of entirely separate app stores (like F-Droid) or if they're going to throw up tons of barriers for every individual app install.
If I were designing the advanced flow, I'd require the decision to be made at phone setup time. Changing your mind later requires a factory reset.
Real sideloaders (F-Droid users, etc.) know at setup time that that's how they'll be using their phone, so it works for them. But ordinary users who are targets for sideloading malware will become a lot less attractive if attackers must convince them to wipe their phone to complete the coercive instructions.
Aliexpress has a similar approach to protect their accounts from takeovers. If you change or forget your password, all your saved payment methods are erased. This makes the account less valuable to an attacker, at the cost of a little pain to authentic account holders.
No, that's ridiculous. If I want to send an app to someone, now they have to wipe their phone to install it? That would kill installing non-Play apps far more than Google's original proposal.
I hadn't installed a non-Play Store app for something like 5 years until this year. I don't see why I should have been forced to factory reset my phone then.
There's a second path, whereby F-Droid registers as an "alternative app store", which is a new category of app created in the fallout of Epic Games v. Google [0]. This is interesting because it applies to all regions and will necessarily need more elevated permissions than the typical REQUEST_INSTALL_PACKAGES permission used today. No idea what requirements Google will impose on such apps.
EU digital markets mandates that you can install apps through f-droid... but doesn't mandate that those apps don't to comply with Google's signing policy.
Sounds like they're rolling back the mandatory verification flow:
Based on this feedback and our ongoing conversations with the community, we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified. We are designing this flow specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer. It will also include clear warnings to ensure users fully understand the risks involved, but ultimately, it puts the choice in their hands. We are gathering early feedback on the design of this feature now and will share more details in the coming months.
I'm a little nervous about what this advanced flow is going to look like, given that sideloading already requires jumping through a bunch of hoops to enable and even that apparently wasn't enough to satisfy Google.
I'm cautiously optimistic though. I'm generally okay with nanny features as long as there's a way to turn them off.
> Sounds like they're rolling back the mandatory verification flow
absolutely no. this is for the user side. but if you're a developer who is planning to publish the app in alternative play store/from your website, you have to do verification flow. please read the full text.
I feel like if safety was really their top priority, they would have done this long ago and not bothered with this mandatory signing nonsense to begin with...
This is misleading though. There is simply no other choice if you want to use mainstream apps. It could be argued (successfully in my view) that any agreement is null and void due to its acceptance under duress.
Users have an inherent legal right to unconditionally access the full advertised functionality of devices they purchase. Any agreement after that is inherently suspect and I wouldn't be surprised to find out it was ruled unconscionable by some court if it came to that.
This isn't misleading in any way. It's unfortunate and we should be pissed about it, but this is exactly the legal arrangement that Google and Apple came up with.
> I wouldn't be surprised to find out it was ruled unconscionable by some court
Last US court battle, Apple told the court it needed the money from the kids casino to keep its profits, and the court just nodded.
Apple had to be held in comptempt of a court order after 4 years and a deluge of evidence, for us to see any significant move.
Which is an unacceptable loophole in our legal system that should be closed immediately. If I buy a product, even if that product is software, then I own it, and I should have ultimate control my copy of it.
Too many people are in denial about what they actually own, and seem to refuse to accept this battle isn't starting or coming up, we're already in the process of losing it.
Clinging to material ownership feels great on the moment, but that's absolutely not what we need to deal with right now. It's kinda like being so proud to be the registered owner of your car, while it's getting impounded and you'll be spending the next 10 years trying to get it back.
* Search for "Smartphone-1 to Smartphone-2" "adb tcpip 5555" in "Motorola moto g play 2024 smartphone, Termux, termux-usb, usbredirect, QEMU running under Termux, and Alpine Linux: Disks with Globally Unique Identifier (GUID) Partition Table (GPT) partitioning": https://old.reddit.com/r/MotoG/comments/1j2g5gz/motorola_mot... (old.reddit.com/r/MotoG/comments/1j2g5gz/motorola_moto_g_play_2024_smartphone_termux/)
* Search for "termux-adb" in "Motorola moto g play 2024 Smartphone, Android 14 Operating System, Termux, And cryptsetup: Linux Unified Key Setup (LUKS) Encryption/Decryption And The ext4 Filesystem Without Using root Access, Without Using proot-distro, And Without Using QEMU": https://old.reddit.com/r/MotoG/comments/1jkl0f8/motorola_mot... (old.reddit.com/r/MotoG/comments/1jkl0f8/motorola_moto_g_play_2024_smartphone_android_14/)
You don't need two phones to use ADB with Termux. Just put the ADB settings app on a split screen and it will work just fine. I used it several months ago.
8 days ago Google and Epic announced a proposed settlement and modification of a permanent injunction that Epic won, I believe this proposed settlement would likely have prohibited Google's plan to forbid installation of third party apps (excluding app stores from the definition of apps) unless those app developers had paid google a registration fee. The proposed settlement is here [1], the relevant portion is
> 13. For a period beginning on the Effective Date through June 30, 2032, Google will [...] and will continue
to permit the direct downloading of apps from developer websites and third-party stores without
any fees being imposed for those downloads unless the downloads originate from linkouts from
apps installed/updated by Google Play (excluding web browsers).
6 days ago the court expressed skepticism as to the proposal and announced that they'd have a hearing, with testimony from expert witnesses, as to whether it would prevent the market harms that the original injunction was trying to cure [2].
Today Google announces this, effectively confirming that they're backing down from their requirement that third party app developers pay google prior to distributing their apps.
Nothing (yet) is explicitly tying these together, but I can't help but suspect that this move is in large part being made to convince the court that they're actually intending to honour this portion of the proposed injunction even though Epic would have little reason to enforce it.
Did we read the same thing? I think Google here said there would be a $25 fee per developer (for those who can't fit in their limited distribution category). I suppose it's much better than a fee per paid install but it's not nothing.
They announced the $25 "verification" plan awhile ago. The new part in this article is that they're going to have it remain possible to install software that didn't do that "verification".
> Based on this feedback and our ongoing conversations with the community, we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified.
Damn. I was excited by the prospect of Google shooting themselves in the foot, inspiring people to make Android replacements that aren't privacy and process nightmares. With this (partial) capitulation, the path of least resistance will remain a proprietary, corporate-controlled, bloated walled garden.
So there was the very concrete problem that F-Droid could not continue to function with the verification requirements, because they rebuild every app and so would have to know every key.
In the end when supporting the non tech people in the family, what I would really like is to setup their device so they can install anything on Fdroid but nothing from the play store (unless approved by me) nor direct from an apk.
Google is about to find out the next step of this chain - give access to everyone, don't gatekeep / do checks, and yet take responsibility for anything that goes wrong.
"You should open up the tool, put no restrictions, and yet ensure that it is safe and secure" is an impossible task for anyone.
Are there any entities on earth with resources to compete with a complicit global duopoly?
If Android is open source, why can't/won't a community fork it? Graphene OS exists but many folks claim Netflix and banking apps do not work with it (despite allowing logins from any common desktop browser)?
If all widely-accepted phone operating systems are de-facto proprietary, what does this say about the current phase of society?
What choice do non-billionaire/millionaire humans have for living in a single-planet society where technology is so highly integrated (and the inherent non-consensual compromises)?
What If the little people are going to get squeezed even more?
LineageOS is based on AOSP and works well. I don't understand the banking app thing either. I suspect it's a regional issue. I can log in to my credit union account via any browser, and if something needs MFA it should be able to use TOTP which works on anything.
Android in practice is full of proprietary blobs, stuck on old kernel versions, and the hardware is barely supported. Lots of downstream crap from the vendors not playing nice. Most devices running Android are instantly doomed to be e-waste. You can look through devices postmarketOS supports, and anything without mainline kernel support and most stuff working is basically e-waste unless someone puts in a lot of work for that particular device. It's a little bit like how modern GPUs don't work without blobs in the kernel anymore and you have to go back to Haswell era or older for things to work with all free software, but the state of smartphones is a few steps worse than that due to their locked down nature.
Pretty much any OnePlus device (other than ones still too new) seems to be a good bet for decent software support (both LineageOS and pmOS). Though annoyingly stuff like the 3G shutdown makes a lot of the earlier models unusable as actual phones these days. At least they can still be computers. Not quite e-waste.
There are many real-world sideloading abuse cases in China. Attackers often trick victims with plausible stories—e.g., claiming a flight is delayed—and ask them to sideload an app (a remote‑meeting or remote‑control tool) to share their screen. Once installed, the attacker can view the victim’s screen and intercept SMS 2FA codes for online banking or other sensitive accounts.
Other schemes include impersonating sex workers to lure victims into nude video chats, then persuading them to install an app that harvests private content and contacts for blackmail.
What's the Android situation there? Last I heard Google didn't license Android there and they were using Chinese app stores with forked AOSP Android. Which would seem to put the sideloading decision in the hands of the forked OS.
These unfortunately gullible people would be tricked in many different other ways throughout their daily lives even if it wasn't for the ability to install something on a device that you paid for and outright own.
Why should that mean anyone else should lose control of their device? Maybe at some point you have to accept that it's the user's responsibility? Maybe empower users to be aware of what the apps they install are doing, without take their control away?
This is how loss of autonomy always happens in every sphere: make an argument that it's for their own safety that individuals are losing autonomy, and the entity gaining control is superior in knowing what's best, and is taking control only out of the goodness of their heart.
Google still hasn't changed anything but took the opportunity to again insult their customers within the first headline, titled "Why verification is important".
Google goes on to say how taking away one of your last remaining rights is good for you, if you like it or not.
It is clear to everyone why Google is partnering with governments around the world to remove our rights to installing apps. Laws are not on your side and must be reevaluated on an individual level to move forward. You decide your own terms, you have the power.
Glad to see Google come to their senses on this. Disabling it entirely would have basically guaranteed an exodus of power users over to iOS. If your only choices are walled gardens, you might as well pick the easiest, prettiest one.
If adb is unrestricted and can work with the Linux command shell (something I seem to remember I had read about before; you will need to enable the developer mode to use it), which is aparently a separate system but runs on the same device, although if it has the ability to communicate with the main Android system using adb (which it might be reasonable to require that to be explicitly enabled with another setting, for additional security in case you do not use adb), then this would help since you do not require another computer that would be compatible with adb in order to do it.
However, I think there are other things they should do as well (in addition to the other things) if they want to improve the safety, such as looking at the apps in Google Play to check that they are not malware (since apparently some are; however, it says they do have some safeguards, so hopefully that would help), and to make the permission system to work better (e.g. to make it clear that it can intercept notificatinos; there are legitimate reasons to do this but it should require an explicit permission setting to make this clear).
As soon as a platform gives control to the fullscreen, harmful apps are possible.
See for example Apple detecting if a user is typing on a keyboard while in a fullscreen website, and then blocking the website. Yes it's as crazy as it's sounds.
"We have realised that boiling the frog this fast will result in it jumping out of the water. Therefore we have slowed down, but remain steadfastly devoted to seeing this frog boiled"
"Based on this feedback and our ongoing conversations with the community, we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified. We are designing this flow specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer. It will also include clear warnings to ensure users fully understand the risks involved, but ultimately, it puts the choice in their hands. We are gathering early feedback on the design of this feature now and will share more details in the coming months."
So they haven't actually changed anything yet, but they say that they will "in the coming months."
We really need to banish the term "sideloading". Installing apps on a terminal is just that, and for as long as I remember on windows, Linux it has always been just that.
Google mentions about being on a call, and being tricked into handing over codes. So why not use signals and huristics to decide?
If user is on a call, block any ability to install a shady app. Implement a cool down before that functionality is restored (say 24 hours). It can also detect where the user is based to add additional protection (such as mandating the use of play protect to scan the app before it's activated and add another cool down regardless).
There's lots of ways to help protect the user but it's wrong to ultimately control them. The real world is full of scary dangers that technology is trying to solve but is actively making things worse (such as computerized safety systems in cars).
Ultimately, the user is responsible and whilst it's palpable Google would want to reduce harm in this specific way, we know authoritarian governments would also love to be able to dictate what software people can run. The harm to democracy is simply too great in favor of saving a few people's money.
They didn't say no changes. They are just saying we'll address the concerns of hobbyists and students.
Lets not celebrate prematurely and let us wait for more details on whats actually changing both technically and process wise. We should demand more clarity and should not wait to discover it after the implementation at which point it is hard and nearly impossible to push back against.
We don't want to be in a situation where they technically make it possible but make it practically impossible to install apps outside playstore.
I worry that the overton window has shifted so much after over a decade and a half of most downloads being mediated by "app stores" that most people don't realize or have the means to vocalize or understand what they're missing.
I have to admit I couldn't even understand this problem, because for me the "stock OS" is already unbearable and I'd simply never be able to use it - I've never used it for more than a hour..
The issue is that of network effects. Making it harder to sideload for example f-droid makes the already small market for it even smaller, leading to less apps. It also forces people developing Apps that they don't want to reveal to be developing for completly valid reasons (Imagine developing a porn app in saudi arabia or an abortion support app in the USA) to validate against google aka the US Government.
I'm just presenting my exotic point of view - since that developer verification would only be needed to run apps on the "stock OS" (which I consider bad), then deliberately excluding it could promote using LineageOS/GrapheneOS which would be a good thing.
But of course I'm talking about non-commercial apps, but commercial app developers would already be on Google Play.
As to relevance to the article - I'm not cheering that much because if Google made "stock OS" even worse then maybe more users would flock to LineageOS/GrapheneOS which would be a great thing and make it harder to push Play Integrity.
From the very first announcement of this, Google has hinted that they were doing this under pressure from the governments in a few countries. (I don't remember the URL of the first announcement, but https://android-developers.googleblog.com/2025/08/elevating-... is from 2025-August-25 and mentions “These requirements go into effect in Brazil, Indonesia, Singapore, and Thailand”.) The “Why verification is important” section of this blog post goes into a bit more detail (see also the We are designing this flow specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer), but ultimately the point is:
there cannot exist an easy way for a typical non-technical user to install “unverified apps” (whatever that means), because the governments of countries where such scams are widespread will hold Google responsible.
Meanwhile this very fact seems fundamentally unacceptable to many, so there will be no end to this discourse IMO.
I don't buy this argument at all that this specific implementation is under pressure from the government - if the problem is indeed malware getting access to personal data, then the very obvious solution is to ensure that such personal data is not accessible by apps in the first place! Why should apps have access to a user's SMS / RCS? (Yeah, I know it makes onboarding / verification easy and all, if an app can access your OTP. But that's a minor convenience that can be sacrificed if it's also being used for scams by malware apps).
But that kind of privacy based security model is anathema to Google because its whole business model is based on violating its users' privacy. And that's why they have come with such convoluted implementation that further give them control over a user's device. Obviously some government's too may favour such an approach as they too can then use Google or Apple to exert control over their citizens (through censorship or denial of services).
Note also that while they are not completely removing sideloading (for now) they are introducing further restrictions on it, including gate-keeping by them. This is just the "boil the frog slowly" approach. Once this is normalised, they will make a move to prevent sideloading completely, again, in the future.
> Why should apps have access to a user's SMS / RCS?
It could be an alternative SMS app like TextSecure. One of the best features of Android is that even built-in default applications like the keyboard, browser, launcher, etc can be replaced by alternative implementations.
It could also be a SMS backup application (which can also be used to transfer the whole SMS history to a new phone).
Or it could be something like KDE Connect making SMS notifications show up on the user's computer.
That's all indeed valid.
> One of the best features of Android is that even built-in default applications like the keyboard, browser, launcher, etc can be replaced by alternative implementations.
When sideloading is barred all that can easily change. If you are forced to install everything from the Google Play Store, Google can easily bar such things, again in the name of "security" - alternate keyboards can steal your password, alternate browsers can have adware / malware, alternate launcher can do many naughty things etc. etc.
And note that if indeed giving apps access to SMS / RCS data is really such a desirable feature, Google could have introduced gate-keeping on that to make it more secure, rather than gate-keeping sideloading. For example, their current proposal says that they will allow sideloading with special Google Accounts. Instead of that, why not make it so that an app can access SMS / RCS only when that option is allowed when you have a special Google Account?
The point is that they want to avoid adding any barriers where a user's private data can't be easily accessed.
> Instead of that, why not make it so that an app can access SMS / RCS only when that option is allowed when you have a special Google Account?
Because then you still need a special Google Account to install your app when it needs to access SMS / RCS.
How about solving this problem in a way that doesn't involve Google rather than the owner of the device making decisions about what they can do with it? Like don't let the app request certain permissions by default, instead require the user to manually go into settings to turn them on, but if they do then it's still possible. Meanwhile apps that are installed from an app store can request that permission when the store allows it, so then users have an easy way to install apps like that, but in that case the app has been approved by Google or F-Droid etc. And the "be an app store" permission works the same way, so you have to do it once when you install F-Droid but then it can set those permissions the same as Google Play.
It's not Google's job to say no for you. It's only their job to make sure you know what you're saying yes to when you make the decision yourself.
I concur.
If they are concerned about malware then one of the obvious solutions would be safe guarding their play store. There is significant less scam on iphone because apple polices their app store. Meanwhile scam apps that i reported are still up on google play store.
re OTPs, there's a special permission-less way to request sms codes, with a special hash in the content so it's clearly an opt-in by both app and sender: https://developers.google.com/identity/sms-retriever/overvie...
so no, it's not necessary at all. and many apps identify OTPs and give you an easy "copy to clipboard" button in the notification.
but that isn't all super widely known and expected (partly because not all apps or messages follow it), so it's not something you can rely on users denying access to.
> Note also that while they are not completely removing sideloading (for now) they are introducing further restrictions on it, including gate-keeping by them.
This blog post is specifically saying there will be a way to bypass the gatekeeping on Google-blessed Android builds, just as we wanted.
> But that kind of privacy based security model is anathema to Google because its whole business model is based on violating its users' privacy.
Despite this, they sell some of the most privacy-capable phones available, with the Pixels having unlockable bootloaders. Even without unlocking the bootloader to install something like GrapheneOS, they support better privacy than the other mass market mobile phones by Samsung and Apple, which both admittedly set a low bar.
> if the problem is indeed malware getting access to personal data, then the very obvious solution is to ensure that such personal data is not accessible by apps
Then you'd have the other "screaming minority" on HN show up, the "antitrust all the things" folks.
The "let's actually enforce antitrust laws" people are in the majority:
https://today.yougov.com/economy/articles/47798-most-america...
https://www.antitrustinstitute.org/wp-content/uploads/2024/1...
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.
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’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 :(
I agree, but I don't see why Google gets more critical attention than the iPhone or Xbox.
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.
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.
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.
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.
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/
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
I bought the hardware, therefore I have the right to modify and repair. Natural right, full stop. That right ends are your nose, as the saying goes.
Consider whether your natural right argument might not stand in several other countries’ legal systems.
The era of United States companies using common sense United States principles for the whole world is coming to an end.
Okay, but currently it's the opposite: an US company is forcing the principles of these few legal systems for the whole world.
This is correct. Our natural rights go much further than unnatural prohibitions from the government.
Do what you please and get enough people to do it with you, and no one can stop you.
Yeah then you have the choice to not buy the locked down hardware, you don't have a right to get open hardware FROM Google.
Of course there are no good options for open hardware, but that is a related but separate problem.
It's not a separate problem, Google are actively suppressing any possibility of open mobile hardware. They force HW manufacturers to keep their specs secret and make them choose between their ecosystem and any other, not both. There's a humongous conflict of interests and they're abusing their dominating position.
> They force HW manufacturers to keep their specs secret
Spoken like someone who has never ever worked with any hardware manufacturers. They do not need reasons for that. They all believe their mundane shit is the most secret-worthy shit ever. They have always done this. This predates google, and will outlive it.
I suppose you have the right to do whatever you want with it, including zapping it in the microwave or using it as a rectal probe. I am not sure that right extends are far as forcing companies to deliver a product to your specifications (open software, hardware, or otherwise)
> Natural right, full stop.
You’re still missing the point the comment is making: In countries where governments are dead set on holding Google accountable for what users do on their phones, it doesn’t matter what you believe to be your natural right. The governments of these countries have made declarations about who is accountable and Google has no intention of leaving the door open for that accountability.
You can do whatever you want with the hardware you buy, but don’t confuse that with forcing another company to give you all of the tools to do anything you want easily.
That's deflection, there's Google blocking users from installing apps and there's OP insinuating that it might be because of governments coercion but there's no evidence to support this. Scammers pay Google to show ads to install apps, that's what the governments are holding Google responsible and it won't change with blocking installing apps.
Malicious app delivery goes beyond Google ads. In Singapore, most scam app installs are from social engineering, e.g. install new app to receive payment, install new app to buy something for cheap.
I’m amazed at how gullible some people are but that’s how it is.
I don't think it's illegal to do whatever you want with your phone. That doesn't mean google legally is required to make it easy or even possible. That being said I ethically they should allow it, and considering their near monopoly status they should be forced to keep things open. In fact there should be right to repair laws too.
Oh, so you're good with everyone having the "natural right" to turn handguns into automatic weapons simply because they find themselves in possession of the correct atoms? How about adding a 3rd story on the top of your house without needing a permit or structural evaluation?
Note that adding "full stop" pointlessly to the end of sentences does not strengthen your argument.
The difference is that you can’t kill other people by installing an app.
Then let them do that for those countries. Not for everyone. I'm not in any of those autocratic countries. Or offer an opt out in the countries where this isn't a thing. Using adb is not really great for doing updates.
And also, I'm the owner of my device. Not my country.
> there cannot exist an easy way for a typical non-technical user to install “unverified apps” (whatever that means), because the governments of countries where such scams are widespread will hold Google responsible.
You can also view this as a "tragedy of the commons" situation. Unverified apps and sideloading is actively abused by scammers right now.
> Meanwhile this very fact seems fundamentally unacceptable to many, so there will be no end to this discourse IMO.
I get that viewpoint and I'm also very glad an opt-out now exists (and the risk that the verification would be abused is also very real), but yeah, more information what to do against scammers then would also be needed.
If nobody pushed back on anything we'd all be subjected to the laws of the worst country on earth, because big tech companies want to do business there, and putting an if/else around the user's country takes effort.
> there cannot exist an easy way for a typical non-technical user to install “unverified apps” (whatever that means), because the governments of countries where such scams are widespread will hold Google responsible.
What, the same way they hold Microsoft responsible for the fact that you can install whatever you want in Windows?
Obviously, there can exist an easy way for a non-technical user to install unverified apps, because there has always been one.
> because the governments of countries where such scams are widespread will hold Google responsible.
This is the unsurprising consequence of trying to hold big companies accountable for the things people do with their devices: The only reasonable response is to reduce freedoms with those devices, or pull out of those countries entirely.
This happened a lot in the early days of the GDPR regulations when the exact laws were unclear and many companies realized it was safer to block those countries entirely. Despite this playing out over and over again, there are still constant calls on HN to hold companies accountable for user-submitted content, require ID verification, and so on.
Yes. The same goes with payment processing. I hate visa/mastercard as much as the next person. But if the court says they're accountable for people who buy drug/firearm/child porn, then it seems to be a quite reasonable reaction for them to preemptively limit what the users can buy or sell.
The government(s) have to treat the middlemen as middlemen. Otherwise they are forced to act as gatekeepers.
These two things are not the same. The GDPR afforded rights to common people. Those companies that would pull out are the ones that were abusing data that was never theirs and could no longer do so.
It's not possible to provide a path for advanced users that a stupid person can't be coerced to use.
Moreover, it's not possible to provide a path for advanced users that a stupid person won't use by accident, either.
These are what drive many instances of completely missing paths for advanced users. It's not possible to stop coercion or accidents. It is literally impossible. Any company that doesn't want to take the risk can only leave advanced users completely out of the picture. There's nothing else they can do.
Google will fail to prevent misuse of this feature, and advanced users will eventually be left in the dust completely as Google learns there's no way to safely provide for them. This is inevitable.
Android could have, for example, a 24 hour "cooling off" period for sideloading approval. Much like some bootloader unlocking - make it subject to a delay.
That immediately takes the pressure off people who are being told that their bank details are at immediate risk.
The people gullible enough to fall for a scam like that are also gullible enough to follow more instructions 24 hours later. I think if you could force a call to the phone and have an agent or even AI that talks to user and makes sure no scam is involved then gives an unlock code based on deviceID or something. But that would cost money and scammers would work around it anyway.
> Android could have, for example, a 24 hour "cooling off" period for sideloading approval.
And, to prevent the scammer from simply calling back once the 24 hours are gone, make it show a couple of warnings (at random times so they can't be predicted by the scammer) explaining the issue, with rejecting these warnings making the cooling off timer reset (so a new attempt to enable would need another full 24 hours).
> the governments of countries where such scams are widespread will hold Google responsible.
This argument is FUD at this point.
Sovereign governments have ways to make clear what they want: they pass laws, and there needs to be no back deal or veiled threats. If they intend to punish Google for the rampant scams, they'll need a legal framework for that. That's exactly how it went down with the DMA, and how other countries are dealing with Google/Apple.
Otherwise we're just fantasizing on vague rumors, exchanges that might have happened but represent nothing (some politicians telling bullshit isn't a law of the country that will lead to enforcement).
This would be another story if we're discussing exchanges with the mafia and/or private parties, but here you're explicitely mentionning governments.
That's a disingenuous argument though: they are in that position because they chose to make themselves the only way that a 'normal' user is able to install software on these devices. If not for that these governments wouldn't have a point to apply pressure on in the first place.
Or maybe Google just has empathy for people losing millions to scams?
No, then the results of many google web searches would not put scam sites at the top over the official sites. Google is fine with people being scammed. As long as they get their cut. Large corporations don't have empathy.
Meta ads too. It’s bonkers the type of ads they approve, straight up scams or obvious misinformation (some prominent figure is in jail! Click here to find out!)
The Play Store is full of of scam apps so obviouly they don't.
From what I've seen, millions lost to scams are with social engineering; through cold calls masquerading as the authorities, phishing, pig butchering; plenty of scam apps on the Play store harvesting data as well, but not a single real life instance of malware installed outside the officially sanctioned platform.
The same scams Google's ad network facilitates and Google in turn profits from?
this is an unresolvable issue
or in this case:This is the worst of both worlds, you can spread your malware as a sideloaded apk just fine, but when it's so big that you're probably burned anyways, then you need to verify your account.
I think a better compromise would have been for google to require developer verification, but also allow third party appstores like f-droid that don't require verification but still are required to "sign" the apks, instead of users enabling wide-open apk sideloading. that way, hobbyists can still publish apps in third party stores, and it is a couple of more steps harder for users to fall for social engineering,because they now have to install/enable f-droid, and then find the right malicious app and download it. The apk downloaded straight from the malicious site won't be loaded no matter what.
Google can then require highlighting things like number of downloads and developer reputation by 3rd party appstores, and maybe even require an inconsistent set of steps to search and find apps to make it harder to social engineer people (like names of buttons, ux arrangements, number of clicks,etc.. randomize it all).
What frustrated me on this topic from the beginning is that solutions like what I'm proposing (and better ones) are possible. But the HN prevailing sentiment (and elsewhere) is pitchforks and torches. Ok, disagree with google, but let's discuss about how to solve the android malware problem that is hurting real people, it is irresponsible to do otherwise.
It's not super clear from the post, but if I read it correctly there are two modifications suggested.
What you describe as "worst of both worlds" is about point 1. I'm not sure point 2 is powerful enough to suppor things like f-droid, but again, we'll see.> Google can then require highlighting things like number of downloads and developer reputation by 3rd party appstores
F-droid doesn't want to track number of installs because that is an invasion of privacy.
> require developer verification, but also allow third party appstores like f-droid that don't require verification
Now you've moved the problem from Google gatekeeping apps to Google gatekeeping app stores. We don't want either.
Edit: be sure to read geoffschmidt's reply below /edit
The buried lede:
> a dedicated account type for students and hobbyists. This will allow you to distribute your creations to a limited number of devices without going through the full verification
So a natural limit on how big a hobby project can get. The example they give, where verification would require scammers to burn an identity to build another app instead of just being able to do a new build whenever an app gets detected as malware, shows that apps with few installs are where the danger is. This measure just doesn't add up
And of course: you need an account, rather than simply allowing you to tell your OS that yes, you know what you're doing.
But see also the next section ("empowering experienced users"):
> We are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified
Oh! I thought I had found the crucial piece finally after ~500 words, but there's indeed better news in the section after that! Thanks, I can go sleep with a more optimistic feeling now :)
Also this will kill any impetus that was growing on the Linux phone development side, for better or worse. We get to live in this ecosystem a while longer, let's see if people keep damocles' sword in mind and we might see more efforts towards cross-platform builds for example
Let's take the "W". This is pretty good news!
This is not a win. This is having independent distribution shut down and controlled.
We no longer own our devices.
We're in a worse state than we were in before. Google is becoming a dictator like Apple.
I am not english native. Is "The W" a synonym for "A Win", described as a positive outcome after a contest? Is there more nuance or context than that?
Yes, but it's often just "a W" or simply "W" in response to something good or seen as a "win."
There is also the same thing with L for loss/loser. "that's an L take", "L [person]", "take the L here", etc.
They are pretty straightforward in their meaning, basically what you described. I believe it comes from sports but they are used for any good or bad outcome regardless of whether it was a contest.
I think it's from people reporting sports statistics for a player or team as "W:5 L:7" meaning "five wins and seven losses".
https://knowyourmeme.com/memes/l-and-w-slang
This isn't a "W", but I am finding my own "W" from this by seeing others distrust Google, and remembering to continue supporting and looking for open alternatives to Google.
That doesn't say that you can just build an APK and distribute it. I suspect this path _still_ requires you to create a developer console account and distribute binaries signed by it... just that that developer account doesn't have to have completed identity verification.
it's probably just gonna be under the Developer Options "secret" menu
Which is totally fine IMO, it was weird to me that they weren't going with this approach when they first announced it.
Macs blocked launching apps from unverified devs, but you can override in settings. I thought they could just do something along those lines.
That's not fine at all. A developer who doesn't want to (or can't) distribute through the Play Store will now need to teach their users how to enable developer mode and toggle a hidden setting. This raises the barrier a bit more than the current method of installing outside the Play Store.
So.. all this drama over an alert(yes/no) box?
Wow, this really pulls back the veil. This Vendor (google) is only looking out for numero uno.
> So.. all this drama over an alert(yes/no) box?
A simple yes/no alert box is not "[...] specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer". In fact, AFAIK we already have exactly that alert box.
No, what they want is something so complicated that no muggle could possibly enable it, either by accident or by being guided on the phone.
I imagine what they're going to do involves a time delay so a scammer cannot wait on the phone with a victim while they do it.
> So.. all this drama over an alert(yes/no) box?
The angry social media narratives have been running wild from people who insert their own assumptions into what’s happening.
It’s been fairly clear from the start that this wasn’t the end of sideloading, period. However that doesn’t get as many clicks and shares as writing a headline claiming that Google is taking away your rights.
I don't think this section is actually the same as the present state just with a new alert box.
I suspect they mean you have to create a android developer account and sign the binaries, this new policy just allows you to proceed without completing the identity verification on that account.
> The angry social media narratives have been running wild from people who insert their own assumptions
There may have been exaggerations in some cases but these hand wavy responses like "you can still do X but you just can't do Y and Z is now mandatory" or "you can always use Y" is how we got to this situation in the first place.
This is just the next evolution of SafetyNet & play integrity API. Remember how many said use alternatives. Not saying safetynet is bad but I don't believe their intentions were to stop at just that.
> The angry social media narratives have been running wild from people who insert their own assumptions into what’s happening.
No, until this post, Google had said that it wouldn't be possible to install an app from a developer who hadn't been blessed by Google completely on your device. That is unacceptable. This blog post contains a policy change from Google.
Sorry what? Their original plan absolutely was the end of sideloading on-device outside of Google's say so. That's what the angry social media narratives were that you seem upset about. Anyone being pedantic and pointing out that adb install is still an option therefore sideloading still exists can fuck off at this point.
What are you talking about? This change for "experienced users" was only just announced and not part of any previous announcement. It has not been clear from the start at all.
Have you missed the plot entirely? This is absurd
Let me guess, a warning box that requires me to give permission to the app to install from third-party sources? Is that not clear enough confirmation that I know what I'm doing? /s
> Keeping users safe on Android is our top priority.
I highly doubt this is your "top" priority. Or if it is then you're gotten there by completely ignoring Google account security.
> intercepts the victim's notifications
And who controls these notifications and forces application developers to use a specific service?
> bad actors can spin up new harmful apps instantly.
Like banking applications that use push or SMS for two factor authentication. You seem to approve those without hesitation. I guess their "top" priority is dependent on the situation.
> > intercepts the victim's notifications
> And who controls these notifications and forces application developers to use a specific service?
Am I alone in being alarmed by this? Are they admitting that their app sandboxing is so weak that a malicious app can exfil data from other unaffiliated apps? And they must instead rely on centralized control to disable those apps after the crime? So.. what’s the point of the sandboxing - if this is just desktop level lack of isolation?
Glossing over this ”detail” is not confidence inspiring. Either it’s a social engineering attack, in which case an app should have no meaningful advantage over traditional comms like web/email/social media impersonation. Or, it’s an issue of exploits not being patched properly, in which case it’s Google and/or vendor responsibility to push fixes quickly before mass malware distribution.
The only legit point for Google, to me, is apps that require very sensitive privileges, like packet inspection or OS control. You could make an argument that some special apps probably could benefit from verification or special approvals. But every random app?
> Are they admitting that their app sandboxing is so weak that a malicious app can exfil data from other unaffiliated apps?
An app can read the content of notifications if the appropriate permissions are granted, which includes 2FA codes sent by SMS or email. That those are bad ways to provide 2FA codes is its own issue.
I want that permission to exist. I use KDE Connect to display notifications on my laptop, for example. Despite the name, it's not just for KDE or Linux - there are Windows and Mac versions too.
yes, they're admitting that their APIs are powerful enough to build accessibility tools (which often must read notifications) and many other useful things (e.g. Pushbullet) that are not possible on iOS.
powerful stuff has room for abuse. I didn't really think there's much of a way to make that not the case. it's especially true for anything that you grant accessibility-level access to, and "you cannot build accessibility tools" is a terrible trade-off.
(personally I think there's some room for options with taint analysis and allowing "can read notifications = no internet" style rules, but anything capable enough will also be complex enough to be a problem)
Only a few things in life are for sure. Death, taxes, and corpospeak.
Hey, sometimes the dumbest people it works on are also the ones with the decision making ability. What a world to live in.
Their top priority is making money.
BINGO! Google doesn't care at all about user security.
- Just yesterday there was a story on here about how Google found esoteric bugs in FFMPEG, and told volunteers to fix it.
- Another classic example, about how Google doesn't give a stuff about their user's security is the scam ads they allow on youtube. Google knows these are scams, but don't care because they there isn't regulation requiring oversight.
> Just yesterday there was a story on here about how Google found [a security vulnerability that anyone running `ffmpeg -i <untrusted file> ...` was vulnerable to] in FFMPEG, and told [the world about it so that everyone could take appropriate action before hackers found the same thing and exploited it, having first told the ffmpeg developers about it in case they wanted to fix it before it was announced publicly]
Fixed that for you. Google's public service was both entirely appropriate and highly appreciated.
> and highly appreciated.
Not by the maintainers it wasn't Mr. Google.
Yes, but it was a public service not a service for the maintainers, and as a member of the public who like anyone who had run `ffmpeg -i <thing I downloaded from the internet>` was previously exposed to the vulnerability I highly appreciate their service.
I'd highly appreciate even if the maintainers never did anything with the report, because in that case I would know to stop using ffmpeg on untrusted files.
So you were using untrusted video files that required the LucasArts Smush codec?
Again, if YOU highly appreciate their service, that's great, but FFMPEG isn't fixing a codec for a decades old game studio, so all Google has done is tell cyber criminals how to infect your Rebel Assault 2. I'm glad you find that useful.
No, I was running on normal untrusted video files. The standard ffmpeg command line would happily attempt to parse those with the LucasArts Smush codec even though I'd never heard of it before.
See the POC in the report by google, the command they run is just `./ffmpeg -i crash.anim -f null /dev/null -loglevel repeat+trace -threads 1` and the only relevant part of that for being vulnerable is that crash.anim is untrusted.
Edit: And to be clear, it doesn't care about the extension. You can name it kittens.mp4 instead of crash.anim and the vulnerability works the same way.
Making money and complying with the law. They are obligated to do both. In many countries laws are still enforced.
Protecting their app store revenues from competition exposes them to scrutiny from competition regulators and might be counter productive.
Many governments are moving towards requiring tech companies to enforce verification of users and limit access to some types of software and services or impose conditions requiring software to limit certain features such as end to end encryption. Some prominent people in big tech believe very strongly in a surveillance state and we are seeing a lot of buy in across the political spectrum, possibly due to industry lobbying efforts. Allowing people to install unapproved software limits the effectiveness of surveillance technologies and the revenues of those selling them. If legal compliance risks are pushing this then it is a job for voters, not Google to fix.
Complying with the law is just another way of protecting your money. I have no doubt if they would break laws if they judged it better for the bottom line --- in fact I have little doubt they're already doing so. On the flip side, if there were ruinous penalties for their anticompetitive behaviors (i.e., in the tens or hundreds of billions of dollars) they might change course.
Certainly voters need to have their say, but often their message is muffled by the layers of political and administrative material it passes through.
this is an absurd rant. they invest, like, billions into security. It's not as perfect as you want it to be but "completely ignoring" is a joke. if you've got actual grievances you should say what they are so that we can actually get on your side instead of rolling our eyes
They absolutely eo completely ignore many security and privacy things because they're very selective in what they focus on, particularly around how those things might impact their ad revenue.
How much they spend is no indicator of how and where they spend it, so is hardly a compelling argument.
I'm not the OP but we know that SMS is not secure. Google should try banning that first.
Some security is better than no security. It already took years to even get some of these backwards-thinking companies and services to adopt SMS OTP and it's simple for non-technical users to intuit. Also, believe it or not, some people don't have smartphones, and they will riot if you try to make them switch to any other MFA method...
Of course, I'm not saying we shouldn't push to improve things, but I don't think this is the right reaction either.
> we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified. We are designing this flow specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer. It will also include clear warnings to ensure users fully understand the risks involved, but ultimately, it puts the choice in their hands.
As long as this is a one-time flow: Good, great, yes, I'll gladly scroll through as many prompts as you want to enable sideloading. I understand the risks!
But I fear this will be no better than Apple's flow for installing unsigned binaries in macOS.
Please do better.
Does this allow unsigned binaries like today? Or is this now requiring you have a binary signed by a android developer account but just one without full identity verification.
What if it imposed a longish (one time) cooldown period? A day?
The key question for me is whether this "advanced flow" will allow the practical use of entirely separate app stores (like F-Droid) or if they're going to throw up tons of barriers for every individual app install.
If I were designing the advanced flow, I'd require the decision to be made at phone setup time. Changing your mind later requires a factory reset.
Real sideloaders (F-Droid users, etc.) know at setup time that that's how they'll be using their phone, so it works for them. But ordinary users who are targets for sideloading malware will become a lot less attractive if attackers must convince them to wipe their phone to complete the coercive instructions.
Aliexpress has a similar approach to protect their accounts from takeovers. If you change or forget your password, all your saved payment methods are erased. This makes the account less valuable to an attacker, at the cost of a little pain to authentic account holders.
No, that's ridiculous. If I want to send an app to someone, now they have to wipe their phone to install it? That would kill installing non-Play apps far more than Google's original proposal.
I hadn't installed a non-Play Store app for something like 5 years until this year. I don't see why I should have been forced to factory reset my phone then.
Great, at phone setup when many people don't know anything about the implications of the choice.
And factory reset when it's impossible to backup and restore everything, or anything at all without a Google account
There's a second path, whereby F-Droid registers as an "alternative app store", which is a new category of app created in the fallout of Epic Games v. Google [0]. This is interesting because it applies to all regions and will necessarily need more elevated permissions than the typical REQUEST_INSTALL_PACKAGES permission used today. No idea what requirements Google will impose on such apps.
[0]: https://en.wikipedia.org/wiki/Epic_Games_v._Google
What would they have to offer Google in return for being granted this status? Would they have to ban NewPipe, for example?
Yes, that possibility has occurred to me as well, and is potentially a reasonable compromise (depending on those requirements).
If F-Droid is no longer part of the android community, then neither will I.
I'm not too worried. My employer should be, though.
It all depends on how the flow is implemented.
If it's a one time unlock, eg like developer mode then hopefully it'll just work.
If it's a big long flow per install... Yikes, that's not much better than adb install
Correct me if I'm wrong but doesn't the EU digital markets act mandate this?
EU digital markets mandates that you can install apps through f-droid... but doesn't mandate that those apps don't to comply with Google's signing policy.
Isn't Apple technically complying with this even while forcing notarization? Seems like Google could get away with the same scheme.
Apple says they are. The EU says they aren't. They're fighting over it.
Sounds like they're rolling back the mandatory verification flow:
Based on this feedback and our ongoing conversations with the community, we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified. We are designing this flow specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer. It will also include clear warnings to ensure users fully understand the risks involved, but ultimately, it puts the choice in their hands. We are gathering early feedback on the design of this feature now and will share more details in the coming months.
I'm a little nervous about what this advanced flow is going to look like, given that sideloading already requires jumping through a bunch of hoops to enable and even that apparently wasn't enough to satisfy Google.
I'm cautiously optimistic though. I'm generally okay with nanny features as long as there's a way to turn them off.
> Sounds like they're rolling back the mandatory verification flow
absolutely no. this is for the user side. but if you're a developer who is planning to publish the app in alternative play store/from your website, you have to do verification flow. please read the full text.
That's only if you don't want your users to have to jump through whatever hoops are needed to bypass the verification requirement.
I feel like if safety was really their top priority, they would have done this long ago and not bothered with this mandatory signing nonsense to begin with...
Still, it seems like good news, so I'll take it.
I don’t like to see the word “allow” in the same sentence with a device I own.
It's a device you own, sure. But you've licensed the software.
This is misleading though. There is simply no other choice if you want to use mainstream apps. It could be argued (successfully in my view) that any agreement is null and void due to its acceptance under duress.
Users have an inherent legal right to unconditionally access the full advertised functionality of devices they purchase. Any agreement after that is inherently suspect and I wouldn't be surprised to find out it was ruled unconscionable by some court if it came to that.
> This is misleading though.
This isn't misleading in any way. It's unfortunate and we should be pissed about it, but this is exactly the legal arrangement that Google and Apple came up with.
> I wouldn't be surprised to find out it was ruled unconscionable by some court
Last US court battle, Apple told the court it needed the money from the kids casino to keep its profits, and the court just nodded.
Apple had to be held in comptempt of a court order after 4 years and a deluge of evidence, for us to see any significant move.
I agree it's not awesome, or even good. Unfortunately, it's what we've got today. A fact HN seems to dislike.
Which is an unacceptable loophole in our legal system that should be closed immediately. If I buy a product, even if that product is software, then I own it, and I should have ultimate control my copy of it.
Let's not shoot the messenger (edoceo)
Too many people are in denial about what they actually own, and seem to refuse to accept this battle isn't starting or coming up, we're already in the process of losing it.
Clinging to material ownership feels great on the moment, but that's absolutely not what we need to deal with right now. It's kinda like being so proud to be the registered owner of your car, while it's getting impounded and you'll be spending the next 10 years trying to get it back.
If there is an alternative software that can run on the device without going through extraordinary hoops, I may agree that it is licensed.
If there is no other alternative, buying hardware and licensing software are not two different steps. Its just buying a device.
We need a free-as-in-freedom version of Android.
GrapheneOS
* "Android Developer Verification Discourse" by agnostic-apollo (https://github.com/agnostic-apollo), Termux app (https://github.com/termux/termux-app) developer: https://gist.github.com/agnostic-apollo/b8d8daa24cbdd216687a... (gist.github.com/agnostic-apollo/b8d8daa24cbdd216687a6bef53d417a6) and https://old.reddit.com/r/termux/comments/1ourtxj/android_dev... (old.reddit.com/r/termux/comments/1ourtxj/android_developer_verification_discourse/)
* "Android Developer Verification Proposed Changes" by agnostic-apollo (https://github.com/agnostic-apollo), Termux app (https://github.com/termux/termux-app) developer: https://issuetracker.google.com/issues/459832198 via https://old.reddit.com/r/termux/comments/1ourtxj/android_dev... (old.reddit.com/r/termux/comments/1ourtxj/android_developer_verification_discourse/)
Android Debug Bridge (https://developer.android.com/tools/adb) using two Android smartphones and Termux (https://github.com/termux/termux-app):
* Search for "Smartphone-1 to Smartphone-2" "adb tcpip 5555" in "Motorola moto g play 2024 smartphone, Termux, termux-usb, usbredirect, QEMU running under Termux, and Alpine Linux: Disks with Globally Unique Identifier (GUID) Partition Table (GPT) partitioning": https://old.reddit.com/r/MotoG/comments/1j2g5gz/motorola_mot... (old.reddit.com/r/MotoG/comments/1j2g5gz/motorola_moto_g_play_2024_smartphone_termux/)
* Search for "termux-adb" in "Motorola moto g play 2024 Smartphone, Android 14 Operating System, Termux, And cryptsetup: Linux Unified Key Setup (LUKS) Encryption/Decryption And The ext4 Filesystem Without Using root Access, Without Using proot-distro, And Without Using QEMU": https://old.reddit.com/r/MotoG/comments/1jkl0f8/motorola_mot... (old.reddit.com/r/MotoG/comments/1jkl0f8/motorola_moto_g_play_2024_smartphone_android_14/)
You don't need two phones to use ADB with Termux. Just put the ADB settings app on a split screen and it will work just fine. I used it several months ago.
8 days ago Google and Epic announced a proposed settlement and modification of a permanent injunction that Epic won, I believe this proposed settlement would likely have prohibited Google's plan to forbid installation of third party apps (excluding app stores from the definition of apps) unless those app developers had paid google a registration fee. The proposed settlement is here [1], the relevant portion is
> 13. For a period beginning on the Effective Date through June 30, 2032, Google will [...] and will continue to permit the direct downloading of apps from developer websites and third-party stores without any fees being imposed for those downloads unless the downloads originate from linkouts from apps installed/updated by Google Play (excluding web browsers).
6 days ago the court expressed skepticism as to the proposal and announced that they'd have a hearing, with testimony from expert witnesses, as to whether it would prevent the market harms that the original injunction was trying to cure [2].
Today Google announces this, effectively confirming that they're backing down from their requirement that third party app developers pay google prior to distributing their apps.
Nothing (yet) is explicitly tying these together, but I can't help but suspect that this move is in large part being made to convince the court that they're actually intending to honour this portion of the proposed injunction even though Epic would have little reason to enforce it.
[1] https://storage.courtlistener.com/recap/gov.uscourts.cand.36...
[2] https://storage.courtlistener.com/recap/gov.uscourts.cand.36...
Did we read the same thing? I think Google here said there would be a $25 fee per developer (for those who can't fit in their limited distribution category). I suppose it's much better than a fee per paid install but it's not nothing.
See the "Empowering experienced users" section.
They announced the $25 "verification" plan awhile ago. The new part in this article is that they're going to have it remain possible to install software that didn't do that "verification".
> Based on this feedback and our ongoing conversations with the community, we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified.
Damn. I was excited by the prospect of Google shooting themselves in the foot, inspiring people to make Android replacements that aren't privacy and process nightmares. With this (partial) capitulation, the path of least resistance will remain a proprietary, corporate-controlled, bloated walled garden.
So there was the very concrete problem that F-Droid could not continue to function with the verification requirements, because they rebuild every app and so would have to know every key.
Do the changes here do anything for F-Droid?
In the end when supporting the non tech people in the family, what I would really like is to setup their device so they can install anything on Fdroid but nothing from the play store (unless approved by me) nor direct from an apk.
This is exactly what I do. Works pretty well. I've never needed to restrict the play store. I just tell them not to use it.
I wonder if MDM can do that.
Google is about to find out the next step of this chain - give access to everyone, don't gatekeep / do checks, and yet take responsibility for anything that goes wrong.
"You should open up the tool, put no restrictions, and yet ensure that it is safe and secure" is an impossible task for anyone.
Are there any entities on earth with resources to compete with a complicit global duopoly?
If Android is open source, why can't/won't a community fork it? Graphene OS exists but many folks claim Netflix and banking apps do not work with it (despite allowing logins from any common desktop browser)?
If all widely-accepted phone operating systems are de-facto proprietary, what does this say about the current phase of society?
What choice do non-billionaire/millionaire humans have for living in a single-planet society where technology is so highly integrated (and the inherent non-consensual compromises)?
What If the little people are going to get squeezed even more?
Troubling questions.
LineageOS is based on AOSP and works well. I don't understand the banking app thing either. I suspect it's a regional issue. I can log in to my credit union account via any browser, and if something needs MFA it should be able to use TOTP which works on anything.
Android in practice is full of proprietary blobs, stuck on old kernel versions, and the hardware is barely supported. Lots of downstream crap from the vendors not playing nice. Most devices running Android are instantly doomed to be e-waste. You can look through devices postmarketOS supports, and anything without mainline kernel support and most stuff working is basically e-waste unless someone puts in a lot of work for that particular device. It's a little bit like how modern GPUs don't work without blobs in the kernel anymore and you have to go back to Haswell era or older for things to work with all free software, but the state of smartphones is a few steps worse than that due to their locked down nature.
Pretty much any OnePlus device (other than ones still too new) seems to be a good bet for decent software support (both LineageOS and pmOS). Though annoyingly stuff like the 3G shutdown makes a lot of the earlier models unusable as actual phones these days. At least they can still be computers. Not quite e-waste.
Well, would the community be willing to respond to AI-submitted CVEs without funding?
Southeast Asian scammers - they could've directly said from India/Pakistan.
Oh thank goodness, hopefully its implemented in a way thats not annoying for pro users
There are many real-world sideloading abuse cases in China. Attackers often trick victims with plausible stories—e.g., claiming a flight is delayed—and ask them to sideload an app (a remote‑meeting or remote‑control tool) to share their screen. Once installed, the attacker can view the victim’s screen and intercept SMS 2FA codes for online banking or other sensitive accounts.
Other schemes include impersonating sex workers to lure victims into nude video chats, then persuading them to install an app that harvests private content and contacts for blackmail.
What's the Android situation there? Last I heard Google didn't license Android there and they were using Chinese app stores with forked AOSP Android. Which would seem to put the sideloading decision in the hands of the forked OS.
These unfortunately gullible people would be tricked in many different other ways throughout their daily lives even if it wasn't for the ability to install something on a device that you paid for and outright own.
We don't cater the most stupid in society.
Why should that mean anyone else should lose control of their device? Maybe at some point you have to accept that it's the user's responsibility? Maybe empower users to be aware of what the apps they install are doing, without take their control away?
This is how loss of autonomy always happens in every sphere: make an argument that it's for their own safety that individuals are losing autonomy, and the entity gaining control is superior in knowing what's best, and is taking control only out of the goodness of their heart.
Yes, this is called malware and isn't the fault of being able to install software on your device.
If someone tricks you into handing over the keys to the kingdom, the solution isn't to remove your door.
Google still hasn't changed anything but took the opportunity to again insult their customers within the first headline, titled "Why verification is important".
Google goes on to say how taking away one of your last remaining rights is good for you, if you like it or not.
It is clear to everyone why Google is partnering with governments around the world to remove our rights to installing apps. Laws are not on your side and must be reevaluated on an individual level to move forward. You decide your own terms, you have the power.
Only we can stop this together.
This brings back memories of "sure you can root your phone, but if you do secure apps like payment won't run anymore"
I can only imagine that allowing "unverified" apps to run would also disable payment/banking apps. Just in case, you know. For your own good.
The Tyranny of the Marginal User strikes again.
Glad to see Google come to their senses on this. Disabling it entirely would have basically guaranteed an exodus of power users over to iOS. If your only choices are walled gardens, you might as well pick the easiest, prettiest one.
it's not
> "Google come to their senses on this"
it's
> "Google was forced to their senses on this"
If adb is unrestricted and can work with the Linux command shell (something I seem to remember I had read about before; you will need to enable the developer mode to use it), which is aparently a separate system but runs on the same device, although if it has the ability to communicate with the main Android system using adb (which it might be reasonable to require that to be explicitly enabled with another setting, for additional security in case you do not use adb), then this would help since you do not require another computer that would be compatible with adb in order to do it.
However, I think there are other things they should do as well (in addition to the other things) if they want to improve the safety, such as looking at the apps in Google Play to check that they are not malware (since apparently some are; however, it says they do have some safeguards, so hopefully that would help), and to make the permission system to work better (e.g. to make it clear that it can intercept notificatinos; there are legitimate reasons to do this but it should require an explicit permission setting to make this clear).
> When the user logs into their real banking app, the malware captures their two-factor authentication codes
That seems like a severe security bug in Android APIs or sandboxing or something else.
> bad actors can spin up new harmful apps instantly
Why are harmful apps possible at all?
As soon as a platform gives control to the fullscreen, harmful apps are possible.
See for example Apple detecting if a user is typing on a keyboard while in a fullscreen website, and then blocking the website. Yes it's as crazy as it's sounds.
so still distributing with f-droid is messed up? i now have to pay a fee to develop an open-source app via f-droid to everyone?
this is a misleading title. they only allow side-loading unverified apps only on fewer devices.
This is great news to me. I'm going to celebrate it. As evil as everyone thinks they are, they did the right thing here. Thanks google.
"We have realised that boiling the frog this fast will result in it jumping out of the water. Therefore we have slowed down, but remain steadfastly devoted to seeing this frog boiled"
"Based on this feedback and our ongoing conversations with the community, we are building a new advanced flow that allows experienced users to accept the risks of installing software that isn't verified. We are designing this flow specifically to resist coercion, ensuring that users aren't tricked into bypassing these safety checks while under pressure from a scammer. It will also include clear warnings to ensure users fully understand the risks involved, but ultimately, it puts the choice in their hands. We are gathering early feedback on the design of this feature now and will share more details in the coming months."
So they haven't actually changed anything yet, but they say that they will "in the coming months."
We really need to banish the term "sideloading". Installing apps on a terminal is just that, and for as long as I remember on windows, Linux it has always been just that.
Google mentions about being on a call, and being tricked into handing over codes. So why not use signals and huristics to decide?
If user is on a call, block any ability to install a shady app. Implement a cool down before that functionality is restored (say 24 hours). It can also detect where the user is based to add additional protection (such as mandating the use of play protect to scan the app before it's activated and add another cool down regardless).
There's lots of ways to help protect the user but it's wrong to ultimately control them. The real world is full of scary dangers that technology is trying to solve but is actively making things worse (such as computerized safety systems in cars).
Ultimately, the user is responsible and whilst it's palpable Google would want to reduce harm in this specific way, we know authoritarian governments would also love to be able to dictate what software people can run. The harm to democracy is simply too great in favor of saving a few people's money.
Over the long run this might help Android a lot
Ahh yes,the slow boiling continues.
So if I want to release a free android game my options are.
A: Hope Google doesn't change course again.
B: Give Google a copy of my apartment lease,
Would be too hard for them to ya know actually implement sandboxing which would prevent this.
Anything aside from full bootloader access means I'm renting my device.
Too late now though.
I still remember when I could give my friends an exe of the stupid little games I made, worry free.
I guess that makes me a cybercriminal, doesn't it.
They didn't say no changes. They are just saying we'll address the concerns of hobbyists and students.
Lets not celebrate prematurely and let us wait for more details on whats actually changing both technically and process wise. We should demand more clarity and should not wait to discover it after the implementation at which point it is hard and nearly impossible to push back against.
We don't want to be in a situation where they technically make it possible but make it practically impossible to install apps outside playstore.
Imagine you could do with your hardware what you wanted. Brave. Innovative. Revolutionary.
/Old man laughing at "cloud" that is my baremetal.
I worry that the overton window has shifted so much after over a decade and a half of most downloads being mediated by "app stores" that most people don't realize or have the means to vocalize or understand what they're missing.
Glad to see them being less evil.
So they can be less evil to more people rather than pushing people to a non-evil platform.
What is the non-evil phone platform? Aftermarket Android ROMs?
Sadly, less evil is still evil.
Now allow individuals to release apps again.
I have to admit I couldn't even understand this problem, because for me the "stock OS" is already unbearable and I'd simply never be able to use it - I've never used it for more than a hour..
i think your opinion is pretty dated.
The issue is that of network effects. Making it harder to sideload for example f-droid makes the already small market for it even smaller, leading to less apps. It also forces people developing Apps that they don't want to reveal to be developing for completly valid reasons (Imagine developing a porn app in saudi arabia or an abortion support app in the USA) to validate against google aka the US Government.
I'm just presenting my exotic point of view - since that developer verification would only be needed to run apps on the "stock OS" (which I consider bad), then deliberately excluding it could promote using LineageOS/GrapheneOS which would be a good thing.
But of course I'm talking about non-commercial apps, but commercial app developers would already be on Google Play.
Ask yourself how relevant and interesting you'd find this comment if someone else had posted it.
I'd agree because I'd feel the same :)
As to relevance to the article - I'm not cheering that much because if Google made "stock OS" even worse then maybe more users would flock to LineageOS/GrapheneOS which would be a great thing and make it harder to push Play Integrity.