←back to thread

Everyone knows all the apps on your phone

(peabee.substack.com)
1192 points gniting | 3 comments | 29 Mar 25 21:26 UTC | HN request time: 0.75s | source
Show context
captn3m0 ◴[30 Mar 25 02:37 UTC] No.43520750[source]▶
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

replies(5): >>43520922 #>>43521144 #>>43521275 #>>43522877 #>>43525081 #
3abiton ◴[30 Mar 25 04:13 UTC] No.43521275[source]▶
> 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.

replies(2): >>43522389 #>>43524918 #
ignoramous ◴[30 Mar 25 08:21 UTC] No.43522389[source]▶
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.
replies(4): >>43522525 #>>43523196 #>>43523377 #>>43523961 #
pava0 ◴[30 Mar 25 08:45 UTC] No.43522525[source]▶
What do you mean by "break open the app sandbox"?
replies(1): >>43523886 #
schnatterer ◴[30 Mar 25 13:11 UTC] No.43523886[source]▶
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.
replies(6): >>43524412 #>>43525977 #>>43526517 #>>43530612 #>>43538653 #>>43538685 #
1. ignoramous ◴[30 Mar 25 14:18 UTC] No.43524412[source]▶
A more recent (2023) sandboxing + isolation overview by the Android team: https://arxiv.org/html/1904.05572v3/ (section 4.3)
replies(1): >>43526257 #
2. NotPractical ◴[30 Mar 25 18:15 UTC] No.43526257[source]▶
> 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...

replies(1): >>43535133 #
3. ignoramous ◴[31 Mar 25 13:56 UTC] No.43535133[source]▶
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.