Compliqué, trop exigeant, pas au point : pourquoi AnyList n'intégrera pas Connexion avec Apple
L'application de liste de courses AnyList n'intégrera pas la fonction Connexion avec Apple. Pourtant, à compter du 30 juin, toutes les applications qui proposent un système tiers (Facebook, Google, Twitter…) pour se connecter ou créer un compte dans l'app sont tenues de proposer aussi l'option Connexion avec Apple, en vertu de la règle 4.8 des guidelines.
La seule méthode de connexion tierce dans AnyList étant Facebook, cela aurait dû pousser l'éditeur à intégrer aussi Connexion avec Apple à partir de la date limite. Les développeurs de Purple Cover ont tout simplement décidé de supprimer la connexion via le réseau social, qui ne convenait plus pour des raisons de respect de la vie privée largement foulé au pied par Facebook.
Une fois Facebook sorti de l'équation, pas besoin de Connexion avec Apple. L'éditeur a décidé de s'en tenir à la seule connexion traditionnelle, qui nécessite de créer un compte en remplissant un formulaire et en laissant une adresse e-mail perso. Pour expliquer cette volonté de se passer des services de connexion d'Apple, Purple Cover avance plusieurs raisons.
Le premier argument est assez convaincant : beaucoup d'identifiants Apple sont liés à des adresses iCloud, qui servent donc d'identifiants pour Connexion avec Apple. Or, un grand nombre d'utilisateurs possédant des adresses iCloud ne vont pas consulter les messages qui leur sont adressés. La « vraie » adresse e-mail, c'est un compte Gmail ou autre, plus rarement iCloud…
Les courriels adressés par Purple Cover à des adresses iCloud reviennent à envoyer des bouteilles à la mer : ennuyeux quand il s'agit de répondre à une demande d'assistance urgente (et elles le sont toutes). « Les gens demandent de l'aide, nous répondons, et ils nous recontactent plus tard, furieux de ne pas avoir reçu de réponse », explique l'éditeur. « Notre réponse est partie sur leur adresse iCloud, mais ils ne la voient pas parce qu'ils ne regardent que leur compte Gmail, dans l'app Gmail ».
Autre difficulté avec Connexion avec Apple : le service permet d'envoyer une adresse masquée, sous la forme dpdcnf87nu@privaterelay.appleid.com, à la place de la vraie adresse iCloud. Là aussi, cela pose des problèmes pour porter assistance à un utilisateur : au cas où le support d'AnyList a besoin de regarder quelque chose dans le compte, il lui faut l'adresse ayant servi à créer ledit compte. Il est toujours possible de remettre la main dessus, mais le processus est plus long et particulièrement exigeant en temps.
Il se pose aussi la question de l'interopérabilité. Connexion avec Apple peut s'intégrer à une application Android, mais là aussi il faut se souvenir de l'adresse masquée puis demander un nouveau mot de passe auprès de l'éditeur. Par ailleurs, Apple fournit très peu de documentation sur le support du service sur Android. Enfin, cette option de masquage d'adresse est un sacré casse-tête pour les proches, qui devront utiliser l'adresse biscornue pour partager leurs listes avec l'utilisateur.
Purple Cover pointe du doigt l'immaturité du service Connexion avec Apple, d'une part le manque de documentation déjà cité, mais aussi en raison de la récente et sérieuse faille de sécurité qualifiée de « très simple » par les développeurs. La confiance n'est pas au rendez-vous (lire : Une faille de sécurité bouchée dans Connexion avec Apple).
Enfin, une autre explication toute simple est que l'équipe en charge d'AnyList n'a tout simplement pas les ressources suffisantes pour gérer un système de connexion tiers destiné à une app par essence multiplateformes. Cette réflexion sera-t-elle aussi celle d'autres petits éditeurs qui ne voudront pas s'embêter à intégrer Connexion avec Apple ? La deadline étant derrière nous, on devrait le savoir assez vite.
@Esowes
L’article mentionne aussi l’interopérabilité... avec Android notamment.
Developer un moyen de contacter le support depuis l’application me semble cela dit être une bonne solution, mais comment l’utiliser par exemple depuis un autre appareil si l’on a des difficultés de connexion ?
@dodomu
Il me semble qu’il faut se connecter à son compte Apple directement
Cette histoire n’est compréhensible que si on tient compte de deux facteurs :
- toujours rejeter la faute sur un autre qui est facilement ciblé comme étant le grand méchant loup
- mettre en valeur, par des sites comme MacG qui adorent utiliser une minorité présentée invariablement comme la majorité (pour cela les journalistes ne connaissent pas le partitifs comme des mais utilisent toujours le les : les développeurs sont remontés contre Apple quand il y en a dix sur 100.000), ces minorités bruyantes.
Toujours plus Apple est sans limite..........
!! ABUS DE POSITION DOMINANTE !!
C'est un peu comme si GOOGLE disait : "Vous voulez que votre site s'affiche dans Chrome ? Bon ben si vous proposez une connexion par facebook, proposez connexion avec Google sinon COUIC COUIC ça va couper"
@nicopulse
Oui... et non...
Les sign in avec Facebook ou Google laissent beaucoup de traces, etc. Apple veut pousser plus loin la confidentialité. C’est pour cela qu’ils imposent la prise en charge du Sign in avec Apple si l’une des méthodes concurrentes est proposée.
C’est fait à la Apple avec obligation etc mais il s’agit vraiment de combler un gros trou dans la politique de confidentialité de la pomme... l’utilisateur reste libre de ne pas l’utiliser bien sûr, mais ils partent du principe qu’il est souvent peu informé... ce qui n’est pas si faux.
« Enfin, une autre explication toute simple est que l'équipe en charge d'AnyList n'a tout simplement pas les ressources suffisantes pour gérer un système de connexion tiers ».
Tout est là en réalité.
C’est effectivement moins simple de déporter l’authentification utilisateur tout en respectant leur vie privée et se prémunir des fuites de données.
Leur décision de n’avoir qu’une authentification interne à leur appli est la plus logique. Même pas besoin de se justifier sur la complexité perçue d’une solution de SSO externe. Ça devrait aussi faire réfléchir les utilisateurs concernés par la sécurité de leurs données... Si intégrer un SSO moderne est compliqué, que cela implique-t-il sur le reste de leur architecture ?
Bon, on peut se dire qu’une liste de courses c’est pas critique.
OSEF d’anylist
Arguments bidon, franchement. OK ils ne sont que 2 ou 3, on a compris.
Le manque de ressources mouai, à la limite l'histoire du partage de listes par email je veux bien et encore il leur suffit de détecter les emails "privaterelay" et ensuite d'informer l'utilisateur que pour la fonction de partage de liste il faut renseigner leur véritable email (dans l'intérêt de l'utilisateur) et fournir un champ de saisie prévu pour ça à l'utilisateur.
Peut-etre qu'ils pourront quand-même intégrer les nouveautés d'Apple Sign in qui permet justement de "relier" l'Apple Sign in a un compte existant 🙂.
Pour avoir intégré le Sign-in with Apple sur l'application happn, certes il a eu aussi du travail côté back mais pas énormément non plus et ce travail été surtout lié au fait que nous faisons du merge de compte automatique pour éviter les doublons etc..
Bref de mon côté l'intégration a été très rapide/simple et c'est faite sur 2 semaines, et si je devais ramener ça a uniquement du temps de dev on serait presque sur 1 semaine + 2/3 aprem de tests en QA.
Je me demande les pauvres utilisateurs qui se sont connecté avec Facebook comment ça va se passé... Mais Anylist c’est vraiment de la mauvaise foi. On peut créer un compte Apple avec Gmail et on utilisant le Sign with Apple, on le fait avec Gmail et on reçoit les mails sur la boîte gmail,... Des développeurs que je connais m’ont dit que c’était d’une facilité infantile. Pour se connecter sur Android, il me semble avoir vu qu’il faut se connecter à son compte Apple directement
Ah mince, moi c'est mon adresse iCloud (enfin… mac.com en fait, na na narle d'un temps que les moins de 20 ans…) qui est la principale et gmail la poubelle où je ne vais jamais.
Je ne suis donc pas normal, c'est affreux !
Pages