Following android best practices permission model

Development UX
1

Best practices says

★ Note: Don’t overburden the user by requesting every permission at app startup. Be courteous of the user and only request permissions when they need access to a specific feature.

For instance, only prompt for microphone access when a user clicks on the microphone button. Users are more likely to allow a permission that they are expecting.

Syncthing purposely does the exact opposite. It requests three permissions at app startup. This process is “not courteous of the user” and when it was brought up in github as part of a feature request #1806, the reasoning provided is in stark contrast to all available best practices.

The permission overview on the developer page:

  1. Design your app’s UX so that specific actions in your app are associated with specific runtime permissions. Users should know which actions might require them to grant permission for your app to access private user data.

In this case,

  • Request All files access only when the user is requesting a folder
  • Request Battery optimizations, only when the sync starts
  • Request location, if and when the user chooses to restrict to a specific WiFi network.

What if the user denies all three permissions? The app should still work according to graceful degradation of app(See handle denial section in the link above):

Guide the user’s attention. Highlight a specific part of your app’s UI where there’s limited functionality because your app doesn’t have the necessary permission. Several examples of what you could do include the following:

Show a message where the feature’s results or data would have appeared.
Display a different button that contains an error icon and color.

In case of storage permission denial, the app should show a error message where “other” folders should have appeared. The app should still show it’s inbuilt hidden private folders /data/data/com.nutomic.syncthingandroid, /storage/emulated/0/Android/data/com.nutomic.syncthingandroid and work with it.

Be specific. Don’t display a generic message; instead, mention which features are unavailable because your app doesn’t have the necessary permission.

The current message isn’t specific at all.

Don’t block the user interface. In other words, don’t display a full-screen warning message that prevents users from continuing to use your app at all.

This is exactly what syncthing is doing. It’s blocking the user interface. In case of storage permission denial, the app should show a error message where other folders should have appeared, but still allow complete functionality of the app with the inbuilt folders.

Consider following standard best practices for a better User experience.

2

Why not. If done very clearly and conveniently. Contributions welcome.

1 Like
3
  • the whole point of installing the app is that at least one folder is being synced. So that permission is IMHO mandatory
  • the app might start to sync in the background depending on what settings are configured. You can only request permissions interactively.
  • agreed, the location permission should be bound to that option
4

The internal private folder sync doesn’t need permission. While the whole purpose of sync is to sync folders, one can choose to do a one way “Receive only” sync. In any case, if the app can work without those permissions, it should work without them, instead of blocking them at app startup.

Even asking battery optimizations can be done after setting up the first sync folder. There is no need to ask for it at app startup. But if denied, the app should still make best effort to work without it.That is the accepted best practice:

Tip: Your app should encourage the best user experience possible, even after permission denials. For example, if microphone access is denied, you should still promote full usability of text functionality.

In this case, If the app is denied all files access, you should still promote internal folders sync. That is graceful degradation of app.

5

I don’t disagree in principle, though I do disagree on it’s importance, and even more so on considering UX a non-issue compared to privacy and security (neither either without good UX. Anyway what I am meaning to day is there’s no “should”, there’s just “useful?” and “do”. Noones going to jump to action because you tell then to, you either get lucky and someone agrees and wants to work on it, it you do it yourself.

6

I understand that. But the github issue was closed almost immediately. For now, as long as I get to reveal the issues, how they directly contradict recommended best practices and show a different point of view to the maintainers, I’m satisfied with that. Thank you for considering this view and your comments so far. Privacy and Security are important. This UX issue is directly related to both. I disagree that this is not related to both. Unnecessary access to All files is a privacy and a security issue. It increases attack surface, in case of a new or unknown vulnerability. “Least perms possible” is a good thing.