Le système de permissions change avec Android 6.0 : Quelles sont les implications pour nous, utilisateurs ?

Comme je l'ai dit plus haut (quelque part), le nouveau système de permissions est une fuite qui montre qu'une nouvelle idée n'est pas souvent une bonne idée.

Soyez avertis ! Cela peut prendre un peu de temps à lire, car je vais parler de l'histoire d'Android, et plus encore ! Allez-y et prenez un verre !

Vous êtes bon ? D'accord, vas-y.

Les origines du nouveau système de permission

Lorsque Google a commencé à travailler sur un moyen d'accorder et de refuser des autorisations de force à la volée, c'était sous Android 4.3. C'était un bogue, alors ils l'ont caché. Il est cependant toujours possible de l'utiliser en créant un raccourci vers le menu des paramètres d'exploitation des applications. Ce menu était très similaire au menu actuel des applications, mais le fait de toucher une option fait immédiatement apparaître les options d'autorisation. Vous deviez également découvrir les permissions avant de pouvoir les activer, et c'était un véritable bogue puisque les applications se demandaient ce qui se passait parce que vous aviez désactivé quelque chose, et se plantaient de manière inopportune. Yay.

Le système a été supprimé une fois que les moddeurs l'ont découvert (il a donc été supprimé dans la 4.4), 1 mais a fait son retour dans Marshmallow. Il avait l'air vraiment bien - vous pouviez enfin choisir si des choses comme Facebook pouvaient saisir votre emplacement (bien qu'il ait demandé gentiment). Même certaines applications Google, comme Hangouts, ne sont pas à l'abri de vos décisions. Mais ensuite, nous avons rencontré un problème : le système est toujours cassé, mais d'une nouvelle manière : les permissions ont été fortement modifiées.

Vous voulez que Stack Exchange se connecte via Google ? Il faut des autorisations pour les contacts (bien que les développeurs de SE aient corrigé cela de leur côté). 2 Vous voulez télécharger des images sur Facebook ? Il doit voir tous vos fichiers. Pourquoi ? Compression . Les permissions sont maintenant accordées en groupe, où le fait de demander votre compte Google permet également aux applications de voir tous les contacts de l'appareil. Je doute que cela ait été voulu, mais la suppression de la plupart des autorisations a obligé à simplifier les règles du jeu ; la plupart des autorisations supprimées étaient juste des autorisations d'accès. poussés dans des groupes super-généraux .

Certaines autorisations ont été supprimées en raison des nouveaux SDK. GET_ACCOUNTS Un nouveau kit de développement logiciel (SDK) a été mis en place pour permettre l'ouverture d'une session Google mais, si l'application ne le prend pas en charge, elle devra utiliser les autorisations des contacts. Cela explique celui-là (y compris la façon dont l'application SE a finalement été corrigée), mais certains des autres ne reçoivent pas ce traitement. A ce jour, les applications peuvent simplement lire le dictionnaire indépendamment du clavier. La plupart des autres permissions mentionnées par Izzy semblent correspondre à des groupes modifiés : La plupart correspondent à la Godmission 'Modifier les paramètres du système' (permissions séparées des principales) et à 'l'accès à l'utilisation'. D'autres sont gérées par les applications elles-mêmes.

Donc, tout ce qui n'a pas reçu de nouvelle maison a été tué. Parfois, cela avait du sens (nous avons seulement besoin GET_ACCOUNTS pour déclencher le SDK) Alors que d'autres fois, cela vous donnait envie de tirer une balle dans votre téléphone : oh oui, je vais juste vous laisser accéder à mes contacts, vous semblez bien. Bien sûr, accédez à mes appels et gaspillez mon argent. (En espérant que personne ne soit que muet. Avec un peu de chance.)

Au début, je pensais que c'était génial ! Simplification ! Mais cela permet à des applications apparemment légitimes de faire des choses illégitimes beaucoup plus facilement. Votre outil de hack Minecraft qui veut votre compte Google est probablement aussi en train de voler vos contacts. Et les vend.

À cela s'ajoute le système Lockdown pour les autorisations, qui vous permettait d'affiner les autorisations des applications. C'est génial, mais ça ne fonctionne pas. Pas du tout. Il est également inexact (il dit par exemple que Stack Exchange lit mes SMS'. Non, non, il ne le fait pas) et est tout simplement horrible.

Mais qu'est-ce que cela signifie pour ma vie privée ?

Je pense personnellement à l'une des deux choses suivantes :

1. Le nouveau système de permissions a été conçu pour permettre des changements simples et rapides à des fins de sécurité. Les autorisations sont désormais accordées par groupes, ce qui explique pourquoi certaines sont supprimées : Google a pensé que les laisser sous un seul grand en-tête était une bonne idée (et pour l'utilisateur final, je vois pourquoi : contrôler chaque permission individuelle pouvait devenir fastidieux). Bien sûr, comme le communisme, ce n'était que bon sur papier ; en réalité, c'est une mascarade qu'ils ne veulent pas admettre. C'est normal.

2. Cependant, il se peut qu'ils fassent cela pour forcer davantage d'applications à utiliser leur SDK afin d'alléger les autorisations suspectes (je ne peux pas les blâmer) et ainsi gagner plus d'argent. Il est prouvé qu'ils le font (et qu'ils essaient de rendre Android moins open-source) qui me dégoûte.

Pour l'utilisateur final, c'est comme un peu d'iOS, c'est-à-dire quelque chose qui a l'air bien, mais qui est merdique. Mais est-ce que ça peut être réparé ? En quelque sorte.

Les "solutions de rechange".

Méthode 1- Xprivacy (Root NEEDED BOI)

Xprivacy fonctionne sur Marshmallow, selon ses développeurs, bien sûr. Cela nécessite de s'occuper de toutes sortes de petits détails sur MM maintenant, et il y a démarrage vérifié . Ce qui est pénible, car vous recevrez probablement un avertissement rouge ou jaune, ce qui peut empêcher le démarrage. (Cela dépend de votre chance, et de la quantité d'erreurs que vous avez faites.) Mais si vous pouvez faire fonctionner Xprivacy, c'est assez facile.

En raison de l'attitude "ne démarre pas à l'arrêt complet" que N va apparemment adopter, il pourrait même être plus cauchemardesque de travailler là-dessus.

2017 EDIT - Les développeurs de Xposed travaillent à contourner tout cela (yay !) Si je trouve le post sur XDA, je vais le lier.

MÉTHODE 2 - Verrouillez tout.

C'est très compliqué, mais cela permet un contrôle maximal (dans la mesure où cela est possible). Vous accordez des autorisations d'applications lorsque c'est absolument nécessaire, puis vous faites une course folle pour les désactiver à nouveau. Ce sera probablement plus facile lorsque Nougat sera disponible sur un plus grand nombre d'appareils, ce qui permettra d'utiliser des fenêtres multiples.

MÉTHODE 3 - Ne pas mettre à niveau (que j'appelle la "solution Izzy")

Si vous avez levé les yeux quand je vous l'ai dit, vous avez peut-être remarqué la méthode d'Izzy : vous vous abstenez tout simplement de faire la mise à niveau vers Marshmallow ou Nougat. Boo-Hoo, je sais, mais aucun des deux ne change vraiment la donne. Donnez-lui.... Six mois, et la plupart des merdes pour N seront sur le play store, si vous les voulez vraiment. Donc, la solution Izzy consiste à s'en tenir à la version 5.1.1 ou à une version inférieure. Je peux vivre, et vous aussi.

MÉTHODE 4 - LE BOMBARDER DEPUIS L'ORBITE.

(Juste pour plaire aux masses. Pour info, ce serait impossible.)

Ou, l'ignorer. Votre décision.

EDIT Izzy a trouvé un lien vers un Question sur Stack Overflow Cela explique que Credentials, Logins similaires pour se connecter à diverses applications relèvent d'une "autorisation normale" ( niveau de protection "normal"), c'est-à-dire que n'importe quelle application peut y accéder à votre insu. Heureusement, certaines applications et logins vous permettront de supprimer cette fonction par l'intermédiaire de leur gestionnaire de compte, selon le degré de malveillance de l'application.

EDIT 2 J'ai oublié de dire que vous pouvez supprimer les applications des comptes :) Je vais utiliser les systèmes de comptes Google et de comptes d'applications Facebook comme exemples, car ce sont les plus utilisés.

Comptes Google

1. Rendez-vous sur accounts.google.com ou ouvrez les paramètres de Google play (cela varie selon l'appareil, il s'agit généralement d'un rouage avec un g).
2. Trouver des applications/applications connectées/applications et services connectés (encore une fois, variable)
3. Trouvez ce que vous voulez supprimer, et cliquez sur "supprimer".

FAIT !

Facebook

1. Se connecter sur le site
2. Allez dans les paramètres du compte > applications
3. Trouvez l'application cible, et cliquez/touchez sur supprimer.

C'est fait !

J'espère que cela vous aidera ! Si ce n'est pas le cas, écrivez un commentaire, vous savez comment faire. Je vais y travailler de toute façon. C'est fait, mais faites-moi quand même savoir si j'ai raté quelque chose !

1 _{Il y a eu différentes tentatives faites par Google pour "mieux le cacher", et différentes versions des frontends d'AppOps l'ont ramené ensuite pour 4.4 et 5.0, mais sans plus.}

2 _{Apparemment, les applications peuvent volontairement utiliser un nouveau SDK qui permet de se connecter à Google sans l'autorisation des contacts. Voir <a href="https://meta.stackexchange.com/questions/285589/how-does-the-new-sign-in-system-work-for-the-android-app/">ici pour les détails </a>.}

En résumant mes propres conclusions - qui peuvent recouper celles de la Commission européenne -, j'ai constaté que la plupart des personnes interrogées n'étaient pas d'accord. La réponse de Dan :

Origine

Google a commencé sur le nouveau système de permission avec Android Jellybean 4.3. L'intention officielle (révélée plus tard) était de donner aux utilisateurs un certain contrôle sur les permissions auxquelles une application devait avoir accès ("permission on demand") - au lieu du "tout ou rien" existant à l'époque (si vous n'aimiez pas qu'une application ait une certaine permission : soit vous vous en accommodiez, soit vous ne l'installiez pas). L'interface AppOps a été cachée, mais bientôt révélée, cachée à nouveau (Kitkat/4.4), révélée à nouveau, et la même chose une troisième fois avec LP/5.0, après quoi elle a été protégée d'une manière difficile à contourner.

État actuel

Enfin, AppOps a fait surface avec Marshmallow/6.0. Mais au lieu de donner aux utilisateurs un contrôle fin des permissions, celles-ci sont réduites et le contrôle est plutôt brut ; si vous voulez par exemple que votre application de voyage soit capable d'ajouter vos réservations à votre calendrier, mais pas de lire vos autres entrées de calendrier : pas question. Soit vous interdisez l'accès au calendrier, soit vous l'autorisez. Il en va de même pour les autres permissions, car AppOps ne s'occupe que des groupes. 1

En outre, de nombreuses permissions ont été soit supprimées complètement, soit attribuées à Niveau de protection "normal" - ils sont donc automatiquement accordés et ne peuvent être révoqués par l'utilisateur. C'est par exemple le cas de l'option INTERNET l'autorisation, mais aussi pour USE_CREDENTIALS (donc toute application ayant cette permission peut utiliser n'importe lequel de vos comptes sans votre approbation explicite !) ou même BLUETOOTH_ADMIN (couplez votre Droid avec n'importe quel appareil BT à portée de main). Pour une liste détaillée, voir ce Gist .

De plus, de nouveaux niveaux de protection ont été ajoutés : appop pour les permissions que l'utilisateur a explicitement accordées via le nouveau système "à la demande", pre23 pour les autorisations automatiquement accordées si une application cible une version inférieure à MM (c'est-à-dire avant l'introduction des "autorisations d'exécution"), preinstalled pour les applications livrées avec la ROM (on ne sait pas très bien comment Android différencie cela de system qui a été renommé en privileged ), plus 3 autres.

Résumé de l'état actuel

En fait, notre situation est pire maintenant :

• Le nombre d'autorisations a été considérablement réduit, ce qui signifie une protection moins granulaire.
• de nombreuses permissions ont été déplacées au niveau normal de protection (et donc hors de portée des AppOps)
• AppOps (permission d'exécution) est plutôt cosmétique en raison de son manque de granularité et de l'absence de permissions essentielles.
• Les applications peuvent demander des autorisations supplémentaires lors d'une mise à jour. Si elles détiennent déjà une autorisation dans le même groupe, l'utilisateur n'en est pas informé (le texte "ne nécessite pas d'autorisation supplémentaire particulière" vous dit quelque chose ?) Le nombre de groupes d'autorisations ayant également été réduit, il est encore plus facile de "faire entrer quelque chose en douce".

Dans la plupart des cas, cela signifie la même chose qu'avant le MM : si vous n'aimez pas qu'une application ait une certaine permission, ne l'installez pas.

Comment y faire face du point de vue de l'utilisateur ?

Plusieurs des éléments de la liste incomplète suivante peuvent s'appliquer simultanément. Faites votre choix :

• Ne faites pas de mise à jour au-delà de LP si vous n'aimez pas cela (et si vous pouvez vivre en restant sur LP). C'est ce que je fais, jusqu'à ce que ce gâchis ait été nettoyé.
• N'installez pas d'applications si vous ne voulez pas leur donner accès à ce qu'elles demandent.
• Lorsque vous installez une mise à jour, ne vous fiez pas à l'indication "aucune autorisation supplémentaire". Vérifiez en détail avant d'appliquer la mise à jour. Ce n'est plus aussi facile qu'avant, car normalement, vous ne voyez pas côte à côte quelles sont les autorisations dont dispose déjà une application et en quoi elles diffèrent de celles demandées par la mise à jour. Dans l'application Playstore, vous pouvez toujours obtenir la liste complète en faisant défiler la page d'une application jusqu'à la fin et en cliquant sur le lien "détails des autorisations". N'ignorez pas la section "Autres" à la fin de la liste, car elle comprend des éléments tels que INTERNET , BLUETOOTH_ADMIN et d'autres "surprises".
• Pour protéger votre appareil contre les applications malveillantes accédant à l'internet, envisagez d'utiliser un Application pare-feu . Il en existe de bons qui ne nécessitent même pas de racine et qui sont libres, tels que Netguard .
• si Root est une option, et que l'installation du framework XPosed l'est aussi (les deux sont disponibles pour MM, mais l'installation peut devenir assez délicate avec N), utilisez un fichier de type gestionnaire de permissions comme Xprivacy pour un contrôle granulaire des autorisations.

1 : _{Évidemment, l'utilisateur ne doit pas être "surchargé". Néanmoins, il pourrait y avoir un "mode avancé" pour y faire face.}