Discussion :

[Stéphane le calme]

Google pourrait supprimer de nombreuses applications qui s'appuient sur les services d'accessibilité,
d'ici le mois de décembre

Le service Android Accessibility est une API Android conçue pour aider les développeurs à créer des applications pour des personnes malvoyantes, malentendantes ou souffrant d’un handicap gênant l’utilisation du smartphone. L'API fonctionne en déclenchant des actions qui, dans des circonstances normales, nécessitent une interaction physique de l'utilisateur. Par exemple, le service d'accessibilité peut remplir automatiquement des mots de passe et champs de texte, copier du contenu sur le presse-papier, automatiser certaines tâches, parcourir les éléments sur l’interface utilisateur, etc.

Comme Google le précise dans le blog des développeurs Android, « Les services d'accessibilité ne doivent être utilisés que pour aider les utilisateurs handicapés à utiliser des appareils et des applications Android. Ils s'exécutent en arrière-plan et reçoivent des rappels du système lorsque AccessibilityEvents est déclenché. De tels événements indiquent une certaine transition d'état dans l'interface utilisateur, par exemple, le focus a changé, un bouton a été cliqué, etc. Un tel service peut éventuellement demander la possibilité d'interroger le contenu de la fenêtre active. Le développement d'un service d'accessibilité nécessite l'extension de cette classe et l'implémentation de ses méthodes abstraites. »

Il s’agit donc là d’une fonctionnalité très puissante, que les auteurs de logiciels malveillants ont également remarquée et incorporée dans leurs applications malveillantes. En effet, une fois qu’une application malveillante reçoit une telle autorisation, la partie est terminée dans la mesure où elle peut alors s’installer comme administrateur de l’appareil. En tant qu’administrateur, elle peut télécharger d’autres applications et exécuter différentes opérations en arrière-plan.

Raison pour laquelle Google a décidé de procéder à un changement dans les conditions d'utilisation des services d'accessibilité d'Android. Dans un courriel envoyé à certains développeurs, l’entreprise a annoncé qu’ils doivent désormais justifier l'utilisation de ces services qui, jusque-là, étaient disponibles pour tous : « les applications requérant les services d’accessibilité doivent uniquement être utilisées pour aider les utilisateurs avec des handicaps à se servir des appareils et applications Android », a insisté Google.

«  Action requise : si vous ne l’avez pas déjà fait, vous devez expliquer aux utilisateurs comment votre application utilise "android.permission.BIND_ACCESSIBILITY_SERVICE“ pour aider les utilisateurs handicapés à utiliser des appareils et applications Android. Les applications qui ne parviennent pas à répondre à cette exigence pourraient être supprimées de Google Play. Toutefois, vous pourrez retirer toutes requêtes pour les services d’accessibilité de votre application. Vous pouvez également choisir de supprimer votre application. »

Une annonce qui vise donc indirectement des applications comme LastPass, Tasker, Cerberus et Universal Copy, qui utilisent toutes l'API susmentionnée. Les développeurs devront alors trouver des solutions de contournement pour leurs applications ou supprimer certaines fonctions afin d'éviter à leurs applications d’être éjectées de Play Store. Certaines fonctionnalités, telles que la capacité de LastPass à remplir automatiquement les mots de passe, peuvent utiliser des fonctionnalités plus récentes qui sont livrées avec la dernière version d'Android. Cependant, cela signifie que cette solution ne pourra pas marcher sur des appareils tournant sur des versions plus anciennes de la plateforme.

« Malheureusement, comme leur décision de supprimer les superpositions de systèmes sur Oreo, cette décision prend tout son sens quand vous considérez qu'ils font pour le mieux afin de contrôler les fonctionnalités des applications Android, empêchant les applications de voler les données des utilisateurs à leur insu. Ce qui est un problème assez important pour eux », a commenté le développeur James Fenn. « Cela dit, j'espère qu'ils trouveront un autre moyen de régler ce problème sans avoir à supprimer des centaines de bonnes applications utiles du Play Store. »

Source : blog développeur Android, BC

[gagouze2]

Bravo les mec

c'est encore les handicapée qui vont en faire les frais !!!!!

[Volgaan]

Bravo les mec

c'est encore les handicapée qui vont en faire les frais !!!!!

Si les développeurs expliquent clairement pourquoi ils ont besoin de cette autorisation et que c'est justifié, alors ils ne craignent rien. Du coup, je ne vois pas bien où est le problème ?

[CoderInTheDark]

Bonjour,

J’interviens un peu tard, mais bon.

Cette situation n’est pas si problématique pour l’accessibilité.
Et ça répond à une de mes interrogation, à savoir « L’accessibilité peut-elle rentrer en conflit avec la sécurité ? ».

La sécurité est une contrainte pour tout le monde, et parfois plus pour les utilisateurs en situation de handicap.

Un exemple concret les catchas.
Un catcha image est parfois très dur à valider par les utilisateurs voyants, encore plus pour les malvoyants, et impossible pour les non-voyants.
L’alternative est le catcha audio, pas si rependu, et pas toujours facile à comprendre, car il y a un bruit de fond parasite pour compliquer la tâche des robots.

Et les nouveaux catchas sémantique (je ne connais pas leur vrai noms), qui demandent de cliquer sur les images de montagne ou de bord de mer, sont encore pire.
Et globalement les catchas compliquent surtout la vie des humains.
Alors il faut demander à une personne voyante de le faire pour vous.
Donc affaiblissement de la sécurité, car il faut déléguer à un tiers de confiance.

Un autre exemple des sites bancaires utilisent des claviers à placement aléatoire des chiffres avec des images, pour composer le code secret.
Ceci pour couper l’Herve sous le pied des robots.
Mais les lecteurs d’écrans se comportent comme des robots.
Alors il faut proposer une alternative moins sécurisé avec un clavier dont les chiffres sont vocalisables pour les utilisateurs de lecteurs d’écran.
Donc affaiblissement de la sécurité.

Et c’est là que peuvent s’engouffrer les hackers, pour profiter de la situation.
On a affaiblit la sécurité pour améliorer l’accessibilité.
C’est le problème soulevé par Google.

Mais dans le cas présent il n’y a pas une véritable régression de l’accessibilité.
Car je pense que dans la pratique tout utilisateur devrait rentrer son mot de passe et ne pas le stocké, car le risque est trop grand.
Il faut juste que l’interface soit accessible et sécurisé, mais c’est problématique.

Par exemple avec mon i-phone, quand je rentre mon code pin, je mets le doigt sur le chiffre.
Le lecteur d’écran (voice over) me dit le chiffre, je tape il me dit les lettres correspondantes (2 Abc, 3 def,…), pour me confirmer.
J’ai besoin de savoir sur quoi j’ai tapé.
Mais pour la discrétion on repassera, c’est comme si on regardait par-dessus mon épaule.
Mais je n’ai pas le choix, sinon je ne peux pas saisir mon code.
Et je tiens à ce que mon téléphone soit verrouillé.
Je fais attention et je baisse le son.

Un autre cas que je n’ai pas pu résoudre.
J’ai voulu essayé Fedora, après l’avoir installé, avec l’aide d’un tiers.
Je n’ai jamais pu l’utiliser.
Car la sécurité bloquait le lecteur d’écrans. Le lecteur d’écran écoute la frappe au clavier, en autre pour vocaliser la frappe au clavier(écho de la frappe) et utilise beaucoup de raccourcis clavier pour permettre la navigation.
Pour le système il s’agissait d’un key logger.