Flush privacy service cache #1678
Comments
|
Yes!! These are exactly the scenarios I had in mind. Especially hiding one's location from Google except when Maps is active, so that they can't build a file on your whereabouts 24/7 but you can still use Maps, Google's best application. I think something like this was mentioned earlier, and it would not be easy to implement because of security, but this would definitely be my number 1 feature request for Xprivacy!! I would donate extra for this! |
|
-1. Sorry. But giving 3rd party apps access to the restrictions db via an intent is a major security concern for me. |
|
The problem with this request is security, see also #1630 |
|
To be clear the feature request now includes protecting the intent via a special XPrivacy specific restriction. So I think an0n981's security concern doesn't apply any more. |
psyoptix
changed the title
|
+2 |
|
I'm okay with this, if we have a clear way to know wich app will or will not be able to use this feature as doing it wrongly may kill the whole purpose of XPrivacy. |
|
Perfect examples of the kind of things i envisioned with tasker integration, with the maps app,all the way too screen off = security fort knox clamp down.......restriction automation based on cofigurable events Take my money.....ahem.....i mean, heres my +1 +2 if plugin is possible but assuming its not |
|
@banderos: plugin would be awesome :) |
|
After some thinking, I am going to veto this. I simply don't want external control over XPrivacy restrictions. The potential security disadvantages do not out-weight the advantages, which are probably only for just a few people. I also do not want to support this feature, because it will inevitable result in all kinds of questions. I recognize that more advanced users have a use for this. Those users can manipulate the privacy database and for that purpose I will provide a way to clear the XPrivacy service cache. This goes with the note that the database structure might change in the future. I will try to keep the database backward compatibly, but this will not be the highest priority. At this moment I don't see a reason to change the database, but that could change in the future. |
M66B
changed the title
|
IMHO clearing the cache is really all that is needed anyways, everything else can already be done via shell scripts that can be automated via Tasker |
|
That is my idea too and since there is now decent documentation, this is within reach of more advanced users without putting a lot of (research) time into it. |
|
Yup, that would work for me too. |
|
Aww let my +1 be recorded for posterity! I am not an advanced user and I have no idea how SQL and databases work, but I would really, really love to have functionality like this. If it can be done outside of Xprivacy with this flushing thing, that would be great; so do you expect someone to make an application or plugin that can do it? If anyone would be willing to write an app or think of an easy way for non-technical people to implement this, I would be willing to donate (a small amount)! And I'm sure there will be many others who would also donate! |
|
@Cerberus-tm Given that there are infinite possibilities that can be achieved using SQL statements, I don't think there is a way to create an app where you can just click your way to the result you want. The best thing to do is learn a little SQL. A documentation of the XPrivacy databases has already been created with a few examples to get you started. https://github.com/M66B/XPrivacy/blob/master/DATABASE.md |
|
@an0n981 Thanks for the tip! I looked at the examples you put in the documentation, and they look interesting. I am not a computer programmer in any way, and I did see various terms that were over my head. I once tried to get Tasker to do something related to SQL; I basically copy-pasted stuff off the Internet hoping that I could modify it and get it to work, but I failed. Maybe I could some day try looking into this when I find the courage to risk messing up my Xprivacy hehe, maybe I could figure it out. As to those infinite possibilities, the scenarios in the OP would really be 90 % of what I think most people would use Tasker for if this were possible. Perhaps someone with the same needs will make an application that can do only those things. Or basically a Tasker plugin that would let you allow and deny any permission for any installed app by creating the appropriate SQL command, that would take care of everything, if I understand how this works correctly. As in, you tap the plugin in Tasker as an action; then, inside the plugin, you have an app picker and a permission picker, and deny/allow. Then the plugin converts your picks into the appropriate SQL commands. The pickers could even be very basic textual drop-down lists. Or maybe that is totally not how it could ever work, just thinking out loud. Either way, thanks for putting things examples in the documentation, good work! |
|
If the cache intent is implemented, the documentation could be expanded to include things like those above, they just don't make a lot sense without it since you currently have to reboot after every change. Or (with @M66B blessing) we could even start a new XDA thread for XPrivacy SQL related question. |
|
I am counting six +1's (only @an0n981 is currenly allowed to vote +2 for his contributions to the project). Please note that there is still no good solution for security (except for using an Android permission for the intent). There is no way to identify the sender of an intent, see here for more information about this: http://www.unwesen.de/2011/04/10/android-intent-sender-verification/ |
|
It seems the only way out is to protect the intent with a permission. Together with some very brief documentation about the syntax of the intent I think this could open the door for a third party to create a (probably quite simple) plugin for Tasker (and compatible apps) with that permission in it's manifest. (A bit like secure settings has additional permissions over standard Tasker.) On the one hand this would provide protection to the Intent in XPrivacy, but on the other hand it gets around the issue that the Tasker devs have ruled out adding an XPrivacy specific permission to their own manifest. |
|
I am not sure, but maybe a plugin can request additional permissions. |
|
I just checked and the plugin is a completely separate app from the automation app. In particular the plugin can request it's own permissions. More info at: http://tasker.dinglisch.net/plugins-intro.html The small helper app idea would be cool too. Maybe more so really as it is actually a more general solution. In particular Tasker can launch any app (or even a particular activity with-in an app) as an actions so we'd end up with the desired capability. |
|
One thing that just came to mind: maybe the helper app could also be set up in such a way that it can only be run by root. Of course it's not a complete fix but it should help. After all, given root an attacker can anyway change the DB (not to mention simply uninstall XPrivacy) which would be a much bigger attack then reloading cache. On the other hand Tasker can perform root operations so it would still allow the desired automation functionality. |
|
Regardless of whether this gets implemented or not, nice discussion here Marcel, if your referencing my +2, sorry man, it was just to enphasize how much i would have liked the stated idea, not an assumption that i have two votes....but if anyone deserves +2 voting, anon sure does, really nice job on the database.md write up......it like a proffesional did it :) http://www.unwesen.de/2011/04/10/android-intent-sender-verification/ |
|
I have added flushing to the privacy service, added a permission protected intent for it and a button in the main settings menu to fire the intent. This makes it possible to manually flush the cache. I will leave external interfacing by a tasker plugin or a helper application to the community. |
|
Is the wakelock enhacement still included in this version? EDIT: disregard, the answer is yes |
|
The good news is, it works as intended, which means the bad news is that I have not yet found a way around the permission 😉 |
|
Yes, the test version is based on the latest commits and includes the wakelock. I think it is good news you didn't found a way around the permission ;-) |
|
haven't given up yet. one solution would of course be to change the code and build myself, but I am gonna try all other options first |
|
Good news, I have given up on circumventing the restriction. One question, a helper app would have to send the following command 'am start -a biz.bokhorst.xprivacy.action.FLUSH' along with having 'biz.bokhorst.xprivacy.MANAGE_XPRIVACY' permission, correct? |
|
It should be:
|
|
Running this as root should work (just tested). |
|
After playing with this (it's a lot easier with the proper command) I'm trying to figure out where the permission part comes into play. I created a helper app with the permission, but it still needs root to run, or I can just send the command from terminal or tasker (with root) although neither has the permission |
|
If you don't have the permission, you'll need root. You will need this in the manifest file: This is how you can send the intent: If you put the source code of the helper app on GitHub I will take a look. |
|
You can check the logcat for potential errors. |
|
I wish could post the source, but the app was created with Tasker AppFactory, it creates an apk from a tasker task woth can be run without having tasker installed. android.permission.INTERACT_ACROSS_USERS_FULL When I add the permission, the app requires root to run |
|
@an0n981 Hi! Did you ever finish your Xprivacy Tasker plug-in, or what did you make in the end? I'm trying to do a similar thing with Tasker and shell commands to the Xprivacy database, but I'd love to know more about what you did. (I'm trying to make Tasker modify the Xprivacy database when a certain app is in the foreground, like Google Maps, then modify again when it is no longer in the foreground. I think I have all the building blocks working, but for far the problem I'm running into is that Tasker's detection of which app is in the foreground seems to be unreliable...or it may be Android that is unreliable in registering which app is in the foreground... I could use work-arounds, like Tasker shortcuts or timers or repeated checking rather than Tasker's standard app contexts, but those all have disadvantages.) |
|
Okay, I have found the cause of the unreliable triggers: Tasker by default only checks for foreground applications ever 1.5 seconds. You can set it to a lower value in Tasker's preferences, which may cause slightly higher battery usage. I tried that, and it really helped. Another, probably even more reliable trigger I found in Tasker is "UI – New Window". This can trigger a task whenever a new window is opened, so it triggers whenever you switch to an application. It seemed to be completely reliable, so far. The disadvantage is that the task is triggered every time you switch to a different window, not only when you switch to certain apps, as with the "Application" trigger. As to battery usage and general phone performance, I haven't noticed any significant effect yet with "UI – New Window" on all the time; but that is difficult to measure, and I have a reasonably fast phone (LG G2). |
Such a functionality would permit a much more fine grained access control model since a user could then enable capabilities for an app(s) not just in terms of absolute Yes or No but also conditioned on a huge variety of run-time conditions being met. For example this could allow revoking permissions needed by an app unless a run-time condition is met explicitly indicating that the user now intends to make use of those capabilities.
Example use cases:
The text was updated successfully, but these errors were encountered: