🆕 Software Suggestion | Add back XPrivacyLua #2147

New Issue

2020-12-07T07:05:38Z

LoganDark commented

2020-12-07 07:05:38 +00:00

(Migrated from github.com)

Basic Information

Name: XPrivacyLua
Category: Android Privacy Add-ons
URL: https://lua.xprivacy.eu/

Description

XPrivacyLua is an application allowing you to prevent applications from accessing your real data by feeding them fake data instead. In fact it's more like a framework that allows you to hook any Java method call or field access to do whatever you want using the Lua programming language. Using these hooks you can do things like hide your contacts list (while making the app think it still has permission to access it), or block calls to tracking / advertising APIs. It comes with a library of built-in hooks to help you get started.

You can use the included hooks but you can also use the companion app to create your own hooks for free. They can run any Lua code you want, and intercept whatever you want as well.

Why I am making the suggestion

XPrivacyLua has been suggested before. There was a great effort to argue against its inclusion and then eventually remove it on the basis that root compromises security. I am here to make my case and propose that XPrivacyLua be added back.

First I will attempt to refute the most common claim, which is that rooting your device undermines privacy or security in some way. I do not believe this is true anymore.

Why root is not insecure (anymore)

Rooting has evolved considerably in recent years and is no longer the hackish mess that it used to be. Yes, it is still kind of ugly to work with Android internals but the community as a whole is starting to move towards a more secure system: let me explain.

I think I should start with the most archaic forms of rooting an Android device. This is so that we can understand why these claims are being made. And so that we can understand why rooting used to be so insecure and, frankly, a big hack.

Way before Android 4, basic methods of rooting the device consisted of gaining root once through some sort of exploit, and placing a setuid binary somewhere which allows processes to elevate their own privileges to root when the binary is executed. It was usually placed somewhere in PATH so processes can simply execute su to gain root.

Various exploits were performed by Poot, Framaroot and other such rooting apps. Later on, there were other exploits like this 2015 use-after-free (Android 4.4), Dirty COW (Android <7), this 2019 use-after-free (Android <10?), the rootmydevice backdoor, and a couple on Android Vulnerabilities, like Diaggetroot, NachoRoot and PingPongRoot, but I'm not going to focus on exploits. One way or another, an su binary was placed.

This method, utilizing only a setuid binary with no verification, was one of the messiest and most insecure ways to root a device, aside from running everything as root by default:

On those old Android versions, root permissions could do anything. Anything, at all, ever, no SELinux, no nothing. SELinux was introduced in 4.3 but was not fully enforcing until 5.0, which was still far off at this point.
Modifying /system would break verification checks... which for the most part did not exist yet back then. Even SafetyNet was only introduced in Android 5 (or thereabouts). Verified boot, however, was introduced in Android 4.3.
The su binary was helpless against detection or deletion, there was no arbitrator. Any process could detect root, any process could unroot the device instantly, without user confirmation or choice, or do other nefarious acts.

There were advantages:

Apps that wanted root could have it, for deep system customization, patching, removing bloatware, cool hardware things, or custom OS flashing.

There were drawbacks as well:

Apps that wanted root could have it, and you couldn't do anything about it (except hide the binary). Malware could instantly dig deep into the OS with no possibility of removal, and then it could unroot your device instantly - leaving you helpless. Many pieces of malware were found in the wild that took advantage of root permissions. They could even root devices on their own to install themselves, using the same methods found in Poot, Framaroot and friends.

However, eventually, some apps came out in the Android 2 era, namely Superuser and then SuperSU (both by Chainfire). These apps attempted to solve the problem of processes being able to gain root access whenever they wanted, by requiring the user to grant permission via a popup dialog.

They still modified the system, of course, though verified boot still did not exist back then. Aside from social engineering tactics, apps could no longer gain root access just by being on a rooted system. This was a huge upgrade in security from the old setup where anything could have root at any time. The old setup essentially made all security pointless in Android.

This worked for a time. It was a basic form of security which satisfied users and gave them peace of mind. It made it harder for malicious apps to gain root access, unless they replicated the exploit that was originally used to root the device.

However, SELinux was going to pose a problem. In Android 4.3, SELinux was brought in and being tested (in permissive). In Android 4.4, SELinux was partially enforced and dm-verity was introduced. dm-verity was extremely problematic for non-systemless roots (placing a binary directly in /system) because the device would panic once the su binary was read from disk, and either remove it (error correction) or refuse to boot and display a message that the phone was corrupted.

Around this time (Android 4) bootloader unlocking was starting to be introduced as a thing that certain devices allowed you to do. It was about the perfect time for that to happen, because it would start a trend that continues to this day - (certain) OEMs being friendly to users modding their devices. Bootloader unlocking was likely the biggest factor in making Magisk possible, as it was starting to look like more recent versions of Android were going to make temporary root access insufficient for rooting!

And that's exactly what happened. Once Android 5.0 came around, surprise surprise, Google's test run had concluded and SELinux was fully enforced, as well as dm-verity. setuid binaries didn't even work anymore because the system partition was being mounted with nosuid. Someone had to find a new solution, or it could have been the end of rooting.

And that is exactly what topjohnwu did with Magisk. Rather than trying to demolish existing protections, Magisk ensures that they are all still fully functional. It also takes steps to ensure that userspace applications cannot detect its existence (when MagiskHide is turned on, at least). It treats root access as the dangerous thing that it is, and implements proper SELinux-enforced protections against exploitation.

Magisk operates in an SELinux environment by creating a couple new SELinux contexts which normal Android applications have no access to (or knowledge of). It overlays /system, not by changing the files underneath, but by using ✨✨ mounting stuff ✨✨ to overlay the filesystem tree by linking locations in /system to files in /data. This is how it places its su binary.

And what a wonderful piece of work that su binary is. It's no longer the gaping security hole that older su binaries were; it is in fact the only binary permitted by SELinux to communicate with Magisk (Internal Details). Rather than raising the privileges of the caller, it runs a subprocess under the magiskd daemon, meaning applications can choose to separate their root access from the rest of the process. This is a nice bonus.

Additionally, thanks to the "Magic Mount" system that Magisk uses, the presence of the su binary can actually be hidden from applications that don't need to see it. The su binary now has protection against detection.

And that's not all. Magisk goes to great lengths to ensure that userspace is not compromised whatsoever. All privacy is still in place, all security is still in place, and if you're determined enough, you can actually enable verified boot & dm-verity with Magisk installed. It's a bit of a process, but I'm working towards it myself.

They are able to keep SELinux enforcing, and the entire operating system secure, and only when the user explicitly allows it can an app gain access to root. Root is simply a new privilege level, a new level of access controlled by the user, and does not undermine security or privacy just by existing.

Anyway, enough about that, and more about root in general. I like to think of root as an extension of the user. The only things that should be granted root are things that the user trusts especially, things that the user knows are going to be above everything else in the system. This includes Magisk itself, interactive terminal sessions that the user controls, Magisk modules (obviously), and certain apps that do cool things, like substratum for theming (they do have a non-root plugin, but it's paid).

Everything else runs securely in userspace. Everything else is untrusted, as it should be. THIS IS WHERE THE PRIVACY TOOLS APPLY! This UNTRUSTED SPACE is where the user wants to harden things. The fact that a space exists above this now is NOT a security compromise, now that no root access is granted without the permission of the user!

Magisk takes steps to prevent click/tapjacking, overlays and etc. from affecting the dialog, and it even has a setting to require biometric authentication to authorize root access to an app. These are all good steps and I believe that root is starting to head towards being just as secure as an unrooted, factory-locked device. Also, I think SuperSU is still sorta-modern and does some modern stuff, but I'm not experienced with it personally.

I know it's nice to be stuck in the past - I totally get it. I've worked with Android phones as low as Android 2.2, and totally tricked out a Jelly Bean phone with CM12, back when that was a thing. However, that's simply not how things are anymore. We're all the way up to Android 11 now (although my phone is still A10). Security has gotten better, MUCH better, and instead of violating security, Magisk has preserved it. This, I think, is proof enough that root does NOT deserve to be ruled out. Root is not this shady, hacky, device-destroying nightmare that you all make it out to be.

It is my belief that YES, XPrivacyLua SHOULD be listed. The fact that it requires root access does not make it invalid. In fact, if anything, that should make it more valid than the other tools listed here, purely because of how powerful it is. How much you, as a knowledgeable user, can use it to its full potential, and lock away anything you don't want apps accessing.

Why SafetyNet is not a concern (for those who care)

Magisk can easily pass SafetyNet on modern (but not too modern) devices without modification simply by enabling MagiskHide. And so can recent versions of Riru - EdXposed, as long as Riru is hidden. There's not really much more to say about this. The proof is in the pudding.

An important point here is that response verification succeeds. The reason it's an important point is because I am not using mods like HiddenCore which grossly clobber the entire SafetyNet check and say "yeah here you passed and here is a shitty blank signature". Most apps will not accept that. I am getting a real response from Google that my device passed the test.

That said, there IS a new cat in the cat-and-mouse game - hardware-backed key attestation. Even if you do manage to re-lock the bootloader without bricking your device (which is a feat in its own right), you will not be able to hide your self-signed status. Google has (unfortunately) recognized the fact that boot status is no longer as simple as "is the bootloader unlocked?", and hardware-backed systems have the ability to report that the bootloader is locked but the OS is still not stock - bad news for us modders.

It will most likely be (ab)used by apps to reject any ROM that is not OEM-signed. You'd need extremely expensive equipment and a very skilled professional to extract the keys from the device to emulate this in software, so that's absolutely not feasible by any stretch of the imagination. You can only deal with it - or take the route of disabling hardware backed attestation altogether, which has been working quite well I hear.

Yes, indeed, you can disable it by simply saying that your phone is one without hardware-backed capabilities. That works well - end of story.

Well, kind of. It works right now while there are still phones in the wild which pass SafetyNet without hardware backed attestation, but... those are going to die out in a few years when they are no longer receiving updates. When your phone gets ahead of the one you are imitating, Google will know.

Anyway, the fact that Magisk and EdXposed pass the basic certification should mean you're good to go. As long as you have a phone which is moddable - if you're interested, I have a OnePlus 7 Pro. Feel free to imitate my phone as well, I won't mind <3

(btw: the module for imitating your fingerprint like this is called MagiskHide Props Config)

I've tested a couple more aggressive root checking apps, more aggressive than SafetyNet is, and take a look at the results:

~~Wow, so confident! Are you sure about that? ;))))~~

I have not made any extra modifications to evade detection - besides hiding Magisk, EdXposed, and using XPrivacyLua to hide my applications list (pending https://github.com/M66B/XPrivacyLua/pull/13/ of course). Yes, XPrivacyLua is actually the hidden piece of the puzzle here, and the reason I'm so convinced that it's necessary.

There are still more exotic PoCs that I have yet to test, but RootBeer is the go-to solution for many apps, so if you can evade that, you can evade a lot.

Thanks for coming to my TED talk

I hope this issue inspires you to reconsider your stance on root access and XPrivacyLua. :)

I will try to be as active as possible addressing any concerns you may have.

If you spot any errors in my writing, please point them out so I can fix them, thanks :D I proofread this many times and did my research but it's still possible I missed something.

My connection with the software

I'm a root user who uses XPrivacyLua to only allow apps to read the data they need to operate, not all of the permissions that they demand. I have put up for review a couple new hooks but they have not been accepted or reviewed yet.

I will keep the issue up-to-date if something I have said changes or I remember a connection with the software.

## Basic Information **Name:** XPrivacyLua **Category:** Android Privacy Add-ons **URL:** https://lua.xprivacy.eu/ ## Description XPrivacyLua is an application allowing you to prevent applications from accessing your real data by feeding them fake data instead. In fact it's more like a framework that allows you to hook any Java method call or field access to do whatever you want using the Lua programming language. Using these hooks you can do things like hide your contacts list (while making the app think it still has permission to access it), or block calls to tracking / advertising APIs. It comes with a library of built-in hooks to help you get started. You can use the included hooks but you can also use the companion app to create your own hooks for free. They can run any Lua code you want, and intercept whatever you want as well. ## Why I am making the suggestion XPrivacyLua has been suggested before. There was a great effort to argue against its inclusion and then eventually remove it on the basis that root compromises security. I am here to make my case and propose that XPrivacyLua be added back. First I will attempt to refute the most common claim, which is that rooting your device undermines privacy or security in some way. I do not believe this is true anymore. ### Why root is not insecure (anymore) Rooting has evolved considerably in recent years and is no longer the hackish mess that it used to be. Yes, it is still kind of ugly to work with Android internals but the community as a whole is starting to move towards a more secure system: let me explain. I think I should start with the most archaic forms of rooting an Android device. This is so that we can understand why these claims are being made. And so that we can understand why rooting used to be so insecure and, frankly, a big hack. Way before Android 4, basic methods of rooting the device consisted of gaining root once through some sort of exploit, and placing a setuid binary somewhere which allows processes to elevate their own privileges to root when the binary is executed. It was usually placed somewhere in PATH so processes can simply execute `su` to gain root. Various exploits were performed by Poot, Framaroot and other such rooting apps. Later on, there were other exploits like [this 2015 use-after-free](https://www.blackhat.com/docs/us-15/materials/us-15-Xu-Ah-Universal-Android-Rooting-Is-Back-wp.pdf) (Android 4.4), [Dirty COW](https://en.wikipedia.org/wiki/Dirty_COW) (Android <7), [this 2019 use-after-free](https://bugs.chromium.org/p/project-zero/issues/detail?id=1942) (Android <10?), [the rootmydevice backdoor](https://www.theregister.com/2016/05/09/allwinners_allloser_custom_kernel_has_a_nasty_root_backdoor/?ma=1505433635001), and a couple on [Android Vulnerabilities](https://androidvulnerabilities.org/all), like Diaggetroot, NachoRoot and PingPongRoot, but I'm not going to focus on exploits. One way or another, an `su` binary was placed. This method, utilizing only a setuid binary with no verification, was one of the messiest and most insecure ways to root a device, aside from running everything as root by default: - On those old Android versions, root permissions could do anything. Anything, at all, ever, no SELinux, no nothing. SELinux was introduced in 4.3 but was not fully enforcing until 5.0, which was still far off at this point. - Modifying /system would break verification checks... which for the most part did not exist yet back then. Even SafetyNet was only introduced in Android 5 (or thereabouts). Verified boot, however, was introduced in Android 4.3. - The `su` binary was helpless against detection or deletion, there was no arbitrator. Any process could detect root, any process could unroot the device instantly, without user confirmation or choice, or do other nefarious acts. There were advantages: - Apps that wanted root could have it, for deep system customization, patching, removing bloatware, cool hardware things, or custom OS flashing. There were drawbacks as well: - **Apps that wanted root could have it**, and you couldn't do _anything_ about it (except hide the binary). Malware could instantly dig deep into the OS with no possibility of removal, and then it could unroot your device instantly - leaving you helpless. Many pieces of malware were found in the wild that took advantage of root permissions. They could even root devices on their own to install themselves, using the same methods found in Poot, Framaroot and friends. However, eventually, some apps came out in the Android 2 era, namely Superuser and then SuperSU (both by Chainfire). These apps attempted to solve the problem of processes being able to gain root access whenever they wanted, by requiring the user to grant permission via a popup dialog. They still modified the system, of course, though verified boot still did not exist back then. Aside from social engineering tactics, apps could no longer gain root access just by being on a rooted system. This was a huge upgrade in security from the old setup where anything could have root at any time. The old setup essentially made all security pointless in Android. This worked for a time. It was a basic form of security which satisfied users and gave them peace of mind. It made it harder for malicious apps to gain root access, unless they replicated the exploit that was originally used to root the device. However, SELinux was going to pose a problem. In Android 4.3, SELinux was brought in and being tested (in permissive). In Android 4.4, SELinux was partially enforced _and dm-verity was introduced_. dm-verity was extremely problematic for non-systemless roots (placing a binary directly in /system) because the device would panic once the `su` binary was read from disk, and either remove it (error correction) or refuse to boot and display a message that the phone was corrupted. Around this time (Android 4) bootloader unlocking was starting to be introduced as a thing that certain devices allowed you to do. It was about the perfect time for that to happen, because it would start a trend that continues to this day - (certain) OEMs being friendly to users modding their devices. Bootloader unlocking was likely the biggest factor in making Magisk possible, as it was starting to look like more recent versions of Android were going to make temporary root access insufficient for rooting! And that's exactly what happened. Once Android 5.0 came around, surprise surprise, Google's test run had concluded and SELinux was fully enforced, as well as dm-verity. setuid binaries didn't even work anymore because the system partition was being mounted with nosuid. Someone had to find a new solution, or it could have been the end of rooting. And that is exactly what topjohnwu did with Magisk. Rather than trying to demolish existing protections, Magisk ensures that they are all still fully functional. It also takes steps to ensure that userspace applications cannot detect its existence (when MagiskHide is turned on, at least). It treats root access as the dangerous thing that it is, and implements proper SELinux-enforced protections against exploitation. Magisk operates in an SELinux environment by creating a couple new SELinux contexts which normal Android applications have no access to (or knowledge of). It overlays /system, not by changing the files underneath, but by using ✨✨ _mounting stuff_ ✨✨ to overlay the filesystem tree by linking locations in /system to files in /data. This is how it places its `su` binary. And what a wonderful piece of work that `su` binary is. It's no longer the gaping security hole that older `su` binaries were; it is in fact the only binary permitted by SELinux to communicate with Magisk ([Internal Details](https://topjohnwu.github.io/Magisk/details.html)). Rather than raising the privileges of the caller, it runs a subprocess under the `magiskd` daemon, meaning applications can choose to separate their root access from the rest of the process. This is a nice bonus. Additionally, thanks to the "Magic Mount" system that Magisk uses, the presence of the `su` binary can actually be hidden from applications that don't need to see it. The `su` binary now has protection against detection. And that's not all. Magisk goes to great lengths to ensure that userspace is not compromised whatsoever. All privacy is still in place, all security is still in place, and if you're determined enough, you can actually enable verified boot & dm-verity with Magisk installed. It's a bit of a process, but I'm working towards it myself. They are able to keep SELinux enforcing, and the entire operating system secure, and _only when the user explicitly allows it_ can an app gain access to root. Root is simply a new privilege level, a new level of access controlled by the user, and does _not_ undermine security or privacy just by existing. Anyway, enough about that, and more about root in general. I like to think of root as an extension of the user. The only things that should be granted root are things that the user trusts especially, things that the user knows are going to be above everything else in the system. This includes Magisk itself, interactive terminal sessions that the user controls, Magisk modules (obviously), and certain apps that do cool things, like substratum for theming (they do have a non-root plugin, but it's paid). Everything else runs securely in userspace. Everything else is _untrusted_, as it should be. **THIS IS WHERE THE PRIVACY TOOLS APPLY!** This UNTRUSTED SPACE is where the user wants to harden things. The fact that a space exists above this now is NOT a security compromise, now that no root access is granted without the permission of the user! Magisk takes steps to prevent click/tapjacking, overlays and etc. from affecting the dialog, and it even has a setting to _require biometric authentication_ to authorize root access to an app. These are all good steps and I believe that root is starting to head towards being just as secure as an unrooted, factory-locked device. Also, I think SuperSU is still sorta-modern and does some modern stuff, but I'm not experienced with it personally. I know it's nice to be stuck in the past - I totally get it. I've worked with Android phones as low as Android 2.2, and totally tricked out a Jelly Bean phone with CM12, back when that was a thing. However, that's simply not how things are anymore. We're all the way up to Android 11 now (although my phone is still A10). Security has gotten better, MUCH better, and **instead of violating security, Magisk has preserved it**. This, I think, is proof enough that root does NOT deserve to be ruled out. Root is not this shady, hacky, device-destroying nightmare that you all make it out to be. It is my belief that YES, XPrivacyLua SHOULD be listed. The fact that it requires root access does not make it invalid. In fact, if anything, that should make it _more_ valid than the other tools listed here, purely because of how powerful it is. How much you, as a knowledgeable user, can use it to its full potential, and lock away anything you don't want apps accessing. ### Why SafetyNet is not a concern (for those who care) Magisk can easily pass SafetyNet on modern (but not too modern) devices without modification simply by enabling MagiskHide. And so can recent versions of Riru - EdXposed, as long as Riru is hidden. There's not really much more to say about this. The proof is in the pudding. ![image](https://user-images.githubusercontent.com/4723091/101403508-345bb600-388a-11eb-88bc-95d3f85ccce8.png) An important point here is that response verification succeeds. The reason it's an important point is because I am not using mods like HiddenCore which grossly clobber the entire SafetyNet check and say "yeah here you passed and here is a shitty blank signature". Most apps will not accept that. I am getting a real response from Google that my device passed the test. That said, there IS a new cat in the cat-and-mouse game - hardware-backed key attestation. Even if you do manage to re-lock the bootloader without bricking your device (which is a feat in its own right), you will not be able to hide your self-signed status. Google has (unfortunately) recognized the fact that boot status is no longer as simple as "is the bootloader unlocked?", and hardware-backed systems have the ability to report that the bootloader is locked but the OS is still not stock - bad news for us modders. It will most likely be (ab)used by apps to reject any ROM that is not OEM-signed. You'd need extremely expensive equipment and a very skilled professional to extract the keys from the device to emulate this in software, so that's absolutely not feasible by any stretch of the imagination. You can only deal with it - or take the route of disabling hardware backed attestation altogether, which has been working quite well I hear. Yes, indeed, you can disable it by simply saying that your phone is one without hardware-backed capabilities. That works well - end of story. Well, kind of. It works right now while there are still phones in the wild which pass SafetyNet without hardware backed attestation, but... those are going to die out in a few years when they are no longer receiving updates. When your phone gets ahead of the one you are imitating, Google will know. Anyway, the fact that Magisk and EdXposed pass the basic certification should mean you're good to go. As long as you have a phone which is moddable - if you're interested, I have a OnePlus 7 Pro. Feel free to imitate my phone as well, I won't mind <3 (btw: the module for imitating your fingerprint like this is called MagiskHide Props Config) I've tested a couple more aggressive root checking apps, more aggressive than SafetyNet is, and take a look at the results: ![image](https://user-images.githubusercontent.com/4723091/101403366-feb6cd00-3889-11eb-86dd-d1371bdd6c29.png) ~~Wow, so confident! Are you sure about that? ;))))~~ I have not made any extra modifications to evade detection - besides hiding Magisk, EdXposed, and using **XPrivacyLua** to hide my applications list (pending https://github.com/M66B/XPrivacyLua/pull/13/ of course). Yes, XPrivacyLua is actually the hidden piece of the puzzle here, and the reason I'm so convinced that it's necessary. There are still more exotic PoCs that I have yet to test, but RootBeer is the go-to solution for many apps, so if you can evade that, you can evade a lot. ### Thanks for coming to my TED talk I hope this issue inspires you to reconsider your stance on root access and XPrivacyLua. :) I will try to be as active as possible addressing any concerns you may have. If you spot any errors in my writing, please point them out so I can fix them, thanks :D I proofread this many times and did my research but it's still possible I missed something. ## My connection with the software I'm a root user who uses XPrivacyLua to only allow apps to read the data they need to operate, not all of the permissions that they demand. I have put up for review a couple new hooks but they have not been accepted or reviewed yet. - [x] I will keep the issue up-to-date if something I have said changes or I remember a connection with the software.

👍 3 👀 2

oXyiGYJ commented

2021-01-14 07:20:12 +00:00

(Migrated from github.com)

I do not agree that any applications that requires Root or Jailbreaking should be posted. There are many security risks that come with this, as well as users breaking things they would not have broken without it.

All of these items that get posted on the site have to be in the best interest of every user, as well as privacy minded.

Rooting is great for those in the know, but the users that are getting into Privacy don't always know what some of us know, and rooting a device could be especially dangerous for those people.

I do not agree that any applications that requires Root or Jailbreaking should be posted. There are many security risks that come with this, as well as users breaking things they would not have broken without it. All of these items that get posted on the site have to be in the best interest of every user, as well as privacy minded. Rooting is great for those in the know, but the users that are getting into Privacy don't always know what some of us know, and rooting a device could be especially dangerous for those people.

LoganDark commented

2021-01-14 16:14:04 +00:00

(Migrated from github.com)

@wylel I understand why you may think this way, but as I spent so much time explaining in the post, there are hardly any security risks that come with root at this point.

The fact that trying to root your device is somewhat dangerous has been known for a while, and people still try anyway. I do not believe that the inclusion of XPrivacyLua will cause a significant increase in bricked devices / failed roots. That said, I do not believe that its exclusion will cause a decrease.

XPrivacyLua is a great way to harden your privacy. It is in the best interest of every user, and very privacy minded. I do not believe that there are any problems with the application itself at this point; there are just those who nitpick at the fact that it requires root.

@wylel I understand why you may think this way, but as I spent so much time explaining in the post, there are hardly any security risks that come with root at this point. The fact that trying to root your device is somewhat dangerous has been known for a while, and people still try anyway. I do not believe that the inclusion of XPrivacyLua will cause a significant increase in bricked devices / failed roots. That said, I do not believe that its exclusion will cause a decrease. XPrivacyLua is a great way to harden your privacy. It _is_ in the best interest of every user, and very privacy minded. I do not believe that there are any problems with the application itself at this point; there are just those who nitpick at the fact that it requires root.

This repo is archived. You cannot comment on issues.