À tous ceux qui pensent encore que l'usurpation de nom de domaine n'est pas un problème catastrophique nécessitant une action immédiate, je n'ai qu'un mot à dire : Methbot. Créé par un groupe de fraudeurs à l'étranger, Methbot a usurpé l'identité de 6 000 éditeurs, escroquant ainsi les blogs de marketing (et les éditeurs qui auraient dû percevoir ces revenus) d'environ 3 à 5 millions de dollars par jour.
Et le problème ne semble pas s’atténuer. En septembre 2017, le Financial Times a publié les résultats de son enquête sur l’usurpation de domaine visant son propre site. À sa grande consternation, l’éditeur a découvert « des publicités display diffusées sur des espaces publicitaires se faisant passer pour FT.com sur 10 plateformes publicitaires distinctes, ainsi que des publicités vidéo sur 15 plateformes, alors même que le FT ne vend même pas de publicités vidéo de manière programmatique » (c’est moi qui souligne). 3
Même s'il est difficile d'évaluer avec précision le montant des sommes détournées chaque année, on peut affirmer sans se tromper qu'il s'agit d'un phénomène criminel se chiffrant en milliards de dollars, contre lequel les forces de l'ordre ont largement laissé les victimes se battre seules. Heureusement, nous disposons désormais d'une stratégie qui peut grandement contribuer à y remédier : ads.txt.
Qu'est-ce que le fichier ads.txt ?
Le fichier Ads.txt est le résultat direct d’un projet de l’IAB visant à mettre fin à l’usurpation de domaine grâce à la transparence. Comme l’explique l’IAB : « Ads.txt signifie “Authorized Digital Sellers” (vendeurs numériques autorisés) et constitue une méthode simple, flexible et sécurisée que les éditeurs et les distributeurs peuvent utiliser pour déclarer publiquement les entreprises qu’ils autorisent à vendre leur inventaire numérique. » 4
Concrètement, le fichier ads.txt permet à l'éditeur d'indiquer explicitement aux plateformes côté demande (DSP) les entités qu'il a autorisées à vendre ou à revendre son inventaire. Ainsi, chaque fois qu'une DSP participant au protocole ads.txt ou l'appliquant reçoit une demande d'enchère provenant d'une place de marché publicitaire, elle peut vérifier si ce vendeur est bien autorisé à vendre l'inventaire de cet éditeur. Si ce n'est pas le cas, cette demande est ignorée.
Comment les éditeurs indiquent-ils aux DSP quels sont leurs revendeurs numériques agréés ?
C'est d'une simplicité déconcertante : il suffit aux éditeurs de publier le fichier « /ads.txt » sur leur domaine racine et, si nécessaire, sur leurs sous-domaines. Ce fichier répertorie tous les vendeurs et revendeurs autorisés, accompagnés d'un identifiant unique (attribué par la plateforme SSP) pour chaque vendeur et revendeur associé à l'éditeur. Ce sont ces identifiants qui indiquent à la plateforme DSP si le vendeur entretient ou non une relation directe ou indirecte avec l'éditeur.
Cela signifie-t-il que les DSP doivent collecter de manière proactive tous les fichiers ads.txt de chaque éditeur ?
Oui, mais c'est plus simple qu'il n'y paraît. Ces listes sont facilement accessibles sur les sites de tous les éditeurs qui en disposent. L'URL correspond à la page d'accueil de l'éditeur, suivie de « /ads.txt » : publisher.com/ads.txt
Par ailleurs, l'IAB a mis au point un robot d'indexation que tout le monde peut utiliser pour analyser les pages web des éditeurs afin de vérifier si un fichier ads.txt y est bien présent et d'identifier l'ensemble des identifiants et des partenaires. Une fois cette information en sa possession, la plateforme DSP ne prendra plus en compte les enchères provenant d'un demandeur dont l'identifiant n'est pas vérifié (à condition que l'éditeur ait effectivement publié un fichier ads.txt).
Si les fichiers ads.txt sont publics, peuvent-ils également faire l'objet d'une usurpation ? Qu'est-ce qui empêche les fraudeurs de simplement les inclure dans leurs requêtes d'enchères ?
Ces identifiants uniques ne peuvent pas être falsifiés, car ils sont attribués à chaque domaine par les SSP et ne peuvent être ni supprimés ni remplacés. Par exemple :
Imaginons que je sois propriétaire de NYTIMES.COM. J'établis une relation avec SSP.com, qui m'attribue un PUBID de 12345. J'ajoute ensuite « SSP.com 12345 Direct » dans mon fichier ads.txt. Chaque fois que SSP.com envoie une demande d'enchère pour ce site, celle-ci inclura systématiquement le pubID 12345 associé à NYTIMES.com. Comme j'ai créé un fichier ads.txt, les DSP vérifieront cette information à l'aide de leur robot d'indexation et m'achèteront de l'espace publicitaire, car tout correspond.
Imaginons que vous soyez propriétaire du site FAKENYTIMES.COM. Vous établissez un partenariat avec SSP.com, qui vous attribue un PUBID de 67890. Vous essayez alors de vous faire passer pour moi en indiquant 12345 dans votre fichier ads.txt. Même si vous parveniez d’une manière ou d’une autre à usurper le domaine, SSP.com transmettra tout de même le PUBID qui vous a été attribué (67890) aux DSP ; celui-ci ne correspondra pas à ce que vous avez indiqué sur votre site, et les DSP n’achèteront donc pas d’espaces publicitaires.
Le fichier ads.txt fonctionnera-t-il si les éditeurs choisissent de ne pas créer ni mettre à jour un fichier ads.txt ?
Non, l'éditeur doit créer un fichier ads.txt pour que l'autorisation puisse être accordée. L'un des inconvénients de cette approche réside dans le fait que les fichiers ads.txt nécessitent une mise à jour régulière de la part de l'éditeur. Cette maintenance peut dissuader un éditeur disposant de nombreux sites web et comptant des centaines de vendeurs et de revendeurs de la mettre en œuvre immédiatement.
À un niveau plus général, cette approche ne permettra de mettre définitivement fin à l'usurpation de domaine que si la grande majorité des éditeurs de premier plan créent et mettent à jour des fichiers ads.txt. Tant que nous n'aurons pas atteint une masse critique, l'usurpation de domaine restera un délit grave.
Que faudra-t-il pour que le fichier ads.txt soit un succès ?
Le succès dépendra en grande partie des DSP et de la manière dont ils choisiront de l'adopter, car ce sont eux qui, en fin de compte, prennent les décisions d'achat sur les places de marché publicitaires. Les plus grands DSP — notamment Google — ont fait savoir qu'ils prévoyaient de mettre en œuvre ads.txt d'ici le 1er novembre 2017.
Concrètement, cela signifie, du moins dans un premier temps, que si un site dispose d'un fichier ads.txt à jour, les DSP respecteront très probablement la liste des régies publicitaires autorisées figurant sur cette page et n'achèteront que auprès de ces partenaires.
Mais si un site web ne dispose pas d'un fichier ads.txt actif, il sera considéré comme inconnu ; toutefois, les DSP peuvent choisir de l'acheter quand même. En d'autres termes, certains DSP peuvent traiter cette situation comme s'il s'agissait d'une procédure habituelle.
Pourquoi un DSP continuerait-il à fonctionner comme si de rien n'était alors qu'il est si facile de vérifier l'identité des vendeurs et des revendeurs ?
Gardez à l'esprit que le fait qu'un éditeur ne dispose pas d'un fichier ads.txt actif ne signifie pas nécessairement qu'il y a un risque à acheter chez lui. Cela peut simplement vouloir dire que l'éditeur n'a pas encore eu le temps de créer un fichier ads.txt, ou qu'il estime qu'il n'est pas prudent d'en créer un pendant la période des fêtes de fin d'année. La création d’un fichier ads.txt, par définition, obligera l’éditeur à évaluer chacun des vendeurs et revendeurs de son écosystème. C’est l’occasion idéale d’évaluer la valeur apportée par chacun d’entre eux et de déterminer s’il convient ou non de maintenir la relation. Il s’agit d’une tâche considérable qu’ils pourraient souhaiter reporter au premier trimestre 2018, lorsque l’activité publicitaire ralentit.
Les DSP courent eux aussi des risques. Imaginons qu’un DSP décide de n’acheter de l’inventaire qu’auprès d’éditeurs disposant d’un fichier ads.txt à jour, mais qu’un nombre important d’éditeurs n’aient pas créé ce type de fichier. Ce DSP sera rapidement confronté à des problèmes d’évolutivité lors de la mise en œuvre de ses futures campagnes.
Le défi pour les DSP — et pour l'ensemble du secteur — consiste à mettre en œuvre le fichier ads.txt de manière efficace et évolutive, sans pour autant aller à l'encontre de son objectif en achetant simultanément des annonces autorisées et non vérifiées.
Combien de sites web ont adopté le fichier ads.txt ?
J'ai du mal à me prononcer avec certitude ; l'adoption a démarré lentement, mais s'est accélérée ces derniers mois. En octobre 2017, on n'en était pas encore à une adoption massive.
