Décision de l'APD relative au TCF : Quels impacts pour Sirdata et ses partenaires ?
Mercredi 2 février 2022, l'Autorité de protection des données belge (APD) a rendu un jugement dans lequel elle estime que le Transparency and Consent Framework (TCF), créé par l’IAB Europe et opéré dans le cadre de l'open RTB et dans sa forme actuelle, ne respecte pas plusieurs dispositions du RGPD.
L’Autorité a donné deux mois à l'IAB Europe pour présenter un plan de mise en conformité de ses activités, et a ordonné aux CMP et aux publishers qui mettent en œuvre le TCF de veiller à ce que les données à caractère personnel qui ont été collectées en violation des articles 5 et 6 du RGPD ne soient plus traitées et supprimées en conséquence.
|
Nous avons rédigé cette page afin d’apporter des réponses concrètes et transparentes à nos partenaires, dont nous commençons par attirer l’attention sur trois points fondamentaux :
- La sanction de l’APD ne concerne que l’IAB Europe : aucun Publisher, aucune CMP, ni aucun Vendor n’est condamné.
- Le jugement de l’APD ne concerne que le TCF opéré dans le cadre de l’open RTB
- Le jugement de l’APD ne concerne que le TCF opéré tel quel, c’est-à-dire sans règles additionnelles et en particulier avec l’activation d’office par les CMP ou la sélection par les Publishers de l’intégralité des finalités et Vendors du TCF
Bien que certains éclaircissements apportés par l’APD s’adressent à tout le monde, bien au-delà du TCF, le jugement n’est donc pas relatif à l’utilisation du TCF par les éditeurs qui n'opèrent pas dans le cadre de l’open RTB.
Le jugement n’est donc pas non plus relatif à l’utilisation du TCF par les éditeurs qui limitent la liste de leurs partenaires ou qui utilisent la version standard de la CMP.
| De manière générale, les éditeurs ayant suivi nos conseils ne sont pas en situation de risque en raison de ce jugement et n’ont pas de données à supprimer, pas plus que leurs partenaires, ni l’obligation de “poper” à nouveau pour recueillir un nouveau consentement. |
Sirdata est très active au sein du TCF, rare société à y participer avec la triple qualité de Publisher, CMP et Vendor, ce qui — by design — nous conduit à intégrer le respect de la vie privée et la conformité réglementaire systématiquement dans nos offres.
| Tant comme CMP qu’en tant que Vendor, Sirdata a toujours enrichi le TCF de fonctionnalités et mesures organisationnelles strictes grâce auxquelles nos partenaires n’ont aujourd’hui pas de données à effacer : la limitation de la liste des Vendors, une UI stricte et standardisée où chaque mot compte, la possibilité d’un retrait du consentement et d’une opposition inconditionnels, et des principes de minimisation avancés, entre autres, permettent à Sirdata et ses partenaires de baser les traitements sur un consentement et des intérêts légitimes valablement mis en oeuvre ! |
I- Le choix stocké dans un terminal est une donnée à caractère personnel soumise au RGPD
Le cœur de la décision de l’APD réside dans la qualification d’un choix individuel, converti en une chaîne de caractère — “TC String” — et stocké dans un cookie — “euconsent-v2” — comme étant une donnée à caractère personnel dont le traitement par un ou plusieurs responsables est soumis au RGPD.
Cette décision découle de la définition même de la donnée à caractère personnel qu’apporte le RGPD, à savoir toute information se rapportant à une personne physique vivante identifiée ou identifiable, et du fait que différentes informations qui peuvent être regroupées pour identifier une personne en particulier constituent des données à caractère personnel.
Partant certainement du principe que la transcription d’un choix univoque en une chaîne de caractère est par nature une information qui ne peut découler que du comportement d’un être vivant, l’APD s’est focalisée sur les deux autres aspects fondamentaux de la définition : la donnée doit concerner un individu qui doit être identifié ou identifiable.
Cette dernière caractéristique en particulier ne semble pas évidente, car le choix est par nature une information commune à plusieurs individus — qui font le même choix — et ne permet donc a priori pas d’identifier directement son auteur : traité de manière isolée, c’est à dire indépendamment d’autres informations, il ne constitue donc pas automatiquement une donnée à caractère personnel au sens du RGPD.
Dit autrement, si 2 individus font le même choix, le choix ne permet pas d’identifier “qui est qui”, et l’APD confirme spécifiquement que le choix contenu dans la TC String ne permet pas d’identifier directement l’utilisateur à qui il se rattache.
Un individu ne peut pas être identifié directement par son seul choix.
Il est donc nécessaire que ce choix soit couplé à d’autres informations directement ou indirectement identifiantes pour qu’il puisse s’agir d’une donnée à caractère personnel.
Plus précisément, l’APD rappelle qu’il faut qu’il soit raisonnablement possible de regrouper ces informations pour identifier : il n’est pas nécessaire que ce recoupement existe, il est suffisant qu’il soit possible. On pourrait considérer cette “possibilité” comme composée de deux éléments fondamentaux : que ce soit techniquement possible, et qu’il soit probable que le ou les responsables de traitement réalisent cette identification, ce qui peut se déduire de la finalité.
Difficile en l'occurrence pour l’APD d’imaginer que la publicité ciblée, qui passe par une personnalisation, ne suppose pas une individualisation… Reste donc à déterminer si cette identification est techniquement possible.
Or l’APD constate que lorsque le choix est stocké sous forme d’information alphanumérique dans le terminal, l’accès à ce dernier implique nécessairement la connaissance de l’adresse IP affectée au terminal de l’utilisateur, qui est selon elle “explicitement classée comme une donnée à caractère personnel au sens du RGPD” :
- soit parce que le choix est stocké dans un cookie — first party ou third party — qui sera automatiquement transmis lors des requêtes http(s) incluant par nature l’adresse IP
- soit parce que l’accès à l’espace de stockage comme le “local storage” sera initié par un script chargé à partir d’un serveur via une requête http(s) incluant par nature l’adresse IP
| L’APD confirme donc que le choix — la TC String — en lui-même ne permet pas d'identifier directement des personnes ou des dispositifs mais que, dès lors que le choix est stocké sur le dispositif de l'utilisateur, une CMP a la possibilité d’attribuer un identifiant unique à cette TC String, c'est-à-dire l'adresse IP du dispositif sur lequel il est stocké. La possibilité de combiner la TC String et l'adresse IP implique selon elle qu'il s'agit d'informations concernant un utilisateur identifiable. |
L’adresse IP accessible lors du stockage ou lors de l’accès au choix dans un terminal rend la personne identifiable.
La portée de cette conclusion dépasse largement le cadre du TCF : tout choix effectué par un utilisateur et stocké dans le terminal répond à cette définition. Un consentement géré en dehors du TCF par exemple, mais aussi l’affichage d’un site dans une langue donnée ou encore la sélection de produits mis dans un panier par exemple.
Mais comme l’ORD en Autriche avant elle à propos de Google Analytics, l’APD démontre qu’il n’est pas suffisant pour conclure qu’il s’agit d’une donnée personnelle, et précise qu’il faut s’attacher finalement aux conséquences de l'existence et du traitement du choix stocké dans le terminal.
Ce dernier, qui résulte d’une action de l’utilisateur — voire dans certains cas d’une absence d’action —, produit de par sa nature des effets spécifiques à cette personne : 2 internautes effectuant un choix différent n’auront effectivement pas la même expérience de navigation, et cette individualisation est la conséquence de leur choix.
Le choix contenu dans la TC String concerne donc son auteur, et l'utilisation de ces préférences a même des conséquences indubitables sur les droits et intérêts des personnes concernées selon l’APD, puisque ces choix déterminent, entre autres, quels tiers recevront et traiteront leurs données à caractère personnel dans le cadre du protocole open RTB.
Par sa nature, le choix “concerne” donc son auteur.
Selon la Chambre Contentieuse, le TCF implique donc intrinsèquement la collecte, le traitement, le stockage et le partage ultérieur des préférences des utilisateurs avec d'autres parties, en combinaison ou non avec des données à caractère personnel supplémentaires dans le contexte de l'open RTB, et par conséquent il y a bien un traitement de données à caractère personnel au sens de l'article 4.2 du RGPD
| L’APD conclut donc que la TC String est une donnée à caractère personnel, et puisque le TCF a vocation à enregistrer et transmettre le choix de l’utilisateur via cette TC String, des données à caractère personnel sont traitées dans le cadre TCF. |
Nous pouvons noter que cette conclusion est inhérente au “signal de choix” qui est physiquement transmis aux tiers qui travaillent avec l’éditeur, et nous n’avons pas connaissance à ce jour qu’un standard autre que le TCF permettrait une telle diffusion d’un choix explicite.
Nous pouvons cependant observer que l’absence d’un tel signal rend nécessaire l’utilisation de techniques dites de conditionnement — via un tag manager par exemple — et que le consentement est déductible du fait que le tag du partenaire soit appelé, faute de quoi l’appel serait la preuve de l’absence de consentement préalable.
En dehors du TCF, une indication de consentement est donc inhérente aux transferts, passivement transmise de fait et attachable à une adresse IP et d’autres données personnelles pour conserver la trace d’une preuve de consentement par exemple, bien que non présente physiquement dans une chaîne de caractères.
Changer de paramétrage pour utiliser Sirdata CMP en dehors du TCF ne changerait donc rien.
II- La responsabilité du traitement de la TC String est conjointe
Puisque la TC String est qualifiée de donnée personnelle, et qu’elle est traitée — stockée, partagée, utilisée — , la nouvelle question qui se pose est de déterminer qui est responsable de son traitement.
En premier lieu, la Chambre Contentieuse constate dans sa décision que l’IAB Europe établit la finalité de la TC String, de son stockage dans le cookie “euconsent-v2” à portée “spécifique” au service ou à “portée globale” — sur le domaine “consensu.org” — , et plus largement de son traitement au sein du TCF.
L’APD estime également que l'IAB Europe détermine avec qui et comment les TC Strings doivent être partagées, notamment en mettant à disposition une liste des fournisseurs adtech inscrits au TCF — la Global Vendors List — ainsi qu'une liste de CMP — Global CMP List — agréées.
Enfin, elle note que la Policy du TCF prévoit explicitement que les CMP et les fournisseurs adtech participants doivent conserver la TC String aussi longtemps que le traitement est en cours, et qu’ils sont tenus de la mettre à la disposition de l’IAB Europe, sur simple demande.
Sur la base de ces observations, la Chambre Contentieuse estime que l’IAB Europe doit être considérée comme responsable du traitement des données à caractère personnel que représente l'enregistrement du signal de consentement, des objections et des préférences des utilisateurs au moyen de la TC String, conformément aux TCF Policies et aux technical specifications du Transparency and Consent Framework.
Les rôles et responsabilités sont donc à définir entre l’IAB Europe et les participants responsables conjointement des traitements.
C’est donc l’action cumulée des responsables de traitement qu’il faut analyser pour interpréter les conséquences de la décision, et non le TCF seul, ce que la Policy clarifie sans ambiguïté dès les premières lignes : “Participants must follow applicable privacy data protection laws. In the event of a conflict between applicable law and the Policies, the law prevails.”
| Plus largement, la Chambre Contentieuse conclut que l’IAB Europe et les organisations participantes — les CMP, Publishers et Vendors — doivent être considérés comme responsables conjointement du traitement pour ce qui concerne la collecte et la diffusion des préférences, des objections et du consentement des utilisateurs. C’est donc les moyens et finalités définis par l’ensemble des participants, et en particulier Sirdata, qui doivent être appréciés pour évaluer la conformité des traitements, et non les seuls éléments définis par l’IAB Europe. En tant qu'acteur de la chaîne, vous devez en effet toujours vous demander quels moyens et finalités ont été mis en œuvre par vous et vos partenaires tels que Sirdata afin de renforcer et sécuriser votre responsabilité. |
III- Analyse des violations constatées
L’APD a déterminé que le TCF mis en œuvre tel quel est en infraction avec certaines dispositions du RGPD, et nous vous expliquons en quoi et de manière granulaire ci-dessous.
Par ailleurs, puisque l’APD a déterminé en quoi les éditeurs, les CMP et les Vendors peuvent être responsables de traitement de la TC String conjointement avec l’IAB Europe, nous vous livrons également des informations additionnelles sur ce que Sirdata met en œuvre dans la CMP sans que cela soit prévu ni imposé par le TCF, et qui permet d’utiliser ce standard en toute sécurité.
En effet, ainsi qu’expliqué auparavant, les rôles et responsabilités définis dans le TCF impliquent que la conformité soit appréciée au regard de l’action conjointe des responsables.
1) Articles 5.1.a et 6 du RGPD
Selon l’APD l’IAB Europe ne fournit pas de base juridique pour le traitement des TC Strings, et ni le consentement ni l’intérêt légitime mis en œuvre pour le traitement des données à caractère personnel par les organisations participantes ne sont valables en l’état.
Tout d’abord, le consentement des personnes concernées ne serait potentiellement pas suffisamment spécifique, informé et granulaire dans le cadre du TCF, parce que la Policy n’oblige pas les participants :
- à informer l’utilisateur du traitement de ses choix
- à transmettre instantanément l’information du retrait de consentement
Ensuite, les intérêts des personnes concernées l’emportent sur l'intérêt légitime des organisations participant au TCF lorsque le traitement des préférences des utilisateurs — collectées sous le TCF — est effectué à grande échelle dans le cadre du protocole open RTB, compte tenu de l'impact que cela peut avoir sur ceux-ci.
| Considérant donc qu’en l’absence de base juridique pour le traitement des TC Strings, et puisque ni le consentement ni l’intérêt légitime attachés aux finalités du TCF ne s'appliquent valablement à ce traitement, l’APD conclut que l’IAB Europe enfreint les articles 5.1.a et 6 RGPD. |
Sirdata est toutefois parfaitement consciente que le TCF n’a jamais eu vocation à garantir à lui tout seul une conformité au RGPD.
Sirdata CMP implémente donc ce standard comme d’autres, et apporte en complément des mesures additionnelles et règles spécifiques permettant un respect des réglementations locales et régionales bien au-delà de ce que requiert le TCF.
Par exemple, alors que rien ne l’oblige dans le TCF, l’UI de la CMP Sirdata affiche quoi qu’il arrive aux utilisateurs Français, dès le premier niveau et sans qu’il soit possible de la désactiver, une option lui permettant de refuser de manière groupée les traceurs et traitements basés sur le consentement. Il n’est pas non plus possible d’utiliser des cases pré-cochées pour recueillir un consentement en second niveau.
Dans le cas présent, les textes standards — obligatoires — de l’UI de Sirdata CMP ont mentionné dès l’origine et dès le premier niveau d’information que les choix de paramétrage de la CMP — qui est un logiciel — font partie intégrante des données traitées, au même titre que l’adresse IP, et pendant combien de temps il s’applique — par défaut 6 mois, qu’il s’agisse d’un consentement ou d’un refus/retrait ou d’une opposition —. Pour plus de clarté encore, la notion de choix apparaît désormais spécifiquement dans la liste des données personnelles amenées à être traitées, au même titre que l’adresse IP ou l’adresse email de l’utilisateur par exemple :
Pour permettre un consentement éclairé, en second niveau les “purposes” du TCF sont regroupées sous des finalités “chapeau” définies par la CNIL dans sa Recommandation Traceurs du 17 septembre 2021, telles que la “publicité ciblée” ou la “mesure d’audience”.
En ce qui concerne la diffusion du retrait du consentement, nous n’avons jamais pu constater que les CMP non compatibles avec le TCF transmettent l’information du retrait du consentement aux partenaires des éditeurs, alors que ces derniers sont passivement informés du consentement.
Grâce au TCF en revanche, Sirdata expose via l’API de la CMP la fonction permettant aux participants du TCF d’enregistrer un écouteur d’événements — __tcfapi('addEventListener') — pour recevoir automatiquement et instantanément le signal du retrait du consentement ou d'opposition.
A ce titre, nous nous devons de rappeler la règle historique et incontournable de l’UI de la CMP Sirdata : lorsque l’utilisateur ouvre volontairement la CMP pour modifier ses choix, un bouton “Tout refuser et continuer” obligatoire et du même format que le bouton d’acceptation apparaît systématiquement sur le premier niveau d’information. Un clic sur ce bouton vaut tout à la fois refus ou retrait du consentement et opposition aux traitements basés sur des intérêts légitimes :
Additionnellement et indépendamment du TCF, Sirdata permet également une diffusion instantanée des choix — et notamment du retrait du consentement — au travers de signaux dédiés utilisables dans un tag manager par exemple.
Par ailleurs, afin de protéger l’utilisateur contre un usage potentiellement non-raisonné de sa donnée, et protéger l’éditeur contre une dégradation de la valeur de cette donnée, Sirdata a toujours refusé d’activer d’office l’intégralité des Vendors présents dans la GVL dans les UI de la CMP.
Les éditeurs doivent sélectionner manuellement chaque partenaire qui sera affiché dans l’UI de la CMP et Sirdata met continuellement en garde contre l’activation d’un trop grand nombre de partenaires.
Dans le cadre de la coopérative de choix qu’elle gère, Sirdata va même jusqu’à imposer un plafond de 200 partenaires, très loin des 2000 partenaires potentiels du TCF et du réseau de consentement géré par Google en complément — “AC Mode” —.
De tels garde-fous permettent d’éviter les traitements à grande échelle des préférences des utilisateurs — collectées sous le TCF — dans le cadre du protocole open RTB : selon l’APD les intérêts des personnes concernées ne l’emportent sur l'intérêt légitime des organisations participant au TCF que lorsque ces dernières sont toutes sélectionnées.
| Sirdata et ses partenaires peuvent donc se prévaloir d’un consentement ou d’un intérêt légitime à traiter les TC Strings. Ces bases légales sont valablement mises en œuvre grâce aux règles de transparence, de recueil et du retrait du consentement, de gestion de l’opposition, ainsi qu’à des mesures contraignantes de gestion et de contrôle additionnelles au TCF. |
Par ailleurs, bien que l’ayant développé, Sirdata n’a jamais implémenté l’option dite “globale” de gestion du choix du TCF V2, et de ce fait n’a jamais stocké de TC String dans le cookie “euconsent-v2” attaché au domaine “consensu.org”.
| De cette analyse il ressort que les partenaires de Sirdata n’ont pas à prendre de mesure particulière dans le cadre des articles articles 24 et 25 du RGPD et du jugement de l’APD : aucune donnée n’ayant été collectée en violation des articles 5 et 6 du RGPD, il n’y a pas lieu d’en supprimer en conséquence. Il n’est pas non plus nécessaire de “poper” à nouveau pour collecter un nouveau consentement. |
2) Articles 12, 13, and 14 RGPD
Comme développé ci-dessus, l’APD considère que la façon dont les informations sont fournies par défaut aux personnes concernées ne répond pas à l'exigence d'une « manière transparente, compréhensible et facilement accessible ».
D’une part parce que l’information obligatoire dans le cadre du TCF n’est pas suffisante pour ce qui concerne les catégories de données à caractère personnel collectées selon l’APD, et que les utilisateurs ne sont pas en mesure de déterminer à l'avance la portée et les conséquences du traitement. Ils ne disposent donc pas d'un contrôle suffisant sur le traitement de leurs données pour éviter d'être surpris par un traitement ultérieur de leurs données à caractère personnel.
Ensuite car les informations données aux utilisateurs sont trop générales pour refléter le traitement spécifique de chaque fournisseur adtech, ce qui empêche a priori la granularité — et donc la validité — du consentement reçu pour le traitement effectué dans le cadre du protocole open RTB. L’information obligatoire dans le cadre du TCF est en effet un socle commun brut insuffisant : Sirdata et ses clients vont bien au-delà.
En plus de refléter les mentions obligatoires du TCF, l’UI de Sirdata CMP apporte un éclairage additionnel sur les données traitées et la finalité de ces traitements, et en hiérarchise l’information pour une compréhension et un contrôle utilisateur facilités.
Une partie de l’information est disponible en premier niveau, une autre, comme la liste des destinataires, l’est aisément en second niveau, et l’accès aux informations additionnelles comme les conditions d’exercice des droits est accessible via des liens vers les pages de Vie Privée.
D’autres garanties de contrôle pour l’utilisateur non imposées par le TCF viennent s’ajouter, comme la granularité possible dans les choix des partenaires en plus des finalités, ou encore la possibilité systématique de ne pas consentir en un clic dès le premier niveau.
| Les règles de transparence, de recueil et de retrait du consentement, et de l’opposition, ainsi que les règles contraignantes de gestion et de contrôle additionnelles au TCF permettent à Sirdata et ses partenaires de se prévaloir de la mise en œuvre valable des obligations de transparence, et de ce fait la conformité aux articles 12, 13 et 14 du RGPD. |
3) Articles 24, 25, 5.1.f et 32 RGPD
En l'absence de systèmes de contrôle systématiques et automatisés des CMP et des fournisseurs adtech participants par l’IAB Europe, l'intégrité de la TC String n'est pas suffisamment assurée selon l’APD, puisqu'il est possible pour les CMP de falsifier le signal afin de générer un cookie “euconsent-v2” et de reproduire ainsi un « faux consentement » des utilisateurs à toutes fins et pour tous types de partenaires.
La Chambre Contentieuse souligne également que le RGPD exige que les droits des personnes concernées puissent être exercés vis-à-vis de chacun des responsables conjoints du TCF de manière à respecter les articles 24 et 25 du RGPD.
Premièrement Sirdata CMP ne falsifie pas le signal pour générer un cookie “euconsent-v2” pour reproduire un « faux consentement » des utilisateurs à toutes fins et pour tous types de partenaires, et procède à des audits manuels réguliers pour s’assurer que le choix n’est pas altéré par des tiers malveillants.
Deuxièmement, ainsi que nous l’avons explicité ci-avant, bien que la fonctionnalité “globale” ait été développée, cette dernière n’a pas été implémentée par Sirdata.
Aucune TC String n’a donc été enregistrée par Sirdata CMP sur le domaine “consensu.org” permettant à l’IAB Europe d’accéder à la TC String et à l’adresse IP de l’utilisateur.
Enfin, bien que la Policy prévoit que les TC strings puissent être transmises à l’IAB Europe, Sirdata ne l’a jamais fait et rien n’impose de transférer d’autres données associées : si nous devions procéder à un tel transfert pour des raisons légitimes, il serait effectué après anonymisation, c’est-à-dire suppression des données additionnelles permettant l’identification, comme l’adresse IP de l’utilisateur — la TC String seule ne permettant pas d’identifier l’utilisateur selon l’APD — .
| L’implémentation du TCF par Sirdata permet donc de répondre aux obligations de sécurité du traitement, d'intégrité des données à caractère personnel et de protection des données dès la conception et par défaut. Dans cette configuration, l’action conjointe ou indépendante des différents responsables de traitement permet donc de justifier d’une conformité aux articles 24, 25, 5.1.f et 32 du RGPD. |
4) Article 30 du RGPD
L’IAB Europe tient un registre des activités, bien que de par sa taille, elle n’en n’ait pas l’obligation.
Néanmoins, au vu de l'ampleur des opérations de traitement et de l'impact potentiel sur la vie privée des utilisateurs que l’APD prête au TCF, cette dernière considère que l’IAB Europe doit mettre à jour son registre actuel pour y inclure les traitements effectués de données personnelles qu’elle opère dans le cadre du TCF.
De son côté Sirdata tient bien un registre de traitement qui inclut les choix des utilisateurs.
| Le registre des traitements tenu par Sirdata mentionne bien les traitements des choix, et plus spécifiquement des TC Strings dans le cadre du TCF, conformément à l’article 30 du RGPD. |
5) Article 35 et 37 du RGPD
La Chambre Contentieuse constate que l’IAB Europe n'a pas réalisé d'analyse d'impact relative à la protection des données — AIPD — complète relative au traitement des données à caractère personnel au sein du TCF.
En conclusion elle a donc violé l’article 35 du RGPD, en raison du grand nombre de personnes concernées qui entrent en contact avec les sites web et les applications mettant en œuvre le TCF, ainsi que des organisations participant au TCF, d'une part, et de l'impact du TCF sur le traitement à grande échelle des données à caractère personnel à travers le protocole open RTB, d'autre part.
Or, ainsi qu’expliqué ci-avant, les éditeurs doivent sélectionner manuellement chaque partenaire qui sera affiché dans l’UI de Sirdata CMP et Sirdata met continuellement en garde contre l’activation d’un trop grand nombre de partenaires.
Dans le cadre de la coopérative de choix qu’elle gère, Sirdata va même jusqu’à imposer un plafond de 200 partenaires, très loin des 2000 partenaires sélectionnables parmi le TCF et le réseau de consentement géré par Google en complément — “AC Mode” —.
Ces mesures et d’autres, qui ont été détaillées dans ce document ou non, viennent “brider” le TCF, et le fondement de la décision de l’APD, à savoir le très grand nombre d’entreprises autorisées à traiter les données n’existe plus.
D’autre part, Sirdata rappelle que de par son fonctionnement le TCF implique que chaque entité participante ne peut recevoir de données personnelles que si elle y est autorisée par l’utilisateur, et ne pourra à son tour transférer des données à un autre participant qu’après vérification que le signal contenu dans la TC String autorise ce destinataire à recevoir et traiter des données personnelles.
Deux cas de figure peuvent donc exister dans le TCF mis en oeuvre dans l’open RTB, lorsqu’après vérification du signal un participant constate que le tiers n’est pas autorisé à traiter des données personnelles :
- il ne lui envoie pas la bid request
- il lui envoie une bid request qui contient la TC String anonymisée (sans identifiant de cookie ou d’adresse IP associés)
Lorsque le signal indique que le tiers est autorisé à traiter de la donnée il recevra la TC String non anonymisée, mais ce traitement sera licite puisque le consentement et l’intérêt légitime sont valablement mise en œuvre dans le TCF par Sirdata CMP, ainsi que démontré préalablement.
Ces mesures se cumulent donc pour permettre d’éviter les traitements à grande échelle mentionnés dans la décision, et une AIPD n’est pas nécessairement obligatoire dans cette configuration. En effet, l'APD n’a conclu à cette obligation que dans l’hypothèse où tous les Vendors sont autorisés par l’éditeur dans la CMP.
Toutefois, Sirdata considère toujours que l’évaluation des impacts sur la vie privée est souhaitable, même lorsque ce n’est pas obligatoire.
| L’absence d'analyse d'impact relative à la protection des données — AIPD — relative au traitement des données à caractère personnel au sein du TCF tel que mis en œuvre par Sirdata CMP n’est pas jugé comme une violation de l’article 35 du RGPD, mais reste néanmoins souhaitable. Par ailleurs Sirdata a désigné un délégué à la protection des données — DPD — tel qu’indiqué par l’article 37 du RGPD. |
|