Se connecter à une application de l’Atmosphère revient à lui donner des droits d’écriture dans son dépôt. Trois vérifications permettent à l’utilisateur de protéger son compte.
1. Vérifier la provenance de l’application
L’utilisateur ne devrait se connecter qu’à des applications dont l’équipe à l’origine est connue, a une réputation en jeu et mérite sa confiance.
Un code open-source, dont le code est disponible à la lecture de tous, ne garantit en rien l’absence de bugs ou l’absence de virus dans ses dépendances. De plus, rien ne permet de garantir que le code visible de tous est bien celui qui fonctionne sur le serveur ou dans le navigateur lors de la visite de l’utilisateur.
Cette application aura des droits d’écriture limités aux lexiques validés par
l’utilisateur, cela ne limite que la forme et non le contenu même. Par exemple,
une application reçoit le droit de stocker dans le PDS d’un utilisateur un
enregistrement app.bsky.feed.post et donc par conséquent de publier sur
le réseau de Bluesky, elle ne sera pas limitée dans ce qu’elle écrira à
l’intérieur même de la publication. Il faut donc avoir confiance que l’application
n’abusera pas de ce pouvoir et que son comportement correspond à celui attendu
pour son usage.
2. Vérifier l’URL lors de la redirection vers le PDS
Lorsque l’utilisateur se connecte, il doit entrer dans un formulaire son handle: @bob.bsky.social, ou @alice.eurosky.social ou encore son nom de domaine personnalisé: @atproto.fr. Alors l’application va déduire de ce handle le lien vers le PDS de l’utilisateur et va rediriger l’utilisateur vers celui-ci pour que, dans une communication privée Utilisateur-PDS, l’utilisateur confirme au PDS que l’application a le droit de modifier ou lire des données dans les limites proposées par l’application. Cette communication privée entre l’utilisateur et son PDS peut nécessiter que l’utilisateur s’authentifie auprès du PDS. La méthode d’authentification la plus courante étant d’entrer à nouveau son mot de passe.
Il est donc crucial pour l’utilisateur de confirmer que le service avec lequel il s’authentifie correspond bien à son PDS et que l’application ne l’a pas redirigé vers un service malveillant qui, en faisant office d’intermédiaire, intercepte le mot de passe. Pour confirmer qu’il s’agit de son PDS, l’utilisateur a pour le moment un seul moyen: vérifier correctement l’URL avant d’entrer des informations dans un formulaire.
alt
Page de connexion du PDS lors d'une connexion à Tangled : la barre d'adresse du navigateur affiche pds.atproto.fr, et la page propose de s'authentifier par passkey ou par mot de passe.
Malheureusement, chaque année plusieurs dizaines de millions de Français sont confrontés à une tentative d’hameçonnage et il est impossible de savoir dans quel état de vigilance l’utilisateur sera lorsqu’il s’authentifiera. Heureusement, pour se protéger, il existe d’autres moyens d’authentification que le formulaire de mot de passe, notamment le système dit passkey qui génère une paire de clefs rattachée au domaine et dont l’usage est donc inopérant via un autre (celui du service malveillant).
3. Vérifier les permissions
Une fois l’utilisateur redirigé vers le PDS et authentifié auprès de lui, le PDS lui indique les droits auxquels l’application demande à avoir accès. Chaque permission (ou scope) que peut demander une application est détaillée dans l’entrée Permissions.
alt
Page d'autorisation d'un PDS de Bluesky pour tangled.org : une fenêtre liste les scopes demandés, des enregistrements repo:sh.tangled.* et des appels rpc:sh.tangled.*.
La logique est de se poser la question, en relisant chaque permission :
est-il cohérent que l’application en question demande des droits sur ce
lexique en particulier ? Pourquoi, par exemple, https://tangled.org
demanderait-il des droits sur le lexique app.bsky.feed.post ?
Certaines implémentations de PDS permettent, au moment de la vérification des autorisations, d’en décocher certaines. C’est une nouvelle couche de sécurité bienvenue, qui permet à l’utilisateur de n’accorder que le minimum de droits dans le contexte d’usage qui est le sien. S’il sait que, durant cette session, il n’utilisera qu’une fonctionnalité de l’application, il peut alors limiter les droits au strict nécessaire.
alt
Page d'autorisation du PDS d'atproto.fr pour Tangled : chaque permission demandée est une case à cocher, regroupée par catégorie, que l'utilisateur peut décocher avant d'autoriser.
Au-delà de l’utilisateur
Ces trois vérifications sont à la portée de chaque utilisateur, mais elles demandent une vigilance qu’il n’est pas raisonnable d’exiger à chaque connexion. Les concepteurs de PDS et les créateurs d’applications ont un rôle important à jouer pour améliorer l’expérience utilisateur : présenter les droits demandés dans un langage compréhensible, expliquer à quoi sert chaque permission dans le contexte de l’application, et permettre de n’accorder que le nécessaire.
Voir aussi l’article Comment utiliser une app Atproto en sécurité.