Les données utilisateurs et les permissions dans Marshmallow

La version d'Android M, la dernière disponible, mais qui n'a pas encore été déployé de manière massive, apportent de nombreuses nouveautés dont la gestion des permissions par application. Cet article précisera la gestion des permissions avec les groupes de permissions et leur liens avec les données utilisateurs.

Android M

L'objectif d'Android M est de faire en sorte que les développeurs fassent les bonnes choses avec les permissions et les données de l'utilisateur.

Permission

Comme préciser depuis différents articles, l'acceptation des permissions par l'utilisateurs ne se fera plus à l'installation, mais pendant l'exécution des applications et sera obligatoire pour toutes les applications ciblant Android 6.0 (SDK 23+). Dans tous les cas votre application devra être mise à jour, donc le but est de le faire intelligemment.

Les permissions à la volée permettent à l'application de demander l'accès à des données sensibles de l'utilisateur, d'expliquer pourquoi la permission est nécessaire sans effrayer l'utilisateur d'une longue liste de permission.

Les permissions sont maintenant organisées en groupe, pour que l'utilisateurs soient informés sans avoir besoin de comprendre des termes techniques. Comme l'utilisateur à le choix, il peut décider de ne pas donner son autorisation ou de la revoker plus tard. Donc l'application a besoin d'être souple pour pouvoir permettre à l'utilisateur d'accéder au reste de l'application sans la permission.

Exemple de groupe de permission (http://developer.android.com/guide/topics/security/permissions.html#perm-groups) : 

Données utilisateurs

Certaines données ne sont plus directement accessibles aux développeurs, comme les adresses du wifi local et Mac bluetooth. Les méthodes getMacAddress() de l'objet WifiInfo et BluetoothAdapter.getDefaultAdapter().getAddress() retourneront 02:00:00:00:00:00.

De plus, les Google Play Services fournissent des Instance ID, qui identifie une instance d'application en cours sur l'appareil. Cet ajout permet de proposer une alternative au non resettable, hardware ID qui est lié à l'hardware, car l'Instance ID ne peut pas être gardé après un factory reset et est limité à une instance d'application.

Voir plus loin

Une mauvaise gestion des permissions et des identifiants augmente le risque de tracking non voulu et cela peut donner l'impression à l'utilisateur que l'application ne prend pas soin des utilisateurs. De nouvelles documentations ont été mis en place pour aider les développeurs :

• Comment les permissions et les données utilisateurs sont liées : http://developer.android.com/training/articles/user-data-overview.html
• Les best practices pour les permissions : http://developer.android.com/training/articles/user-data-permissions.html
• Les best pratices pour les identifiants uniques : http://developer.android.com/training/articles/user-data-ids.html