Discussion :

[Cedric Chevalier]

Google supprime une fonctionnalité vitale pour la protection de la vie privée dans Android 4.4.2
l’EFF réagit

Enfin ! Les utilisateurs d’Android avaient le pouvoir de dicter leur loi aux applications installées sur leur smartphone. L’élément à l’origine de cette prise de contrôle absolu : « App Ops ».

App Ops est une application qui permet de gérer les permissions des différentes applications qu’on installe sur son périphérique mobile Android. Par exemple, pour l’application sidecar, App Ops donne la possibilité à l’utilisateur d’empêcher que ne soient collectées ses données de géolocalisation, ou même encore que son carnet d’adresses ne soit consulté.

Les rapports de sécurité des différents acteurs majeurs dans le domaine pointent du doigt Android comme la plateforme mobile la plus touchée par les malwares. Ceci en grande partie à cause de la gestion chaotique des permissions des applications.

La venue d’App Ops, disponible sous Android 4.3 (Jelly Bean) et KiKat, était d’un intérêt capital pour le contrôle de la vie privée des utilisateurs. L’introduction de cette fonction avait été saluée par l'Electronic Frontier Foundation (EFF). Cependant, les utilisateurs ont noté son absence dans la mise à jour Android 4.4.2.

L’EFF a interrogé le géant de Mountain View sur la disparition subite de cette application. Ce à quoi Google a répondu : « C’était juste une fonctionnalité expérimentale qui pouvait nuire au bon fonctionnement des applications ».

Des questions se posent alors : pourquoi n’avoir pas fait une mise à jour en bonne et due forme d’App Ops ? Des enjeux économiques importants seraient-ils derrière la disparition d’App Ops ? La confidentialité des données des utilisateurs aurait-elle réellement de l’importance aux yeux de Google ?

On espère seulement qu’il s’agisse d’un malentendu et qu’App Ops fera rapidement son « come back ».

Source : EFF

Et vous ?

Qu'en pensez-vous ?

[Arnard]

On espère seulement qu’il s’agisse d’un malentendu et qu’App Ops fera rapidement son « come back ».

Ahahah, pourquoi pas après tout, c'est bientôt noël, on peut rêver....

Avant que Google propose vraiment une fonctionnalité de ce type, il va passer du temps à mon avis. Si on craint pour ses données, il me semble que le projet Cyanogenmod était en train de mettre en place une telle feature. Je ne sais pas ce qu'il en est de la réalisation au final

[HardBlues]

Plus ça va plus Google m’exaspère, j'aimerai vraiment que le père Noel fasse quelque chose pour qu'on puisse bientôt avoir un vrai système libre sur Smartphone

[Atem18]

Il me semble avoir lu que Google allait réintroduire cette fonctionnalité, mais en version stable.

[Roadkiller]

Plus ça va plus Google m’exaspère, j'aimerai vraiment que le père Noel fasse quelque chose pour qu'on puisse bientôt avoir un vrai système libre sur Smartphone

Regarde du côté de Firefox OS ou de Sailfish OS

[Traroth2]

Euh, là, c'est un peu la goutte d'eau qui met le feu aux poudres. Google qui supprime une fonctionnalité, en gros, parce qu'elle permet aux utilisateurs de trop bien se protéger, à la fois des malwares et des intrusions contre leur vie privée, c'est pas acceptable. Si ce truc ne revient pas, mon prochain smartphone tournera définitivement sous FirefoxOS !

[Aiekick]

Qu'est ce qu'on est bien chez blackberry, ok on a pas beaucoup d'applis mais franchement niveau sécurité on est au top !! donc quand on voit ca le nombre d'applis importe peu...

[HardBlues]

Pour RoadKiller, je regarde mais je ne vois rien venir en France...

[martopioche]

Ok, est ce que la qualité des publication en prend autant un coup en cette veille de Noël ?

Les rapports de sécurité des différents acteurs majeurs dans le domaine pointent du doigt Android comme la plateforme mobile la plus touchée par les malwares. Ceci en grande partie à cause de la gestion chaotique des permissions des applications.

La gestion est très loin d'être "chaotique", c'est surtout que les applications peuvent accéder à énormément de privilèges. Et que personne ne fait attention à ce qu'elles demandent. Alors forcément, une lampe torche qui a besoin d'accéder au carnet d'adresse, il n'y a pas de problème de "gestion de permissions".

L’EFF a interrogé le géant de Mountain View sur la disparition subite de cette application. Ce à quoi Google a répondu : « C’était juste une fonctionnalité expérimentale qui pouvait nuire au bon fonctionnement des applications ».

Des questions se posent alors : pourquoi n’avoir pas fait une mise à jour en bonne et due forme d’App Ops ? Des enjeux économiques importants seraient-ils derrière la disparition d’App Ops ? La confidentialité des données des utilisateurs aurait-elle réellement de l’importance aux yeux de Google ?

Pardon ??? App Ops n'est pas Google, App Ops s'appuie sur la fonctionnalité que Google avait publié puis retiré. Google n'a pas à gérer le devenir d'App Ops qui se repose sur des APIs non publiés ni documentés.

Mais ce qui me dérange le plus est la formulation ici : la justification de Google ne convient pas ? Quel est le comportement des apps qui vont demander l'accès au GPS (dont la présence est confirmée par le système) et dont l'utilisateur plus malin que les autres a interdit ?

Quand à la confidentialité des données, si une app est en cause, il y a une action simple : paramètres, applications, choisir l'application et désinstaller.

[martopioche]

Euh, là, c'est un peu la goutte d'eau qui met le feu aux poudres. Google qui supprime une fonctionnalité, en gros, parce qu'elle permet aux utilisateurs de trop bien se protéger

Non, ça c'est l'interprétation des journaleux, Google la supprime car l'exploitation de cette fonctionnalité peut nuire au bon fonctionnement des apps dans l'état actuel de leur exigence.

[Jarodd]

Regarde du côté de Firefox OS ou de Sailfish OS

Cet OS est stable ? Il y a des téléphones Firefox OS vendus en France ? Je n'en ai pas trouvé.

[Invité]

La gestion est très loin d'être "chaotique", c'est surtout que les applications peuvent accéder à énormément de privilèges. Et que personne ne fait attention à ce qu'elles demandent. Alors forcément, une lampe torche qui a besoin d'accéder au carnet d'adresse, il n'y a pas de problème de "gestion de permissions".

Le problème est surtout que lors des mises à jour d'application, celles-ci vont souvent demander de plus en plus de privilèges sans apporter de nouvelles fonctionnalités visibles. Et lorsqu'on utilise une appli depuis un moment c'est très chiant de la supprimer parce qu'on ne veut pas qu'elle envoie des SMS (exemple).

Il serait tout à fait imaginable que la gestion des privilèges par application ne "casse" pas le fonctionnement d'une appli.
Je m'explique :
- si je ne veux pas qu'elle accède à mes contacts, au lieu de lui donner la liste de mes contacts lorsqu'elle le demande, on lui donne une liste vide
- si je ne veux pas qu'elle accède à mes coordonnées GPS, on lui envoie des coordonnées bidons (0, 0 par exemple)
- si je ne veux pas qu'elle envoie de sms, on lui fait utiliser un objet ayant la même interface que l'objet permettant l'envoi de SMS sauf qu'il ne fait rien
- etc

Et si malgré tout cette application ne fonctionne plus correctement après que j'ai limité ces droits, libre à moi de la supprimer ou de lui ré-accorder ces droits. Donc pour moi Google supprime bien cette fonctionnalité (expérimentale certes) sous la pression des éditeurs d'applis qui veulent pouvoir continuer d'abuser en obligeant l'utilisateur à leur accorder des droits qui ne sont pas toujours nécessaires au bon fonctionnement de leurs logiciels (par exemple je ne vois pas pourquoi Angry bird a forcément besoin de connaitre ma position pour fonctionner mais j'ai quand même envie d'y jouer sans lui donner).

[find12]

Les clients n'aiment les choses compliqués comme ça.
Ce que je pense c’est que dès fois il y’a aucune amélioration d’une version à une autre.
Et dans le cas de la suppression de la protection de la vie privée dans Android 4.2.2, c’est la vrai cata.

[martopioche]

Le problème est surtout que lors des mises à jour d'application, celles-ci vont souvent demander de plus en plus de privilèges sans apporter de nouvelles fonctionnalités visibles. Et lorsqu'on utilise une appli depuis un moment c'est très chiant de la supprimer parce qu'on ne veut pas qu'elle envoie des SMS (exemple).

Lors des mises à jour, si l'application demande de nouveaux privilèges, ceux-ci sont indiqués explicitement. Pour rappel, sous Android, une app ne peut être mise à jour automatiquement si elle demande un nouveau privilège. De même, en choisissant de "tout mettre à jour", une fenêtre informe des nouvelles demandes permettant de ne pas le faire.

Il n'y a donc pas de "gestion chaotique".

Il serait tout à fait imaginable que la gestion des privilèges par application ne "casse" pas le fonctionnement d'une appli.
Je m'explique :
- si je ne veux pas qu'elle accède à mes contacts, au lieu de lui donner la liste de mes contacts lorsqu'elle le demande, on lui donne une liste vide
- si je ne veux pas qu'elle accède à mes coordonnées GPS, on lui envoie des coordonnées bidons (0, 0 par exemple)
- si je ne veux pas qu'elle envoie de sms, on lui fait utiliser un objet ayant la même interface que l'objet permettant l'envoi de SMS sauf qu'il ne fait rien
- etc

Ces propositions ont souvent été proposées mais ne sont que du pur bricolage. Exemple simplifé : liste vide pour les contacts ? On passe sur le comportement incohérent mais si mon app fait appel au quickcontact ou au contactpicker, mon app récupère un id de contact (sauf cas extrême où un utilisateur aurai par soucis de protection de sa vie privée interdit l'accès à ses contacts aux apps de gestion de contact). J'ai un id, j'interroge le dataprovider qui donc me retourne une liste vide. Sauf que comme j'ai un id, je récupère les données du premier élément... OutOfBoundException -> plantage.

Et si malgré tout cette application ne fonctionne plus correctement après que j'ai limité ces droits, libre à moi de la supprimer ou de lui ré-accorder ces droits. Donc pour moi Google supprime bien cette fonctionnalité (expérimentale certes) sous la pression des éditeurs d'applis qui veulent pouvoir continuer d'abuser en obligeant l'utilisateur à leur accorder des droits qui ne sont pas toujours nécessaires au bon fonctionnement de leurs logiciels

Sauf que dans la pratique, l'utilisateur, qui maitrise super bien son appareil verra une app planter et une conséquence sera la mauvaise note sur le store et le flammage en règle. En tant qu'éditeur, si je me rends compte que je me fais descendre du fait du choix de SciptKiddies reposant sur une fonctionnalité mal gérée par Google, la conséquence sera de fuir la plate forme pour la concurrence. Google a conscience de ça, bien plus que la soi-disante pression des apps "abusives".

Et les posts ici sur un forum "de développeurs et d'IT pro" qui sont persuadés qu'App Ops est proposé par Google ou qui se posent la question sur le bien fondé du retrait de cette fonction confirme Google a eu raison de supprimer cette fonction.

(par exemple je ne vois pas pourquoi Angry bird a forcément besoin de connaitre ma position pour fonctionner mais j'ai quand même envie d'y jouer sans lui donner).

C'est ce que je trouve fascinant dans la dépendance aux produits futiles, c'est le fait que l'utilisateur a conscience que l'app/éditeur va abuser de sa confiance, mais préfère assouvir sa pulsion de consomateur

[Invité]

Lors des mises à jour, si l'application demande de nouveaux privilèges, ceux-ci sont indiqués explicitement. Pour rappel, sous Android, une app ne peut être mise à jour automatiquement si elle demande un nouveau privilège. De même, en choisissant de "tout mettre à jour", une fenêtre informe des nouvelles demandes permettant de ne pas le faire.

Il n'y a donc pas de "gestion chaotique".

Je ne suis pas non plus forcément d'accord avec l'expression "gestion chaotique". Je dis juste que votre raisonnement "tu n'acceptes pas d'accorder un droit => tu désinstalles" est plus compliqué à appliquer lors des mises à jour d'applis qui sont utilisées depuis longtemps.

Ces propositions ont souvent été proposées mais ne sont que du pur bricolage. Exemple simplifé : liste vide pour les contacts ? On passe sur le comportement incohérent mais si mon app fait appel au quickcontact ou au contactpicker, mon app récupère un id de contact (sauf cas extrême où un utilisateur aurai par soucis de protection de sa vie privée interdit l'accès à ses contacts aux apps de gestion de contact). J'ai un id, j'interroge le dataprovider qui donc me retourne une liste vide. Sauf que comme j'ai un id, je récupère les données du premier élément... OutOfBoundException -> plantage.

Je ne vois pas en quoi ce serait du bricolage, au contraire, ce serait mettre le choix de l'utilisateur final au coeur du système. Après la façon dont c'est implémenté peut être du bricolage. D'ailleurs l'exemple que vous donnez y fait penser : je ne vois pas pourquoi quickcontact ou contactpicker devrait forcément retourner un id ! Pourquoi y aurait-il forcément au moins un contact enregistré dans l'appareil ? Android ne fonctionne pas tant qu'on a pas saisi un contact ?

Sauf que dans la pratique, l'utilisateur, qui maitrise super bien son appareil verra une app planter et une conséquence sera la mauvaise note sur le store et le flammage en règle. En tant qu'éditeur, si je me rends compte que je me fais descendre du fait du choix de SciptKiddies reposant sur une fonctionnalité mal gérée par Google, la conséquence sera de fuir la plate forme pour la concurrence. Google a conscience de ça, bien plus que la soi-disante pression des apps "abusives".

Ou bien les éditeurs seront-ils forcés de faire en sorte de gérer les différents scenarii s'ils ne veulent pas avoir de mauvaise note. Et si les blocages de droits sont correctement implémentés ils pourraitent même être invisibles pour les applis, donc pas forcément de plantage. On pourrait même imaginer un choix à l'installation avec un argumentaire de l'éditeur du logiciel expliquant pourquoi tel ou tel droit doit être accordé et quelles fonctionnalités seraient impactées en cas de refus.
Selon moi c'est Google qui devrait intégrer cette fonctionnalité au cœur de son système (et pas SciptKiddies). Et rien ne l'oblige à "mal gérer cette fonction", ils ont les compétences pour bien le faire. Mais tu as raison, certains éditeurs le verraient d'un mauvais oeil d'où la pression des éditeurs.

Et les posts ici sur un forum "de développeurs et d'IT pro" qui sont persuadés qu'App Ops est proposé par Google ou qui se posent la question sur le bien fondé du retrait de cette fonction confirme Google a eu raison de supprimer cette fonction.

Ou bien qu'ils devraient l'implémenter eux mêmes au coeur de leur système

C'est ce que je trouve fascinant dans la dépendance aux produits futiles, c'est le fait que l'utilisateur a conscience que l'app/éditeur va abuser de sa confiance, mais préfère assouvir sa pulsion de consomateur

Je suis d'accord avec vous concernant cette attitude fascinante (et ne me sens par ailleurs pas du tout concerné). Mais ça n'a pas vraiment de rapport avec ce que j'écris vu que l'idée est de donner le pouvoir à l'utilisateur sur les données qu'il veut partager et justement plus de l'obliger à choisir entre une application et sa vie privée. Les éditeurs ont déjà assez de moyens pour se faire de l'argent que ce soit avec la vente de leurs applis, la publicité ou les paiements in-app. Pas besoin en plus de leur permettre par défaut d'imposer leurs droits contre l'utilisation de leurs applis et ainsi de récolter des données à des fins lucratives. Et s'ils l'imposent en bloquant une fonctionnalité de façon abusive, pourquoi pas une mauvaise note tiens !

[martopioche]

Je ne suis pas non plus forcément d'accord avec l'expression "gestion chaotique". Je dis juste que votre raisonnement "tu n'acceptes pas d'accorder un droit => tu désinstalles" est plus compliqué à appliquer lors des mises à jour d'applis qui sont utilisées depuis longtemps.

On est d'accord sur cette difficulté, c'est tout le bonheur de notre profession, il n'y a pas besoin de grand chose pour rendre un utilisateur captif

Je ne vois pas en quoi ce serait du bricolage, au contraire, ce serait mettre le choix de l'utilisateur final au coeur du système. Après la façon dont c'est implémenté peut être du bricolage.

C'est l'exemple d'implémentation cité que je considère être du bricolage. Dans la pratique, iOS gère ça très bien. La différence est qu'on est sur une implémentation officielle et documentée, ce qui n'est pas le cas sur Android.

D'ailleurs l'exemple que vous donnez y fait penser : je ne vois pas pourquoi quickcontact ou contactpicker devrait forcément retourner un id ! Pourquoi y aurait-il forcément au moins un contact enregistré dans l'appareil ?

Parce que c'est leur fonction... Si l'utilisateur n'a pas choisi de contact bien entendu qu'il ne renvoi rien, mais si l'utilisateur a choisi un contact, alors ils renvoient un id, ce qui est logique, c'est à l'app appelante de traiter ce dont elle a besoin du contact...

Ou bien les éditeurs seront-ils forcés de faire en sorte de gérer les différents scenarii s'ils ne veulent pas avoir de mauvaise note. Et si les blocages de droits sont correctement implémentés ils pourraitent même être invisibles pour les applis, donc pas forcément de plantage. On pourrait même imaginer un choix à l'installation avec un argumentaire de l'éditeur du logiciel expliquant pourquoi tel ou tel droit doit être accordé et quelles fonctionnalités seraient impactées en cas de refus.
Selon moi c'est Google qui devrait intégrer cette fonctionnalité au cœur de son système (et pas SciptKiddies). Et rien ne l'oblige à "mal gérer cette fonction", ils ont les compétences pour bien le faire. Mais tu as raison, certains éditeurs le verraient d'un mauvais oeil d'où la pression des éditeurs.

On parle de la situation d'aujourd'hui et aujourd'hui, ce comportement n'est pas officiel et sa gestion n'est pas documenté. Ce que vous décrivez est la situation d'iOS qui se gère très bien et que Google est certainement en train de transposer à Android comme on peut voir l'impact sur les profils limités (raison de la présence de cette fonctionnalité comme tout le monde l'a certainement déduit). Sauf que sa généralisation est très loin d'être finalisée.

Je suis d'accord avec vous concernant cette attitude fascinante (et ne me sens par ailleurs pas du tout concerné). Mais ça n'a pas vraiment de rapport avec ce que j'écris vu que l'idée est de donner le pouvoir à l'utilisateur sur les données qu'il veut partager et justement plus de l'obliger à choisir entre une application et sa vie privée. Les éditeurs ont déjà assez de moyens pour se faire de l'argent que ce soit avec la vente de leurs applis, la publicité ou les paiements in-app. Pas besoin en plus de leur permettre par défaut d'imposer leurs droits contre l'utilisation de leurs applis et ainsi de récolter des données à des fins lucratives. Et s'ils l'imposent en bloquant une fonctionnalité de façon abusive, pourquoi pas une mauvaise note tiens !

La raison pour laquelle je trouve cela fascinant, c'est qu'on retrouve ce comportement dans tous les produits de consommation. Il y a encore quelques années, un produit qui serait allé à l'encontre de ses consommateurs aurait été boycotté pour pousser le producteur à faire marche arrière. Aujourd'hui, le consommateur est si dépendant de ses produits qu'il va soit accepter ces "abus", soit préfère trouver un moyen de "patcher" lui même ce qui ne lui va pas, avec plus ou moins de succès. Au final, j'estime juste que les boites "qui abusent" auraient tord de s'en priver. Et en soi, ce n'est pas compliqué. On veut la géolocalisation pour cibler la pub ? Bon, ben si la géolocalisation est indisponible, on ne fonctionne pas, ça marche déjà avec des jeux qui ne peuvent fonctionner que si il y a du réseau.

Personnellement, si j'estime les conditions abusives, je n'installe pas.

[MathiasSeguy]

Je croyais que sur DVP y'avait que des informaticiens.
Et les gars, vous vous rendez compte de la galère des programmeurs d'applications Android pour vous faire des applications multi-versionning, multi screen, responsive, smooth. Et pour l'instant quand on demande des permissions, on les obtient toutes ou aucune, c'est la spec officielle. Imaginez maintenant que votre application, on lui dise, ah non pas d'internet, ben elle plante.
Si on ne met pas à jour les docs des développeurs, vous allez avoir un grand nombre d'applications en rade avec des bons vieux NullPointerException.
C'est pas que la fonctionnalité ne me plait pas, je la trouve super, mais de l'autre côté du code, c'est juste l'enfer.
Alors, oui, le jour où cela deviendra officiel et où tous les développeurs Android vont en pleurer pour mettre à jour leurs applications, on le mettra en place, d'ici là, c'est le meilleur moyen pour faire planter les applications.
Et puis, c'est aux utilisateurs de lire les permissions, il est responsable et possède un cerveau. C'est un peu comme les gens qui utilisent le GPS (qui appartient à l'armée américaine) et qui se plaignent que les services secrets américains puissent les suivre à la trace. Le beurre, l'argent du beurre, le sourire de la crémière.
Pour moi cette décision (de rétirer la beta) est une décision motivée par la vision côté développeur, par côté utilisateurs.

[vampirella]

Et puis, c'est aux utilisateurs de lire les permissions, il est responsable et possède un cerveau.

Et c'est au développeur de faire un code correct avec des "catch" pour gérer les NullPointerExc. et penser à tous les cas possibles, même une interruption momentanée / définitive d'Internet pour X raisons.

Si l'ensemble des applications smartphone étaient mieux codées / plus honnête, peut-être que "App Ops" n'aurait pas eu autant de succès. Un exemple parmi d'autres : l'utilisation intempestive de bande-passante / batterie pour une application n'ayant aucun besoin sur le moment d'une connexion internet.

[Hellwing]

Je croyais que sur DVP y'avait que des informaticiens.
Et les gars, vous vous rendez compte de la galère des programmeurs d'applications Android pour vous faire des applications multi-versionning, multi screen, responsive, smooth. Et pour l'instant quand on demande des permissions, on les obtient toutes ou aucune, c'est la spec officielle. Imaginez maintenant que votre application, on lui dise, ah non pas d'internet, ben elle plante.
Si on ne met pas à jour les docs des développeurs, vous allez avoir un grand nombre d'applications en rade avec des bons vieux NullPointerException.
C'est pas que la fonctionnalité ne me plait pas, je la trouve super, mais de l'autre côté du code, c'est juste l'enfer.
Alors, oui, le jour où cela deviendra officiel et où tous les développeurs Android vont en pleurer pour mettre à jour leurs applications, on le mettra en place, d'ici là, c'est le meilleur moyen pour faire planter les applications.
Et puis, c'est aux utilisateurs de lire les permissions, il est responsable et possède un cerveau. C'est un peu comme les gens qui utilisent le GPS (qui appartient à l'armée américaine) et qui se plaignent que les services secrets américains puissent les suivre à la trace. Le beurre, l'argent du beurre, le sourire de la crémière.
Pour moi cette décision (de rétirer la beta) est une décision motivée par la vision côté développeur, par côté utilisateurs.

Sur le principe je suis complètement d'accord avec toi. Mais c'est également aux développeurs (enfin plutôt les décideurs) de demander des droits cohérents avec les fonctionnalités proposées dans leurs application au lieu de demander n'importe quoi.

[Arnard]

Le problème, quand on installe une app android, c'est que l'on a droit à un catalogue de droits divers. Un truc qui serait bateau, ce serait de mettre en premier les droits que l'utilisateur peut juger critique (accès internet, accès contacts, appel, gps).

Un utilisateur de foursquare aura sûrement rien à cirer du gps lu par tout le monde par exemple. Par contre il veut facilement être sûr qu'une appli ne va pas envoyer des sms dans son dos...