You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 6, 2019. It is now read-only.
As far as i understand IPC/binder and identification/proc can be used to circumvent restrictions.
I currently restrict the categories and then add entries to my whitelist if they dont look suspicious to me.
For example "/proc/meminfo" looks like asking for the amount of memory. And if theres was something like "proc/blabla_IMEI" i would deny it.
But of course i dont know what all the different requests mean.
If we knew how someone can request the IMEI or Serial via indentification/proc or IPC/binder, then we could make a category to check that blocks these attempts, without any claim to completeness of course.
Maybe by creating a whitelist of the most common harmless requests.
The text was updated successfully, but these errors were encountered:
I got another idea.
In the log files i often see "original:0123456789" when a request by an app was restricted.
So that means Xprivacy can see the data that would have been returned, had there not been a restriction.
I think the most sensitive data that users want to protect are probably the IMEI, Serial, android id, etc. these numbers.
Maybe it would be an option to just scan all of the data that is returned to the app through /proc and /binder for that number, and then intercept the data and replace the number?
That way you wouldnt even have to know what is possible with /proc and /binder.
Of course it could also be that some app crashes because some number returned by chance is identical to your IMEI. Or it could be that the data is returned in some obscure way.
I agree that having a way to automatically allow certain items that don't have any real privacy issues would improve XPrivacy.
As another example, almost every app with internet access will make a query to check for IPv6. This results in an extra item that has to be approved the first time most apps makes an internet connection; there is currently no way to automatically whitelist these types of items in expert mode.
@MartinS84 Could you share more experience about using IPC/binder and identification/proc restriction?
e.g. I have some questions:
/proc/{pid}/cmdline , some apps ask for this. I need to whitelist the app's own pid and deny others, but as the pid often changes, I can only allow it for 15s every time. How to solve this ?
What does IPC IPackageManager:getPackageInfo mean? Why does every app need this? If I allow this , will the app have the ability to access packageinfo of all installed apps?
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
As far as i understand IPC/binder and identification/proc can be used to circumvent restrictions.
I currently restrict the categories and then add entries to my whitelist if they dont look suspicious to me.
For example "/proc/meminfo" looks like asking for the amount of memory. And if theres was something like "proc/blabla_IMEI" i would deny it.
But of course i dont know what all the different requests mean.
If we knew how someone can request the IMEI or Serial via indentification/proc or IPC/binder, then we could make a category to check that blocks these attempts, without any claim to completeness of course.
Maybe by creating a whitelist of the most common harmless requests.
The text was updated successfully, but these errors were encountered: