Android 15 may make it harder for sideloaded apps to get sensitive permissions | Hacker News Reader

Android 15 may make it harder for sideloaded apps to get sensitive permissions

androidauthority.com

99 pointsthunderbong117 comments

I actually want Play Store apps to be equally configurable. Apps like Truecaller refuse to work without so many permissions. Being Android you'd expect some way to provide a dummy contact book, location & other accesses that apps need.

Heck I'd want an option to freeze apps once I'm logged in & only unfreeze them when I need to use them. Would absolutely improve battery life.

In Developer options you can select a mock location app like Private Location[1], and there is an app named Shelter[2] that allows you to freeze and unfreeze (depending on what you mean by the terms, you may want the last mentioned app, see [3]) applications in your personal and work profile (and to isolate and run multiple instances of apps using Work Profiles). Additionally, you might find SuperFreezZ App stopper[3] useful and it might be what you are looking for. It allows you to entirely freeze all background activities of apps (unused apps, too, automatically). All of the apps mentioned work without root, and are worth checking out.

[1] Private Location - https://redplanet.gitlab.io/fdroid-website/en/packages/com.w...

[2] Shelter - https://f-droid.org/packages/net.typeblog.shelter/

[3] SuperFreezZ App stopper - https://f-droid.org/en/packages/superfreeze.tool.android/

---

EDIT: According to https://f-droid.org/pl/2023/10/19/twif-client-alpha-kde-remo...,

> Private Location was also removed as was no longer functioning and development has stopped years ago, as reported in #3096 (https://gitlab.com/fdroid/fdroiddata/-/issues/3096).

That is a shame. The other applications are fine, at least.

Wasn't Private Location removed from the store though? If it's the app that I'm thinking about I used it before but it stopped working because the map API changed which broke the app and it never got updated, so it was removed. There should be a github issue about that somewhere.

You are right. I made the necessary corrections.

My concern with apps like Shelter, Insular and Island is: who guards the guards? How confident can I be that an xz-type attack hasn’t been made on them? Who are the individuals behind such projects, and what nation-states and influences are they subject to?

You could ask the same questions about Google or Apple or any of the countries that have jurisdiction over them.

The best answer is to make the sensitive parts open source. Then anyone can review it themselves if they're so inclined, including you. And since some software developers and large organizations actually do this, it's difficult to get backdoors into popular projects without anybody noticing.

Notice that the xz attack was detected before it made it into e.g. Debian Stable or the distributions based on it.

The best answer to "who watches the watchers" is everybody. The prerequisite for which is for everybody to be able to see what's going on in the places where there could be something fishy happening.

I can't find private location in the f droid app and the APK downloads don't work. I tried fake traveler but it was crashing constantly and was not able to fool organic maps

Apparently it was removed for the reasons mentioned in my edited comment. Thank you for pointing this out.

> Apps like Truecaller refuse to work without so many permissions.

Android apps have had bad habits for a very long time because Android didn’t have the granular runtime permissions system like iOS did (Android had only install time permissions that was either grant all or no install allowed). Even though Android brought granular runtime permissions from version 6 (?), apps have continued to badger users for every permission that allows them to collect more data. Android users have also been conditioned from the beginning to provide all permissions. So apps expect them to provide what they ask or refuse to work.

On iOS, Apple has stated in its policies for a long time that apps should continue to work even when permissions are denied (with obvious caveats, like for example camera not working if camera permission is not granted).

It’s a stark and disturbing contrast when comparing how Android apps refuse to work whereas the same app by the same developer on iOS would be a lot better behaved even when various permissions are denied.

BTW, Truecaller on iOS will work without getting permissions to access contacts. It will also work if it’s not given access to SMS.

Do a CTRL-F (or CMD-F) through these comments and look for the word "refuse". It comes up way too often. This seems to be a huge problem: Apps taking it upon themselves to "refuse to work" until the user gives in to their demands. It's like a hostage negotiation. Developers really shouldn't have the power to say "well I'm in charge, user, not you, so fuck off."

I'm a big fan of how iOS lets you decide which images are available from the camera roll. So the app can have "access" to the camera roll but there is that intermediate stage where I can scope down which images are in it.

Some iOS apps like Google Photos refuse to work unless you give them full access to the camera roll. I don’t know how they detect the limited access scope, but it is a fundamental design flaw that it is possible at all for an app to do this.

It's egregious how it won't even let you view photos if you don't give it full access. This was one of the motivating factors for me to de-Google.

Same here, it was the final straw that pushed me away from using Google services. But I would argue that Apple's behavior is equally egregious here for not enforcing the same permission usage guidelines they require the smaller devs to comply with.

That's present already under limited access, afaik - where images made available to application are mediated through file picker

GraphenOS offers that, since the Playstore/Google Applications are non privileged applications.

Big Plus for being easy installable from the Graphenos Appstore Applications. It currently offers 8 applications and 4 of them are GraphenOS own applications.

GrapheneOS is nice for people using Google Pixel phones. And useless for anyone else.

FWIW the Pixel 8, the newest device offering Advanced Memory Protection, sells for less than $600 brand new right now. You can tune memory tagging & hardened memory allocation on a per-app basis. It's a game changer

You are saying that as if it was cheap. I am pretty sure most people buy <$250 smartphones. That is at least the case in my social circle, very few iphones, pixel, an awful lot of cheap Xiaomi Redmi and the Samsung Galaxies are usually the A line instead of the S line.

If someone uses Xiaomi they probably also don't worry about privacy.

At least it is possible (really annoying process) to unlock the bootloader on Xiaomi devices.

Forgive my ignorance, but what is it about GrapheneOS that makes it better on Pixel devices?

It’s only available for Pixels.

Ah, that would do it!

It's due to hardware reasons just as an FYI - I forget the specifics, so forgive me if this is dated, but I believe it had to do with some crypto-specific chip if I remember right.

Yeah the proprietary blackbox security chip that they pinky promised to open source but never did...

+1 for freezing unused apps. Would lower the attack surface nicely!

Interesting, so this isn't a standard Android feature? My Galaxy S-series phones have been doing this for years.

See my other comment: https://news.ycombinator.com/item?id=40142394

If you give SuperFreezZ App stopper permissions (it needs to be registered as an accessibility service, and requires usage access as well) to check for usage of applications, then it will freeze unused applications automatically. You can even specify after how many days of not having used them you want to freeze them.

Samsung's Android flavour removes permissions from unused android apps automatically, and sends a notification to let you know. Close enough I guess.

fwiw this seems to be partially in place already.

Requests for access to files, location, mic, and camera usually give me the option of allowing them all of the time or only when the app is open.

I've also noticed system notifications stating that permissions will be used from unused apps.

Greater configurability is always nice though.

As others have mentioned GrapheneOS does give some control back to the user. You can set up contact scopes and file access scopes, you can remove the Internet permission as easily as any other permission.

Managing running apps is still a nightmare though.

I regularly go through the battery history of the previous night, to see if any apps were running while I slept.

So far I've, for example, found my banking app running something called a telemetry service, in the background, even if I set its battery profile to restricted. No way to stop that other than to uninstall the app.

GrapheneOS has one more feature that almost solves this called "Disable app". The downside is that it will remove the app from your home screen and it is a pain to re-enable it.

My current workaround is this:

I use a custom home screen shortcut app to create a shortcut to the settings page of the app I want to disable. Then each time I want to use it, I tap it on the home screen, tap "Enable", tap "Open" and after I'm done I tap "Disable" one more time and close the settings.

However now I've found a new culprit eating my battery. I use Google Meet through a browser, since the app won't work without Play Services. The browser I use for this is Brave. Now every time I leave a meeting, Brave will be listed as using most of my battery when idle. Nothing will remove it. Force stop, nope. Running services list, not listed. Only restarting the phone will stop it.

With all the rabbit holes I've gone through, I've only come out with one response to all this: "This is how Android is designed to work." so I'm not hopeful this will ever get better.

> So far I've, for example, found my banking app running something called a telemetry service, in the background, even if I set its battery profile to restricted. No way to stop that other than to uninstall the app.

Have you considered creating a new 'banking' user account that you only log in to when you need to access that app? Its incredibly easy with Graphene.

Folks have been asking for this for a long time, but for whatever reason they won't implement it.

The way I do it to freeze apps is using focus mode. You can flag these apps as "distracting" and enter "focus mode". Their icons will turn gray, only run when explicitly opened, and auto-freeze in 5 minutes. After 4 minutes a notification appears to extend this run time. This works for me for most of the cases.

It's up to app maker to ensure it will work without permissions granted.

...but ofc most app makers are lazy and just throw up error whenever they don't get what their wont, forcing users to give up.

I guess google could introduce a dummy system for every single service and feed that to the apps when the permission is not granted, but I imagine that would be a lot of work. Maybe some day...

Dummy/empty data is already a thing in Android if I'm not mistaken. It just needs ADB/App Ops to activate it.

There's three states of permissions in android land from a permission request perspective:

* Granted. Just full access to all things behind the permission, no questions asked.

* Ignore. Returns no rejection, but all permission-restricted functions will return no/default data. This can technically be checked for by the app but usually isn't.

* Deny. No data, return an explicit error to the app to tell them the permission isn't granted.

For some reason that second one isn't available for the default UX; you need to manually set it with ADB or use App Ops to do it.

Don't apps just refuse to work now a days if ADB is activated? It has been a few years since I tried it. But I remember my bank app refusing to working with the developer options(forgot what this is exactly) turned on. Also if I remember right, some apps do not work on rooted phones. Or are we talking about different things?

ADB requires USB debugging to be enabled, yes, although modifying the appops settings (App Ops = app that can modify appops on the device itself using ADB, appops = android service that handles application permissions and application operations) doesn't need it to be continuously enabled.

You can just activate it, change the settings and disable it afterwards. Pretty annoying but it is what it is.

This doesn't require root either, although enabling USB debugging is an important step towards rooting, which is probably why you think it's related.

I have never had an app refuse to work because of developer mode, but several if rooted. Anecdotal, but it would seem the two are treated differently by developers.

My insulin pump app would refuse. I want to say it was medtronic's.

Android already does something like this for location services. For example, give precise location vs approximate location. And then for other permissions, there's a popup for whether to give permissions only this time, always, or to not. I guess there could be a 4th option for "mock" permissions. I wonder if an OEM could provide something like this because at the end of the day, the OEM has control over the sensors that are providing the data that's consumed by these apps.

I have apps constantly refuse to work if I only allow Approximate location on Android.

Even stuff like weather apps.

Tangential: there are websites which provide good weather info. (eg, not affiliated https://www.windy.com )

Everything weather related, I uninstall, and if it is bloatware I "pm disable-user" in shell

There is an exact same feature in developer options called Mock location app. Just download an app which does this and enable it there. It works.

Just to drag us out of the techie land of make-believe, this presents such a horrendous user experience for everyone except advanced users that Google or any mainstream OEM is completely sensible to dismiss it on those merits alone.

It’s just another layer of crap that moves smartphones one step closer to being as ridiculously complex as Windows PCs.

> It’s just another layer of crap that moves smartphones one step closer to being as ridiculously complex as Windows PCs.

So, useful computing devices? I'm for anything that pushes this plastic toy towards being a real tool.

Providing dummy data would also diminish the value of Android users to Google itself, unless they give themselves an exemption from such a setting which would mean they would be dragged to court by the competition.

> Heck I'd want an option to freeze apps once I'm logged in & only unfreeze them when I need to use them

I have this on Android 13, it's called "pause app" and seems to do just this. Might not be available on all variants tho, I'm running crDroid.

There is "pause app" on my stock Android 12 as well, although I have no clue how well it works. I use https://f-droid.org/en/packages/superfreeze.tool.android/.

The question you need to ask, how would this profit Google? It's an advanced setting that would need user interaction, a fraction of them would do this. This "Enhanced Confirmation" is also about automatic restriction.

> Being Android you'd expect some way to provide a dummy contact book, location & other accesses that apps need.

Yeah, definitely. It would be so nice to have that built in. With LSPosed and XPrivacyLua, you can block/give garbage data to a lot of permissions, including contacts, though unfortunately it only works by sharing your favourites, with no way to configure a per-app list.

Afaik disabling apps is built into Android but not directly accessible. I think there's a way to do it with ADB. SwiftBackup can also freeze & unfreeze

Doesn't this "freezing concept" effectively kill the idea of background services?

Yes and I think that's what people want.

Are you saying that people don't want the features that background services provide? Features like notifications

people want control. not every app under the sun needs that regardless of what it devs think.

If there's an app that I only need when I open and don't care for it bg service then I should be able to tell it f off. devs might think their widget phoning home everytime is worth my battery time, I might think otherwise.

Techies want control and customisation. People want convenience and smooth interop. The most used desktop OS is Windows not Linux. HNers often forget that they live in a tech bubble. Reminds of me when Dropbox was dismissed because anyone could write a little script to replicate the Dropbox functionality.

Not every app needs to be a web app or use internet yet most apps nowadays do. Either you allow ALL apps to have it or you don't. You will think that devs would make apps that don't need background services. It won't happen. What will happen is that every time you open the app, you will be nagged to allow background services to run. The only thing that would stop it is for that feature to not be available at the application level.

Being privacy-conscious or wanting control and customization is not and should not be exclusive to techies IMO.

I am not saying what should be only what it is.

It does, but you can do it on a per-application basis.

My point is that the suggestion is effectively asking for the removal of background services

That's up to the user, not the developer.

It's up to the developer. Users don't know what background services are

Users understand the idea of an application "doing things in the background". Multitasking operating systems have been a thing for decades.

If the user doesn't want that happening for a particular application, the user should be able to turn it off. Mobile OSes have given way too much control over to developers. Whose device is it anyway? The user's or the app developer's?

I would argue that most don't.

If you ask most senior citizens or simply most users of computing devices to explain what they think about "background services", most won't know what you are talking about. Just because a functionality has been present in a system for a while does not mean that everyone will know about it. Ask people about dual booting, most won't know about it. Ask most people about "SSL", most won't know about it. Ask users about the command line, most won't know about it. And so on. Even the abstract concept of a search engine (separate from the concept of Google Search) is likely to fly over the head of many people. You vastly overestimate your audience. Let's put it this way: most computing devices nowadays are mobile phones and for many people this is their first and main interaction with computation. The modern ubiquity of phones is bigger than that of personal computers by an order of magnitude imo. Personal computers were huge but mobile phones have a level of penetration PCs could never reach.

When you buy a device, you agree to the terms of service. Most manufacturers like Apple have something along the lines of "don't interfere with the proper working of the system". Freezing apps sound like it breaks the ToS.

Buying a device is less like buying a toothbrush and more like buying a tractor. You don't own it inconditially. You own it under certain terms. Those terms give the manufacturers lots of power.

> If you ask most senior citizens or simply most users of computing devices to explain what they think about "background services"

Have you personally asked them? I think you'd be surprised. The #1 end user smartphone concern is around battery life, and end users, across all ages and technical sophistication are at least vaguely aware that their phones "do things" that they can't visibly see and that it's often what drains their batteries. Senior citizens aren't fools. They might not know the technical details of what exactly is happening on their phones, but they are absolutely aware of battery-draining things going on unseen in the background.

And even if they weren't aware--that doesn't address my main point: The end user should ultimately be in control of their device's function, not the app developer. If there is a conflict between what the end user wants to do and what the developer wants to limit them to, the end user should win.

I speak to them every week and in fact I did ask them this week. It's very insightful. They understand that the phone is on and that it drains the batteries in the same way it did pre-smartphone. The same way an electrical device consumes electricity. The idea of background activity linked to apps (as opposed to general system activity to keep the phone running) they have installed is not something they are aware of. Hence, the first action when it happens is to take it to a technician to "fix" it or buy a new one.

You can desire all you want. Doesn't change the reality. You can't truly have control without understanding. All it means is that users will get some user defaults (and the device will function exactly as it does now) or worse, they will be compelled to change the user defaults to their detriment (and to the benefit of a third party). There's a fundamental information asymmetry. This is the source of the power imbalance and giving more "control" to users (who already struggle to understand the one they already have) won't fix it.

It's not too different from consumer protection laws. Consumers have a limited understanding of their power while companies have a wider understanding. This means that overall companies win and there needs to be a knowledgeable third party constantly watching and advocating over the interests of the consumer.

Techies have this tendency of trying to fix every problem with tech, even when it doesn't work (looking at every problem like a nail that can be hammered). You can't fix this with more tech. A better solution (by no means an optimal one) is to have public free phone tech knowledgeable advocates that people can see in person to talk about their problems and desires regarding their device.

If i have an app I installed once and forgot about it i probably dont need it to run in the background either. This is for those situations. Apps that I use, won't be frozen.

Sounds like GrapheneOS is exactly what you want.

I do this with XPrivacyLua

Less and less my phone. I want the small apps which I develop for myself to have all the access without any restrictions. It's getting worse and worse and I wish they'd allow me to whitelist my apps somehow so that they get the same access as system apps do. And if this would mean that I can't use Google Wallet, then at least all the permissions which don't affect apps like Google Wallet.

> Malicious Android apps, no matter where they’re sourced from, commonly try to trick users into granting them access to the Accessibility and Notification Listener APIs because of their power.

So does Gadgetbridge. I've had devices where Android wouldn't allow me to give it access to the Notification Listener resulting in me not being able to forward the messages to my Mi Band. In the end this was solvable by using ADB, but this is not ok.

cut the "sideloading" term. It's downloading. Exactly the same we download any other file. It's not some obscure feature. This kind of terminology is word games to make it sound like somebody doing this is inherent using it wrong or must be up to no good.

Its one thing to make it harder to enable stuff. But there absolutely should be ways to say "yes I know what I'm doing".

I'd prefer if we used sideloading for the appstore / playstore. The main location is the website of the developer and the mobile store is a side channel.

Hmm I hope there's still a way to bypass this. I sideload all my apps using aurora store (so I don't have to sign in with a Google account) and I don't want them limited in functionality.

Yes, if you're willing to jump through scare dialogs and search for where in the UI to find "hidden" settings, you can manually override it per app as before.

Apps installed from alternative stores (using APIs made for those) aren't subject to those restrictions - it's written in the article.

It's explicilty restricted only to apps that don't use the new "app store" APIs in Android.

As with all non-feature creep, I feel the need to compulsively blurt out: "Yet."

Aurora isn't an official third party store. There isn't much chance that Google will whitelist it because it's a privacy alternative for the play store itself. Google has been all over it trying to block it so I doubt it will select it as an exception.

What do you mean "official third party store"? There's no such thing. It's an OS level API where store needs to register itself as a store unrelated to Google (it's an AOSP concept).

Read the article. There's an explicit white-list for being exempt from this new restriction and only "trusted installers" will be on it. Clearly the Play Store will be exempt, but we have no idea what will be put on the white list according to what criteria. As pointed out in the article's conclusion.

> Apps installed from alternative stores (using APIs made for those) aren't subject to those restrictions

These restrictions already exist for in call audio accessibility APIs. At least one call recorder app has gone as far as making their own app store to bypass these restrictions.

Increased restrictions on which programs may run and what they can do are the future of computing. We really can't afford the risks of letting everybody just run arbitrary code. Windows and macOS are next.

It didn't mention apps installed with 'adb install'. I think you might be able to run those with no restrictions. And LineageOS, GrapheneOS, and so forth may give you the option of disabling this feature or making it more configurable.

As far as desktop OSes go, I think the much larger problem is how to let users control the degree of sandboxing an application has. On mobile we're broadly used to each application asking for permissions (and whether we've trained users to just hammer 'allow' until it proceeds) and each is largely independent.

Windows also has its legacy software that wouldn't know about new restrictions, so would need dummy access until allowed, and UI for the user to gain understanding about why their newly downloaded utility can't access their webcam and all their files yet, and how to rectify that. Windows already has something like this through controlled folder access, but I've yet to hear of someone who turns it on. Part of the biggest strength of desktops is how all the software/hardware parts combine, so I think this is high stakes in terms of not pissing people off so the feature actually gets used.

Yes, the open software war has been lost fairly comprehensively and many programs that are routinely installed on computers are dreadful spyware, but instead of being random ill-advised junk from some forum, they're 389MB of analytics masquerading as productivity software from the very biggest corporate names in software.

Who know what all that evil junk is doing with its execute bit and filesystem and network access. (https://xkcd.com/1200/)

And if you think the situation is bad with Teams and Dropbox and other "Western-style" software, it's way worse elsewhere in the world.

'So today we have marketing departments who say things like "we don't need computers, we need... appliances. Make me a computer that doesn't run every program, just a program that does this specialized task, like streaming audio, or routing packets, or playing Xbox games, and make sure it doesn't run programs that I haven't authorized that might undermine our profits". And on the surface, this seems like a reasonable idea -- just a program that does one specialized task -- after all, we can put an electric motor in a blender, and we can install a motor in a dishwasher, and we don't worry if it's still possible to run a dishwashing program in a blender. But that's not what we do when we turn a computer into an appliance. We're not making a computer that runs only the "appliance" app; we're making a computer that can run every program, but which uses some combination of rootkits, spyware, and code-signing to prevent the user from knowing which processes are running, from installing her own software, and from terminating processes that she doesn't want. In other words, an appliance is not a stripped-down computer -- it is a fully functional computer with spyware on it out of the box.'

https://en.wikisource.org/wiki/The_Coming_War_on_General_Com...

If Macs too far down that road I’ll move to Linux for my desktop computing. It’s already getting annoying.

If it happens to you with any degree of regularity does that not imply that you are regularly granting new code access to sensitive aspects of your machine?

macOS is a far far cry from, let’s say, Vista UAC.

Updates break thing tha used to work. My mouse situation drives me crazy, and my Wacom Cintiq stopped working a couple of months back. File management is starting to be a problem.

Yes exactly. I already did just that.

> We really can't afford the risks of letting everybody just run arbitrary code.

The pleb running applications they want on the device they own? Madness!

While poorly phrased, I think the concern is legit. As somebody who wants full control over my system, I don't want most of the applications I use on a day to day basis to have that same full control over my system. I'm a separate entity from the programs I use and the people who make the programs I use. The world is so much more complex than it used to be. I'd rather applications be limited in what they can access on my system by default, and a way to change it based on my needs. I don't want the programs to decide on their own what they're entitled to anymore. There's been a fundamental breach of trust by too many actors too many times.

Yes, you should be able to run apps you want in a way you want. Not the way the manufacturer or OS vendor wants.

Of course sandboxing options should be available, but if you wanted to run an app fully unrestricted, you should be able to.

I am still quite upset that I cannot run call recording apps on Android as they can't obtain permission to record audio during a call.

edit:

Just to add, call recording is legal in my country. Years ago it saved me from losing money when insurance company attempted to scam me. I agreed to a policy over the phone based on the promised features. When I got the documents mailed, it turned out most of what was promised was missing in the agreement. Then company said they never promised these things and wanted to charge me substantial cancellation fee. Once I told them I have recordings, they backtracked on everything and cancelled it.

The other ways I found it very useful was recording calls with my doctor so I could listen again in case I forgot or misheard something and also I used to record calls with my very ill relative to have some memories of him.

Now I cannot do that anymore.

The key point for someone "who wants full control over my system" is that *you*, the end user, have the final say over what programs are entitled to.

End users can't be trusted. Most of them are a "Taylor Swift nudes here! Download this file, open it, and enable all requested permissions" away from being pwned. The most effective defense against this kind of attack has been allowlisting what can be run.

>We really can't afford the risks of letting everybody just run arbitrary code.

You are, of course, talking about JavaShit right?

It's like they are asking to get slapped by the EU. Hopefully they will be, and hard.

Which EU law would that violate? Especially since EU is lately very sensitive about digital abuse.

The Digital Markets Act (DMA), presumably: the law that forced Apple to allow installing apps from third party sources (though I doubt their current solution is compliant).

Large vendors (gatekeepers) are not allowed to give themselves benefits that their competitors don't have. A third party alternative must have the ability to compete with the gatekeepers, which means Google isn't allows to treat Google Maps specially, Apple isn't allowed to treat Safari specially, and so on.

They can still comply with these laws if they have a quick and accessible method of getting your app store listed in the exemption list (which would quickly run into edge cases from apps like Aurora and the abusive shitstains that install stalkerware), especially if they show their willingness by pre-populating the list with common Play Store alternatives. They could also just disable the feature in EU phones (the way Apple chose to comply with the law) so they don't break the law. Or they could leave the list unpopulated inside the EU, making the OS harder to use for EU users but not exempting themselves as a middle finger to the EU lawmakers (the way Apple tends to comply with these laws).

This doesn't apply to third-party stores I think.

If this works anything like other prompts of this kind, this will only appear for apps installed directly from an apk file, but not via apps installed from a store, even if the store itself was installed through an app file.

In principle, it would be possible to create a store that installs apps from the file system, perhaps with some affordances to enable automatic updates from a URL. I don't think it could support app files directly, there are some extra requirements on store "bundles", but an "installer" should be possible.

Presumably gets close to

> Digital Markets Act, a 2022 law that requires Apple to open iPhones in the bloc to competing app marketplaces and alternative payment systems for in-app sales.

They are not blocking side loading, they are closing a loophole that prevented what Google deems "sensitive permissions" from being locked away behind a number of scare screens. It appears that you will still be able to grant those permissions for apps downloaded from outside the playstore, you will just have to jump though the same hoops you have to do today for apps that are not using the current loophole.

The article lists clearly that the exception doesn't appear for any app store, not just Google Play ones. It uses PackageManager APIs there.

For any appstore explicitly allowlisted.

Do you think Google will allowlist fdroid?

Is there any good data/analysis on how prevalent attacks on these devices are?

I’m always on the fence with this stuff. As an engineer I like having access to my device, and the freedom to tinker.

But on the flip side. It’s obvious to me that these devices that people’s lives revolve around are absolutely critical targets.

Bank accounts, location, 2fa apps/sms, crypto apps, scam calls, literally all the user’s communications are on offer.

Ive a feeling this comes from some Singapore Govt ruling to "protect" citizens from scam app. https://www.straitstimes.com/tech/android-users-in-s-pore-to...

So it will be less and less possible to use apps downloaded from other places. This is both anti-user and anti-competition.

They see apple asking for 99 dollars a year and wonder why they aren't doing that already.

Reasonable, but I can't help thinking that the expectation here is that most users won't do anything about the restriction - the net effect is to discourage developers from sideloading altogether.

Most apps don't need these restrictions. It's a bit annoying if you're installing some kind of third party accessibility service, but I can't remember when I last installed an app that needed notification access.

These permissions are rarely needed and often abused by stalkerware to do things like read messages and screen contents.

If they keep the override button in the settings, I honestly don't mind the change, as long as Google Play and vendor app stores aren't exempted. If you're going to make things difficult for developers, make them difficult for your own developers as well.

I'm sure the DMA will affect this feature for EU models, or Google will be subjected to a chunky fine and forced to change it the moment the first signs of abuse pop up.

Google has restricted more and more functionality to their apps only. System signed, that is.

The only way for e.g. KDE connect to continue working properly today is using adb, three hacky permissions, accessibility access and notification access.

It's just going to get worse.

But if I had a Chromebook, Google would give me the same functionality for free.

Yeah, it's rather annoying that I needed to root my phone to fix KDE Connect's clipboard access. That's the only workaround I've needed for years, though. The (relatively recent) changes Google made to the app store API made my life a whole lot easier now that F-Droid can actually update packages without root access.

As long as the existing manual overrides (going through the settings and toggling the permission) still exists, I don't see much of a problem.

It's becoming a common scam in India where people are sent a malicious APK via WhatsApp and the moment they install it, the attacker will reset their passwords via Phone Number + 2FA

Why only side loaded apps though?!

And the walled garden gets hiked up a few more inches, just as Google always planned.

From the article and comments, I'm assuming this will operate similarly to how Windows makes it slightly harder to run applications that aren't signed by a known trusted source.

If so, I don't have a problem with that.

I have, first you have to click "yes" on a modal dialog that blocks screen completely when you start the app, then you have to check checkbox "yes, I agree" and then click ok, then you have to change some hidden settings, then this settings "accidentally" reverts on each update... until they remove it completely. Microsoft, Google, Apple wants more and more control as usual.

Reply on news.ycombinator.com