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

Feature request: Add option for "advanced mode" to also restrict critical methods by default #716

Closed
danielmmmm opened this issue Oct 1, 2013 · 6 comments

Comments

@danielmmmm
Copy link
Contributor

By default, XPrivacy does not restrict critical methods within a category, when a category is checked. E.g. checking the category "Identification" will not check "/proc", "/system/build.prop" and "GservicesProvider".

Please give us an option to enable an advanced mode, where these critical methods within a category get checked as well as the non-critical ones (at least in non-system apps). I am aware that blocking these critical methods might "break" an app and that I might have to re-boot after having granted access to a previously blocked critical method, but it is impossible to block all these methods for > 100 apps manually and I prefer the brutal way of telling an app which methods to use and which not.

After enabling such an advanced mode, XPrivacy could show a message for ~20 seconds and ask the user to confirm.

@jpeg729
Copy link
Contributor

jpeg729 commented Oct 8, 2013

I shall +1 this request. My usual workflow on installing a new app is to restrict everything and when it bugs I look at what its usage and start allowing stuff bit by bit.

@28Black
Copy link
Contributor

28Black commented Oct 9, 2013

@danielmmmm We're looking forward to get a more detailed template. As soon as @M66B applies this, it would be easy to restrict these unsafe categories by default when you install a new app.
I agree with you, I'm restricting almost always manually "/proc" and "GservicesProvider".

@danielmmmm
Copy link
Contributor Author

Awesome, I am also looking forward to this :-D
Thanks!

@M66B
Copy link
Owner

M66B commented Nov 7, 2013

The next version will allow dangerous categories in templates

@danielmmmm
Copy link
Contributor Author

Thanks a lot!

@danielmmmm
Copy link
Contributor Author

Will you also allow dangerous methods in the future? This is actually something I'd like to see even more than allowing dangerous categories ;-)

@M66B M66B closed this as completed in 3e10a96 Nov 15, 2013
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

4 participants