[Feature Request] Warning on new permissions in update

[mziehm]

Guidelines

• I have searched the issue tracker for open and closed issues that are similar to the feature request I want to file, without success.
• I'm on the latest version.
• I'm not using a test build (alpha/beta/release-candidate).
• This issue contains only one feature request.

Problem Description

Some updates of apps will extend the permissions
e.g. https://f-droid.org/packages/de.z11.roboyard/
version 30 (97) vs updates 41 (118) and later with added network permission since 41 (118).

Changing permission might change the evaluation of the app e.g. I might not mind contact or storage access if there is no network access as there is not risk of data loss, or I do not want an app suddenly without explanation or added features requesting additional permissions, as it might have been compromised.

Proposed Solution

Please highlight or warn when an update from the installed to the updated version is requesting additional permissions.

For example when hitting update there could be an pop-up with "This update incl. additional permissions:\n abc\nxyz".

Also consider if automatic updates should only occur when no new permissions are included.

Note that during permission comparison of versions, this comparison need to be invariant to order of permission declaration.

Alternatives Considered

Highlighting new permission in the permission section with a tag "New" in front similar to what the F-droid client (unreliably (see https://gitlab.com/fdroid/fdroidclient/-/work_items/3220) does.

IMO this would be also an option if reliable, but less ideal, as people need to actively check.

Relevant information

No response

[machiav3lli]

It's already implemented for sensitive permissions, since when do you use NS and didn't it notify you of such changes before?

[machiav3lli]

For reference: #752

[TotallyAvailable]

Might be wrong here (despite getting to see it several times lately) while the warning does exist...it appears only after the (manually triggered) update is successful, giving a potentially unwanted/malicious update the time to do whatever in the background (assuming the app has been opened at least once in the past (sidenote that this might not be entirely necessary due to "reasons" and/or "external factors"). Some (usually Play Store) Apps absolutely straight up auto run after a first time install and more than happily after every update, devices unlock, network change,...)

The request here might just be to straight up "refuse" the update to even happen if the old and new app permissions do not match in a "comfortable" way. As in excluded from Update All and a warning message before a manual update. Should ideally also apply to the fresh install flow triggered by a user defined "blacklist" ?

the following went slightly beyond the scope

While the permission overview and "heat"bar do exist...I personally find neither to be all that comfortable/intuitive. While the way it is presented could be endlessly discussed, neither the bar color nor the point ratings may align with my "values", points of concern or even the actual purpose of a given app if that makes sense.

Like SD Maid SE deep in the red...for doing its job ? Does tap into (no doubt) sensitive permissions for the exact reason it exists. How this could be solved is unfortunately not trivial. Given that there's no further escalation potential to immediately warn a user anymore. If the bar is full due to expected functionality, the simple addition of even network access is likely to be missed even for someone like me doing it the "hard" way...1 by 1, for certain (usually non open source) Apps only afteractively making sure old permissions=new permissions. At least the Play Store is still "that" (still hiding plenty of permissions) transparent in this regard.

If this could be solved in a more obvious and foolproof way in the open source world, that would obviously be phenomenal. New users might feel even more respected, existing users get to move further ahead of/away from the way it's usually done in the walled-in garden of madness of the big companies.