Skip to content
This repository has been archived by the owner on Sep 6, 2019. It is now read-only.

Whitelist for getExternalStorageState automatically applied to open, openFile etc?? #2384

Open
T-vK opened this issue Nov 3, 2016 · 6 comments

Comments

@T-vK
Copy link

T-vK commented Nov 3, 2016

According to the Xprivacy UI (whitelists), my WhatsApp seems to be allowed to use:

open, openAssetFile, openAssetDescriptor, openFile, openFileDescriptor, openInputStream, openOutputStream and openTypesAssetFileDescriptor

on my /storage/emulated/0 directory even though I completely restricted the access to all of these.
The only thing that is not completely restricted is getExternalStorageState.
It appears that the whitelist for getExternalStorageState is automatically being applied to all the functions mentioned above.

To reproduce:
Restrict every single function of the Storage category and also set the question mark.
When WhatsApp asks for access to getExternalStorageState with parameter /storage/emulated/0, grant it (whitelist). Then, when WhatsApp asks for access to getExternalStorageState without a parameter mentioned, grant it too.

I feel like WhatsApp should only be allowed to use the function getExternalStorageState after these actions. I don't understand why it would have access to more than that now.
Without the pro license I wouldn't even have noticed this. That's kinda scary.

@M66B M66B added the lowprio label Nov 3, 2016
@T-vK
Copy link
Author

T-vK commented Nov 3, 2016

I see the issue was tagged with "lowprio". Does this mean that this is potentially never gonna be fixed?
The issue seems rather critical to me tbh, especially due to it's misleading nature.
In the meantime: Is there a way to manually change the whitelists somehow? Are the settings stored in a readable format somewhere?

@M66B
Copy link
Owner

M66B commented Nov 3, 2016

I am not sure if this is a bug, since there is not enough information to determine it is.

"WhatsApp is allowed to use: open, openAssetFile, openAssetDescriptor, openFile, openFileDescriptor, openInputStream, openOutputStream and openTypesAssetFileDescriptor" are these functions restricted? There is no relation to getExternalStorageState. What is your expected outcome?

See also the support section.

@M66B M66B closed this as completed Nov 3, 2016
@T-vK
Copy link
Author

T-vK commented Nov 4, 2016

I edited the issue text to explain in more detail what is happening and how this can be reproduced.
If you need more information, screenshots or anything else, tell me please.

@M66B
Copy link
Owner

M66B commented Nov 4, 2016

It is correct that these function share the same file whitelist, but this is by design.

Search for cTypeFilename In this file:
https://github.com/M66B/XPrivacy/blob/master/src/biz/bokhorst/xprivacy/Meta.java

Since there are a lot of existing users, this logic cannot be changed anymore.

@T-vK
Copy link
Author

T-vK commented Nov 5, 2016

Thanks for clarifying.

Since there are a lot of existing users, this logic cannot be changed anymore.

I don't agree with that. In fact I would argue that you could maintain backwards compatibility and yet allow the user to set individual whitelists...

I would probably do it like this:
Add a note informing the user of this change when he updates or imports his old settings.
Also, in the popups add a note clarifying what functions will be affected by the whitelisting.
And finally, add a checkbox "only apply for this function" for the whitelisting in the popup.

Another way could be to ask the user when he starts the new version for the first time, which behavior he would prefer.

The least that should be done in any case, is clarifying that the whitelist is applied to more than the mentioned function. Because however desired this behavior might be, it is not obvious to the user.

@T-vK
Copy link
Author

T-vK commented Nov 6, 2016

Will you reopen this issue?

@M66B M66B reopened this Nov 7, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants