❌ Software Removal | XPrivacyLua #1124

New Issue

2019-08-09T20:52:08Z

Mikaela commented

2019-08-09 20:52:08 +00:00

(Migrated from github.com)

Description

@blacklight447-ptio has been asking if we shouldn't list apps requiring root on Android and with a quick glance XPrivacyLua is the only root requiring app we list.

https://www.privacytools.io/operating-systems/#aaddons

The following add-ons require root access, which makes your device more vulnerable. Proceed with caution.

XPrivacyLua
Manage your apps' permissions with XPrivacyLua
Revoking Android permissions from apps often let apps crash or malfunction. XPrivacyLua solves this by feeding apps fake data instead of real data.

Requirements: Magisk (xda-developers), Xposed Framework (xda-developers)

## Description @blacklight447-ptio has been asking if we shouldn't list apps requiring root on Android and with a quick glance XPrivacyLua is the only root requiring app we list. * https://www.privacytools.io/operating-systems/#aaddons > The following add-ons require root access, which makes your device more vulnerable. Proceed with caution. > XPrivacyLua > Manage your apps' permissions with XPrivacyLua > Revoking Android permissions from apps often let apps crash or malfunction. XPrivacyLua solves this by feeding apps fake data instead of real data. > > Requirements: Magisk (xda-developers), Xposed Framework (xda-developers)

blacklight447 commented

2019-08-09 22:21:02 +00:00

(Migrated from github.com)

yh, i don't think increasing the attack surface this much and breaking the os's fundamental security model is worth it.

👍 1

beerisgood commented

2019-08-09 22:46:28 +00:00

(Migrated from github.com)

Root destroy the whole system security.
You got no advantage which such solutions. Just wait for Android 10 / Q for new internal privacy improvement

Root destroy the whole system security. You got no advantage which such solutions. Just wait for Android 10 / Q for new internal privacy improvement

👍 1

dawidpotocki commented

2019-08-10 00:56:50 +00:00

(Migrated from github.com)

If something I would remove it, because of Xposed and not root.

dreamerchris commented

2019-08-10 07:41:11 +00:00

(Migrated from github.com)

I propose that it will not be removed but there should be some badges like, a green badge for root access app only if its open source and proven to be safe but the pop up it should state "warning: root access equals the app can access and modify all the file system of your device which means that even a safe app if updated before cheching if the update is safe or if the pp has a bug or has evaded detection by first evaluation could compromise your safety"

A orange root access badge if the app has auto update or a way to update the app by pressing a button

And maybe a red badge for root access that is not open source and even if it's open source and it hasn't it been audited by specialists

I propose that it will not be removed but there should be some badges like, a green badge for root access app only if its open source and proven to be safe but the pop up it should state "warning: root access equals the app can access and modify all the file system of your device which means that even a safe app if updated before cheching if the update is safe or if the pp has a bug or has evaded detection by first evaluation could compromise your safety" A orange root access badge if the app has auto update or a way to update the app by pressing a button And maybe a red badge for root access that is not open source and even if it's open source and it hasn't it been audited by specialists

beerisgood commented

2019-08-10 07:51:07 +00:00

(Migrated from github.com)

Even if the root app is clean/ safe, root still isn't safe. No matter for what

Exposing app-accessible root access for privacy / security features massively reduces the security of the OS by completely breaking the basics of the security model and massively increasing attack surface. It's an incredibly lazy way of implementing features by people being negligent with user security. It's never needed, and you should never use improperly written code taking this approach. It should be using privilege separation and preserving the security model rather than handing root to any attacker able to gain a bit of control over the user interface layer of the OS or just exploiting an application granted this access.

from GrapheneOS Dev: https://www.reddit.com/r/GrapheneOS/comments/bx2uq9/internal_firewall_feature/eq30ric/

Even if the root app is clean/ safe, root still isn't safe. No matter for what > Exposing app-accessible root access for privacy / security features massively reduces the security of the OS by completely breaking the basics of the security model and massively increasing attack surface. It's an incredibly lazy way of implementing features by people being negligent with user security. It's never needed, and you should never use improperly written code taking this approach. It should be using privilege separation and preserving the security model rather than handing root to any attacker able to gain a bit of control over the user interface layer of the OS or just exploiting an application granted this access. from GrapheneOS Dev: https://www.reddit.com/r/GrapheneOS/comments/bx2uq9/internal_firewall_feature/eq30ric/

dreamerchris commented

2019-08-10 07:57:09 +00:00

(Migrated from github.com)

Well there should be a page just for root that explains the risks but some people (like me) want root cause Of want full control, so privacytools.io should include root apps and if they are safe and open source they should be promoted

beerisgood commented

2019-08-10 08:07:37 +00:00

(Migrated from github.com)

And here a comment about XPrivacy itself:

(User question quoted) xPrivacyLua is selfexplaining

(Dev's answer) It's not self-explaining, and see below for why you probably don't want this. You do probably want the ability to force apps to see fake data, but this doesn't do that. It's a client-side check inserted into the app that the app can bypass (even unintentionally, by using a different client-side implementation) or disable.

And

(User question quoted) You should try to look for a rootless solution of your needs xprivacylua: virtualxposed (latest version from github) can be used to isolate apps and apply xprivacy rules to them.

(Dev's answer) It does not provide any isolation and cannot fundamentally improve privacy / security because it's based on client side checks, which is not a working approach. It relies on apps not accessing the data via other approaches or alternate implementations of the client-side code, which isn't uncommon. Apps can also detect it and simply work around it directly. This will only give you a false sense of privacy / security. Apps will likely use the fake data for their user-facing functionality, making you think that it works, but a tracking SDK bundled with the app can easily bypass this and harvest your data if you allow the permissions via the OS. This is harmful approach...

https://www.reddit.com/r/GrapheneOS/comments/ch5kv8/is_magisk_and_edxposedxprivacylua_working/euqzel7/

And here a comment about XPrivacy itself: > **(User question quoted)** xPrivacyLua is selfexplaining >> **(Dev's answer)** It's not self-explaining, and see below for why you probably don't want this. You do probably want the ability to force apps to see fake data, but this doesn't do that. It's a client-side check inserted into the app that the app can bypass (even unintentionally, by using a different client-side implementation) or disable. And > **(User question quoted)** You should try to look for a rootless solution of your needs xprivacylua: virtualxposed (latest version from github) can be used to isolate apps and apply xprivacy rules to them. >> **(Dev's answer)** It does not provide any isolation and cannot fundamentally improve privacy / security because it's based on client side checks, which is not a working approach. It relies on apps not accessing the data via other approaches or alternate implementations of the client-side code, which isn't uncommon. Apps can also detect it and simply work around it directly. This will only give you a false sense of privacy / security. Apps will likely use the fake data for their user-facing functionality, making you think that it works, but a tracking SDK bundled with the app can easily bypass this and harvest your data if you allow the permissions via the OS. This is harmful approach... https://www.reddit.com/r/GrapheneOS/comments/ch5kv8/is_magisk_and_edxposedxprivacylua_working/euqzel7/

blacklight447 commented

2019-08-10 09:44:35 +00:00

(Migrated from github.com)

The problem is, if anything gets control over the GUI layer, it can trivially trick the user into granting root access, so just saying "just don't grant root access" sadly doesn't hold up.

👍 3

Namnodorel commented

2019-10-28 15:59:33 +00:00

(Migrated from github.com)

I would like to add to the discussion with this:

if anything gets control over the GUI layer, it can trivially trick the user into granting root access

If an attack gains control over the UI layer, you likely already have bigger problems than tricking the user into anything. Root access would be "the final straw", but once an application is this powerful the device is basically lost.

About the statement from the GOS dev:
It's true that apps can technically bypass XPL, however that doesn't mean it's generally useless. It won't be of too much help when you install an app that specifically tries to do harm or circumvent XPL. But I'd say that this is rather unlikely in your average threat model. Instead, the usual use of XPL is to prevent apps that just "casually" collect data in the background from doing so. XPL isn't popular enough to be deliberately circumvented by the major data collection companies, which means that in the majority of cases, using it will be an improvement - especially, when the OS you're using just allows access to what XPL would usually fake! This is still quite a lot, even with the improvements from the latest versions of Android.

I can agree that XPL isn't the solution to all of our privacy problems, but it can still help significantly. It can be used without root, with solutions like the aforementioned VirtualXposed.
IMO it should be made clear for what XPL is good for and for what it isn't, but not being a perfect solution should not be the reason to discard it.

I would like to add to the discussion with this: > if anything gets control over the GUI layer, it can trivially trick the user into granting root access If an attack gains control over the UI layer, you likely already have bigger problems than tricking the user into anything. Root access would be "the final straw", but once an application is this powerful the device is basically lost. About the statement from the GOS dev: It's true that apps can technically bypass XPL, however that doesn't mean it's generally useless. It won't be of too much help when you install an app that specifically tries to do harm or circumvent XPL. But I'd say that this is rather unlikely in your average threat model. Instead, the usual use of XPL is to prevent apps that just "casually" collect data in the background from doing so. XPL isn't popular enough to be deliberately circumvented by the major data collection companies, which means that in the majority of cases, using it will be an improvement - especially, when the OS you're using just allows access to what XPL would usually fake! This is still quite a lot, even with the improvements from the latest versions of Android. I can agree that XPL isn't the solution to all of our privacy problems, but it can still help significantly. It can be used without root, with solutions like the aforementioned VirtualXposed. IMO it should be made clear for what XPL is good for and for what it isn't, but not being a perfect solution should not be the reason to discard it.

This repo is archived. You cannot comment on issues.