At this point I'm convinced that there's something deeply wrong with how our society treats technology.
Ruining Android for everyone to try to maybe help some rather technologically-hopeless groups of people is the wrong solution. It's unsustainable in the long run. Also, the last thing this world needs right now is even more centralization of power. Especially around yet another US company.
People who are unwilling to figure out the risks just should not use smartphones and the internet. They should not use internet banking. They should probably not have a bank account at all and just stick to cash. And the society should be able to accommodate such people — which is not that hard, really. Just roll back some of the so-called innovations that happened over the last 15 years. Whether someone uses technology, and how much they do, should be a choice, not a burden.
This has nothing to do with keeping people safe. If it did then power users could continue to install their own software by being given that ability as a developer setting. The fact that some people are gullible enough to go into a hidden setting on their phone and enable that in order to install an app from a random Chinese website is not a good reason to take away everyone's freedom. Consolidation of power is all this is about.
> Ruining Android for everyone to try to maybe help some rather technologically-hopeless groups of people is the wrong solution.
This isn't about how skilled a person is, it is about tackling social engineering. The article gave the example of someone posing as a relative, it could also be a blackmail scheme, but it could also be the carefully planned takeover of a respected open source project (ahem, xz).
What I am saying is this sort of crime affect anyone. We simply see more of it among the vulnerable because they are the low hanging fruit. Raising the bar will only change who is vulnerable. Society is simply too invested in technology to dissuade criminals. Which is why I don't think this will work, and why I think going nuclear on truly independent developers is going to do more damage than good.
There's quite a gap between this sort of opportunistic scamming that's happening all over the world and targeted multi-year campaigns that probably require the resources of a nation state.
> People who are unwilling to figure out the risks just should not use smartphones and the internet.
Sounds great in theory, but just today I was reminded how impossible this is when walking back from lunch, I noticed all the parking meters covered with a hood, labelled with instructions on how to pay with the app.
> People who are unwilling to figure out the risks just should not use smartphones and the internet.
That train has left the station decades ago. The internet has become an essential part of modern societies. People can't not use the internet (or smartphones), at least if they don't live in the woods.
I was always under the impression security was a red herring and the real reason was control. Google wants to own the device and rent it to users with revocable terms the same way SaaS subscription software works. Locking down what can run is a key step in that process
I worked at a bank on the backend for architecture and security.. and I've posted this before, but the sheer volume of fraud and fraud attempts in the whole network is astonishing. Our device fingerprinting and no-jailbreak-rules weren't even close to an attempt control. It was defense.
I'm not coming to Google's defense, but fraud is a big, heavy, violent force in critical infrastructure.
I like this idea. But last time I tried it the customer representative on the other line told me they were sorry but they could not accommodate my request at this time.
Not sure how it works in countries that didn't go through 80 years of socialism, but I assume that you're saying that in those countries, your salary is required to go to your bank account and can't be paid in cash. Then you can still pretty much "stick to cash" by withdrawing the whole thing on your payday. But then idk, maybe everyone in those countries is aware of the risks related to keeping their money in a bank, it's just the internet banking that introduces the new ones for them.
Illegal would by a hyperbole. But the noose is tightening a bit.
There are upcoming limits for cash transactions (10K, countries can opt to go lower), and strong requirements for identity verification at 3K or more euros in cash.
Also illegal in Denmark. You need a NemKonto by law. Also making cash payments over 15000 is illegal since 2024.
So you can't make a large purchase without a bank transfer.
Not illegal per se in Germany but you won't find a legal job that doesn't require you to have a bank account. Benefits will also only be paid electronically (exceptions for some asylum seekers apply).
You also cannot get a tax refund or pay taxes without a bank account.
Is this even the reason? If Android phonemakers are simply concerned about tech-illiterate users switching to iPhone, they could sell a locked-down Android phone that requires some know-how to unlock.
Your mistake is taking Google's argument at face value. Protecting users is an outright lie, this is purely about control.
Google doesn't give one single shit if users download malware from the Play Store, but hypothetical malware from third party sources is so much worse that we need to ruin the whole OS? That doesn't pass the sniff test.
Google wants to make sure you can only download malware from developers who give google a cut. They want to control the OS and remove user choice. That's all it is. That's what it's always been about.
"Protecting users" is a pretense and nothing more. Google does not care at all about user safety. They aren't even capable of caring at this point. There are far, far cheaper and more effective ways to actually protect users, and google isn't doing any of them.
I'm assuming good faith and giving them the benefit of the doubt.
Of course it might be that they want more control. In addition to controlling the world's most popular web browser and the world's most popular search engine and the world's most popular online advertising network and the world's most popular online video service.
It's really hard to when there's already technical solutions. They could require a process like bootloader unlocking that puts it in "dev" mode for instance
While signing is useful, leaving no escape hatch imo is blatantly predatory
These restrictions already don't apply to something you install over adb, so there's already that. But that still considerably raises the bar for things like apps made by sanctioned entities, for example, most Russian banks.
It's all part of the war on general computing. This dystopian nightmare is coming to desktop operating systems too. See the age verification stuff that's all of a sudden being pushed hard by countries all over the world.
As someone that was going to switch from iPhone to Android/Pixel later this year, at least now I know not to bother anymore, as the locking down of Android won't stop here.
This is going to hurt legitimate sideloading way more than actually necessary to reduce scams:
- Must enable developer mode -- some apps (e.g., banking apps) will refuse to operate and such when developer mode is on, and so if you depend on such apps, I guess you just can't sideload?
- One-day (day!!!) waiting period to activate (one-time) -- the vast majority of people who need to sideload something will probably not be willing to wait a day, and will thus just not sideload unless they really have no choice for what they need. This kills the pathway for new users to sideload apps that have similar functionality to those on the Play Store.
The rest -- restarting, confirming you aren't being coached, and per-install warnings -- would be just as effective alone to "protect users," but with those prior two points, it's clear that this is just simply intended to make sideloading so inconvenient that many won't bother or can't (dev mode req.).
>- Must enable developer mode -- some apps (e.g., banking apps) will refuse to operate and such when developer mode is on, and so if you depend on such apps, I guess you just can't sideload?
Hi, I'm the community engagement manager @ Android. It's my understanding that you don't have to keep developer options enabled after you enable the advanced flow. Once you make the change on your device, it's enabled.
If you turn off developer options, then to turn off the advanced flow, you would first have to turn developer options back on.
>- One-day (day!!!) waiting period to activate (one-time) -- the vast majority of people who need to sideload something will probably not be willing to wait a day, and will thus just not sideload unless they really have no choice for what they need.
ADB installs are not impacted by the waiting period, so that is an option if you need to install certain unregistered applications immediately.
> ADB installs are not impacted by the waiting period, so that is an option if you need to install certain unregistered applications immediately.
Someone is just going to make a nice GUI application for sideloading apks with a single drag-and-drop, so if your idea is that ADB is a way to ensure only "users who know what they're doing" are gonna sideload, you've done nothing. This is all security theatre.
The scammers don't even need to make a GUI, they just need to get you to enable adb-over-tcp and bridge that to their network somehow - an ssh client app would do the trick.
If you mean things like Shizuku or local adb connection through Termux, it's quite an awkward process to set up even for someone like me who's been building Android apps since 2011. Like, you can do if you really really need it, but most people won't bother. You have to do it again after every reboot, too.
Do I need to be signed in to Google play to get the sideloading exception turned on? I don't sign in to it because I don't want to have my phone associated with a Google account. But I can't uninstall play completely on the devices I have.
It says something about 'restart your phone and reauthenticate' that's why I'm asking. What do you autenticate?
> ADB installs are not impacted by the waiting period, so that is an option if you need to install certain unregistered applications immediately.
Um yeah but then do I have to install every update via adb? I want to just use F-Droid.
>It says something about 'restart your phone and reauthenticate' that's why I'm asking. What do you autenticate?
You're authenticating that you're the device owner (via your device's saved biometrics or PIN/pattern/password).
>Um yeah but then do I have to install every update via adb? I want to just use F-Droid.
No, once you go through the advanced flow and choose the option to allow installing unregistered apps indefinitely, you can both install and update unregistered apps without going through the flow again (or using ADB).
So... we're just going to move the scam into convincing the end user to run an application on their PC to ADB sideload the Scam App. Got it, simple enough. It's not hard to coach a user into clicking the "no, I'm not being coached" button, too, to guide them towards the ADB enable flow.
I think this is a "don't let the perfect be the enemy of the good thing". It's technically possible to get around, but adding more speed bumps in the way of scammers tends to drastically reduce the number of people who get scammed.
> This is going to hurt legitimate sideloading way more than actually necessary to reduce scams
Isn't that the objective? "Reducing scams" is the same kind of argument as "what about the children"; it's supposed to make you stop thinking about what it means, because the intentions are so good.
> - Must enable developer mode -- some apps (e.g., banking apps) will refuse to operate and such when developer mode is on, and so if you depend on such apps, I guess you just can't sideload?
What apps are those? I've yet to run into any of my banking apps that refuse to run with developer mode enabled. I've seen a few that do that for rooted phones but that's a different story. I've been running android for a decade and a half now with developer mode turned on basically the whole time and never had an app refuse to load because of it.
The one-day waiting period is so arbitrary. Have they demonstrated any supporting data? We know google loves to flaunt data.
Something like Github's approach of forcing users to type the name of the repo they wish to delete would seem to be more than sufficient to protect technically disinclined users while still allowing technically aware users to do what they please with their own device.
Brother, there's an entire genre of scamming where the scammers spend months building rapport with their victims, usually without ever asking for anything, before "cashing out". One day is nothing.
This is obvious to anyone with a brain. I'm not familiar with scam logistics or the videos you mentioned, and the exact same line you put in quotes is what first came to my mind.
tl;dr of this post is that Google wants to lock down Android and be its gatekeeper. Every other point of discussion is just a distraction.
Right, this friction makes it much harder for a scammer to get away with saying something like, "wire me $10,000 right now or you won't see your child ever again!" as the potential victim is forced to wait 24 hours before they can install the scammer's malicious app, thus giving them time to think about it and/or call their trusted contacts.
Sure, but what about a 30 minute delay? 1 hour? 2 hour?
24 is just so long.
But also, my expectation is that a scammer is going to just automate the flow here anyways. Cool, you hit the "24 hour" wait period, I'll call you back tomorrow, the next day, or the next day and continue the scam process.
It might stop some less sophisticated spammers for a little bit, but I expect that it'll just be a few tweaks to make it work again.
24 hours is long enough to get them off the phone, and potentially talking to other people who might recognize the scam.
There will be some proportion of people who mention to their spouse/child/friend about how Google called them to fix their phone, and are saved by that waiting period.
Sure, but wouldn't 35 hours do the same trick? Or 5 hours? Or 10 hours and 28 minutes? :)
The question is, why exactly 24 hours? The argument is that the time limit is set to protect the users and sacrifice usability to do so. So it would be prudent to set the time limit to the shortest amount that will protect the user -> and that shortest amount is apparently 24 hours, which is rather.. suspiciously long and round :)
You've got to pick some time value (if you choose this route at all), and if the goal is to prevent urgency-coercion it needs to be at least multiple hours. An extremely-common-for-humans one seems rather obvious compared to, like, 18.2 hours (65,536 seconds).
Unless you want to pick 1 week. But that's a lot more annoying.
Have you ever watched Kitboga? Scammers call people back all the time. They keep spreadsheets of their marks like a CRM. It takes time to build trust and victimize someone, and these scammers are very patient.
> some apps (e.g., banking apps) will refuse to operate and such when developer mode is on
Enable dev mode, sideload the apk, then disable dev mode. I'd argue that it is poor security practice to keep developer mode enabled long-term on a phone that is used for everyday activities, such as banking.
We'll see when this rolls out, but I don't foresee the package manager checking for developer mode when launching "unverified" apps, just when installing them. AFAICT the verification service is only queried on install currently.
Googler here (community engagement for Android) - I looked into the developer options question, and it's my understanding that you don't have to keep developer options enabled after you enable the advanced flow. Once you make the change on your device, it's enabled.
If you turn off developer options, then to turn off the advanced flow, you would first have to turn developer options back on.
You have to wait one day only once, when enabling the feature. I agree that enabling developer mode could be a problem but mostly because it's buried below screens and multiple touches. As a data point, I enabled developer mode on all my devices since 2011 and no banking app complained about it. But it could depend by the different banking systems of our countries.
As described developer mode is only required at install time. Remains to be seen in the actual implementation, but as described in the post developer mode can be switched off after apps have been side loaded.
Yes, it is really dumb that some of these settings are exposed to all apps with no permission gating [0]. But it will likely always be possible to fingerprint based on enabled developer options because there are preferences which can only be enabled via the developer options UI and (arguably) need to be visible to apps.
Because estimates suggest Americans lose about $119 billion annually to financial scams, which is a not insignificant fraction of our entire military budget, or more than 5% of annual social security expenditures.
Most of the victims were last in school in the 1960s when all this stuff didn't exist. Also from experience teaching people with dementia or memory issues is kinda challenging as they just forget.
I wonder if you might be relying on a stereotype of victims. Here's some recent data: "The 2024 FTC Consumer Sentinel Network reported that 44% of all 20-somethings claimed losses in 2023". More data here: https://www.synovus.com/personal/resource-center/fraud-preve...
The forced ID for developers outside the Play store is already killing open source projects you could get on F-Droid. The EU really needs to identify this platform gatekeeping as a threat. As an EU citizen I should not be forced to give government ID to a US company, which can blacklist me without recourse, in order to share apps with other EU citizens on devices we own.
The DSA covers App stores with a large numbers of users - this is about allowing users side load unsigned apps. Afaik there is no requirement to identify the developers of applications that can be installed on a vendors platform (outside the app store). Otherwise Microsoft would require Government ID to compile and email someone an EXE.
I'm not in agreement with most of you, hn. They've found a decent compromise that works for power users and the general population. Your status as a power user does not invalidate the need to help the more vulnerable.
Having to wait a day for a one off isn't a big deal, if they kept it looser then you'd be shouting about the amount of scams that propagate on the platform.
My personal hard line is having to ask Google for permission to sideload. Even if it's free and no personal info is exchanged.
This new process is annoying but I can see it helping prevent scams.
Death, taxes and escalating safety are the only certainities in this tech dominated world. So, be ready for more safety in the next round few months/years down the line. Eventually Android will become as secure as ios. We need a third alternative before that day comes.
It's not a win by any means. I hope that we don't stop making noise.
It's a a defeat, albeit a minor one. The defeats will escalate until there's nothing left to lose. "Normies" don't care and the tech people who do care are fewer and further between than you'd think.
Google serves ads with known scams and nothing seems done about it.
Yet, they are concerned about this.
It has nothing to do with safety, but everything to do with control.
I remember when Google disabled call recording in Android, so you no longer could record scammers. Thanks to recording I was able to get money back from insurance company that claimed they absolutely didn't sell me this and that over the phone (paid for premium insurance and got basic).
I believe that is why "escalating safety" and "secure" were written in italics in the comment. Those are the terms Google would use, not necessarily the truth.
This 24-hour wait time nonsense is a humiliation ritual designed to invalidate any expectation of Android being an open platform. The messaging is very clear and the writing's on the wall now, there's nowhere to go from here but down.
I'm generally OK with this, but the 24 hour hang time does seem a bit onerous.
Most of the apps on my phone are installed from F-Droid. I guess the next time I get a new phone I'll have to wait at least 24 hours for it to become useful.
I'm seriously considering Graphene for a next personal device and whatever the cheapest iOS device is for work.
The apps might not be available though. Many developers are simply stopping in the face of Google's invasive policies. I don't blame them. Say goodbye to useful apps like Newpipe.
A few apps have been showing pop-ups warning users in advance that they are not going to do the verification. Obtanium is definitely on of them. I think I saw something similar on NewPipe.
This is hopefully an exciting time to consider a Motorola device, since they are partnering with GrapheneOS, but I worry that Google will block Google Play Services on any device that doesn't comply, so this might actually be a demoralizing time to be a GrapheneOS fan, when we watch them worm their stupid walled garden nonsense into the Motorola version of it.
> In addition to the advanced flow we’re building free, limited distribution accounts for students and hobbyists. This allows you to share apps with a small group (up to 20 devices) without needing to provide a government-issued ID or pay a registration fee.
I don't quite understand how those installs would be tracked. If I create a "hobbyist" account and share the apk, are the devices that install that app all reporting it to Google? To my knowledge, Google only does this through the optional Play Protect system, is that now no longer optional? I'd like to know if my computer is reporting every app I install up to Google.
I switched to iOS in anticipation of this change. The reality is, if they are thinking about doing this, it's only a matter of time before they do it. If I have to choose between two walled gardens, apple will win every time.
As an idea, what about allowing the 24 hours to be bypassed using adb (edit: bypass to allow indefinitely, not just install a single app)?
I understand there is some problem trying to be solved here, but honestly this is still quite frustrating for legitimate uses. If this is the direction that computing is moving, I'd really rather there were separate products available for power users/devs that reflected our different usage.
Right, if this is being built into AOSP I dont see how they wouldn't add an adb command to immediately skip the "Advanced Flow" wait. if it's safe to let uses run "adb install", then "adb skip-advanced-flow" should be just as safe to do too.
24 hour mandatory wait time to side load!? All apps I want to use on my phone are not in the Play Store. So I buy a new phone (or wipe a used phone) and then I can’t even use it for 24 hours?
1) The one-time, one-day waiting period only applies if you go through the advanced flow to allow installing unregistered apps. You can still install registered apps (ie. apps made by developers who have verified their identity) even if they're distributed outside the Play Store.
2) You can use ADB to immediately install unregistered apps. ADB installs are not subject to the waiting period.
From purely a usability standpoint, not a freedom standpoint, I would actually be okay with that for my personal use if it stayed like that. But the point is that they're just making it worse and worse. They won't stop with this. I can arrange to do without an important app for a day, even if I had to get a new phone unexpectedly (If I had to skip attending an event and stay at home where my computer is, because I could only properly be on call with my sideloaded app, I'd chalk it up to an unusual situation). But it won't be long before they change it again.
Reminder that when you use terminology like "sideloading" you're accepting the premise that there's something inherently dodgy about installing your software onto your hardware.
I'd rather not have to go through this ritual, but I appreciate that there is a genuine security problem that google are trying to address. I also suspect that they have other motivations bound-up in this - principally discouraging use of alternative app stores. But basically I could live with this process.
Yeah, I know... Stockholm syndrome...
Although I may not have to live with it, as none of my present devices are recent enough to still receive ota updates.
Context: I don't use alternative app stores. I occasionally side-load updates to apps that I've written myself, and very occasionally third party apps from trusted sources.
The 24 hour wait period is the largest of the annoyances in this list, but given that adb installs still work, I think this is a list of things I can ultimately live with.
Do you need a Google account to opt out of the restriction? It says something about authenticating.
I don't have a Google account on my Androids. But I can't remove play services on them, sadly. As an intermediate protection I just don't sign in to Google play, that gives them at least a bit less identifying information to play with.
Nothing screams being infantilised by your platform more than having to wait 24 hours to be allowed to install software on your own purchased computing devices.
From my read, it's explicitly a one-time thing. Presumably that means that even if you pick the "allow for 7 days" option, you can re-enable it after that without a delay (maybe with a reboot?).
>And what is malware? For [Android Ecosystem President], malware in the context of developer verification is an application package that “causes harm to the user’s device or personal data that the user did not intend.”
Like when Google, Facebook, Apple, Microsoft, et al. cooperated with¹ the unconstitutional and illegal² PRISM program to hand over bulk user data to the NSA without a warrant? That kind of harm to my personal data that I did not intend?
If so, I'd love to hear an explanation of why every Google/Alphabet, Facebook/Meta, and Microsoft application haven't been removed for being malware already.
I wonder how long this will last before they lock it down further. There was a lot of pushback this time around and they still ended up increasing the temperature of the metaphorical boiling frog. It still seems like they're pushing towards the Apple model where those who don't want to self-dox and/or pay get a very limited key (what Google currently calls "limited distribution accounts").
I am not happy about this, but as long as advanced Android users can still turn this off and keep it off, we're still in a better place than iOS.
Even though I understand the design decisions here, I think we're going about this the wrong way. Sure, users can be pressured into allowing unverified apps and installing malware, and adding a 24-hour delay will probably reduce the number of victims, but ultimately, the real solution here is user education, not technological guardrails.
If I want to completely nuke my phone with malware, Google shouldn't stand in my way. Why not just force me to read some sort of "If someone is rushing you to do this, it is probably an attack" message before letting me adjust this setting?
Anyone who ignores that warning is probably going to still fall for the scam. If anything, scammers will just communicate the new process, and it risks sounding even more legitimate if they have to go through more Google-centric steps.
I'd urge everyone here to seriously consider switching to GrapheneOS. It's a far simpler transition than e.g. switching from Windows or OSX to Linux, and many people find that it has basically no friction vs android.
More people moving to GrapheneOS is the best tool we have against Google's continued and escalating hostility to user freedom and privacy and general anti-competitive conduct. (Of course, you could ditch having a smartphone entirely..., but if you're willing to consider that you don't need me plugging an alternative).
Honestly, if coerced sideloading is a real attack vector, then this seems to be a pretty fair compromise.
I just remain skeptical that this tactic is successful on modern Android, with all the settings and scare screens you need to go through in order to sideload an app and grant dangerous permissions.
I expect scammers will move to pre-packaged software with a bundled ADB client for Windows/Mac, then the flow is "enable developer options" -> "enable usb debugging" -> "install malware and grant permissions with one click over ADB". People with laptops are more lucrative targets anyway.
After today's announced policy goes into effect, it will be easier to coach users to install a Progressive Web App ("Installable Web Apps") than it will be to coach users to sideload a native Android app, even if the Android app has no permissions to do anything more than what an Installable Web App can do: make basic HTTPS requests and store some app-local data. (99% of apps need no more permissions than that!)
I think Google believes it should be easy to install a web app. It should be just as easy to sideload a native app with limited permissions. But it should be very hard/expensive for a malware author to anonymously distribute an app with the permission to intercept texts and calls.
I don't think Google has a strategy around what should be easy for users to do. PWAs still lack native capabilities and are obviously shortcuts to Chrome, and Google pushes developers to Trusted Web Activities which need to be published on the Play Store or sideloaded.
But these developer verification policies don't make any exceptions for permission-light apps, nor do they make it harder to sideload apps which request dangerous permissions, they just identify developers. I also suspect that making developer verification dependent on app manifest permissions opens up a bypass, as the package manager would need to check both on each update instead of just on first install.
Yep, I have a legitimate use case for exactly this. It integrates directly with my application and gives it native phone capabilities that are unavailable if I were to use a VoIP provider of any kind.
As a legitimate developer developing an app with the power to take over the phone, I think it's appropriate to ask you to verify your identity. It should be an affordable one-time verification process.
This should not be required for apps that do HTTPS requests and store app-local data, like 99%+ of all apps, including 99% of F-Droid apps.
But, in my opinion, the benefit of anonymity to you is much smaller than the harm of anonymous malware authors coaching/coercing users to install phone-takeover apps.
(I'm sure you and I won't agree about this; I bet you have a principled stand that you should be able to anonymously distribute malware phone-takeover apps because "I own my device," and so everyone must be vulnerable to being coerced to install malware under that ethical principle. It's a reasonable stance, but I don't share it, and I don't think most people share it.)
I think you read a bit too much into my message. I agree, it's complicated, I don't want my parents and grandparents easily getting scammed.
But yes they are my devices, and I should be able to do exactly what I want with them. If I'm forced to deal with other developers incredibly shitty decisions around how they treat VoIP numbers, guess who's going to have a stack of phones with cheap plans in the office instead of paying a VoIP provider...
But no, I have no interest in actually distributing software like that further than than the phones sitting in my office.
For a security-sensitive permission like intercepting texts and calls, I'm not sure it makes sense for that to be anonymous at all, not even for local development, not even for students/hobbyists.
Getting someone to verify their identity before they have the permission to completely takeover my phone feels pretty reasonable to me. It should be a cheap, one-time process to verify your identity and develop an app with that much power.
I can already hear the reply, "What a slippery slope! First Google will make you verify identity for complete phone takeovers, but soon enough they'll try to verify developer identity for all apps."
But if I'm forced to choose between "any malware author can anonymously intercept texts and calls" or "only identified developers can do that, and maybe someday Google will go too far with it," I'm definitely picking the latter.
> Honestly, if coerced sideloading is a real attack vector, [...]
I don't believe that it is. I follow this "scene" pretty closely, and that means I read about successful scams all the time. They happen in huge numbers. Yet I have never encountered a reliable report of one that utilized a "sideloaded"[1] malicious app. Not once. Phishing email messages and web sites, sure. This change will not help counter those, though.
I don't even see what you could accomplish with a malicious app that you couldn't otherwise. I would certainly be interested to hear of any real world cases demonstrating the danger.
[1] When I was a kid, this was called "installing."
I get that its pretty clear with the straight sideloading case, but can anyone say for sure what this will look like for an f-droid user? Its hard to keep track but I thought something new here because of EU is that alternative app stores != sideloading? Something where app stores could choose themselves to get "verified," whatever that means, to become a trusted vendor? Or is this completely wrong?
They'll just remove the "Advanced" ability in a few years once they've frog boiled people into jumping through hoops to use their phone the way they want.
Meh. I get the annoyance, but it's a one time cost for a small subset of their users. I would prefer if there was a flow during device setup that allowed you to opt into developer mode (with all the attendant big scary warnings), but it's a pretty reasonable balance for the vast majority of their users. (I suspect the number of scammers that are able to get a victim to buy a whole new device and onboard it is probably very low).
Developers, including non-US citizens, are forced to give Google their government ID to distribute apps. This enables Google to track and censor projects, like NewPipe, an alternative open source Youtube frontend, by revoking signing permissions for developers.
>Developers, including non-US citizens, are forced to give Google their government ID to distribute apps.
Developers can choose to not undergo verification, thereby remaining anonymous. The only change is that their applications will need to be installed via ADB and/or this new advanced flow on certified Android devices.
Either way, you can still distribute your apps wherever you want. If you verify your identity, then there are no changes to the existing installation flow from a user perspective. If you choose not to verify your identity, then the installation will still be possible but only through high-friction methods (ADB, advanced flow). These methods are high-friction so anonymous scammers can't easily coerce their victims into installing malicious software.
This. Side loading being restricted is only one part of the problem; the other is mandatory developer verification for apps distributed through the Play Store.
That's not correct - the flow described in the post outlines the requirements to install any apps that haven't had their signature registered with Google.
That means those apps still keep on existing, they are just more of a hassle to install.
They already announced it. Here they only mention the special case where it does not apply:
> In addition to the advanced flow we’re building free, limited distribution accounts for students and hobbyists. This allows you to share apps with a small group (up to 20 devices) without needing to provide a government-issued ID or pay a registration fee.
i.e. Government-issued ID and fees are needed for more than 20 devices, e,g, every app on F-Droid
I'll say it again: this isn't a problem for Android to solve. Scammers will naturally adapt their "processes" to account for this 24-hour requirement and IMO it might make it seem more legitimate to the victim because there's less urgency.
The onus of protecting people's wealth should fall on the bank / institution who manages that persons wealth.
Nevertheless, this solution is better than ID verification for devs.
Why should the bank/institution be responsible for protecting individuals from themselves? They don't have police power- protecting people from bad actors is like, the reason to have a state. If the state wishes to farm it out to third parties, then we don't need the state anymore!
Yea I have no idea why the original commenter thinks Banks should have the power to tell me what I can and can't do with my own money.
It's nice that Zelle has checks and identity information shown to you when you're sending money, but if I click through 5 screens that say "Yes I know this person" but I actually don't.....no amount of regulation is going to solve that.
Banks absolutely have that power and will stop transactions that seem suspicious or fraudulent already, no? Sometimes they'll call/text to verify you want it go through. I imagine that type of thing but cranked up for accounts flagged "vulnerable" where a family or the person themselves can check a box saying "yes, lockdown this account heavily please" (or whatever you can imagine, idk, I'm not a bank)
The bank/institution is where the money is leaving from therefore they should implement policies that protect vulnerable customers like seniors, for example. I don't know how that looks but it seems reasonable that they could put limits on an account flagged "vulnerable person"
I'm not sure what you're getting at with the rant about police power and a state? Google isn't the government either. What would legislation provide that banks can't already do today?
Sure, there are things banks can do, and those are features they can market. But ultimately, if the state isn't pursuing criminals who prey on the vulnerable, then society as we know it has failed and we would need a new society, or a new state, or both...The bank can't arrest anyone!
I never said anything about it being Googles responsability, I agree it is not. And the only legislation that might be necessary over what we have is a budget directly to go after criminal fraudsters.
Fraud is already illegal, the issue is that these scammers reside in other countries. I don't doubt there could be pressure applied from really high up at the diplomatic level but I highly doubt the FBI for example is going to be able to do anything even with legislation.
> I'll say it again: this isn't a problem for Android to solve.
They're not solving that problem. They're using it as an excuse to lock down the platform further and assume more control. Any incidental benefit for user "security" is an unintended consequence of their real agenda.
It's not like the Google Play store hasn't been known to host malicious apps, yet you are not required to wait 24 hours before you install apps from their store.
I suspect they are hoping users just give up and go to the play store instead. Google touts about "Play Protect" which scans all apps on the device, even those from unknown sources so these measures can barely be justified.
Imagine if Microsoft said you need to wait 24 hours before installing a program not from their store, which is against the entire premise of windows.
Computing, I once believed was based on an open idea that people made software and you could install it freely, yes there are bad actors, but that's why we had antivirus and other protection methods, now we're inch by inch losing those freedoms. iOS wants you to enter your date of birth now.
The future feels very uncertain, but we need to protect the little freedoms we have left, once they're gone, they're gone for good.
It's a little inconvenient for someone setting up a new phone to have to wait a full day to install unregistered apps. But while I can't speak for others, it's a price I'm personally willing to pay to make the types of scams they mention much less effective. The perfect is the enemy of the good.
How would you feel about needing to wait 24 hours to visit an "unapproved" website on your phone? You would pay Google/Apple $25 to get whitelisted so people can browse to your personal website without getting a scary security message.
This is the same thing since it applies to all apps, not just apps that need special permissions.
On what basis do you believe that it will meaningfully reduce the dollars lost or persons harmed by fraud, as opposed to simple shuffling around the exact means used?
At this point I'm convinced that there's something deeply wrong with how our society treats technology.
Ruining Android for everyone to try to maybe help some rather technologically-hopeless groups of people is the wrong solution. It's unsustainable in the long run. Also, the last thing this world needs right now is even more centralization of power. Especially around yet another US company.
People who are unwilling to figure out the risks just should not use smartphones and the internet. They should not use internet banking. They should probably not have a bank account at all and just stick to cash. And the society should be able to accommodate such people — which is not that hard, really. Just roll back some of the so-called innovations that happened over the last 15 years. Whether someone uses technology, and how much they do, should be a choice, not a burden.
This has nothing to do with keeping people safe. If it did then power users could continue to install their own software by being given that ability as a developer setting. The fact that some people are gullible enough to go into a hidden setting on their phone and enable that in order to install an app from a random Chinese website is not a good reason to take away everyone's freedom. Consolidation of power is all this is about.
> Ruining Android for everyone to try to maybe help some rather technologically-hopeless groups of people is the wrong solution.
This isn't about how skilled a person is, it is about tackling social engineering. The article gave the example of someone posing as a relative, it could also be a blackmail scheme, but it could also be the carefully planned takeover of a respected open source project (ahem, xz).
What I am saying is this sort of crime affect anyone. We simply see more of it among the vulnerable because they are the low hanging fruit. Raising the bar will only change who is vulnerable. Society is simply too invested in technology to dissuade criminals. Which is why I don't think this will work, and why I think going nuclear on truly independent developers is going to do more damage than good.
There's quite a gap between this sort of opportunistic scamming that's happening all over the world and targeted multi-year campaigns that probably require the resources of a nation state.
> People who are unwilling to figure out the risks just should not use smartphones and the internet.
Sounds great in theory, but just today I was reminded how impossible this is when walking back from lunch, I noticed all the parking meters covered with a hood, labelled with instructions on how to pay with the app.
https://www.cbc.ca/news/canada/saskatchewan/city-of-regina-r...
> People who are unwilling to figure out the risks just should not use smartphones and the internet.
That train has left the station decades ago. The internet has become an essential part of modern societies. People can't not use the internet (or smartphones), at least if they don't live in the woods.
Have you read my comment in full?
I was always under the impression security was a red herring and the real reason was control. Google wants to own the device and rent it to users with revocable terms the same way SaaS subscription software works. Locking down what can run is a key step in that process
I worked at a bank on the backend for architecture and security.. and I've posted this before, but the sheer volume of fraud and fraud attempts in the whole network is astonishing. Our device fingerprinting and no-jailbreak-rules weren't even close to an attempt control. It was defense.
I'm not coming to Google's defense, but fraud is a big, heavy, violent force in critical infrastructure.
I like this idea. But last time I tried it the customer representative on the other line told me they were sorry but they could not accommodate my request at this time.
Idiocracy needs a spiritual "sequel" with modern times.
It is called baseline reality, unfortunately.
We haven't started watering crops with salt-water but it's only a matter of time.
Given how many tech savvy people here run OpenClaw or one of it’s copycats I wouldn’t be so harsh in my judgment.
>They should probably not have a bank account at all and just stick to cash
Pretty much illegal in some parts of EU
Completely illegal in Spain if you have a paid job.
Not sure how it works in countries that didn't go through 80 years of socialism, but I assume that you're saying that in those countries, your salary is required to go to your bank account and can't be paid in cash. Then you can still pretty much "stick to cash" by withdrawing the whole thing on your payday. But then idk, maybe everyone in those countries is aware of the risks related to keeping their money in a bank, it's just the internet banking that introduces the new ones for them.
>Then you can still pretty much "stick to cash" by withdrawing the whole thing on your payday.
Not if you want to make a purchase beyond a small amount, like $500 or $1000. Then it has to be through some fucking bank or CC.
All withdrawals of more than 1000€ in Spain must be accounted for and more than 5000€ must be authorized.
You "may" but maybe you "cannot".
Source?
Also how is it related to the EU if it only affects certain places? Could have just said certain places in Europe
Illegal would by a hyperbole. But the noose is tightening a bit.
There are upcoming limits for cash transactions (10K, countries can opt to go lower), and strong requirements for identity verification at 3K or more euros in cash.
See: https://www.deloittelegal.de/dl/en/services/legal/perspectiv...
EDIT: The other side of the coin is that banks are _required_ to give legal residents of a country a basic account that can be used for payments.
Also illegal in Denmark. You need a NemKonto by law. Also making cash payments over 15000 is illegal since 2024. So you can't make a large purchase without a bank transfer.
Spain: you must be paid through a bank if you
-have a steady contract -are paid more than 1000€ for a job (say you are self-employed).
Not illegal per se in Germany but you won't find a legal job that doesn't require you to have a bank account. Benefits will also only be paid electronically (exceptions for some asylum seekers apply).
You also cannot get a tax refund or pay taxes without a bank account.
> just should not use smartphones and the internet
That's ridiculous. Phones are being made more and more of a requirement to participate in society, including by governments.
Which is exactly my point! This is exactly the thing that desperately needs to be undone.
>That's ridiculous. Phones are being made more and more of a requirement to participate in society, including by governments.
The latter is what's ridiculous, not what the parent suggests.
Is this even the reason? If Android phonemakers are simply concerned about tech-illiterate users switching to iPhone, they could sell a locked-down Android phone that requires some know-how to unlock.
This was a reason that someone at Google gave iirc, but its ridiculous.
Its not society, this is simply more fascism. Corperate and government cooperation to surviel and controll the masses.
So long as the 5g chips and the 2 mobile app stores remain under control, then 5 eyes has nearly full coverage.
A fascist society is a society. Members of that society will gladly vote in more fascism.
Your mistake is taking Google's argument at face value. Protecting users is an outright lie, this is purely about control.
Google doesn't give one single shit if users download malware from the Play Store, but hypothetical malware from third party sources is so much worse that we need to ruin the whole OS? That doesn't pass the sniff test.
Google wants to make sure you can only download malware from developers who give google a cut. They want to control the OS and remove user choice. That's all it is. That's what it's always been about.
"Protecting users" is a pretense and nothing more. Google does not care at all about user safety. They aren't even capable of caring at this point. There are far, far cheaper and more effective ways to actually protect users, and google isn't doing any of them.
I'm assuming good faith and giving them the benefit of the doubt.
Of course it might be that they want more control. In addition to controlling the world's most popular web browser and the world's most popular search engine and the world's most popular online advertising network and the world's most popular online video service.
It's really hard to when there's already technical solutions. They could require a process like bootloader unlocking that puts it in "dev" mode for instance
While signing is useful, leaving no escape hatch imo is blatantly predatory
These restrictions already don't apply to something you install over adb, so there's already that. But that still considerably raises the bar for things like apps made by sanctioned entities, for example, most Russian banks.
It's all part of the war on general computing. This dystopian nightmare is coming to desktop operating systems too. See the age verification stuff that's all of a sudden being pushed hard by countries all over the world.
As someone that was going to switch from iPhone to Android/Pixel later this year, at least now I know not to bother anymore, as the locking down of Android won't stop here.
what
This is going to hurt legitimate sideloading way more than actually necessary to reduce scams:
- Must enable developer mode -- some apps (e.g., banking apps) will refuse to operate and such when developer mode is on, and so if you depend on such apps, I guess you just can't sideload?
- One-day (day!!!) waiting period to activate (one-time) -- the vast majority of people who need to sideload something will probably not be willing to wait a day, and will thus just not sideload unless they really have no choice for what they need. This kills the pathway for new users to sideload apps that have similar functionality to those on the Play Store.
The rest -- restarting, confirming you aren't being coached, and per-install warnings -- would be just as effective alone to "protect users," but with those prior two points, it's clear that this is just simply intended to make sideloading so inconvenient that many won't bother or can't (dev mode req.).
>the vast majority of people who need to sideload something will probably not be willing to wait a day
I disagree with this. Won't somebody who need to sideload something will just try again the next day...
>- Must enable developer mode -- some apps (e.g., banking apps) will refuse to operate and such when developer mode is on, and so if you depend on such apps, I guess you just can't sideload?
Hi, I'm the community engagement manager @ Android. It's my understanding that you don't have to keep developer options enabled after you enable the advanced flow. Once you make the change on your device, it's enabled.
If you turn off developer options, then to turn off the advanced flow, you would first have to turn developer options back on.
>- One-day (day!!!) waiting period to activate (one-time) -- the vast majority of people who need to sideload something will probably not be willing to wait a day, and will thus just not sideload unless they really have no choice for what they need.
ADB installs are not impacted by the waiting period, so that is an option if you need to install certain unregistered applications immediately.
> ADB installs are not impacted by the waiting period, so that is an option if you need to install certain unregistered applications immediately.
Someone is just going to make a nice GUI application for sideloading apks with a single drag-and-drop, so if your idea is that ADB is a way to ensure only "users who know what they're doing" are gonna sideload, you've done nothing. This is all security theatre.
The scammers don't even need to make a GUI, they just need to get you to enable adb-over-tcp and bridge that to their network somehow - an ssh client app would do the trick.
> “For a lot of people in the world, their phone is their only computer, and it stores some of their most private information,” Samat said.
Not applying the policy to adb installs makes a lot more sense if the people this is trying to protect don't have a computer
I've seen a few apps that run locally on Android and hook into the ADB connection over loopback networking to do certain things.
This just adds the step of "download Cool ABD Installer from the play store" to the set of directions I would think.
You can run adb install locally without a computer
If you mean things like Shizuku or local adb connection through Termux, it's quite an awkward process to set up even for someone like me who's been building Android apps since 2011. Like, you can do if you really really need it, but most people won't bother. You have to do it again after every reboot, too.
Scammers will figure something out to help that workflow smoother, you can count on that.
May I use ADB or Developer mode to disable the one-day period?
Do I need to be signed in to Google play to get the sideloading exception turned on? I don't sign in to it because I don't want to have my phone associated with a Google account. But I can't uninstall play completely on the devices I have.
It says something about 'restart your phone and reauthenticate' that's why I'm asking. What do you autenticate?
> ADB installs are not impacted by the waiting period, so that is an option if you need to install certain unregistered applications immediately.
Um yeah but then do I have to install every update via adb? I want to just use F-Droid.
I think the authentication is doing your face/fingerprint/passcode unlock?
Correct.
>It says something about 'restart your phone and reauthenticate' that's why I'm asking. What do you autenticate?
You're authenticating that you're the device owner (via your device's saved biometrics or PIN/pattern/password).
>Um yeah but then do I have to install every update via adb? I want to just use F-Droid.
No, once you go through the advanced flow and choose the option to allow installing unregistered apps indefinitely, you can both install and update unregistered apps without going through the flow again (or using ADB).
Ah thanks I'm glad I don't need a Google account to enable this.
So... we're just going to move the scam into convincing the end user to run an application on their PC to ADB sideload the Scam App. Got it, simple enough. It's not hard to coach a user into clicking the "no, I'm not being coached" button, too, to guide them towards the ADB enable flow.
I think this is a "don't let the perfect be the enemy of the good thing". It's technically possible to get around, but adding more speed bumps in the way of scammers tends to drastically reduce the number of people who get scammed.
> This is going to hurt legitimate sideloading way more than actually necessary to reduce scams
Isn't that the objective? "Reducing scams" is the same kind of argument as "what about the children"; it's supposed to make you stop thinking about what it means, because the intentions are so good.
> - Must enable developer mode -- some apps (e.g., banking apps) will refuse to operate and such when developer mode is on, and so if you depend on such apps, I guess you just can't sideload?
What apps are those? I've yet to run into any of my banking apps that refuse to run with developer mode enabled. I've seen a few that do that for rooted phones but that's a different story. I've been running android for a decade and a half now with developer mode turned on basically the whole time and never had an app refuse to load because of it.
Wero in Europe. It's really insane. They make wero to make us less dependent on US tech and then hamstring it in this way.
I enable developer mode on every android phone to at least change the animation durations to twice the speed. I also have never run into an issue fwiw
SumUp won't let you use your phone to accept contactless payments while developer mode is enabled. You can still use an external card reader though.
RBC in Canada for instance, just having developer mode enabled blocks it here
The one-day waiting period is so arbitrary. Have they demonstrated any supporting data? We know google loves to flaunt data.
Something like Github's approach of forcing users to type the name of the repo they wish to delete would seem to be more than sufficient to protect technically disinclined users while still allowing technically aware users to do what they please with their own device.
To paste code into the chrome dev console you just need to type “allow pasting”
> The one-day waiting period is so arbitrary.
Scammers aren't going to wait on the phone for a day with your elderly parent.
Brother, there's an entire genre of scamming where the scammers spend months building rapport with their victims, usually without ever asking for anything, before "cashing out". One day is nothing.
Scammers already will spend multiple days on a scam call. Watch some Kitboga videos, he'll strings them along for a week.
"Google will call you again tomorrow to get you your refund."
There, we've successfully circumvented all of Google's security engineering on this "feature."
Check out this A&E Intervention episode for Greg. They have continuously worked this guy over for months.
https://youtu.be/YIR-nJv_-VA?t=121
They don't mind being patient when they have dozens of other victims in the wait queue.
This is obvious to anyone with a brain. I'm not familiar with scam logistics or the videos you mentioned, and the exact same line you put in quotes is what first came to my mind.
tl;dr of this post is that Google wants to lock down Android and be its gatekeeper. Every other point of discussion is just a distraction.
Right, this friction makes it much harder for a scammer to get away with saying something like, "wire me $10,000 right now or you won't see your child ever again!" as the potential victim is forced to wait 24 hours before they can install the scammer's malicious app, thus giving them time to think about it and/or call their trusted contacts.
Sure, but what about a 30 minute delay? 1 hour? 2 hour?
24 is just so long.
But also, my expectation is that a scammer is going to just automate the flow here anyways. Cool, you hit the "24 hour" wait period, I'll call you back tomorrow, the next day, or the next day and continue the scam process.
It might stop some less sophisticated spammers for a little bit, but I expect that it'll just be a few tweaks to make it work again.
24 hours is long enough to get them off the phone, and potentially talking to other people who might recognize the scam.
There will be some proportion of people who mention to their spouse/child/friend about how Google called them to fix their phone, and are saved by that waiting period.
Sure, but wouldn't 35 hours do the same trick? Or 5 hours? Or 10 hours and 28 minutes? :)
The question is, why exactly 24 hours? The argument is that the time limit is set to protect the users and sacrifice usability to do so. So it would be prudent to set the time limit to the shortest amount that will protect the user -> and that shortest amount is apparently 24 hours, which is rather.. suspiciously long and round :)
You've got to pick some time value (if you choose this route at all), and if the goal is to prevent urgency-coercion it needs to be at least multiple hours. An extremely-common-for-humans one seems rather obvious compared to, like, 18.2 hours (65,536 seconds).
Unless you want to pick 1 week. But that's a lot more annoying.
Exactly - the idea is to make it harder for scammers to create a false sense of urgency.
Have you ever watched Kitboga? Scammers call people back all the time. They keep spreadsheets of their marks like a CRM. It takes time to build trust and victimize someone, and these scammers are very patient.
Scammers will gladly wait on hold for 10 hours a day, for a week, if they think they'll get their Bitcoin.
They have infinite time and patience.
That is working as intended. Google wants to kill side loading.
> some apps (e.g., banking apps) will refuse to operate and such when developer mode is on
Enable dev mode, sideload the apk, then disable dev mode. I'd argue that it is poor security practice to keep developer mode enabled long-term on a phone that is used for everyday activities, such as banking.
Medical apps (such as those that talk to insulin pumps) also refuse to run when developer mode is turned on.
We'll see when this rolls out, but I don't foresee the package manager checking for developer mode when launching "unverified" apps, just when installing them. AFAICT the verification service is only queried on install currently.
Googler here (community engagement for Android) - I looked into the developer options question, and it's my understanding that you don't have to keep developer options enabled after you enable the advanced flow. Once you make the change on your device, it's enabled.
If you turn off developer options, then to turn off the advanced flow, you would first have to turn developer options back on.
You have to wait one day only once, when enabling the feature. I agree that enabling developer mode could be a problem but mostly because it's buried below screens and multiple touches. As a data point, I enabled developer mode on all my devices since 2011 and no banking app complained about it. But it could depend by the different banking systems of our countries.
You don't use the HSBC or Citibank app then I assume?
As described developer mode is only required at install time. Remains to be seen in the actual implementation, but as described in the post developer mode can be switched off after apps have been side loaded.
> some apps (e.g., banking apps) will refuse to operate and such when developer mode is on
JFC. Why would an app be allowed to know this? Just another datapoint for fingerprinting.
It's always boggled my mind what native apps are allowed to know versus the same thing running in a browser on the same device.
Yes, it is really dumb that some of these settings are exposed to all apps with no permission gating [0]. But it will likely always be possible to fingerprint based on enabled developer options because there are preferences which can only be enabled via the developer options UI and (arguably) need to be visible to apps.
0: https://developer.android.com/reference/android/provider/Set...
Because estimates suggest Americans lose about $119 billion annually to financial scams, which is a not insignificant fraction of our entire military budget, or more than 5% of annual social security expenditures.
So put a disclaimer in... Same way tons of other stuff works...
Maybe they should educate them then. Oh wait education is communist. And bad for the religious conservatives.
Most of the victims were last in school in the 1960s when all this stuff didn't exist. Also from experience teaching people with dementia or memory issues is kinda challenging as they just forget.
I wonder if you might be relying on a stereotype of victims. Here's some recent data: "The 2024 FTC Consumer Sentinel Network reported that 44% of all 20-somethings claimed losses in 2023". More data here: https://www.synovus.com/personal/resource-center/fraud-preve...
That's what I would expect too - old and young.
> This is going to hurt legitimate sideloading … way more than actually necessary to reduce scams
Google: I already said I love it, you don’t have to sell it to me.
The forced ID for developers outside the Play store is already killing open source projects you could get on F-Droid. The EU really needs to identify this platform gatekeeping as a threat. As an EU citizen I should not be forced to give government ID to a US company, which can blacklist me without recourse, in order to share apps with other EU citizens on devices we own.
you know this is an EU requirement?
The DSA covers App stores with a large numbers of users - this is about allowing users side load unsigned apps. Afaik there is no requirement to identify the developers of applications that can be installed on a vendors platform (outside the app store). Otherwise Microsoft would require Government ID to compile and email someone an EXE.
I'm not in agreement with most of you, hn. They've found a decent compromise that works for power users and the general population. Your status as a power user does not invalidate the need to help the more vulnerable.
Having to wait a day for a one off isn't a big deal, if they kept it looser then you'd be shouting about the amount of scams that propagate on the platform.
Same with bootloader unlocking isn't it?
Ah, its not much, just an email away ...
oh, not much it's email and a phone call away ...
Just wait 7 days ... no, it's just a month, and only one device par account? What's wrong with it? You are overreacting
Wait! Why you want to unlock your boot loader, only 0.000001% does it. You are abnormal, not the mass user
Fool me once it's on you Fool me twice ... it's on me.
We are already over twice, but none the wiser.
My personal hard line is having to ask Google for permission to sideload. Even if it's free and no personal info is exchanged. This new process is annoying but I can see it helping prevent scams.
But this is very rich from them given they serve scam ads with impunity.
I'd say this has nothing to do with preventing scams, but to make independent software more difficult to distribute.
Death, taxes and escalating safety are the only certainities in this tech dominated world. So, be ready for more safety in the next round few months/years down the line. Eventually Android will become as secure as ios. We need a third alternative before that day comes.
It's not a win by any means. I hope that we don't stop making noise.
> It's not a win by any means.
It's a a defeat, albeit a minor one. The defeats will escalate until there's nothing left to lose. "Normies" don't care and the tech people who do care are fewer and further between than you'd think.
Google serves ads with known scams and nothing seems done about it.
Yet, they are concerned about this.
It has nothing to do with safety, but everything to do with control.
I remember when Google disabled call recording in Android, so you no longer could record scammers. Thanks to recording I was able to get money back from insurance company that claimed they absolutely didn't sell me this and that over the phone (paid for premium insurance and got basic).
It's not secure when one of the main adversaries (Google) controls all the keys.
I believe that is why "escalating safety" and "secure" were written in italics in the comment. Those are the terms Google would use, not necessarily the truth.
Ahh in the glider app I use the italics didn't appear. I use very old version because I didn't like their last redesign.
*Tightening control. Nothing about safety here.
This 24-hour wait time nonsense is a humiliation ritual designed to invalidate any expectation of Android being an open platform. The messaging is very clear and the writing's on the wall now, there's nowhere to go from here but down.
I'm generally OK with this, but the 24 hour hang time does seem a bit onerous.
Most of the apps on my phone are installed from F-Droid. I guess the next time I get a new phone I'll have to wait at least 24 hours for it to become useful.
I'm seriously considering Graphene for a next personal device and whatever the cheapest iOS device is for work.
If my employer wants me to use a phone for work, they can buy whatever phone they want for me. I'm not going to buy a separate one just for them.
The apps might not be available though. Many developers are simply stopping in the face of Google's invasive policies. I don't blame them. Say goodbye to useful apps like Newpipe.
I don't see anything on NewPipe's website about not continuing development?
A few apps have been showing pop-ups warning users in advance that they are not going to do the verification. Obtanium is definitely on of them. I think I saw something similar on NewPipe.
Yes, but that isn't them giving up developing the app, that is them fighting back!
If you install it or update it you will get a banner to this effect at first use.
It says they are giving up, throwing in the towel? It is my understanding it provided information about Googles plans and how it will impact users?
This is hopefully an exciting time to consider a Motorola device, since they are partnering with GrapheneOS, but I worry that Google will block Google Play Services on any device that doesn't comply, so this might actually be a demoralizing time to be a GrapheneOS fan, when we watch them worm their stupid walled garden nonsense into the Motorola version of it.
Blocking Play might not be that bad if some frameworks/efforts crop up to allow easily targeting devices without it.
> In addition to the advanced flow we’re building free, limited distribution accounts for students and hobbyists. This allows you to share apps with a small group (up to 20 devices) without needing to provide a government-issued ID or pay a registration fee.
I don't quite understand how those installs would be tracked. If I create a "hobbyist" account and share the apk, are the devices that install that app all reporting it to Google? To my knowledge, Google only does this through the optional Play Protect system, is that now no longer optional? I'd like to know if my computer is reporting every app I install up to Google.
I switched to iOS in anticipation of this change. The reality is, if they are thinking about doing this, it's only a matter of time before they do it. If I have to choose between two walled gardens, apple will win every time.
That's a lot of words to explain how to install things on the device I supposedly own.
Wondering how long the blogpost would be if it explained what the flow for corpoloading applications approved by Google's shareholders would be?
That's similar to the process of enabling developer options on Xiaomi phones, for the last 5 years
They should let you skip the wait if you're setting up a device for the first time.
As an idea, what about allowing the 24 hours to be bypassed using adb (edit: bypass to allow indefinitely, not just install a single app)?
I understand there is some problem trying to be solved here, but honestly this is still quite frustrating for legitimate uses. If this is the direction that computing is moving, I'd really rather there were separate products available for power users/devs that reflected our different usage.
Right, if this is being built into AOSP I dont see how they wouldn't add an adb command to immediately skip the "Advanced Flow" wait. if it's safe to let uses run "adb install", then "adb skip-advanced-flow" should be just as safe to do too.
This is already how it works.
It's getting harder and harder to be an Android enthusiast. Especially given the hypocrisy of Google Play containing an awful lot of malware.
From a detached perspective Play Services itself is practically sanctioned malware and this is to protect that monopoly.
The goal seems to be breaking the real-time guidance scammers rely on. 24h probably works, but it feels like a heavy tradeoff for legit users.
Capitulating now means next time the terms of the deal will be worse.
Am I going to have to wait 24hrs to have Google's malware and spyware forceloaded onto my phone, or is this a different category of malware?
That comes preinstalled :)
24 hour mandatory wait time to side load!? All apps I want to use on my phone are not in the Play Store. So I buy a new phone (or wipe a used phone) and then I can’t even use it for 24 hours?
1) The one-time, one-day waiting period only applies if you go through the advanced flow to allow installing unregistered apps. You can still install registered apps (ie. apps made by developers who have verified their identity) even if they're distributed outside the Play Store.
2) You can use ADB to immediately install unregistered apps. ADB installs are not subject to the waiting period.
3) And how can we keep on using F-Droid and other app stores?
4) How can we install apps made by devs who won't do the verification dance with Google?
asian development bank?
Android Debug Bridge, a CLI for connecting to Android devices: https://developer.android.com/tools/adb
You can if you have a way to use ADB.
From purely a usability standpoint, not a freedom standpoint, I would actually be okay with that for my personal use if it stayed like that. But the point is that they're just making it worse and worse. They won't stop with this. I can arrange to do without an important app for a day, even if I had to get a new phone unexpectedly (If I had to skip attending an event and stay at home where my computer is, because I could only properly be on call with my sideloaded app, I'd chalk it up to an unusual situation). But it won't be long before they change it again.
Reminder that when you use terminology like "sideloading" you're accepting the premise that there's something inherently dodgy about installing your software onto your hardware.
Just calling it "installing".
Is there an accurate, neutral third party link about this that we can make the primary link instead?
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...?
Edit: I've put one up there now - if there's a better article, let us know and we can change it again. I put the submitted URL in the toptext.
I'd rather not have to go through this ritual, but I appreciate that there is a genuine security problem that google are trying to address. I also suspect that they have other motivations bound-up in this - principally discouraging use of alternative app stores. But basically I could live with this process.
Yeah, I know... Stockholm syndrome...
Although I may not have to live with it, as none of my present devices are recent enough to still receive ota updates.
Context: I don't use alternative app stores. I occasionally side-load updates to apps that I've written myself, and very occasionally third party apps from trusted sources.
The 24 hour wait period is the largest of the annoyances in this list, but given that adb installs still work, I think this is a list of things I can ultimately live with.
Do you need a Google account to opt out of the restriction? It says something about authenticating.
I don't have a Google account on my Androids. But I can't remove play services on them, sadly. As an intermediate protection I just don't sign in to Google play, that gives them at least a bit less identifying information to play with.
I hope this can be done without a Google account.
The reauthenticate means using device pin/biometrics if you have them enabled.
You will not need a Google account.
Oof that's what I was hoping for, thanks!
Funny how that post doesn't mention that a huge amount of malware is downloaded from Google (from the Chrome Web Store as well as from Google Play).
This is eminently reasonable.
Now if only Android would allow for stronger sandboxing of apps (i.e. lie to them about any and all system settings).
Nothing screams being infantilised by your platform more than having to wait 24 hours to be allowed to install software on your own purchased computing devices.
is it 24 hour per app or to enable sideloading at all?
From my read, it's explicitly a one-time thing. Presumably that means that even if you pick the "allow for 7 days" option, you can re-enable it after that without a delay (maybe with a reboot?).
>And what is malware? For [Android Ecosystem President], malware in the context of developer verification is an application package that “causes harm to the user’s device or personal data that the user did not intend.”
Like when Google, Facebook, Apple, Microsoft, et al. cooperated with¹ the unconstitutional and illegal² PRISM program to hand over bulk user data to the NSA without a warrant? That kind of harm to my personal data that I did not intend?
If so, I'd love to hear an explanation of why every Google/Alphabet, Facebook/Meta, and Microsoft application haven't been removed for being malware already.
¹ https://www.theguardian.com/world/2013/jun/06/us-tech-giants...
² https://www.reuters.com/business/media-telecom/us-court-mass...
tl;dr:
- You need to enable developer mode
- You need to click through a few scare dialogs
- You need to wait 24h once
I wonder how long this will last before they lock it down further. There was a lot of pushback this time around and they still ended up increasing the temperature of the metaphorical boiling frog. It still seems like they're pushing towards the Apple model where those who don't want to self-dox and/or pay get a very limited key (what Google currently calls "limited distribution accounts").
Will these measures eliminate fraud? Of course not. What a shame; I guess we'll need to lock down the platform even further.
This is so overt.
I am not happy about this, but as long as advanced Android users can still turn this off and keep it off, we're still in a better place than iOS.
Even though I understand the design decisions here, I think we're going about this the wrong way. Sure, users can be pressured into allowing unverified apps and installing malware, and adding a 24-hour delay will probably reduce the number of victims, but ultimately, the real solution here is user education, not technological guardrails.
If I want to completely nuke my phone with malware, Google shouldn't stand in my way. Why not just force me to read some sort of "If someone is rushing you to do this, it is probably an attack" message before letting me adjust this setting?
Anyone who ignores that warning is probably going to still fall for the scam. If anything, scammers will just communicate the new process, and it risks sounding even more legitimate if they have to go through more Google-centric steps.
Can you set your clock forward or does this also require phoning home to a central server to install an app on your computer?
I'd urge everyone here to seriously consider switching to GrapheneOS. It's a far simpler transition than e.g. switching from Windows or OSX to Linux, and many people find that it has basically no friction vs android.
More people moving to GrapheneOS is the best tool we have against Google's continued and escalating hostility to user freedom and privacy and general anti-competitive conduct. (Of course, you could ditch having a smartphone entirely..., but if you're willing to consider that you don't need me plugging an alternative).
I'll repeat my question from a while ago. Is the official Temu app, available on the Play Store, still full of questionable malware / spyware code?
If so, it's clear that none of these changes are actually to protect users.
Those working in Google (AOSP) that write these code should be ashamed of themselves. Eventually they are doing a bad thing for the society.
Honestly, if coerced sideloading is a real attack vector, then this seems to be a pretty fair compromise.
I just remain skeptical that this tactic is successful on modern Android, with all the settings and scare screens you need to go through in order to sideload an app and grant dangerous permissions.
I expect scammers will move to pre-packaged software with a bundled ADB client for Windows/Mac, then the flow is "enable developer options" -> "enable usb debugging" -> "install malware and grant permissions with one click over ADB". People with laptops are more lucrative targets anyway.
I predict that they're going to introduce further restrictions, but I think the restrictions will only apply to certain powerful Android permissions.
The use case they're trying to protect against is malware authors "coaching" users to install their app.
In November, they specifically called out anonymous malware apps with the permission to intercept text messages and phone calls (circumventing two-factor authentication). https://android-developers.googleblog.com/2025/11/android-de...
After today's announced policy goes into effect, it will be easier to coach users to install a Progressive Web App ("Installable Web Apps") than it will be to coach users to sideload a native Android app, even if the Android app has no permissions to do anything more than what an Installable Web App can do: make basic HTTPS requests and store some app-local data. (99% of apps need no more permissions than that!)
I think Google believes it should be easy to install a web app. It should be just as easy to sideload a native app with limited permissions. But it should be very hard/expensive for a malware author to anonymously distribute an app with the permission to intercept texts and calls.
I don't think Google has a strategy around what should be easy for users to do. PWAs still lack native capabilities and are obviously shortcuts to Chrome, and Google pushes developers to Trusted Web Activities which need to be published on the Play Store or sideloaded.
But these developer verification policies don't make any exceptions for permission-light apps, nor do they make it harder to sideload apps which request dangerous permissions, they just identify developers. I also suspect that making developer verification dependent on app manifest permissions opens up a bypass, as the package manager would need to check both on each update instead of just on first install.
> But it should be very hard/expensive for a malware author to anonymously distribute an app with the permission to intercept texts and calls.
And how hard/expensive should it be for the developer of a legitimate F/OSS app to intercept calls/texts?
Yep, I have a legitimate use case for exactly this. It integrates directly with my application and gives it native phone capabilities that are unavailable if I were to use a VoIP provider of any kind.
As a legitimate developer developing an app with the power to take over the phone, I think it's appropriate to ask you to verify your identity. It should be an affordable one-time verification process.
This should not be required for apps that do HTTPS requests and store app-local data, like 99%+ of all apps, including 99% of F-Droid apps.
But, in my opinion, the benefit of anonymity to you is much smaller than the harm of anonymous malware authors coaching/coercing users to install phone-takeover apps.
(I'm sure you and I won't agree about this; I bet you have a principled stand that you should be able to anonymously distribute malware phone-takeover apps because "I own my device," and so everyone must be vulnerable to being coerced to install malware under that ethical principle. It's a reasonable stance, but I don't share it, and I don't think most people share it.)
I think you read a bit too much into my message. I agree, it's complicated, I don't want my parents and grandparents easily getting scammed.
But yes they are my devices, and I should be able to do exactly what I want with them. If I'm forced to deal with other developers incredibly shitty decisions around how they treat VoIP numbers, guess who's going to have a stack of phones with cheap plans in the office instead of paying a VoIP provider...
But no, I have no interest in actually distributing software like that further than than the phones sitting in my office.
For a security-sensitive permission like intercepting texts and calls, I'm not sure it makes sense for that to be anonymous at all, not even for local development, not even for students/hobbyists.
Getting someone to verify their identity before they have the permission to completely takeover my phone feels pretty reasonable to me. It should be a cheap, one-time process to verify your identity and develop an app with that much power.
I can already hear the reply, "What a slippery slope! First Google will make you verify identity for complete phone takeovers, but soon enough they'll try to verify developer identity for all apps."
But if I'm forced to choose between "any malware author can anonymously intercept texts and calls" or "only identified developers can do that, and maybe someday Google will go too far with it," I'm definitely picking the latter.
> Honestly, if coerced sideloading is a real attack vector, [...]
I don't believe that it is. I follow this "scene" pretty closely, and that means I read about successful scams all the time. They happen in huge numbers. Yet I have never encountered a reliable report of one that utilized a "sideloaded"[1] malicious app. Not once. Phishing email messages and web sites, sure. This change will not help counter those, though.
I don't even see what you could accomplish with a malicious app that you couldn't otherwise. I would certainly be interested to hear of any real world cases demonstrating the danger.
[1] When I was a kid, this was called "installing."
I get that its pretty clear with the straight sideloading case, but can anyone say for sure what this will look like for an f-droid user? Its hard to keep track but I thought something new here because of EU is that alternative app stores != sideloading? Something where app stores could choose themselves to get "verified," whatever that means, to become a trusted vendor? Or is this completely wrong?
> Wait 24 hours
Man, fuck Google. I hope this bullshit is struck down by government regulation as malicious compliance to 3rd party app stores.
I wonder if GrapheneOS will have the same level of user-hostile bullshit. That may be my salvation board right now.
Sailfish OS would be great, but unfortunately my banks don't seem to play along with it.
Seems like a very reasonable compromise. What's the catch?
They'll just remove the "Advanced" ability in a few years once they've frog boiled people into jumping through hoops to use their phone the way they want.
I don't find it reasonable that Google wants to make me wait 24h to install software on a device I own.
Meh. I get the annoyance, but it's a one time cost for a small subset of their users. I would prefer if there was a flow during device setup that allowed you to opt into developer mode (with all the attendant big scary warnings), but it's a pretty reasonable balance for the vast majority of their users. (I suspect the number of scammers that are able to get a victim to buy a whole new device and onboard it is probably very low).
Get with the newspeak, it's called "sideloading" now and your corporate overlords get to dictate the terms.
Developers, including non-US citizens, are forced to give Google their government ID to distribute apps. This enables Google to track and censor projects, like NewPipe, an alternative open source Youtube frontend, by revoking signing permissions for developers.
>Developers, including non-US citizens, are forced to give Google their government ID to distribute apps.
Developers can choose to not undergo verification, thereby remaining anonymous. The only change is that their applications will need to be installed via ADB and/or this new advanced flow on certified Android devices.
Either way, you can still distribute your apps wherever you want. If you verify your identity, then there are no changes to the existing installation flow from a user perspective. If you choose not to verify your identity, then the installation will still be possible but only through high-friction methods (ADB, advanced flow). These methods are high-friction so anonymous scammers can't easily coerce their victims into installing malicious software.
My friend's little kid likes to make games that he and his friends can play. As far as I am aware, these apps don't require any permissions.
Are apps like this more dangerous than browsing to a website? I thought they were entirely sandboxed from the rest of the device?
This. Side loading being restricted is only one part of the problem; the other is mandatory developer verification for apps distributed through the Play Store.
That's not correct - the flow described in the post outlines the requirements to install any apps that haven't had their signature registered with Google.
That means those apps still keep on existing, they are just more of a hassle to install.
I don't see that on the page
They already announced it. Here they only mention the special case where it does not apply:
> In addition to the advanced flow we’re building free, limited distribution accounts for students and hobbyists. This allows you to share apps with a small group (up to 20 devices) without needing to provide a government-issued ID or pay a registration fee.
i.e. Government-issued ID and fees are needed for more than 20 devices, e,g, every app on F-Droid
Isn't this a huge loophole? Couldn't a scammer just make many variants of their malware?
Enforcement of the device restriction would also mean they also are collecting information from your device about the app.
https://developer.android.com/developer-verification
Note that the OP is about side loading, i.e. installing apps from non-Play Store sources and thereby circumventing developer verification.
That I have to wait 24 Hours on my own device to install software?
I'll say it again: this isn't a problem for Android to solve. Scammers will naturally adapt their "processes" to account for this 24-hour requirement and IMO it might make it seem more legitimate to the victim because there's less urgency.
The onus of protecting people's wealth should fall on the bank / institution who manages that persons wealth.
Nevertheless, this solution is better than ID verification for devs.
Why should the bank/institution be responsible for protecting individuals from themselves? They don't have police power- protecting people from bad actors is like, the reason to have a state. If the state wishes to farm it out to third parties, then we don't need the state anymore!
Yea I have no idea why the original commenter thinks Banks should have the power to tell me what I can and can't do with my own money.
It's nice that Zelle has checks and identity information shown to you when you're sending money, but if I click through 5 screens that say "Yes I know this person" but I actually don't.....no amount of regulation is going to solve that.
Banks absolutely have that power and will stop transactions that seem suspicious or fraudulent already, no? Sometimes they'll call/text to verify you want it go through. I imagine that type of thing but cranked up for accounts flagged "vulnerable" where a family or the person themselves can check a box saying "yes, lockdown this account heavily please" (or whatever you can imagine, idk, I'm not a bank)
The bank/institution is where the money is leaving from therefore they should implement policies that protect vulnerable customers like seniors, for example. I don't know how that looks but it seems reasonable that they could put limits on an account flagged "vulnerable person"
I'm not sure what you're getting at with the rant about police power and a state? Google isn't the government either. What would legislation provide that banks can't already do today?
Sure, there are things banks can do, and those are features they can market. But ultimately, if the state isn't pursuing criminals who prey on the vulnerable, then society as we know it has failed and we would need a new society, or a new state, or both...The bank can't arrest anyone!
I never said anything about it being Googles responsability, I agree it is not. And the only legislation that might be necessary over what we have is a budget directly to go after criminal fraudsters.
Fraud is already illegal, the issue is that these scammers reside in other countries. I don't doubt there could be pressure applied from really high up at the diplomatic level but I highly doubt the FBI for example is going to be able to do anything even with legislation.
> I'll say it again: this isn't a problem for Android to solve.
They're not solving that problem. They're using it as an excuse to lock down the platform further and assume more control. Any incidental benefit for user "security" is an unintended consequence of their real agenda.
It's not like the Google Play store hasn't been known to host malicious apps, yet you are not required to wait 24 hours before you install apps from their store.
I suspect they are hoping users just give up and go to the play store instead. Google touts about "Play Protect" which scans all apps on the device, even those from unknown sources so these measures can barely be justified.
Imagine if Microsoft said you need to wait 24 hours before installing a program not from their store, which is against the entire premise of windows.
Computing, I once believed was based on an open idea that people made software and you could install it freely, yes there are bad actors, but that's why we had antivirus and other protection methods, now we're inch by inch losing those freedoms. iOS wants you to enter your date of birth now.
The future feels very uncertain, but we need to protect the little freedoms we have left, once they're gone, they're gone for good.
It's a little inconvenient for someone setting up a new phone to have to wait a full day to install unregistered apps. But while I can't speak for others, it's a price I'm personally willing to pay to make the types of scams they mention much less effective. The perfect is the enemy of the good.
How would you feel about needing to wait 24 hours to visit an "unapproved" website on your phone? You would pay Google/Apple $25 to get whitelisted so people can browse to your personal website without getting a scary security message.
This is the same thing since it applies to all apps, not just apps that need special permissions.
On what basis do you believe that it will meaningfully reduce the dollars lost or persons harmed by fraud, as opposed to simple shuffling around the exact means used?