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

[b4minee]

Bro Is this good FOR pie SDK 28
Please advise

Thank you

Sent from my Google Pixel 2 using XDA Labs

 

[M66B]

Bro Is this good FOR pie SDK 28
Please advise

There is no Xposed for Android 9 Pie, so no.

I will updated XPrivacyLua for Android 9 Pie as soon as there is an Xposed for Android 9 Pie.
I will never update the old XPrivacy anymore.

 

[Eye_of_Osiris]

This app offers PROVEN protection to me since 2015.
Marcel YOU ARE A TRUE HERO ★★★★★

 

[frugihoyi]

While testing Xprivacy I denied the entire Media category for the Duolingo app, but the microphone still works whenever Duolingo asks me to speak a phrase. What's up with that?
Android 5.1.1

 

[M66B]

While testing Xprivacy I denied the entire Media category for the Duolingo app, but the microphone still works whenever Duolingo asks me to speak a phrase. What's up with that?

First of all you should probably use XPrivacyLua instead of XPrivacy.

To answer your question: the app likely uses native code which cannot be hooked by Xposed, see also here:
https://github.com/M66B/XPrivacyLua/#notes

 

[JohnC]

weird issue

I have been using XPrivacy for years - GREAT app. I am currently using it on a Samsung S4 running 5.0.1.

As everyone knows, whenever you install a new app or update an existing one, XPrivacy adds a notification about the new/updated app in your drop-down notification panel (which allows you to jump right into that apps settings in Xprivacy).

But something weird is happening...

XPrivacy seems to randomly add "update" notifications for apps that I have NOT updated on my phone. My first thought was that maybe the playstore is automatically updating my apps, but that isn't the case because I disabled auto-update in the play store. And besides, when I go into playstore and select "My Apps and Games", it will list all the apps that have updates, and at the very bottom it will list the apps that I "recently" updated. But the app that Xprivacy says was recently updated is NOT listed in this "Recently updated" list.

So, in summary, I am seeing "Xprivacy app-updated" notifications for random apps that are already installed on my device but yet were NOT updated by me or the play store. So, I am real confused why xprivacy is generating these update notifications when the apps were NOT updated.

Any ideas anyone?

 

[M66B]

I have been using XPrivacy for years - GREAT app. I am currently using it on a Samsung S4 running 5.0.1.

As everyone knows, whenever you install a new app or update an existing one, XPrivacy adds a notification about the new/updated app in your drop-down notification panel (which allows you to jump right into that apps settings in Xprivacy).

But something weird is happening...

XPrivacy seems to randomly add "update" notifications for apps that I have NOT updated on my phone. My first thought was that maybe the playstore is automatically updating my apps, but that isn't the case because I disabled auto-update in the play store. And besides, when I go into playstore and select "My Apps and Games", it will list all the apps that have updates, and at the very bottom it will list the apps that I "recently" updated. But the app that Xprivacy says was recently updated is NOT listed in this "Recently updated" list.

So, in summary, I am seeing "Xprivacy app-updated" notifications for random apps that are already installed on my device but yet were NOT updated by me or the play store. So, I am real confused why xprivacy is generating these update notifications when the apps were NOT updated.

Any ideas anyone?

I have no idea and nobody has reported this before either.

 

[JohnC]

What are all the possible "events" that would trigger xprivacy to think that an app was "updated"?

 

[M66B]

What are all the possible "events" that would trigger xprivacy to think that an app was "updated"?

See here:
https://github.com/M66B/XPrivacy/blob/master/src/biz/bokhorst/xprivacy/PackageChange.java#L142

https://developer.android.com/reference/android/content/Intent.html#ACTION_PACKAGE_REPLACED

 

[JohnC]

See here:
https://github.com/M66B/XPrivacy/blob/master/src/biz/bokhorst/xprivacy/PackageChange.java#L142

https://developer.android.com/reference/android/content/Intent.html#ACTION_PACKAGE_REPLACED

Very strange issue.

 

[Fif_]

Any ideas anyone?

https://developer.android.com/reference/android/content/Intent.html#ACTION_PACKAGE_REPLACED

I've seen that for the last 5-6 months, google play "shadow updates" apks in the background even if you have updates turned off. By shadow updates I mean that the apk's checksums change, but the version stay the same. The apk contents also stays the same.
If you don't believe me, checksum /data/app/*.apk and see for yourself.
There has been times where these shadow updates would show up in the Play Store "Recently Updated" section.
It could well be that the PACKAGE_REPLACED intent would be fired in this instance.
I'm still seeing shadow updates almost daily and will be recording whether or not PACKAGE_REPLACED gets fired when that happens.

 

[M66B]

Are there still people using the classic version of XPrivacy? I am planning to end support and close this thread after Android Q has been released, unless there are a lot of objections. That would mean that there has been five years of support. Not many companies support their stuff this long ...

 

[elsquare]

Are there still people using the classic version of XPrivacy? I am planning to end support and close this thread after Android Q has been released, unless there are a lot of objections. That would mean that there has been five years of support. Not many companies support their stuff this long ...

Me + Familie = 4
Overdue to upgrade our rock solid S4s to Oreo or Pie and XPL, I know...

 

[mnjm9b]

Are there still people using the classic version of XPrivacy? I am planning to end support and close this thread after Android Q has been released, unless there are a lot of objections. That would mean that there has been five years of support. Not many companies support their stuff this long ...

I have a few devices that I can't update due to lack of manufacturer support and an un-unlockable bootloader. so they are stuck on jellybean/kitkat. I keep them alive specifically because they have xprivacy/afwall on them. otherwise I would smash them with a hammer as they have no business connecting to my network with the outdated OS's security risks.

However, XP works flawlessly on these devices so as long as you keep it available to download, I would support your decision to lock thread and end support.
(although, I have backed up several apk versions already as well as source, so I don't care about the downloads too much anyway.)

 

[M66B]

I have a few devices that I can't update due to lack of manufacturer support and an un-unlockable bootloader. so they are stuck on jellybean/kitkat. I keep them alive specifically because they have xprivacy/afwall on them. otherwise I would smash them with a hammer as they have no business connecting to my network with the outdated OS's security risks.

However, XP works flawlessly on these devices so as long as you keep it available to download, I would support your decision to lock thread and end support.
(although, I have backed up several apk versions already as well as source, so I don't care about the downloads too much anyway.)

XPrivacy will keep being published in the Xposed repository and the source code will keep being published on GitHub.

 

[mirizlivpor]

I've hesitated to upgrade my phone because of the risk of not being able to use XPrivacy and didn't even know that a newer version was out there. Made sure that my new phone could be rooted and XPosed can be installed on it just because I can't imagine using my phone without this module. I'm sure you've been praised thousands of times but I'll add to that anyway - simply the number one module ever.

I'd like to add that I've been getting messages about updated apps as well, although the auto updates are turned off.

 

[mobileanimal]

I'm still using it as XPrivacy as well. I've updated and compiled it for Oreo and have it working alongside XPrivacyLUA for the on demand privacy / security features that XPrivacyLUA can't do yet (DNS, clipboard access, View), GetAccounts with whitelisting, and randomization of fake data on boot.

 

[M66B]

I'm still using it as XPrivacy as well. I've updated and compiled it for Oreo and have it working alongside XPrivacyLUA for the on demand privacy / security features that XPrivacyLUA can't do yet (DNS, clipboard access, View), GetAccounts with whitelisting, and randomization of fake data on boot.

Be aware that some XPrivacy restrictions are known not to work on recent Android versions.

XPrivacyLua:

You can use custom hooks from the repository to block DNS. The clipboard can be restricted. Randomization, also on boot, is supported for a few values now. Edit: accounts are automatically whitelisted.

 

[arianat01]

I'm still using it as XPrivacy as well. I've updated and compiled it for Oreo and have it working alongside XPrivacyLUA for the on demand privacy / security features that XPrivacyLUA can't do yet (DNS, clipboard access, View), GetAccounts with whitelisting, and randomization of fake data on boot.

You can do all of these by XprivacyLua, except on demand privacy. By XprivacyLua you can restrict anything without any crash.
Look at the XprivacyLua Pro hook definition.

 

[mobileanimal]

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 an app, developer, company, and all its employees to not access your device at any time for unscrupulous purposes? 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.