zlacker

>>gnitin+(OP)
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

>>captn3+ou
> 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.

>>3abito+RC
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.

>>ignora+PU
What do you mean by "break open the app sandbox"?

>>pava0+1X
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.

>>schnat+Yi1
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.