[CLOSED] XPrivacy - The ultimate, yet easy to use, privacy manager

Status
Not open for further replies.
Search This thread

M66B

Recognized Developer
Aug 1, 2010
26,011
56,003
XPrivacyLUA is excellent, but the lack of on demand features in XPrivacyLUA leaves open massive privacy holes that makes still running XPrivacy essential. With XPrivacyLUA, one would have to log DNS queries by app, a task in itself, and also while potentially permitting the application to communicate out to undesirable hosts first before they can be blocked with XPrivacyLUA. As an example, many apps use and communicate with graph.facebook.com, crashlytics.com, along with many additional not necessarily well known services that will track users. Add on the fact that without the capability of randomization of identifying data by default per app at first access/run after install like XPrivacy can do, with someone running only XPrivacyLUA, these services can tie all the apps that someone is using together for tracking, an absolutely massive invasion of your privacy.

For on-demand View access, there are many apps that force opening your web browser with a custom URL to track you. It’s essential to be able to view the URL that an app is opening before it’s allowed to open a potentially unwanted URL.

Access to the clipboard without one’s knowledge is obviously a huge privacy issue. I have seen 2 different apps try to read my clipboard without any interaction, with one of those apps being an app that I do need to copy/paste information into on occasion.

Also, I doubt very many users realize that most apps generate a unique tracking ID the first time an app is run, and it is saved permanently. From testing, this ID is frequently either a hash based on MAC address, Android ID, device name, etc. So, it’s essential that any fake data be randomized per app at boot time or access (optimally) by default before the app gets a change to run, so that you’ve created a unique ID just for that app that’s different than any other app. Feeding an app blank data can lead to the app generating and storing the same unique ID to track you every time since the blank data will be the same every time and generate the same hash.

The XPrivacyLUA model is that you only have the option to either completely trust or not trust specific privacy related permissions of an app. This in itself leaves open massive opportunities for privacy problems. The XPrivacy model lets you deal with potentially rogue and buggy apps with on demand access. A perfect example would be an issue similar to Apple’s recent Facetime eavesdropping bug where someone can call another user and eavesdrop without their knowledge. Let’s say this was an audio/video chat app for Android. With XPrivacyLUA one would have granted complete and permanent access to the microphone and camera for the app. With XPrivacy, one can on-demand give the app access to my camera/microphone as needed, so this type of exploit could be averted. Furthermore, who is to say that you should trust and app, developer, company, and all its employees to not access your device at any time? The same goes for storage access. Think about an app that you need to use to upload information or photos from storage on your device. What’s to say that there’s not an exploit in the app or there is not a rogue developer on the dev team that might lead to all the data on your storage device being uploaded without your knowledge?

Crashes from XPrivacy have been extremely, extremely rare, and have always been correctable with reviewing the XPrivacy log along with a logcat.

So, it’s absolutely essential that users heed these warnings and run both XPrivacy and XPrivacyLUA at the moment for optimal privacy and hopefully this serves as a warning to those that don’t.
I don't agree that XPrivacyLua leaves massive privacy holes.

First of all there is a pretty good reason why XPrivacyLua doesn't intercept internet traffic: it doesn't work for native code, also not in XPrivacy classic, so following your reasoning XPrivacy leaves "massive privacy holes" without you even knowing it. This is also why the XPrivacyLua FAQ says you should use a firewall app to control internet access.

As said before, XPrivacyLua can restrict the clipboard and can randomize values.

XPrivacyLua is designed to restrict everything by default and to allow only what needs to be allowed, so saying that XPrivacyLua is designed to completely trust or not trust is incorrect.
 

mobileanimal

Senior Member
Jul 23, 2013
56
14
I don't agree that XPrivacyLua leaves massive privacy holes.

First of all there is a pretty good reason why XPrivacyLua doesn't intercept internet traffic: it doesn't work for native code, also not in XPrivacy classic, so following your reasoning XPrivacy leaves "massive privacy holes" without you even knowing it. This is also why the XPrivacyLua FAQ says you should use a firewall app to control internet access.

As said before, XPrivacyLua can restrict the clipboard and can randomize values.

XPrivacyLua is designed to restrict everything by default and to allow only what needs to be allowed, so saying that XPrivacyLua is designed to completely trust or not trust is incorrect.

So my argument/opinion has been that there is more to privacy than just allowing all / denying all, and in this example Internet access by app. There are many reasons to selectively allow/block access to specific hosts per app like XPrivacy can do. For example, I want the Yelp! app to access to be able to access *.yelp.com, but not the tracking services with DNS entries *.branch.io or *.crashlytics.com or *.bugsnag.com). The first time I execute Yelp!, I have no idea what it's going to access, and it may take time for it to collect data and reach out to some of the tracking services it uses. So, the on demand and wildcard DNS restriction features of XPrivacy are absolutely phenomenal for controlling this. and much underappreciated

Again with clipboard access, though it's rare to see an app act rogue, there's not guarantee an app that you would like to use the clipboard in on occasion won't spy on your clipboard contents or contain an exploit that allows someone to. So all or none access doesn't always work here. The same thing obviously applies for camera and microphone access as I mentioned.

I love a great privacy discussion so anyone please feel free to chime in with any comments, dissent, etc.

Also, I edited the original post slightly to be slightly more specific and clear.
 
Last edited:

M66B

Recognized Developer
Aug 1, 2010
26,011
56,003
So my argument/opinion has been that there is more to privacy than just allowing all / denying all, and in this example Internet access by app. There are many reasons to selectively allow/block access to specific hosts per app like XPrivacy can do. For example, I want the Yelp! app to access to be able to access *.yelp.com, but not the tracking services with DNS entries *.branch.io or *.crashlytics.com or *.bugsnag.com). The first time I execute Yelp!, I have no idea what it's going to access, and it may take time for it to collect data and reach out to some of the tracking services it uses. So, the on demand and wildcard DNS restriction features of XPrivacy are absolutely phenomenal for controlling this.

Again with clipboard access, though it's rare to see an app act rogue, there's not guarantee an app that you would like to use the clipboard in on occasion won't spy on your clipboard contents. So all or none access doesn't always work here.

I love a great privacy discussion so anyone please feel free to chime in with any comments, dissent, etc.

Also, I edited the original post slightly to be slightly more specific and clear.
Still, using a firewall app is safer than relying on XPrivacy. NetGuard has on demand access notifications ...
 

mobileanimal

Senior Member
Jul 23, 2013
56
14
Still, using a firewall app is safer than relying on XPrivacy. NetGuard has on demand access notifications ...

Yes, however there are a couple big issue with Netguard at the moment:
1. Netguard is dependent on a VPN connection being nailed up to restrict access and leaks. There is also not root version allowing you to use other VPN services. Privacy conscious individuals use VPN services to access their home and work networks so that they aren't dependent on exploit ridden cloud and cloud relay services to bypass firewalls and NAT for access to service such as cameras, file shares, etc. which give the cloud service full access to your devices.
2. There is no wildcard support in Netguard
 

M66B

Recognized Developer
Aug 1, 2010
26,011
56,003
Yes, however there are a couple big issue with Netguard at the moment:
1. Netguard is dependent on a VPN connection being nailed up to restrict access and leaks. There is also not root version allowing you to use other VPN services. Privacy conscious individuals use VPN services to access their home and work networks so that they aren't dependent on exploit ridden cloud and cloud relay services to bypass firewalls and NAT for access to service such as cameras, file shares, etc. which give the cloud service full access to your devices.
2. There is no wildcard support in Netguard
NetGuard uses the Android VPN service, but not a remote VPN server, see also this FAQ:

https://github.com/M66B/NetGuard/blob/master/FAQ.md#FAQ6

Since NetGuard, still unlike any other firewall, works with domain names instead of IP address, you'll hardly need wildcards. See this FAQ about why wildcards are not supported:

https://github.com/M66B/NetGuard/blob/master/FAQ.md#FAQ41
 

mobileanimal

Senior Member
Jul 23, 2013
56
14
NetGuard uses the Android VPN service, but not a remote VPN server, see also this FAQ:

https://github.com/M66B/NetGuard/blob/master/FAQ.md#FAQ6

Since NetGuard, still unlike any other firewall, works with domain names instead of IP address, you'll hardly need wildcards. See this FAQ about why wildcards are not supported:

https://github.com/M66B/NetGuard/blob/master/FAQ.md#FAQ41

In regard to VPN, from the perspective of Android, a VPN connection is nailed up so this prevents another VPN connection - that's the biggest issue at hand. For someone to access their home or work VPN, they would need to disable Netguard.

Wildcards have always worked well with XPrivacy and XPosed hooks.
 

M66B

Recognized Developer
Aug 1, 2010
26,011
56,003
In regard to VPN, from the perspective of Android, a VPN connection is nailed up so this prevents another VPN connection - that's the biggest issue at hand. For someone to access their home or work VPN, they would need to disable Netguard.

Wildcards have always worked well with XPrivacy and XPosed hooks.
Maybe AFWall+ can be used, which has on access notifications too as far as I know.

XPrivacy wildcards worked for Java code internet accesses, but not for native code internet accesses.

Again: there are custom hook definitions in the repository that do what XPrivacy did and a big advantage of XPrivacyLua exactly this: you can customize/add things.

Anyway, XPrivacy will never be updated again and I am planning to end support after the release of Android Q.
 

mobileanimal

Senior Member
Jul 23, 2013
56
14
Maybe AFWall+ can be used, which has on access notifications too as far as I know.

XPrivacy wildcards worked for Java code internet accesses, but not for native code internet accesses.

Again: there are custom hook definitions in the repository that do what XPrivacy did and a big advantage of XPrivacyLua exactly this: you can customize/add things.

Anyway, XPrivacy will never be updated again and I am planning to end support after the release of Android Q.


Sadly AFWall+ won't do on-demand or anything DNS related. I'm not a big Android dev - I just try to understand what I can, but I believe you mentioned it would never be possible to ever have any capability for on-demand restrictions in XPrivacyLUA? So referring to the issues above, as an example, having the capability for a custom hook to prompt a user whether or not to allow access to a certain folder or file in storage, and options to whitelist / blacklist with wildcard with storage of those permissions in a database, would never be possible? I've seen the custom hooks for DNS, storage, etc, but permanently adding exceptions vs just allowing access on demand via prompts to a file in storage, your clipboard, camera, microphone, etc. leaves room for a lot of difficulties and privacy issues.

XPrivacy really raised a lot of users awareness to privacy exploits. It's really sad how little the Android OS has built in for security and privacy controls, though it's very much capable. It's more designed as a spyware friendly operating system.

I understand it's been game over for XPrivacy for quite a while, but I feel it's a least important to continue to raise awareness to some of the specific privacy issues that it dealt with so nicely.
 
  • Like
Reactions: Omen of Peace

M66B

Recognized Developer
Aug 1, 2010
26,011
56,003
Sadly AFWall+ won't do on-demand or anything DNS related. I'm not a big Android dev - I just try to understand what I can, but I believe you mentioned it would never be possible to ever have any capability for on-demand restrictions in XPrivacyLUA? So referring to the issues above, as an example, having the capability for a custom hook to prompt a user whether or not to allow access to a certain folder or file in storage, and options to whitelist / blacklist with wildcard with storage of those permissions in a database, would never be possible? I've seen the custom hooks for DNS, storage, etc, but permanently adding exceptions vs just allowing access on demand via prompts to a file in storage, your clipboard, camera, microphone, etc. leaves room for a lot of difficulties and privacy issues.

XPrivacy really raised a lot of users awareness to privacy exploits. It's really sad how little the Android OS has built in for security and privacy controls, though it's very much capable. It's more designed as a spyware friendly operating system.

I understand it's been game over for XPrivacy for quite a while, but I feel it's a least important to continue to raise awareness to some of the specific privacy issues that it dealt with so nicely.
Since XPrivacyLua only hooks into apps when restrictions are enabled, on demand restricting similar to in XPrivacy classic is not possible.

Note that this approach has two big advantages: more stability and less performance impact.
 

mobileanimal

Senior Member
Jul 23, 2013
56
14
That's understandable regarding stability and performance for the general masses. The limitation is not really a limitation in using Lua, just the design of the app?
I just want to make sure my point gets across to the user base that understands privacy and security about the benefits that were achieved by XPrivacy up thorough Android 5, where some of the potential exposure and risk is with Android, and how some limited knowledgeable users used them to protect themselves and monitor what their apps are doing with ease.
I do really appreciate your work XPrivacy and XPrivacyLUA!
 

M66B

Recognized Developer
Aug 1, 2010
26,011
56,003
That's understandable regarding stability and performance for the general masses. The limitation is not really a limitation in using Lua, just the design of the app?
I just want to make sure my point gets across to the user base that understands privacy and security about the benefits that were achieved by XPrivacy up thorough Android 5, where some of the potential exposure and risk is with Android, and how some limited knowledgeable users used them to protect themselves and monitor what their apps are doing with ease.
I do really appreciate your work XPrivacy and XPrivacyLUA!
The "limitation" is a design choice. If something not worked in XPrivacy, it could bring down the entire system and you couldn't do anything about it. If something is not working in XPrivacyLua, it can only bring down an app and you have the possibility to disable the faulty restriction for the app. In other words: all restrictions in XPrivacy were always executed, but in XPrivacyLua only enabled restrictions are executed, which is also causing the performance difference. Another thing is that XPrivacyLua will report any problems in the (Lua) hook definitions, so if you don't get error notifications, you can be pretty sure everything works (and is a great help while developing hook definitions).

Related is that in XPrivacy restriction were selected by uid and in XPrivacyLua by app, which makes a big difference when apps are bundled under the same uid, which is typically the case with system apps. In XPrivacy you could only restrict all system apps, in XPrivacyLua you can restrict only one system app.

Summarized, it is just a different approach with other advantages and disadvantages.
 
Last edited:

M66B

Recognized Developer
Aug 1, 2010
26,011
56,003
With the release of Android Q, planned in Q3 2019, XPrivacy will be retired, which means support will be ended and this thread will be closed.

You are advised to switch to XPrivacyLua, which is available for Android 6 Marshmallow and later.
 

syncopath

Senior Member
Oct 31, 2005
140
25
Amsterdam
But my Galaxy Note original doesn't "support" Android "Q", or 5 or whatever. It won't go higher than 4.1.2, which actually works just fine for me.

So am I now to be left with my privacy unprotected?

I don't need "support", I just want XPrivacy to keep working on my device. Will it?
 
Last edited:

M66B

Recognized Developer
Aug 1, 2010
26,011
56,003
But my Galaxy Note original doesn't support Android "Q", or 5 or whatever. It won't go higher than 4.1.2, which actually works just fine for me.

So am I now to be left with my privacy unprotected?

I don't need "support", I just want XPrivacy to keep working on my device. Will it?
You can keep using XPrivacy, but it won't be supported anymore.
 
  • Like
Reactions: Entehaye Khat1

JohnC

Senior Member
May 5, 2007
697
182
Amazon Fire TV
Google Pixel 4a
I am still actively using XPrivacy Classic on my Android 5.0.1. I did look at the new version, but it does not have a lot of the on demand and granular control that xprivacy does.

I totally understand that you would like to stop supporting Xprivacy.

But what would the harm be in keeping this forum open so that we can support each other and have just one place to search for help?

I mean, this thread has a TON of pages and a huge amount of resources.

For example, just a few months ago I started seeing a problem and another user offered some very helpful information:

https://forum.xda-developers.com/xp...ate-android-privacy-app-t2320783/post78893240

And if this forum was closed, I would not have been able to post my problem or have it at least reach the right eyes of someone who could possibly help.

So, please keep this thread/forum open and we will understand that you will be no longer monitoring it.
 

M66B

Recognized Developer
Aug 1, 2010
26,011
56,003
I am still actively using XPrivacy Classic on my Android 5.0.1. I did look at the new version, but it does not have a lot of the on demand and granular control that xprivacy does.

I totally understand that you would like to stop supporting Xprivacy.

But what would the harm be in keeping this forum open so that we can support each other and have just one place to search for help?

I mean, this thread has a TON of pages and a huge amount of resources.

For example, just a few months ago I started seeing a problem and another user offered some very helpful information:

https://forum.xda-developers.com/xp...ate-android-privacy-app-t2320783/post78893240

And if this forum was closed, I would not have been able to post my problem or have it at least reach the right eyes of someone who could possibly help.

So, please keep this thread/forum open and we will understand that you will be no longer monitoring it.
As developer and thread starter I am responsible for this thread, so I am not going to leave this thread open without monitoring it.

I am planning to close this thread and stop supporting XPrivacy completely with the release of Android Q beta 4 next month.
 

JohnC

Senior Member
May 5, 2007
697
182
Amazon Fire TV
Google Pixel 4a
As developer and thread starter I am responsible for this thread, so I am not going to leave this thread open without monitoring it.

I am planning to close this thread and stop supporting XPrivacy completely with the release of Android Q beta 4 next month.

Understand - you need to keep monitoring this thread for things like abuse I'm guessing.

But why can't you keep it open with the understanding that you will not reply to any direct support requests?

There appears to be many people still using this app, and like I mentioned, users could support each other if this thread is left open - I don't understand why you wouldn't want to let user's support each other?
 

M66B

Recognized Developer
Aug 1, 2010
26,011
56,003
Understand - you need to keep monitoring this thread for things like abuse I'm guessing.

But why can't you keep it open with the understanding that you will not reply to any direct support requests?

There appears to be many people still using this app, and like I mentioned, users could support each other if this thread is left open - I don't understand why you wouldn't want to let user's support each other?
I don't want to monitor this thread for the few people that are still using XPrivacy.
 
Status
Not open for further replies.

Top Liked Posts

  • There are no posts matching your filters.
  • 1150
    ic_launcher.png
    XPrivacy

    After weeks of research, development and testing I proudly present the ultimate, yet easy to use, privacy manager: XPrivacy.

    XPrivacy can prevent applications from leaking privacy sensitive data. XPrivacy can restrict the categories of data an application can access. This is done by feeding an application with no or fake data. There are several data categories which can be restricted, for example contacts or location. For example, if you restrict access to contacts for an application, this will result in sending an empty contact list to the application. Similarly, restricting an application's access to your location will result in a set location being sent to the application.

    You can use the successor XPrivacyLua on Android 6.0 Marshmallow and later.

    Features

    • Simple to use
    • No need to patch anything (no source, no smali or anything else)
    • For any (stock) variant of Android version 4.0.3 - 6.0.1 (ICS, JellyBean, Lollipop, Marshmallow)
    • Newly installed applications are restricted by default
    • Displays data actually used by an application
    • Option to restrict on demand
    • Free and open source
    • Free from advertisements

    Read more on GitHub


    The download link is in the installation instructions

    You can also use the XPrivacy Installer as an aid to install XPrivacy.

    This forum is for questions only. See here for bug reports and feature requests.

    Please post messages related to privacy only.
    XPrivacy is not intended to make other application do things they are not supposed to do.


    There is only support for the latest official XPrivacy version.

    XPrivacy was a lot of work, so please support this project

    If you want to donate, see here for all options.

    Use at your own risk !




    The latest version from a while ago still works properly up to Android 6 Marshmallow, if Xposed works properly on your device
    (you can ignore any internal error report of XPrivacy, since these are known to be harmless)

    XDA:DevDB Information
    XPrivacy, Xposed for all devices (see above for details)

    Contributors
    M66B
    Source Code: https://github.com/M66B/XPrivacy

    Xposed Package Name: biz.bokhorst.xprivacy

    Version Information
    Status: No Longer Updated
    Current Stable Version: 3.6.19
    Stable Release Date: 2015-07-01

    Created 2014-08-03
    Last Updated 2018-02-08
    77
    "More than 250 Android Games Use Your Mic to Track What You’re Watching"
    https://www.xda-developers.com/android-apps-tracking-mic-always-listening/

    The above made me decide that we still need a decent privacy solution.

    At this moment I have a fully functional proof of concept where Xposed hooks can be defined in JSON (text) files and can be applied to any app at runtime. The hook code can be written in LUA script. This means that hooks can be added without updating the Xposed module (for now called XLua).

    To test XLua I have defined two hooks to fake the device location and applied them to the GPS status app. The result is that GPS status reports a fake location.

    I will start with built-in privacy related hooks, but in the near future there might be a repository where you can download hook definitions from.

    There is a lot more to tell about this, but I want to keep it brief for now. You are free to ask questions, but don't ask when it will be ready.

    I wish you a happy and private new year.
    67
    Due to too many bad experiences I will not be active on XDA anymore, which means that this will be my very last XDA comment. However, this doesn't mean I don't follow the XDA XPrivacy and NetGuard threads anymore and that development will be stopped. XPrivacy will be updated when critical bugs are found only (which didn't happen in more than a year). NetGuard will be maintained as well and new features might be added occasionally.

    If you check my post count, you can see that I have been very supportive and that more than likely all mayor questions have been answered already. So, if you have a question, use the XDA search and you'll likely find an answer. If that fails, then other XDA members might be able to answer your question.

    So, my last word: goodbye.
    65
    After almost nine months since the initial release and after 85 experimental, test and beta releases since the last stable release, I have just made available stable version 2.0.

    The main changes since the last stable version 1.11 are:

    • Replaced XML settings files by a privacy service and privacy a database
      - Increased speed, stability and security
      - Allows for new features formerly not possible, like:
    • Added on demand restricting
      - XPrivacy will ask to allow/deny on actual function usage
    • Added white and black listing for files, IP addresses, domain names, commands, libraries and URLs
      - White and black listing on demand are available to anyone
      - White/black list management from the user interface requires a Pro license
      - Clearing restrictions will clear white/black lists too
    • Added parameters to usage data (option) (only Pro license)
    • Added a service to migrate settings, upgrade and randomize
    • Added sorting and extended filtering
    • Added multiple select and batch operations to set, reset, import and export restrictions
    • Added a series of new restrictions and improved existing restrictions
    • Added template for functions
    • Added user defined dangerous functions
    • Added in application documentation for all functions
    • Added switch to disable restrictions for each application
      - Allows for disabling restrictions, without taking away the ability to edit restrictions
    • Support for multiple users (if your device supports this)
    • XPrivacy became one of the Open Source Rookies of 2013
    • The number of crowd sourced restrictions is more than 5 million now
    • Donations are accepted in Bitcoins now too
    If you want to know all changes since the last stable version, you'll need to read the changelog, but be prepared: it is a long list.

    Read here about how to upgrade:
    https://github.com/M66B/XPrivacy#upgrading

    After handling over 1500 bug reports and feature requests and more than 5000 commits, I guess XPrivacy is pretty feature complete and bug free now. As I have said before, I don't want to continue working almost full time on this project, which doesn't mean reported bugs will not be addressed and also not that XPrivacy will not be updated for the next Android releases. It just means that no new big features will be added anymore. Since the core feature of XPrivacy is to protect your privacy, new restrictions will be added when requested.

    XPrivacy was really a lot of work, so thanks or donations are appreciated.

    If you think something should be written about this greatly enhanced version of XPrivacy on the XDA portal, you might want to use Tip us?.
    56
    IF an Xposed version for Android 7 Nougat will be released, I MIGHT consider developing a paid only, slimmed down version of XPrivacy to protect your most privacy sensitive data, like contacts, calendars and location. We can discuss about what should be included. However, there would be no support to prevent tracking, so no restriction of device IDs, IP addresses, etc, since this is a lost battle anyway.

    Would there be interest in this?