Add an option to not delete restrictions when fetching (default disabled)

[an0n981]

I just installed an app and fetched restrictions for it. Since only 2 people had submitted restrictions these were not considered reliable and all checks were removed. It would to have an option to cancel in such cases or maybe a general option to see what will be fetched and then have to confirm.

[wbedard]

+1 to displaying a summary of what permissions will be applied. This display would have an option to cancel the operation.

[Jimmy34742]

If I fetch and my fetch request is "rejected" due to an unsatisfactory confidence interval, it should default to leaving the restrictions as they were instead of clearing them. Clearing them is the same behavior as a high confidence fetch that fetches all cleared restrictions. So the current method is ambiguous, requiring the user who notices to do some bookkeeping to verify what happened.

[jpeg729]

If I'm reading the server code correctly, it doesn't communicate the confidence level to the app. It just reports non-restricted for any method whose votes don't meet the confidence interval. So if the app is in the database with only one submission, doing a fetch would result in nothing being restricted.

Maybe an app should only be available for fetching if at least all its categories meet the confidence interval. The app details view's fetch option could work differently, fetching the votes themselves to present the user a preview and let them choose.

Supposing one could add a comment per category on submission, the app could present for comment only the categories where at least one non-dangerous method was not restricted. So you'd be able to say why you allow the app to access the internet, or use the clipboard, or ... The comments should have a limited length.

Supposing then that the app details view could fetch the votes and comments and present it all for preview, the user could then read a few comments and choose which option to apply in each case. When the user has finished choosing, his choices could be transmitted back to the server to add weight to the votes.

[M66B]

The crowd sourced restriction server will report No restrictions available" now, if none of the restrictions is reliable.
Is this a good enough solution for this issue?

[M66B]

For reference: 610e829

[jpeg729]

Supposing there are only three sets of votes, that only agree on one
category.
The result would be clearing everything except that category.

Maybe we need a minimum number of categories satisfying the CI. How about
reporting Nothing found if 5 or more categories don't satisfy the CI.

[Cerberus-tm]

What would make more sense to me would be if only those check boxes are changed for which there is a clear consensus, and the other boxes are left the way the user had them before fetching the restrictions, with a warning toast. Or is this impracticable?

[jpeg729]

In other words, don't wipe first. That would work, wouldn't it?

[Cerberus-tm]

@jpeg729 Exactly!

P.S. Some kind of notification about which boxes had valid values in the database would be nice, but may not be worth the effort. Or at least a toast message "some tick boxes have been changed" or "no tick boxes have been changed".

[M66B]

Duplicate or extension to #1319