Sign in with Apple : Apple devient fournisseur d’identité privée

Anthony Nelzin-Santos |

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.


avatar byte_order | 

@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...

avatar Sgt. Pepper | 

@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

avatar byte_order | 

@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.

avatar xDave | 

@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.

avatar webHAL1 | 

@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.

avatar xDave | 

@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.

avatar webHAL1 | 

@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.

avatar byte_order | 

@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.

avatar xDave | 

@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
?

avatar iDanny | 

@Yohmi

Justement j’ai suivi le lien, et je vois pas cette clause ?

avatar byte_order | 

@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...

avatar cosmoboy34 | 

@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.

avatar Yohmi | 

@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 ☺️

avatar byte_order | 

@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.

avatar webHAL1 | 

@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 ?

avatar byte_order | 

@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.

avatar webHAL1 | 

@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é.

avatar cosmoboy34 | 

@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

avatar Sgt. Pepper | 

@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

avatar LaurentR | 

Disponible sur MacOs et Ios et, mais quelle version ? Uniquement les nouvelles ou également via une mise à jour, les anciennes ?

avatar UraniumB | 

@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.

avatar Sgt. Pepper | 

@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

avatar byte_order | 

@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.

avatar UraniumB | 

@byte_order

Bonne remarque.

avatar reborn | 

@byte_order

Si l’app en question affiche une vue web pour la connection..

Pages

CONNEXION UTILISATEUR