Sign in with Apple : Apple devient fournisseur d’identité privée
Personne ne l’attendait, et c’est pourtant l’une des annonces les plus importantes de la WWDC. Avec « Sign in with Apple », Apple prend une place centrale dans votre vie numérique, en devenant une fournisseuse d’identité. Une identité brouillée, détachée des données, purement utilitaire… et hautement stratégique. « Sign in with Apple » vient contrecarrer les plans de Google, de Facebook, et tous ceux qui cherchent à enfoncer un coin entre Apple et ses clients.
« Sign in with Apple » peut être utilisé par toutes les applications proposant un formulaire de connexion, mais doit être utilisé par les applications intégrant des systèmes d’identification comme « Google Sign-in » ou « Facebook Connect ». Dans ce cas, le bouton « Sign in with Apple » doit être aussi grand que les autres, et placé le plus haut possible. L’apparence et le texte du bouton peuvent être (légèrement) personnalisés.
La création d’un compte est aussi simple qu’un paiement avec Apple Pay. Appuyez sur le bouton « Sign in with Apple » : le système génère un identifiant de compte unique, et vous présente une fenêtre modale, qui contient déjà votre nom. Ne vous reste qu’un choix, celui de fournir votre adresse e-mail, auquel cas le développeur peut retrouver un éventuel compte préexistant, ou bien d’utiliser une adresse relais fournie par Apple.
Apple invite les développeurs à reconsidérer leurs pratiques. Ont-ils vraiment besoin de récupérer le nom et l’adresse e-mail ? Dans certains cas, l’identifiant unique devrait suffire. L’adresse e-mail permet certes de fournir une assistance au client, mais aussi de l’inonder de courriers indésirables. Autoriser l’un tout en prévenant l’autre, c’est l’objectif des adresses relais.
D’abord parce que le relai fonctionne dans les deux sens. Le développeur ne voit que l’adresse relais, mais vous recevez son courrier dans votre « vraie » boite de réception. Le risque serait que vous dévoiliez votre adresse en répondant, mais toutes vos communications sont couvertes par le relai. Apple ne conserve aucune information, et les messages sont supprimés des boites relais dès qu’ils ont été distribués.
Ensuite parce que le relai est exclusif et temporaire. À chaque fois que vous créez un compte dans une nouvelle application, « Sign in with Apple » crée une nouvelle adresse relais unique. Vous recevez des messages indésirables par le biais d’une adresse relais ? Vous pouvez identifier l’application fautive, et révoquer le relai.
Identifiant unique, nom, adresse… mais où est passé le mot de passe ? C’est bien simple : il n’y en a pas. Vos données d’authentification sont enregistrées dans le Trousseau iCloud, verrouillé par votre mot de passe iCloud et (normalement) protégé par l’identification à deux facteurs d’Apple. Sur un nouvel appareil, vous pourrez vous connecter avec Touch ID ou Face ID, dans chaque application.
« Sign in with Apple » protège l’utilisateur, mais aussi le développeur. Le comportement de l’utilisateur et les données de l’appareil sont analysés, sur l’appareil lui-même, pour tenter d’identifier les comptes suspicieux et les robots. Apple n’empêche pas l’inscription, mais envoie l’information au développeur, sous la forme d’un simple bit d’avertissement. À lui d’agir en conséquence.
Comme Apple Pay, « Sign in with Apple » vise à sécuriser la transaction que représente la création d’un compte, mais aussi à la repousser. Apple conseille ainsi de « retarder l’inscription aussi longtemps que possible », et dans le cas d’une application de vente en ligne, d’« attendre que le client ait effectué un achat avant de lui demander de créer un compte ».
Après quelques mois de tests, « Sign in with Apple » sera disponible cet automne sur macOS, iOS et iPadOS, ainsi que watchOS et tvOS. Mais aussi le web, et même les applications Android et Windows, avec une implémentation JavaScript. Dans Safari, « Sign in with Apple » fonctionnera comme Apple Pay, et l’inscription pourra être validée avec le capteur Touch ID intégré ou les appareils environnants.
@Sgt. Pepper
Ne soyez pas naif. Si d'ici 2 ou 3 ans Apple constate que 80% des utilisateurs de iOS choisissent "Sign In with Apple", vous pariez combien que de "obligatoire de proposer *aussi* Sign In with Apple" cela passera à "*que*" ?!
La concurrence c'est d'avoir le choix.
Y compris de ne pas faire un choix particulier.
Imposer un truc, c'est de facto réduire le choix.
Ici, des développeurs, donc. En s'appuyant sur le monopole sur la distribution de leurs apps iOS.
Sans l'imposer mais en en faisant une large promotion des avantages au grand public, une grosse partie des utilisateurs demanderaient probablement d'eux même le support de ce service d'anonymisation d'ID, et qui dit demande dit offre.
Mais convaincre c'est risqué, mieux vaut imposer un truc. Enfin, quand c'est dans votre ADN et que vous pouvez abuser d'une situation de monopole...
@byte_order
Plus de choix = (pour vous ) moins de choix ?
On verra , on peut tout imaginer
mais pout l’instant en tant qu’utilisateur je suis ravis d’avoir le choix
@Sgt. Pepper
> Plus de choix = (pour vous ) moins de choix ?
C'est plus de choix pour l'utilisateur final.
Mais c'est moins de choix pour le développeur :
avant :
- je peux choisir de mettre que le système d'authentification Single Sign-In qui me plait
après
- je *dois* mettre obligatoirement le système d'authentification Single Sign-In d'Apple en plus de ce que je choisi. Et mettre celui d'Apple en tête de liste.
C'est donc bien, pour le développeur, *moins* de choix.
> mais pout l’instant en tant qu’utilisateur je suis ravis d’avoir le choix
Mais y'a pas que la position de l'utilisateur en jeu ici. Qui a toujours eu le choix d'accepter ou pas d'utiliser telle méthode Single Sign In ou même de refuser d'utiliser l'app ou le site, faisant ainsi jouer la concurrence et l'offre et la demande.
Ce n'est pas la position du développeur désormais, a qui on refuse les mécanismes de libre concurrence. Grace à l'abus de l'exclusivité d'Apple sur la distribution d'app iOS, et donc sur leur existence même.
@webHAL1
Je ne suis pas juriste mais Apple n’impose pas sa solution pour être précis.
Elle impose en revanche de donner le choix à l’utilisateur de pouvoir l’utiliser Si et seulement si l’application propose un système « identique ».
Par exemple, certains sites ou applications ne proposent qu’une seule possibilité en plus du login/mdp classique voire uniquement un système tel. Genre s’identifier avec son compte Facebook.
Si on en a pas, on est marron.
J’aime bien la recommandation de s’identifier le plus tard possible, ça va en calmer quelques uns.
@xDave
« [...] Apple n’impose pas sa solution pour être précis. Elle impose en revanche de donner le choix à l’utilisateur de pouvoir l’utiliser si et seulement si l’application propose un système "identique". »
Donc elle l'impose, il n'y a pas moyen de le dire autrement.
Un développeur qui est content avec la solution d'authentification de Google ne pourra plus la proposer sans également offrir celle d'Apple, avec le développement et le support en plus que cela représente.
« Par exemple, certains sites ou applications ne proposent qu’une seule possibilité en plus du login/mdp classique voire uniquement un système tel. Genre s’identifier avec son compte Facebook. Si on en a pas, on est marron. »
Oui, et ? On a le choix de ne pas utiliser ses sites ou applications.
Un développeur pouvait choisir les systèmes d'authentification qu'il souhaitait proposer. Plus maintenant, où il se retrouve forcé, s'il veut offrir celui de Google et/ou Facebook, à devoir prendre en charge celui d'Apple.
Encore une fois, la Pomme impose ses pratiques sur sa boutique pour affaiblir la concurrence.
@webHAL1
Je parlais de l’imposer à l’utilisateur final.
Quant aux devs qui m’imposent Facebook je leur dit ?. Je n’ai et n’aurais jamais de compte FB.
@xDave
« Je parlais de l’imposer à l’utilisateur final. »
Et moi je parlais des développeurs.
Comme l'a dit byte_order, l'utilisateur final a toujours eu le choix. Ici, le développeur ne l'aura plus et par extension l'utilisateur final se verra également imposer quelque chose. Admettons que la fenêtre de connexion prenne toute la hauteur de l'écran, la seule méthode d'authentification qui sera visible sans scroller sera celle d'Apple. Même si le développeur aimerait mettre celle de Google ou Facebook en premier, puisqu'elles comptent infiniment plus de clients et donc seront plus demandées, il ne pourra pas le faire.
@xDave
> Je ne suis pas juriste mais Apple n’impose pas sa solution pour être précis.
> Elle impose en revanche de donner le choix à l’utilisateur de pouvoir l’utiliser
> Si et seulement si l’application propose un système « identique ».
*Et* de positionner celle d'Apple le plus haut possible. En premier, quoi. En tête de gondole, quoi.
Ce qui me semble pas franchement relever ni du libre choix pour le développeur ni du respect de la libre concurrence.
@byte_order
Ah pour le coup de la tête de gondole, je ne peux qu’acquiescer.
On va dire qu’Apple impose aux devs une alternative
?
@Yohmi
Justement j’ai suivi le lien, et je vois pas cette clause ?
@Yohmi
> Dans ce cas, le bouton « Sign in with Apple » doit être aussi grand que les autres,
> et placé le plus haut possible.
Le plus haut possible = "en premier", quoi.
Si ça c'est pas la définition d'une déformation de la concurrence...
@Yohmi
Mais ça implique de renoncer à avoir un accès direct à ses clients et de laisser un contrôle total sur ce que le client peut donner comme info ou pas ou même stopper complètement les transferts d’info sans que le site ou appli puisque y faire quelque chose. Aujourd’hui si un client supprime son compte il reçoit plein de spams pour l’inciter à revenir. Sans compter tous les sites qui vendent ces informations pour rentabiliser leur base client.
@cosmoboy34
Le but c’est justement que ça ne se passe plus comme ça. Dans sa course à la différenciation, Apple cherche à faire tout le contraire de Google et, par voie de conséquence, s’affaire à limiter ce modèle économique de la récolte et vente de données à l’insu des utilisateurs. C’est un sale modèle économique, et c’est donc une bonne chose de s’y attaquer.
Les développeurs auront toujours accès à certaines données (car c’est important de comprendre qui sont les consommateurs et quels sont leurs comportements) et pourront toujours en demander davantage à leurs utilisateurs. Mais ni Facebook ni Google y auront accès.
Je suis abonné à une newsletter dont le lien de désinscription est inutilisable. C’est typiquement le genre de cas que j’espère pouvoir facilement éviter avec la généralisation de ce type de système ☺️
@Yohmi
> Apple cherche à faire tout le contraire de Google et, par voie de conséquence,
> s’affaire à limiter ce modèle économique de la récolte et vente de données à
> l’insu des utilisateurs.
Ne citez pas Google alors, car y'a vraiment rien qui se fait à l'insu de l'utilisateur quand une app ou un site veut acceder au profil d'un compte Google : l'utilisateur voit forcément une fenêtre qui lui indique le nom de l'app/site web, les autorisations qu'il demande sur son compte. Qui peuvent par ailleurs être annulées à n'importe quel moment.
Pour Facebook, je connais pas, mais cela me semble déjà nettement moins clair et vu l'historique de FB, je pense sincèrement qu'il y a effectivement plus de "à l'insu".
Mais c'est surtout le cas bien plus fréquents encore d'apps ou sites qui vous demandent "simplement" de vous connecter avec *votre* adresse mail, qu'ils vérifient ensuite via une demande de validation *et* qui revendent alors votre adresse email - vérifiée comme active, donc avec de la valeur - et ce, là, sans votre accord et sans vous en avoir prévenu.
@mapiolca
« La question est de savoir si les applications vont l’intégrer [...] »
C'est ce que cet article semble avoir passé sous silence. Un système d'authentification que personne n'utilise ne sert à rien.
Quel va être l'intérêt des services en ligne de proposer de se connecter via un moyen qui anonymise l'utilisateur pour eux ?
@webHAL1
C'est bien pourquoi Apple a décidé d'utiliser son monopole sur la distribution d'apps iOS pour le leur imposer. En pariant que sa clientèle, au taux de confiance envers Apple assez élevé, fera le reste, en choisissant massivement désormais d'utiliser Sign In With Apple.
@byte_order
« C'est bien pourquoi Apple a décidé d'utiliser son monopole sur la distribution d'apps iOS pour le leur imposer. »
Exactement. Tout comme elle fait en sorte de limiter au maximum l'information à l'intérieur des applications qui proposent un service payant comme quoi il pourrait être acheté autrement que via un achat intégré.
@mapiolca
Je me dis la même chose. C’est génial tout ça mais encore faut il que les dev adoptent cette technologie et renoncent à capter toutes les informations que leur donnent Facebook ou Google. Pas sûr qu’une majorité soit prête à ça encore
@mapiolca
Ce n’est pas vraiment le but d’empêcher la collecte de data qui continura comme avant...
Je vois plutôt cela comme
1) une mesure de sécurité: le Service ne stocke plus d’émail/password en cas de Hack plus sûr
2) Simplification : plus d’email de vérification (lien à cliquer ) ou de processus de recovery password perdu a gérer
Disponible sur MacOs et Ios et, mais quelle version ? Uniquement les nouvelles ou également via une mise à jour, les anciennes ?
@LaurentR
Bonne question ! Si les sites sont contraints de mettre un Sign In With Apple, alors j’imagine que ce sera disponible sur toutes les plateformes de toutes les versions.
@UraniumB
Sur iOS il faudra obligatoirement utiliser le SDK d’iOS13.
Sur Web/Android , cela sera du JavaScript , donc plus universel, mais côté Trusted device, il faudra peut être aussi iOS13
@UraniumB
> Si les sites sont contraints de mettre un Sign In With Apple
Les apps iOS. Voir macOS.
Pour les sites web, je vois mal comment Apple pourrait *forcer* un site web d'utiliser son service. Jusquà preuve du contraire, Apple n'a pas de pouvoir de coercition au delà de *ses* plateformes. Et c'est pas la part de marché déclinante de Safari qui va changer quoi que ce soit.
@byte_order
Bonne remarque.
@byte_order
Si l’app en question affiche une vue web pour la connection..
@reborn
Il me semble que les webapps ne sont pas soumis aux mêmes obligations.
Et puis, bon, cela doit pas être trop compliquer de passer la validation *avec* le bouton sur la page web *puis* de modifier ladite page web pour le retirer ou le déplacer plus bas, ailleurs, en tout cas moins en tête de gondole.
Le principe même d'exiger d'être le choix en tête de gondole pose de facto problème.
D'exiger d'être dans les choix possibles, à la rigueur, c'est comme d'exiger que Microsoft propose d'installer un navigateur web parmi une liste triée aléatoirement, c'est déjà tordu, mais au final l'utilisateur garde le choix et ce choix n'est pas arbitrairement biaisé.
Quel sera le montant de la commission facturée par Apple ?
@rua negundo
Dans les 30-15% de commission ?
?
Lorsque ça va être intégré directement sur l’iPhone, sa sera vraiment simple et rapide à utilisé ?
Bien, j’imagine qu’il faut s’attendre à ce que les développeurs cessent de supporter la connexion via les réseaux sociaux, au profit de la création d’un compte sur leur app. Les applications qui prendront en compte Apple Connect se compteront sur les doigts (des deux mains, soyons généreux), dans la mesure où ça les empêcherait d’obtenir les infos personnelles. Encore un bide pour Apple! ?
@Crkm
Ben non justement, une victoire pour la vie privée et contre Facebook et Google si soudainement toutes les apps retirent leurs API ;)
@Crkm
T’as rien compris toi... ?♂️
@Crkm
Au contraire.
Les Applications qui procèdent ainsi sont obligées de proposer cette solution en plus.
Donc si ça fait suer le dev il aura le choix de n’utiliser que le login / pwd et pas uniquement le login Facebook par exemple.
Ben oui c’est bien ce que je dis. Les développeurs auront trois choix:
1)soit ils ne proposent qu’une seule méthode d’inscription, c’est à dire la méthode classique avec une adresse e-mail ou nº de tel
2)soit en plus de la méthode précédente, ils proposent aussi la connexion via réseaux sociaux ou bien Apple Connect qui empêche la récolte du nom et de l’adresse e-mail
3)soit ils ne proposent que Apple Connect
La méthode nº1 sera à mon avis largement privilégiée, car les choix 2 et 3 ne permettent pas la collecte d’informations personnelles. On aura ainsi la plupart des applis qui ne proposeront plus le login via Twitter et Facebook, la méthode d’inscription proposée sera l’adresse e-mail en grande majorité. Peu d’applis actuellement ne proposent que le login via Facebook.
Mais du coup, si j’utilise par ailleurs certains comptes sur PC, comment m’y connecter vu qu’il n’y a pas safari ?
@fanchperon
C’est du javascript ça fonctionne de partout normalement
@reborn
Mais je m’y connecte avec quoi ? Mes identifiants iCloud ? Où sont la sécurité et l’anonymat dans ce cas ?
@fanchperon
Le dev ne voit pas l’adresse icloud, il voit un alias
@fanchperon
C’est du code JavaScript .
Ce que j’ai compris:
un « overlay » Apple sera affiché pour rentrer AppleId/password Du compte Apple.
Avec une double Authent via le Trusted Device (comme pour icloud.com)
Le site web ne verra rien des données utilisées,
c’est comme une redirection vers un autre site d’Apple
(Comme pour lors d’un achat ou il y a une redirection vers une page de la banque )
@Sgt. Pepper
Ok merci pour vos explications à tous les deux !
Sous Windows (et peut-être aussi sur macOS), si l'utilisateur est dans l'impossibilité temporaire de s'identifier par son iBidule alors Sign with Apple pourrait exiger que la navigation web se fasse avec Safari, lui-même connecté à iCloud,…
Cela va faire remonter les parts de marché de Safari
@irep
Safari sous Windows??
Tu as inventé cette histoire d’exigence Apple? ?
Car Apple a déjà un process pour cela via appleid.apple.com
Ça a vraiment l’air bien ce système.
En tout cas c’est génial ! ???
C'est effectivement une petite nouveauté bienvenue. je faisais justement le tri dernièrement des comptes que j'ai pu crée depuis 10 ans ... on en cumule ! La RGPD a bien aidé à se rappeler de ces comptes !
J'espère qu'Apple offrira une page dédiée à leur gestion : répertoire des comptes, informations mises à disposition, etc etc.
Bref le fameux petit plus qu'on attend de la part d'Apple.
Vous utilisez beaucoup ces systèmes de « sign in with machin chose » ?
Ça met quand même machin chose en intermédiaire entre vous et le service pour un bénéfice que je ne comprends pas bien.
Mais bon, c’est sûrement plus moderne.
@Bigdidou
Vous utilisez beaucoup ces systèmes de « sign in with machin chose » ?
Jamais
Mais le système d’Apple si il est proposé je vais m’y intéresser.
@Bigdidou
Google et Facebook : sûrement pas ?
Mais avec Apple : je vois que des avantages
Fini les multiples Login/password côté App donc meilleur sécurité contre le piratage (combien d’accidents et de message nous demandant de changer le mdp)
Simplification: pas de nouveaux mdp, plus de lien à cliquer dans un e-mail pour vérification, recovery simplifier
Du gagnant -gagnant pour l’App et l’utilisateur ?
@Bigdidou
Souvent y a pas le choix en fait, c'est sign in with Facebook ou rien du tout!
Pages