XPrivacy
XPrivacy copied to clipboard
M66B
Blacklisting without resticting main function is possible
Blacklisting is possible while not having the associated function ("open") restricted. As mentioned by daniel_m at xda forum.
I have tried this too with an txt file. XPrivacy v3.6.2 - Android v4.2.2 - Samsung S4 mini
Tested the "Open" black/white listing. Used app: WPS Office. Used file type: txt
- Not restricting the function but asking on demand and black listing does really restrict the file from being opened.
- Removing the on demand check mark after already having a blacklist item does still work in restricting file from being opened.
Not sure if this is the case with the whitelist for accounts and contacts
@kaizokan Thanks for reporting!
I just tested this with the IntentFirewall and uninstalling an app. The result is the same, the intend PACKAGE_REMOVED was blocked, even though the function IntentFirewall was allowed and on-demand was deactivated. Since two white lists behave like this, it is statistically safe to say that all do ... says I, the biologist ;-P
Hmm this could be intended behaviour. After all, it might make sense to have an app access all Internet addresses except a certain specific site. On the other hand, that use-case scenario is probably rare; I guess it is better to have blacklists deactivate (temporarily) while the restriction is allowed, as the OP suggests.
yeah i agree on that it might be useful this way but not sure anymore, i can't quickly come up with an example in which black/white listing without restricting first would have an advantage over restricting before black/white listing. It would only give me the impression that the default action would be allow, after the time expires.
That could also cause confusion when a user un-checks all functions and on-demand, but things are still restricted. The user should actually know by the icon for white listing though. so not sure if this is a good reason to not allow this behaviour.
For me it's not a problem anyway i always restrict and whitelist
@kaizokan I agree with your reasoning. And I also use it that way, either restrict and whitelist with on-demand, or restrict and whitelist without on-demand, or allow. I only use blacklist for restrictions that I also use whitelist for, so I would never use blacklist without a whitelist, so using a blacklist while allowing a restriction is never something I use.
For blacklisting specific domains, I would want to blacklist that domain throughout Android, so I would use Adaway or something (which happens to be built into my ROM/kernel, so I can't change the lists at the moment).
Although it could be a bit confusing, I think I may like the current functionality (assuming I understand it correctly). With the current functionality, you can blacklist specific sites while still allowing access to all other sites.
To make this even more useful, adding the ability to manually enter whitelist/blacklist items would be an excellent enhancement.
(OTOH, I do agree that it's currently a bit confusing to have anything restricted when the checkbox is not checked... perhaps something similar to the tri-mode checkbox could be used for these situations.)
To help everyone, I just added FAQ 82 to the README. Please verify that I go it right. See https://github.com/M66B/XPrivacy/pull/2284
Marcel considers this to be a bug in XPrivacy. See our discussion in #2284.
In my idea this is no intended behavior, which can confuse people, so I have marked this issue as a bug. Since this bug has been existing for a long time and nobody complained, I have marked it as low priority.
White/black listing is being processed here: https://github.com/M66B/XPrivacy/blob/master/src/biz/bokhorst/xprivacy/PrivacyService.java#L595
The more I think about it, there are only two desired states:
State 1: Restricted (with whitelist) State 2: Unrestricted (with blacklist)
It gets confusing due to how the "restricted" and "on demand" functionality interact with each other.
Perhaps a simple fix would be to use a tri-state checkbox just for the "restricted" checkbox:
Checked: Restricted
Square: Only restricted by blacklist
Unchecked: Not restricted
This way, none of the processing code would need to be changed. Only the UI code would require adjustment to reflect the actual behavior.
I am wondering now what black listed should mean, especially what is being black listed.
A possible interpretation could be that the category is restricted, but the function isn't and the black list reverses this, but this could be confusing as well.
The only other option I see, besides removing black listing, is that a black list reverses a not restricted function.
@Gitoffthelawn on demand restricting is only a means to select restrictions run time, so I would like to leave this outside this discussion for now.
@Gitoffthelawn Square: Only restricted by blacklist: there is already a white list icon that will be shown for a black list as well (although I haven't checked this, but it probably will).
I am confused. The original issue as discribed by @kaizokan is that with a function set as [ ] [ x ] and adding an onDemand popup to blacklist does not prevent opening. I have just tested on an AOSP rom using the Gallary app and cannot confirm his/her findings. The Storage/Open onDemand works just fine no matter how the restrictions are set and whether I allow/deny once or add white/blacklist entry....
And then you guys kind of lost me with the rest.
I honestly don't see a bug or anything that should be changed.
FAQ 34 describes beautifully how function restrictions work.
What I understood and what I also see as a problem is that black listing stays in effect, even after disabling the function restrictions.
I cannot find your original post regarding this. The discussion was quite some time ago. But IMHO and the way you described it back then is that black/white lists should remain intact, even if the restriction is unchecked. For example I may have an app set to [ ] [x] because it is a dangerous system app and in case of an onDemand while Sleeping=true. Since it is dangerous I want onDemand to be allowed in this case. However I have already blacklisted items that should not be allowed.
@an0n981 That is a realistic scenario. In that situation, the current system (blacklist blocks things even when its permission is allowed).
But there is also another scenario where blacklisting is useful. Suppose I were using Chrome with libraries restricted on demand. When I first started Chrome, it needed to load some library to function at all, so I whitelisted that library. Then browsing worked without further prompts. Then later I went to a certain strange web page and Chrome suddenly asked to load some library. It seemed potentially unwanted, so I blacklisted that library for Chrome. The nest time a page wants Chrome to load that library, it is automatically forbidden, so it won't bother my any more. If, in the future, Chrome wants to do something else that requires a new library and that I actually want to do, then I will be prompted and I can whitelist that new library. So it makes sense to work with on-demand and blacklists together. I actually never use blacklisting unless combined with on-demand.
In short, to accommodate both my scenario and that of Anon above, perhaps every should stay the way it is, after all. Maybe with an extra warning somewhere, because I can see how this could confuse people.
@Cerberus-tm and @an0n981 I tend to agree with both of you. (Although I have not flushed out every case.) Instead of a warning, I propose using the associated checkbox to reflect what is going on. That way, a visual cue is provided to the user. Furthermore, no functionality will have to change, thus nothing will break for existing users.
@Gitoffthelawn Good point. So as you imagine it, only the main check box for the app, the one at the top above all categories, toggles between those three states? That actually sounds like a nice idea.
- One thing to consider is that users will probably not understand what the square means.
- A question: when the box is set to "restricted" or "unrestricted except by blacklist", will the whitelist still be active in both cases? (I presume yes.)
- Another question: is the blacklist erased when you toggle between the options? (I presume no.)
- A remark: isn't it true that whitelist and blacklist are processed as one big set of rules? If so, maybe it would be difficult to split them into two separate "actions" for the deeper processing? If so, then maybe the three states of the box should be:
everything allowed, no white/blacklists applied (this would be new) everything allowed, except that white/blacklists are applied (currently indicated by a square) nothing allowed, except that white/blacklists are applied (we definitely want keep this option)
This still sounds like quite a bit of work; for me, it wouldn't be of a high priority.
@Cerberus-tm You raise excellent issues. Unfortunately, I am pressed for time right now and thus cannot carefully think about them and respond thoughtfully.
Very quickly, I am thinking that the restriction checkbox for each function would have a unique appearance (filled square in it, different color, etc.) iff (if and only if) the restriction is not present but a blacklist is being enforced.
I'm pretty sure that could be implemented in 1-5 lines of code.
@Cerberus-tm Simple for me... I'm not the one who will implement it. ;-)
But there is also another scenario where blacklisting is useful. Suppose I were using Chrome with libraries restricted on demand. When I first started Chrome, it needed to load some library to function at all, so I whitelisted that library. Then browsing worked without further prompts. Then later I went to a certain strange web page and Chrome suddenly asked to load some library. It seemed potentially unwanted, so I blacklisted that library for Chrome. The nest time a page wants Chrome to load that library, it is automatically forbidden, so it won't bother my any more. If, in the future, Chrome wants to do something else that requires a new library and that I actually want to do, then I will be prompted and I can whitelist that new library. So it makes sense to work with on-demand and blacklists together. I actually never use blacklisting unless combined with on-demand.
- Cerberus-tm
This is exactly how I use it with different apps. It looks like the black/white list option works as an individual function that is not directly connected to the first checkbox. Maybe this is how it should stay, the (w) icon for white listing should be a good indicator already imoh maybe make it glow/highlight for more attention if necessary. Or even a four state check box.
@an0n981 for me it did prevent opening. @Gitoffthelawn The square check mark has already a purpose. Won't using this for another purpose make it worse?
I might not get certain things mentioned, there where so many reactions. Correct me if i think wrong.
@kaizokan The use of that specific UI element (square check mark) would need to be evaluated for just the reason you mention. Off the cuff, the meaning is similar enough that it could work (i.e. "not completely restricted and not completely unrestricted").
@Cerberus-tm I think you have a good point there with your Chrome example.
Instead of tinkering with the check boxes, could not the white list icon itself indicate that the white list contains data and is active? Maybe an empty white list could be white with a grey "w", as it is now, and then turn grey with a white "w" (or green or something else) when it is active.