Si le contenu des échanges échappe de mieux en mieux aux regards extérieurs, l’accès aux services continue de dépendre de données comme l’adresse IP, le navigateur ou le comportement de navigation, mobilisées pour juger de la légitimité d’une requête, au prix d’une confidentialité tronquée.
Le chiffrement du trafic a longtemps concentré l’essentiel des débats sur la confidentialité en ligne. Le sujet principal, c’était le contenu des échanges. Est-ce qu’un tiers peut voir ce que vous lisez ? Ce que vous envoyez ? Ce que vous cherchez ? Ce que vous téléchargez ? Le chiffrement a apporté une réponse satisfaisante à ces questions, et il a profondément changé la face du web. Toujours est-il qu’avant même de consulter une page, créer un compte, publier un message ou retourner un formulaire, les services en ligne cherchent encore à obtenir des preuves de légitimité. Pour trancher, ils s’appuient non seulement sur des CAPTCHA, mais aussi sur toute une série de signaux techniques qu’ils croisent entre eux, et qui participent déjà d’une forme d’identification, alors même que les technologies disponibles permettent désormais d’envisager des formes de vérification moins intrusives.
Pourquoi (et comment) le web vous demande encore de faire vos preuves
Si les CAPTCHA se sont imposés partout, ce n’est pas par sadisme pur, même si l’expérience donne parfois l’impression inverse. À mesure que le trafic s’est densifié et que les usages automatisés se sont multipliés, les services en ligne ont eu de plus en plus de mal à distinguer, dans un flot continu de requêtes, ce qui relève d’un usage légitime, d’une automatisation tolérable ou d’un comportement réellement malveillant.
Il a donc fallu inventer un outil capable de ralentir les scripts, les requêtes massives ou d’autres formes d’automatisation sans bloquer complètement les internautes de bonne foi. Cet outil, vous le connaissez, c’est le CAPTCHA, qui repose sur une idée très rudimentaire, celle de soumettre un petit test qu’un humain peut en principe franchir plus facilement qu’un programme.
Mais cette rustine a très vite montré ses limites. D’une part, parce qu’elle fatigue tout le monde. D’autre part, parce qu’elle ne règle pas grand-chose sur le fond. Les bots se perfectionnent, les tests se complexifient (le bout du guidon qui dépasse, ça compte pour le vélo ou pas ?), si bien que les sites ont fini par doubler ces défis visibles de contrôles plus discrets, mais aussi plus intrusifs. Le navigateur, l’adresse IP, le rythme de navigation, certains éléments techniques relatifs à l’appareil ou à l’environnement logiciel peuvent aujourd’hui entrer dans l’équation pour tenter d’évaluer la légitimité d’une requête.
Toutes ces données relèvent déjà de l’empreinte numérique de l’internaute. Une fois croisées, elles permettent de dresser un tableau suffisamment précis pour que la tentation soit grande, côté services en ligne, de les exploiter à des fins de suivi, de catégorisation ou d’analyse plus poussée. Que le trafic soit chiffré ou non ne change alors pas grand-chose au prix informationnel qu’il faut parfois payer pour avoir simplement le droit d’accéder à ces sites et plateformes.
Privacy Pass, un standard pour dissocier la preuve de l’identité
Faut-il pour autant se résigner à admettre qu’accéder à un service en ligne revient forcément à céder une part non négligeable de sa confidentialité ? Pas tout à fait. Depuis le début des années 2020, on a vu émerger des dispositifs cherchant à corriger le tir, à l’image des Private Access Tokens chez Apple ou des Private State Tokens (anciennement Trust Tokens) chez Google.
Pour autant, l’idée remonte à plus loin encore. Elle est formulée dès la fin des années 2010 avec Privacy Pass, qui a pour lui un atout de taille. Là où les déclinaisons proposées par Apple ou Google restent liées à des écosystèmes ou à des implémentations spécifiques, Privacy Pass évolue dans un cadre standardisé par l’IETF en 2024, ouvert, sur lequel plusieurs acteurs peuvent en théorie s’appuyer pour dissocier la preuve de l’identité sans faire reposer tout le modèle sur une solution maison.
Mais qu’est-ce donc que Privacy Pass exactement ? C’est un dispositif de preuve cryptographique fondé sur des jetons. Son but n’est pas de révéler précisément qui vous êtes, mais de permettre à votre navigateur ou à votre application de montrer qu’une requête peut être jugée légitime sans repasser par une vérification plus lourde. Un acteur de confiance émet ce jeton en amont, puis le client le présente au service web au moment où celui-ci doit décider s’il accepte la requête telle quelle ou s’il impose un contrôle supplémentaire.
Un tel jeton peut alors tenir lieu de preuve suffisante et éviter, dans certains cas, de repasser par le duo CAPTCHA + ribambelle d’indices techniques glanés au passage. Le service ne renonce pas à vérifier, mais il n’a plus, en théorie du moins, à fonder chaque autorisation sur une collecte aussi dense d’éléments relatifs au contexte technique ou comportemental du visiteur. C’est sur cette technologie que s’appuient notamment les fameux Private Access Tokens d’Apple, et que rejoint aussi Turnstile chez Cloudflare.
Une avancée réelle, mais pas une solution magique
Bref, pour l’internaute, c’est tout bénef. Moins de CAPTCHA qui confinent parfois à l’absurde, et un dispositif potentiellement moins intrusif du point de vue des données mobilisées pour exercer les vérifications.
Il serait pourtant trompeur de présenter Privacy Pass comme l’acte de naissance d’un web soudainement purgé de ses (mauvaises) habitudes de surveillance. Le système ne supprime ni les logiques de tri, ni les politiques anti-abus, ni les décisions de confiance prises par les services.
D’abord parce qu’un jeton de confiance n’est pas une preuve universelle. Il ne vaut que dans un cadre donné, à certaines conditions, et parce qu’un acteur a, à un moment ou à un autre, décidé qu’il pouvait être émis. Privacy Pass peut alléger la répétition des contrôles, pas abolir le besoin d’évaluer, de filtrer, de trancher.
Ensuite parce que la confidentialité promise par ces architectures repose sur des conditions de déploiement très précises, à savoir la séparation effective des rôles. Tout l’intérêt du système repose sur le fait que l’émetteur, le client et le service qui vérifie la requête n’ont ni les mêmes informations, ni la même capacité à les rapprocher. Si les acteurs impliqués partagent trop de données, ou si d’autres canaux permettent malgré tout de corréler les informations, le dispositif perd sa raison d’être.
Reste enfin qu’en réduisant la collecte locale de signaux sur chaque site, on peut aussi déplacer la confiance vers un petit nombre d’acteurs capables d’émettre ces preuves, au risque de renforcer la dépendance du web à quelques grandes infrastructures déjà en position dominante.
