Skip to navigationSkip to content

Ads.cert : le nouveau Ads.txt?

Par Dom Fortin,
CIO
21 December 2017

L’initiative Ads.txt lancée en mai dernier continue de faire sa marque sur l’industrie. Et pourtant, une forme évoluée pointe déjà à l’horizon: Ads.cert. Voici un topo sur qu’est-ce qu’Ads.cert et en quoi l’initiative diffère de la précédente.

Qu’est-ce qu’Ads.cert?

Ads.cert pousse l'initiative un peu plus loin qu’Ads.txt en ce qui à trait au combat pour plus de transparence dans l’industrie. Cette évolution, lancée elle aussi par IAB, utilise la cryptographie afin de signer numériquement les bid requests, rendant la tâche bien plus difficile à n’importe qui souhaitant trafiquer le fichier, mais permettant aussi plus de transparence quant à l’information transmise entre l’acheteur et le vendeur.

Alors, quelle est la différence avec Ads.txt?

Avec Ads.txt, le processus était plutôt simple. Les éditeurs n’avaient qu’à intégrer un fichier .txt au code source, listant tous les vendeurs et revendeurs autorisés, comme nous pouvons voir ci-dessous :

Sur réception d’une requête, les DSPs envoient des crawlers vers le site Web des éditeurs en questions afin de vérifier si la requête provient d’une source autorisée, évitant ainsi des faudes comme le domain spoofing.

Toutefois, les inévitables failles de cette première initiative n’ont pas tardé à être exploitées, créant ainsi un besoin pour une nouvelle solution plus efficace.

Ads.cert repousse donc les limites en fournissant toute information transmise entre l’acheteur et le vendeur, telle que le type d’impression, l’appareil, ou encore la position de la publicité sur la page. De cette façon, le supply path possède un niveau de transparence plus élevé, utilisant aussi la cryptographie pour exiger une signature numérique lorsqu’un changement est apporté à la requête.

Alors, comment ça fonctionne?

  1. Le destinateur bâti un bid request décrivant l’impression offerte à l’enchère;
  2. Le destinateur génère ensuite une signature numérique propre à la requête qui sera envoyée et l’attache à cette dernière;
  3. Sur réception, le destinataire utilisera la clé publique pour générer une signature pour cette même requête;
  4. Si les deux signatures correspondent, cela indique que le message n’a pas été modifié et qu’aucune fraude n’est survenue.

Grâce au processus de signature numérique, l’initiative participe à une chaîne d’offre plus saine, car toute tentative de falsification de la requête rendra la signature non valide.

Il faut toutefois prendre note que l’initiative est encore en cours de développement, ainsi, plusieurs détails restent à être clarifier au cours des prochains mois.

Quelle est la prochaine étape?

Nous sommes heureux de voir qu’IAB continue son combat pour apporter une transparence plus que nécessaire à l’industrie. Ceci étant dit, en raison de son degré technique plus élevé, Ads.cert ne sera probablement pas implanté aussi rapidement que son prédécesseur.

Premièrement, cette nouvelle solution n’est compatible qu’avec OpenRTB 3.0, annoncé en septembre dernier, mais encore en phase de développement. Deuxièmement, même lorsque la nouvelle version sera lancée, il faudra attendre une implantation à grande échelle de la part des DSPs, des SSPs et des exchanges avant qu’Ads.cert puisse atteindre son plein potentiel.

Toujours est-il que Ads.cert promet d’ajouter de nouvelles normes qui contribueront sans aucun doute à créer un écosystème beaucoup plus sain en 2018.

Articles reliés

Éditeurs
Ads.txt: where are we at now?
08 December 2017 — Par Luc Marsolais
district m
Ads.txt: Paving the road for a more transparent ecosystem
29 August 2017 — Par Sandrine Tessier

Accéder à nos plateformes

Let's talk about Tech