XPrivacy
XPrivacy copied to clipboard
UI: Template UI design could lead to accidental data exposure
I discovered the issue below while teaching someone how to use XPrivacy. It's possible the behavior is by design, but it is not what I (or the student) expected. The test version is 3.6.19.
To reproduce:
- Go to Options > Template
- Scroll down to Sensors and expand the category
- Ensure the Sensors category is selected, as well as every item within the category.
- Uncheck both checkboxes for acceleration
- Collapse the Sensors category
- Uncheck both checkboxes for the Sensors category
- Check both checkboxes for the Sensors category
At this point, if you expand the Sensors category, you will notice that despite checking both checkboxes for the category, the acceleration item will remain unchecked. I think this is different than what most users would expect (in the UI world, we call this "violating the users expectations").
Although this behavior does make sense for the task of enabling/disabling a category, it can result in common mistakes, and thus data accidentally being exposed.
With the current behavior, the only way to ensure that all 'non-dangerous' items with a category are really being restricted by a template is to open up each category and scroll through all the items. Categories without 'dangerous' functions are not affected, since the presence/absence of a checkmark alleviates this issue.
This is a deliberate choice, so that accidentally disabling the category restriction doesn't erase the maybe carefully chosen function restrictions (which are in fact exceptions to the category restriction). Moreover, changing this behavior now, will affect a lot of existing users.
Gitoffthelawn [email protected] schreef op 26 september 2015 00:10:59 CEST:
I discovered the issue below while teaching someone how to use XPrivacy. It's possible the behavior is by design, but it is not what I (or the student) expected.
To reproduce:
- Go to Options > Template
- Scroll down to Sensors and expand the category
- Ensure the Sensors category is selected, as well as every item within the category.
- Uncheck both checkboxes for acceleration
- Collapse the Sensors category
- Uncheck both checkboxes for the Sensors category
- Check both checkboxes for the Sensors category
At this point, if you expand the Sensors category, you will notice that despite checking both checkboxes for the category, the acceleration item will remain unchecked. I think this is different than what most users would expect (in the UI world, we call this "violating the users expectations").
Although this behavior does make sense for the task of enabling/disabling a category, it can result in common mistakes, and thus data accidentally being exposed.
With the current behavior, the only way to ensure that all 'non-dangerous' items with a category are really being restricted by a template is to open up each category and scroll through all the items. Categories without 'dangerous' functions are not affected, since the presence/absence of a checkmark alleviates this issue.
Reply to this email directly or view it on GitHub: https://github.com/M66B/XPrivacy/issues/2266
That is a good rationale, and I'm glad to hear it was deliberate (and not a bug).
There is a significant tradeoff to that design. Perhaps something could be implemented to mitigate the negatives of that design while keeping the positives.
May I propose, in such cases, that XPrivacy evoke a message box asking the user whether they want to enable all 'non-dangerous' functions, or only ones previously enabled? I think such a solution will eliminate errors (resulting in possible data exposure), while simultaneously satisfying existing users and honoring your original rationale. I think it's a win-win-win.
@Gitoffthelawn That is not such a bad idea! I often forget that I had unchecked some permissions when I reënable a category. It does require an extra tap, though, so perhaps this should be options (an option in settings). Or perhaps it would be too much work to be a high priority in development of the application, I don't know.
I don't like options, unless necessary.
To be consistent with the check box in the application list, I envision a question weather to erase the restrictions or not when removing the category check mark.
Cerberus-tm [email protected] schreef op 26 september 2015 05:02:19 CEST:
@Gitoffthelawn That is not such a bad idea! I often forget that I had unchecked some permissions when I reënable a category. It does require an extra tap, though, so perhaps this should be options (an option in settings). Or perhaps it would be too much work to be a high priority in development of the application, I don't know.
Reply to this email directly or view it on GitHub: https://github.com/M66B/XPrivacy/issues/2266#issuecomment-143393537
Also, there is already an implicit option: using the function restrictions requires agreeing to be an expert user. For this reason I will set this feature request to low priority.
Just FYI, this issue definitely appears when Expert mode is disabled. (It may also appear when it is enabled.)
I guess you mean the expert mode you can toggle using a check box in the main settings. What I mean is the implicit expert mode which will be enabled after answering yes to the question when drilling down a category for the first time.
If you have the opportunity: clear all data using the (expert) button in the main settings and drill down a category restriction to see what I mean.
Lol... I'll take your word for it. I don't want to risk an export/import failing and having to start over... I have over 20 hours invested in researching restrictions and setting things up.
You are correct... I was referring to the actual expert mode setting.
The only time a user will see an implicit mode agreement will be the first time they try XPrivacy, and are so confused they have no idea on what they are clicking. XPrivacy is fairly easy to understand once you get a hang of it, but it has a steep initial learning curve where nothing makes much sense (even after reading the FAQ). I've had to teach several people how to use it because they were so confused initially. I liken XPrivacy to riding a bicycle: very scary initially, but a great tool once you are familiar with how to 'ride' it.
IMHO the question is pretty clear and new users should not answer to be an expert.
While developing XPrivacy I have cleared all data so many times that XPrivacy is probably not very useful to me anymore.
While developing XPrivacy I have cleared all data so many times that XPrivacy is probably not very useful to me anymore.
LOL. Same here. While setting it up, I changed restricted/allowed permissions so many times that I question whether or not it's really of any value at this point. And then there was a surprise ROM update that removed root (and thus XPrivacy functionality), which completely opened the door.
I figure for new apps it will at least help... I just hope it doesn't slow things down... I didn't run metrics before installing it, so I have no idea how much performance impact it is having.
I know how this aspect of Xprivacy works, but I just keep forgetting it; I forget to check the individual permissions after tuning a category restriction back on.
What is this talk of Xprivacy's not being useful any more? I, too, have experimented a lot, but if you just restore a back-up of your permissions, what's the problem?
M66B and I were just lamenting that after you clear or experiment with restrictions enough times, so much data has passed through that the full benefit of XPrivacy has been compromised.
XPrivacy is still very useful, even in this situation. And of course, if you have not gone through these same procedures, it is even more useful.
Ah okay, yes, I have done the same thing. But who hasn't? Even users who never experiment will have used a smartphone before installing Xprivacy, so everyone's data have passed through... as you say, it is still very useful. I have made a fresh start on my new phone and been fairly consistent. The only applications that I should have restricted more is Google Play Services. (Recently, I have restricted libraries for them on demand, but the phone sometimes reboots when they are disallowed.)
If I'm reading this correctly, perhaps it could be solved by having the category check boxes be tristate. When all items are restricted, fill the box, when none are selected clear it. But when only some are selected, shade the box. You could even go further and shade it the dangerous functions color when dangerous functions are selected, though that seems unnecessary.
@Efreak Sounds like a very good idea! This bothers me too.