"Restrict on demand" not working as expected

[danielmmmm]

Yes, the topic is vague and yes, I forgot where the official discussion on GitHub takes place.

Here are my issues/concerns:

1. The feature seems to work the other way around, requiring an "empty template" with no restrictions at all. With my default template (everything restricted), I do not get any "restriction on demand" requests.
   The problem here is that as soon as "restrict on demand" is switched off for an app, all non-restricted functions will stay non-restricted and therefore become available to the app! I would feel much better if "restrict on demand" would either apply the user's template or even restrict everything, ask when permissions are requested (only for blocked functions/categories!), and upon disabling "request on demand" , leave the app securely restricted for everything that was not allowed before. This would (in my opinion) be what the main purpose for "request on demand" is, namely a better way to configure an app with maximum possible restrictions without going back and forth between XPrivacy and the app (launching the app).

2. When an app requests a function (category) and the user stays inactive, XPrivacy defaults to allow the function (category). The default should either be "deny" (isn't XPrivacy about security?) or the user should be able to set the default himself.

3. There does not seem to be a way to reset "request on demand" for an app. When a function was allowed and "request on demand" is switched off and on again, the function that was allowed before will be without a question mark. This might be intended, but I am not sure if it is good or not. (Edit: Just found out that restricting the function and allowing it again will put it on the list of "request on demand" functions. This doesn't seem to be overly intuitive to me.)

[jpeg729]

1. A couple of days ago, I would have agreed. Now, I can see myself leaving on demand on.
2. The default isn't to allow, it is to deny once.
3. The feature is in development, so your comments are welcome.

[banderos101]

"3) There does not seem to be a way to reset "request on demand" for an app. When a function was allowed and "request on demand" is switched off and on again, the function that was allowed before will be without a question mark."

if im reading that right, thats why i sugested a "temp alow" option, for restrictions i might want to only allow once in every 5 intances of using an app, like for instance internet.......i want to allow that one time, but i also want the prompt to return because i might not want that app to have internet access the next time, the way it is now, if i allow, i have to go back into xprivacy and turn on prompt for that restriction again, whereas a temp allow, would allow that one time, AND reset the prompt to return the next time that restriction is called for, where i would temp deny when internet is not needed, the temp funtioning as a "hey i want this allowed/denied, but i want you to return the next time this restriction is called for

Two options, Allow/Deny, by default, both set to temp, with a switch, that flips that to permanent, the "remember selection" option, to me, that seems the most intuiative way, but maybe that only applies to the way im looking to use ondemand, i dont know

For me, its a little confusing having three options, when what i need can be done with two, and another benefit to having the two options set to temporarily by default, is that if a new user accidently denies something he shouldnt, and app crashes, the prompt comes back, samething with temp allow, if a new user accidently allows something they didnt want to allow, prompt comes back next time restriction is called again, this basically saves a new user/vets from having to go back into xprivacy finding the app then restriction and re-ondemand

this reminds me, ive been meaning to ask, what right now, "resets" the prompt,
every instance a restriction is called?
predetermined set amount of time?
or app force close, open?
or something else?

[danielmmmm]

@jpeg729:

1. Yes, everything is fine, as long as one leaves on demand on. But wouldn't it be better to have it the other way around? People who leave on demand on wouldn't see a difference, and paranoid weirdos like me would be happy. The possibility of granting all requests by mistake (be it by me or a bug in XPrivacy) seems very scary to me!

2. I tried it with an app that force closes when "load library" is restricted. When I allow "load library" and set the app to "request on demand", it FCs nicely when I deny the request for this function. When I wait for the pop-up to disappear on its own, the app does not FC. I don't know what happened internally, but to me this looks a lot like the function was allowed.

3. banderos101's comment sounds reasonable to me.

I would also not display the question mark next to blocked functions/categories. When I allow something, and "request on demand" is activated, I would expect the question mark to appear again (just a personal preference).
But, could you replace the "Check to restrict:" check box by a "restrict on demand:" check box? I am talking about the check box below an app's icon in the app view, which is superfluous anyway due to "clear" in the settings menu.

[M66B]

The next version will have rewritten on demand logic, so try again.

[banderos101]

"I would also not display the question mark next to blocked functions/categories"

I actually think its better to have a question mark irregardless of whether a restriction box is ticked or blanked, making it clear to users, that a ? would supercede the tick or blank, i.e. ? =a definite prompt iregardless of tick or blank, the reason why, THIS paranoid person might worry that on demand might not function as expexted one day, and might not prompt when it should, and in that situation, if xprivacy then falls back to following whats been selected for that permission, at least it'll have the correct information to fall back on, a tick or blank, but this i think needs a second column in order for this to work i think, user interface wise.....things might function in the background correctly, xprivacy might even already take this worry into account, but they'll be no easy user interface to communicate this, not using just one column, not when the option to turn on a prompt is the requirement, or non requirement of either a tick or a blank........if that makes sense

lets wait and see what the next version brings

[danielmmmm]

Nice, the test version does exactly what I would expect! I like the way you handled the automatic denial, where the question mark remains for the (automatically) denied function. And allowing manually disabled functions (like from my template) is also working like a charm!
Thanks a lot!