Everyone knows all the apps on your phone

The ACTION_MAIN loophole has been written about before: https://commonsware.com/blog/2020/04/05/android-r-package-vi...

Google refuses to patch this. I wonder what would happen if you submit it to the Android VDP as a permission bypass.

There’s also this SO question by the author about the bypass: https://stackoverflow.com/q/79527331

Thanks for the link, seems like the loophole is already there since the introduction of the package visibility restriction, and almost everyone and their mother knows how to bypass this restriction.

> Google refuses to patch this

While I don't believe Google engineers are not aware of this widely used loophole, do you have any source that they refused to fix it?

That loophole was published 5 years ago, it hasnt been fixed since.

Do you need someone from Google to explicitly write an official note, notarized, indicating they are refusing to fix it?

What do you mean with "refused to patch this"? Google will reject any app publishing attempt that asks for that filter and isn't a launcher on Play store.

> refusing to fix it

Google addressed similar isolation concerns (without breaking a tonne of APIs in incompatible ways) with Private Space and Work Profile: https://source.android.com/docs/security/features/private-sp...

Author claims that this same hack is used widely, including by apps on the Play Store like Snapchat and Facebook.

> Google refuses to patch this.

That's why projects like XPL-Extended (and previously XPrivacyLua), are an absolute need. I never run an android phone without these.

How is that congruent with the article's claim that 31 out of 47 apps they tested had this filter?

No idea, but we did have apps rejected because of similar permissions.

"similar". so what you said isn't true then?

XPrivactLua and other XposedMod/Magisk extensions break open the app sandbox. It is better to restrict running those on usereng/eng builds (test devices). For prod builds (user devices), I'd recommend using Work Profiles (GrapheneOS supports upto 31 in parallel) or Private Spaces (on Android 15+) to truly isolate apps from one another.

What do you mean by "break open the app sandbox"?

If it's a security issue fix, they should release it in one of the monthly security patch.

I also think that private space do not fix the underlying issue. If you have four apps and you don't want them to know about each other you can put one of them in main profile, work profile, app locker and you run out of profile for the last one. The way app locker work doesn't scale to tens of sandbox.

Submitting it to the Android VDP is a solid idea, though I wouldn't be surprised if it gets waved off as "working as intended."

The HSBC bank app uses this and is in the Play Store.

The question is: Who is the beneficiary of the app sandbox? Is it you, the user, because no malicious processes can taper with your apps? Or is it the corporations, because they prevent you from modifying their apps – which makes you a pure consumer?

I think, for the tech-savvy, the latter is more accurate and I think it is very important to be able to crack open these sandboxes and tinker with processes. Be it to inject ad blockers, automate them, modify their appearance, etc. It should be a right of a user to be able to do these things.

Can't wait for App List Scopes, like we have with Contacts or Storage already. Not a day too early.

For a few months all the UK banks I have accounts in send the list of all apps to the mothership.

I noticed it first when suddenly Revolut refused to start up because I had an app installed, Natwest and Nationwide at least inform prior to the data collection, but weren't concerned.

It ended up with the long overdue confinement of all the banking apps in their dedicated profile, but I'd love to be able to confine them further.

I, the user.

Malicious apps sneak through the vetting process all the time.

Genuine, honest apps have to process unsafe content (be it we pages, messages) all the time.

One exploit should at most make single App vulnerable, not expose everything I have on my phone.

Strong, restrictive sandboxing, memory and execution protections are the only safe way.

And how is destroying the sandboxing related to having more rights as a consumer? You could still patch and repack them in the way Lucky Patcher does with ads, for example?

I know you didn't ask for this sort of answer, but you could use user profiles for this.

You can have more users on the "standard" AOSP Android as well, but with a certain AOSP-derived you can also have notifications forwarding.

Until they add Application List Scopes (I believe it's on the road map), in the exactly the same way users can now lie to apps they have only specific contacts in their contact list and only one or two specific folders in the Storage.

I found this description about the security risks of rooting very eye-opening https://madaidans-insecurities.github.io/android.html It also explains the sandbox.

I'm on Android 14 and I've been pretty happy with an app called Insular on F-Droid or Island on the Play Store. It let's you install as many instances of an app as you'd like and they'll show up in the work profile, ignorant of the others' existence.

The right ("as intended", in my view) functionality would be to support a manifest with, say, five apps, and if as a dev you wanted more youd apply to google for an exception (like aws limit increases) with a list of reasons for each app.

> I think, for the tech-savvy, the latter is more accurate and I think it is very important to be able to crack open these sandboxes and tinker with processes

Anyone tech-savvy that wants to mod their Android (like they'd mod Linux distros), should consider purchasing Android devices (like Pixel) that support ownership transfer (that is, unlocking then relocking the bootloader), and flash CalyxOS/GrapheneOS usereng/eng builds.

I know people may not remember this, but Android was initially designed with interoperability in mind. It's sad to see both the system development and the community opinion to have turned against it so hard.

A more recent (2023) sandboxing + isolation overview by the Android team: https://arxiv.org/html/1904.05572v3/ (section 4.3)

You mentioned NatWest. I remember using NatWest and noticing on NoRoot Firewall (on my Android) it was 'speaking' regularly to Facebook. Of course I had all FB and IG and their IP ranges blocked from the get-go, but still. Why (TF!!!!) would my effing back telling FB that I launched their app? (one could say that they use this or that library, so the code, blah blah blah)

This is disgusting and the reason I don't use iOS. The utter lack of firewall! (plus the batterygate scandal)

> If there is one leap that the infosec community consistently fails to make, it is this: people who are not like me, who have different needs and priorities, who have less time or are less technical, STILL DESERVE PRIVACY AND SECURITY.

https://hachyderm.io/@evacide/114184706291051769

It seems like the ACTION_MAIN loophole could be fixed (eventually) if apps that declare it are required to actually be launchers. It seems like legitimate integrations should have more specific intents.

At that point, Android prompting if random game you just downloaded should be your defaut launcher seems pretty dangerous interaction for sneaky apps to risk. They either cause the user to bounce and report or the fools select it as default launcher, replace their launcher, can't provide the launcher functionality and break the user's home screen and end up getting reported in Play Store. I also assume actually getting published as a launcher-class app at that point brings automated testsuites and other requirements that will be burdensome for developers.

it's a frontend to work profiles feature.

not recommended to run insular anymore. use Shelter for a14

that proves bad faith.

they keep releasing overly complicated features to sidestep the obvious reported vulnerability, to silence power users and please corporate enterprise sysadms.

the rest of the 99.9 of users keep the vulnerability, which is very profitable for ad networks. wonder why an ad networks who maintains android would do that.

That link seems to have... an agenda. It's way too hand-wavy (e.g., it doesn't at all attempt to tease out the nuance of whether a rooted phone inherently has a broken security boundary by design, or whether [like on Linux] it's secure as long as the implementation is non-buggy) and seems laser-focused on convincing users that desire sovereignty over their own devices that they might as well jump off a cliff.

> Android’s security design has fundamentally been based on a multi-party authorization model: an action should only happen if all involved parties authorize it.

> these are user, platform, and developer (implicitly representing stakeholders such as content producers and service providers). Any one party can veto the action.

How is this not anti-user? It explicitly states that the app developer should be able to veto my decisions...

Madaidan's articles are well-known to be centered around "security at all costs", and often at the cost of user freedom. That's just not a realistic take when it comes to privacy. What good is absolute security if all it does is secure the device from your "tampering"? Sure, it would be nice if the device were highly secure, but I'd rather it stop spying first.

With absolute security, you can rest assured that only Google has access to all of your data, and only Google is allowed to turn off the siphoning.

As dataflow says that site has an agenda. I've used rooted phones continuously since Android v4 and I've had no trouble. Moreover, I'd posit that much of the crap I remove from phones lowers the attack risk which to some degree offsets the risk of rooting.

Granted, I'm not suggesting that everyone should root their phones, in fact in recent years I even stopped suggesting it to my tech-savvy friends (that is unless they approach me for advice).

I don't need to lecture about these things but all those who've rooted their phones know the huge advantages—power and control one has over one's phone is enormous.

For example, some apps contain so many trackers that normally you'd never use them except they're the only apps suitable for one's purpose. Rooting allows you the user to take control and have them do what you want and not that of the developer.

Yes, rooting has its risks but for my purposes its benefits far outweigh them.

Under the shared responsibility model, such veto makes sense. Just because the end-user (the app has no way to determine if it was a thief or a spy or a monkey or the actual device owner) approves of an action doesn't mean the OS and the app have to grant authorization.

I can see how such a setup is hostile to power users, but then Android is used by 50% of all humanity, and your guess is as good as mine as to just how many want "sudo make me a sandwich" level of control.

That sounds very sensible.

As someone who cherishes the power of root privs, I'd still like to make a point for alternative solutions that came up like distros such as GrapheneOS or CalyxOS or non-root filtering options via VPN. If it weren't for backups I could manage my everyday life without root. For all other cases I would root and later unroot my phone via an OTA update :D https://github.com/schnatterer/rooted-graphene/

Hopefully GrapheneOS deliver on their promise to provide a better backup solutions than seedvault.

I'd like to add one more finding about the perils of root access: https://github.com/chenxiaolong/my-avbroot-setup/blob/c52e44...

> The term [rooting] generally also includes the functionality for making runtime code patches (eg. with Zygisk) and making runtime filesystem modifications (eg. Magisk modules).

> Out of the many root-enabled apps I've studied or reverse engineered, the vast majority fail to handle arbitrary inputs properly (especially filenames). For example, some root-supporting file managers turn a seemingly benign action like listing a directory into local privilege escalation. This is trivially exploitable, especially with browsers auto-downloading files with server-provided filenames to /sdcard/Download/.

To avoid repeated root access UI prompts, some apps spawn a long-running shell session, write commands to stdin, and rely on parsing stdout and searching for the shell prompt to determine when commands complete. This approach is prone to desync, which can lead to commands being skipped or other inputs being interpreted as commands.

All in all, I simply do not trust most root-enabled apps to not leave a gaping security hole, so I avoid them entirely. There are apps that do handle root access in what I would consider a more proper way, by spawning a daemon as root and then talking to the daemon over a well defined binary protocol. Unfortunately, this approach is the extreme minority.

Undortunately the trend set by google is becoming extremely antagonistisc for modders. It's becoming a tradeoff between security and convenience, arguably that was not the case back in early android version, actually it was nearly the opposite. i remember hiw CyanogenMod features were surpassing the state of Pure Android at the time, it was fun to see the innovation happening in that space. Then came the ostracization of modders, from GApps restrictions to Play Integrity, all of those made it nearly impossible to have an android OS built to your taste, while able to run useful apps like banking and payments. It's sad that I have to carry 2 devices with me because Google took the greedy way.