Utiliser P2B pour avoir plus d’informations sur les APIs

Depuis le 12 juillet, le règlement Plateforme-To-Business est entré en application. Ce règlement ambitionne de rendre plus équitables et transparentes les relations entre les plateformes et les entreprises. P2B s’applique entre autres aux magasins d’applications qui permettent d’installer des applications sur smartphones. Dans cet article je m’intéresse plus particulièrement à son impact sur l’app store d’Apple.

Le règlement « promouvant l’équité et la transparence pour les entreprises utilisatrices de services d’intermédiation en ligne » (aka Platform-To-Business ou P2B)[1] a été adopté en juin 2019 et est entré en application il y a quelques jours. Comme son nom l’indique, ce règlement essaie d’établir un peu d’équilibre entre les plateformes (i.e. les services d’intermédiation en lignes et les moteurs de recherche) et les entreprises. Le scope visé par le règlement est relativement large puisque derrière le terme de service d’intermédiation en ligne, on retrouve les plateformes de site hôteliers (par exemple booking, hotels,…), les place de marché de biens (par exemple les marketplaces d’amazon, de la fnac,…) et les magasins d’applications. Le règlement couvre aussi les moteurs de recherches.

Comme le soulignait l’Arcep[2], ce règlement apporte une première pierre vers l’ouverture des terminaux. Néanmoins, il reste limité pour l’essentiel dans l’impact qu’il aura sur ces derniers puisque les APIs sont assez explicitement exclues du champ d’application du règlement… sauf dans le cas où elles sont directement liés à un service d’intermédiation en ligne :

« Les fonctionnalités et interfaces technologiques qui se limitent au raccordement du matériel et des applications ne devraient pas être régies par le présent règlement, étant donné qu’elles ne remplissent pas, en règle générale, les critères pour être considérées comme des services d’intermédiation en ligne. Toutefois, ces fonctionnalités et interfaces peuvent être raccordées directement à certains services d’intermédiation en ligne, ou leur être accessoires, et dans ce cas, les fournisseurs de services d’intermédiation en ligne concernés devraient être soumis aux exigences en matière de transparence liées au traitement différencié sur la base de ces fonctionnalités et interfaces. [mise en gras] »

Or dans le cas d’Apple, la possibilité pour une app d’utiliser certaines APIs se décide directement au niveau de l’App store.

L’App Store comme point de contrôle des APIs

Pour développer une application sur iOS, les développeurs sont restreints dans les APIs qu’ils peuvent utiliser : seules les APIs publiques sont documentées et ouvertes aux développeurs tiers. Il existe des APIs privées qui ne sont utilisables que par les applications d’Apple, celles-ci offrent des fonctionnalités plus avancées aux développeurs d’Apple.

Apple vérifie qu’aucune API privée n’est utilisée au moment où une app est soumise sur l’App Store. Par le passé, certaines apps ont réussi à contourner cette vérification mais ont par la suite été retirées de l’app store[4] pour violation des conditions d’utilisation de l’App Store[5].

La question de l’ouverture de ces APIs est importante puisque certaines peuvent donner un avantage compétitif aux apps d’Apple[3] mais si elles étaient ouvertes à tous, cela pourrait nuire à la sécurité d’iOS et à sa stabilité.

Certaines APIs (privées et publiques) requièrent une autorisation explicite d’Apple (un entitlement) au moment où l’application est soumise sur l’App Store. A défaut d’obtenir un entitlement, iOS ne laissera pas l’application utiliser l’API[6].

Ainsi, on peut considérer que ces APIs raccordées directement à l’App Store puisque c’est ce dernier qui fait office de point de contrôle.

On pourrait alors considérer que le règlement P2B s’applique à l’utilisation des APIs privées ou soumises à entitlements. En particulier, l’article 7 du règlement imposent aux plateformes de décrire les traitements différenciés qu’elles mettent en place :

1.   Les fournisseurs de services d’intermédiation en ligne incluent dans leurs conditions générales une description de tout traitement différencié qu’ils accordent, ou pourraient accorder, en relation avec des biens ou services proposés aux consommateurs par le biais de ces services d’intermédiation en ligne par, d’une part, soit le fournisseur lui-même, soit toute entreprise utilisatrice contrôlée par ce fournisseur et, d’autre part, d’autres entreprises utilisatrices. Cette description mentionne les principales considérations économiques, commerciales ou juridiques à l’origine de ce traitement différencié.

3.   Les descriptions visées […] couvrent notamment, le cas échéant, tout traitement différencié au moyen de mesures spécifiques que prend le fournisseur de services d’intermédiation en ligne ou d’un comportement qu’ils adoptent, en relation avec l’un des éléments suivants:

d)l’accès aux services, fonctionnalités ou interfaces techniques pertinentes pour l’entreprise utilisatrice ou l’utilisateur de site internet d’entreprise et qui sont directement associés à l’utilisation des services d’intermédiation ou des moteurs de recherche en ligne concernés, ou directement accessoires à cette utilisation, les conditions d’utilisation de ces services, fonctionnalités ou interfaces ou toute rémunération directe ou indirecte perçue pour cette utilisation.

Cet article pourrait s’appliquer aux APIs, ainsi si ces APIs servaient à un traitement privilégié, elles pourraient dans certains cas être soumises à plus de transparence. 

Néanmoins, en pratique, cette disposition s’appliquerait dans peu de cas comme nous le verrons ci-dessous.

Le cas UBER

L’application UBER eu le droit à un traitement privilégié : en 2017, il a été découvert qu’Apple avait accordé à UBER un entitlement pour une API privée permettant à l’app de lire le contenu de l’écran[7]. Au passage, cette dérogation exceptionnelle démontre qu’il est possible pour Apple d’offrir sélectivement des privilèges à certaines apps sans pour autant modifier son OS.

Apple n’a pas particulièrement expliqué ce geste et si cela se reproduisait aujourd’hui cela pourrait ressembler à un cas d’école pour la mise en application du règlement P2B, mais étonnamment P2B ne pourrait pas s’appliquer. En effet, P2B ne vise que les traitements différentiés qui bénéficient à l’opérateur de la plateforme (soit le fournisseur lui-même, soit toute entreprise utilisatrice contrôlée par ce fournisseur.) Or Uber n’étant pas contrôlé par Apple ce privilège n’aurait pas à être justifié d’après P2B.

L’enquête Apple Pay

En juin dernier, la direction générale à la concurrence a déclaré ouvrir deux enquêtes visant Apple pour abus de position dominante[8]. L’une d’elle visait le refus d’Apple d’ouvrir la fonctionnalité « tap and go » aux concurrents d’Apple Pay. En effet, seul le service Apple Pay peut bénéficier de cette fonctionnalité et les concurrents se considèrent injustement désavantagés.

Dans ce cas, contrairement au cas précédent, le service mis en avant appartient bien à la société qui déploie le service d’intermédiation en ligne. Pour autant, P2B ne vise que les traitements en relation avec des biens ou services proposés aux consommateurs par le biais de ces services d’intermédiation en ligne, or Apple Pay est un service intégré à iOS et n’est pas accessible depuis l’App Store.

Dans ce contexte; il n’est pas évident que le règlement P2B trouve à s’appliquer.

L’utilisation du Bluetooth en arrière-plan

Les applications de contacts tracing qui ont souhaité s’appuyer sur le bluetooth plutôt que sur la localisation se sont retrouvée limitées sur iOS du fait que les applications peuvent difficilement utiliser le bluetooth lorsqu’elles sont en arrière-plan. Les différents états se sont retrouvés contraints de faire un choix : développer une application qui fonctionnerait moins bien sur iPhone ou utiliser l’API commune à Apple et Google même si elle ne correspondait pas à leur besoin[9] et qui par ailleurs ne fonctionnait qu’avec la dernière version d’iOS (excluant ainsi 10% des utilisateurs d’iPhones[10]).

Pour beaucoup, le refus d’Apple se justifiait par le souhait de protéger la vie privée des utilisateurs, mais rien ne prouve que cet objectif a bien pesé dans le refus d’Apple. D’une part, les applications qui ont essayé de contournées la restriction d’Apple (et qui ont été accepté sur l’App Store) nuisaient à la sécurité des smartphones en incitant les utilisateurs à les laisser déverouillés [11] ou étaient plus intrusives en utilisant la géolocalisation[12]. D’autre part, toutes les documentations officielles d’Apple indiquaient que les restrictions étaient motivées par la volonté de réduire la consommation de ressources (batterie [13]  et mémoire[14]) des iPhones.

Actuellement, il demeure difficile de connaitre la motivation d’Apple puisque la société ne s’est pas exprimée sur le sujet et n’a par conséquent jamais eu a justifié son choix. Or en pratique, les règlement P2B pourraient trouver à s’appliquer.

En effet, Apple permet d’accéder à plusieurs applications pré-installée depuis l’app store. Même si les applications ne sont pas installables depuis l’app store, elles sont néanmoins visibles et entre en concurrence avec les services concurrents proposées par la plateforme[15]. Par ailleurs, certaines de ces applications utilisent le bluetooth même en arrière-plan. C’est notamment le cas de l’application « Find My » qui utilisent le BLE en arrière-plan pour permettre aux iPhones d’être retrouvés [16] . Ainsi Apple pourrait avoir à justifier la restriction d’accès aux fonctionnalités bluetooth en arrière-plan.

Une nécessité de plus de transparence

Le débat sur les applications de contacts tracing démontrent bien l’intérêt de la transparence : justifier les choix architecturaux des OS. En effet, Apple n’a pas eu a justifié du choix de refusé d’ouvrir l’accès aux BLE aux applications de contact tracing. Ce mutisme n’a pas été critiqué puisque la société s’est vue érigée en chevalier blanc protecteurs de la vie privée face aux états. Mais en l’absence d’explication cette posture est questionnable. Si il était avéré que la société avait effectué ce choix juste pour économiser les ressources des iPhones ou même de façon complétement arbitraire, le débat ne serait plus le même.

Image de couverture par Jay Goldman
https://creativecommons.org/licenses/by-nc-sa/2.0/


[1] https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32019R1150&from=EN

[2] « Platform-to-Business » : un premier pas vers les terminaux ouverts dans le règlement européen ! https://www.arcep.fr/larcep/pendant-ce-temps-a-bruxelles.html#c18616

[3] « Apple frees a few private APIs, makes them public » https://www.theregister.com/2017/06/13/apple_inches_toward_openness/

[4] « Apple bans over 250 apps that secretly accessed users’ personal info » https://www.theverge.com/2015/10/19/9567447/apple-banned-apps-youmi-privacy-personal-data

[5] Voir la section 2.1.5  des software requirements https://developer.apple.com/app-store/review/guidelines/#software-requirements

[6] Voir la section 2.3 de ,«iRiS: Vetting Private API Abuse in iOS Applications » par Zhui Deng, Brendan Saltaformaggio, Xiangyu Zhang, Dongyan Xu

[7] « Uber App Has Access to Special iPhone Functions That Can Record Your Screen » https://www.inc.com/business-insider/uber-apple-iphone-features-app-software.html

[8] Ainsi la restriction d’accès à certaines fonctionnalités NFC fait l’objet d’une enquête de la DG-Comp: https://ec.europa.eu/commission/presscorner/detail/en/ip_20_1075

[9] « Why are Google and Apple dictating how European democracies fight coronavirus? » https://www.theguardian.com/commentisfree/2020/jun/16/google-apple-dictating-european-democracies-coronavirus

[10] L’API Apple nécessite iOS 13 alors que StopCovid ne nécessite qu’iOS 11 et TraceTogether iOS 10 https://gs.statcounter.com/ios-version-market-share/mobile-tablet/france

[11] « iOS a ‘major hurdle’ to contact tracing app » https://www.innovationaus.com/ios-a-major-hurdle-to-contact-tracing-app/

[12] https://twitter.com/je5perl/status/1248230776287776769

[13] « Because performing many Bluetooth-related tasks require the active use of an iOS device’s onboard radio—and, in turn, radio usage has an adverse effect on an iOS device’s battery life—try to minimize the amount of work you do in the background. » https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetoothBackgroundProcessingForIOSApps/PerformingTasksWhileYourAppIsInTheBackground.html

[14] « WWDC 2017: Because while your application is running in the background, the system may terminate it if it needs to free up more memory for the foreground application. » (https://asciiwwdc.com/2013/sessions/703 )

[15] « Apple Dominates App Store Search Results, Thwarting Competitors » https://www.wsj.com/articles/apple-dominates-app-store-search-results-thwarting-competitors-11563897221

[16] « Un service de localisation décentralisé et privacy by design entre appareils » https://linc.cnil.fr/fr/un-service-de-localisation-decentralise-et-privacy-design-entre-appareils

A la recherche des annonceurs qui me ciblent

Au mois de novembre, j’ai effectué  une demande de droit d’accès à Google. Après un délai d’un mois, Google m’a indiqué que le traitement de ma requête aller prendre du temps. Deux mois après cette prolongation, Google a répondu à ma requête… en m’indiquant ne pas pouvoir répondre à la plupart de mes demandes.

L’objet de ma demande

Ma demande est disponible ci-dessous, elle vise à obtenir un maximum d’informations concernant la façon dont je suis ciblé via les services de Google. Mon objectif est de comprendre d’une part comment mes données sont monétisées par Google, et surtout de connaître les annonceurs qui utilisent les outils de ciblage offerts par la société. Comme je l’ai détaillé dans ma contribution aux EGNum, je pense que la meilleure solution pour influer sur les plateformes est d’agir sur les annonceurs qui paient pour utiliser ces services publicitaires. Plus que les utilisateurs, ce sont les annonceurs qui in-fine contribuent au chiffre d’affaires des plateformes et ce sont eux qui ont réussi à obtenir le plus de concessions de la part des plateformes. Aussi ma requête devait me permettre de mieux identifier ces acteurs, mais c’est loin d’être une réussite.

Ma demande de droit d’accès

Trois mois pour un pdf de 6 lignes…

En effet, trois mois après ma demande initiale (ce qui correspond au délai maximal autorisé par l’article 12-3 du RGPD), la seule information que j’ai eue est la liste des annonceurs qui m’ont effectivement ciblé avec « Customer Match », c’est à dire ceux qui me ciblent en utilisant mon adresse mail. Cette liste est assez utile, et je vous invite d’ailleurs à faire une demande similaire à la fois pour votre information personnelle, mais aussi pour motiver Google à fournir une meilleure interface d’accès. Facebook offre une bien meilleur interface que Google qui n’offre qu’un PDF qu’il m’aura fallu attendre 3 mois, pourtant Facebook est très critiqué (à juste titre)  pour l’opacité de son système de ciblage alors que Google l’est moins. Cerise sur le gâteau, une jolie mention « Confidentiel, propriété de Google » figure sur le document. Au passage, et sans dévoiler leurs noms, les annonceurs qui me ciblent via Customer Match de Google sont les mêmes que ceux qui me ciblent via Facebook Custom Audience.

Rien sur les « Reminder Ads »

Concernant mes autres demandes, Google botte en touche. Tout d’abord, selon eux, il serait possible de savoir sur cette page quelles sociétés me reciblent (au passage, ils parlent de « reminder ads » c’est à dire de « publicité de rappel » plutôt que de retargeting). Je ne trouve cette information sur la page en question, mais n’hésitez pas à m’indiquer si vous avez plus d’informations concernant votre compte.

Enfin concernant la liste des annonceurs, Google indique ne pas gérer de base de données avec toutes les publicités vues par un utilisateur particulier (“does not maintain a database of every advertisement seen by a specific user. Account holders can visit My Activity to see the websites and apps they’ve visited on which Google ads were shown”). Cela ne signifie pas que Google n’a pas cette information, mais simplement qu’elle n’est pas facilement restituable. En effet, Google garde certainement pour chaque publicité la liste des utilisateurs qui l’ont vue. Pour recomposer la liste des publicités que j’ai vues, Google devrait regarder pour chaque campagne publicitaire si je figure bien dans cette liste. S’il est vrai que c’est sans doute compliqué,  je ne comprends pas l’intérêt d’exploiter pleinement le délai de 3 mois offert par le RGPD pour juste répondre qu’ils ne peuvent pas faire suite à ma demande tout en reconnaissant à demi-mot avoir les données.

Prochaines étapes

Je ne compte pas me satisfaire de cet échec. A moyen terme j’aimerais créer un outil pour collecter la liste des annonceurs qui me ciblent sur Google, comme le fait AdAnalyst pour les publicités de Facebook. En effet, l’extension permet aux utilisateurs de retrouver la liste des annonceurs qui les ciblent via Facebook et de savoir comment ils sont visés. Un tel outil permettrait techniquement de répondre à ma demande.

Ensuite, je vais reformuler des demandes de droits d’accès par étape pour obtenir un maximum d’informations sur les annonceurs. Par exemple, en procédant service par service (Google, Gmail, Youtube) et je pense demander quels sont tous les cookies identifiant qui ont été associés à mon compte, puis la liste des sites visités par ce cookies pour enfin obtenir la liste des publicités qui ont été affichées sur ces sites.

Bien sûr, je suis preneur de toutes suggestions concernant les deux types de solutions.

@vtoubiana

Réponse à ma demande

Image de couverture par Jay Goldman
https://creativecommons.org/licenses/by-nc-sa/2.0/

Qookie Fix: Intro et prochaines étapes

Rendre à César

Comme ce billet est long et que je ne suis pas sûr que vous le lirez dans son ensemble, je commence par remercier Guénaël Pépin pour m’avoir mis l’idée en tête via son tweet. Un grand merci aussi à Nymous sans qui l’extension serait devenue un gouffre de mémoire.

Le RGPD est arrivé

Comme tout le monde, j’ai constaté que les bandeaux cookies recommençaient à pulluler à l’approche de l’été. Ce qui est peut-être moins commun, c’est que j’étais heureux car l’utilisateur semblait enfin pouvoir consentir au dépôt de cookies au lieu d’être mis devant le fait accompli comme il l’a été durant plusieurs années. J’ai rapidement déchanté en découvrant le périple qu’il fallait accomplir pour s’opposer au dépôt de cookies.

Le bandeau auquel j’ai été le plus confronté est celui de Quantcast. Il permet de consentir très facilement. Mais il n’offre pas vraiment de choix car si on souhait s’opposer, les choses se compliquent puisqu’il est souvent nécessaire de décocher les cases une par une. Le pire étant qu’il faut répéter l’opération presque quotidiennement car dès lors qu’on ne consent pas, le bouton réapparaît fréquemment.

Peut-être coupable mais pas responsable

En fait, ce bandeau propose par défaut aux éditeurs de mettre un bouton « je refuse » sur leur bandeau (et d’ailleurs, si vous allez sur le site de Quantcast, vous le verrez apparaître) mais très très peu de sites le proposent. La plupart des éditeurs configurent le module pour que le bouton de refus n’apparaisse pas car, évidemment, ça décourage les utilisateurs qui ne voudraient pas consentir. A noter qu’une autre option permet aux éditeurs de choisir à quelle fréquence le bandeau réapparaît en cas de refus, et par défaut c’est « une fois par jour ».

Paramétrage du bandeau depuis le site de Quantcast

 

Il n’est pas certain qu’un consentement obtenu de cette façon soit valable. Il me semble, par contre, que Quantcast n’est pas attaquable puisque l’outil proposé permet, selon le paramétrage choisi, d’obtenir un consentement valable. Ce sont donc les éditeurs de sites qui le configurent de manière à « forcer » le consentement. Par conséquent, pour régler le problème il faudrait attaquer les sites un par un.

Bien que Quantcast ne soit pas responsable, la société communique sur le taux de consentement qui atteint 90%, au point qu’on en viendrait à se demander quel est l’intérêt d’offrir un choix à l’utilisateur.

Des contournements peu efficaces

Comme il est compliqué de simplement ignorer ces bandeaux, j’ai d’abord cherché à les contourner en utilisant systématiquement le mode « lecture » du navigateur. Malheureusement cette approche n’est pas utilisable sur tous les sites, et elle n’envoie en plus aucun signal aux éditeurs. Or, comme Quantcast met en avant les taux de consentement élevés, il devient important de pouvoir signaler que l’on s’oppose au suivi et d’avoir une influence sur ces chiffres.

Twitter a fini de me convaincre que je n’étais pas le seul à me préoccuper de cette situation et j’ai donc commencé à réfléchir à une extension qui équilibrerait le choix. Ajouter le bouton sur le bandeau était la partie facile, mais il restait à matérialiser le choix des personnes qui clique sur le bouton “s’opposer”.

Une solution simple

Quand une personne consent ou s’oppose via un bandeau Quantcast, son choix est sauvegardé dans un cookie. J’ai voulu répliquer un cookie d’opt-out Quantcast pour matérialiser l’opt-out mais je n’ai pas réussi à créer un cookie d’opt-out générique.

Comme je voulais une solution simple, il m’a fallu explorer une autre piste et, en analysant un peu le code du bandeau, et surtout en allant sur le site de Quantcast, je me suis rendu compte qu’il était simple de faire appel à la fonction d’opt-out. C’est donc ce que fait l’extension, dès qu’elle détecte la présence d’un bandeau Quantcast, l’extension fait apparaître un bouton « Je refuse » et lui associe la fonction d’opt-out prévue par Quantcast. L’extension n’a pas pour objectif de bloquer techniquement les trackers mais simplement d’offrir un vrai choix aux utilisateurs là où les dark patterns tentent de forcer le consentement. Par la même occasion, elle permet d’envoyer un signal aux éditeurs de sites puisqu’il est probable que ceux-ci prêtent attention aux taux de consentement.

Le Framework de l’IAB “Consent & Transparency”

Techniquement, l’extension est donc assez simple. Là où les choses se compliquent, c’est qu’elle est spécifique au bandeau Quantcast et qu’il est compliqué de l’adapter aux autres bandeaux cookies. A minima, il faudrait pouvoir l’adapter à toutes les solutions compatibles avec le framework de l’IAB.

De ce que j’en comprends, tous les bandeaux compatibles avec ce framework utilisent le même cookie de consentement. Les informations contenues dans ces cookies sont codées selon un algo proposé par l’IAB.

A la simple lecture de ces cookies, il n’est pas possible pour un utilisateur de savoir à quelles finalités il a consenti. C‘est problématique puisque la seule solution mise à disposition des utilisateurs lambda pour savoir à quelles finalités ils ont consenti est de retrouver le bandeau. Pour décoder le contenu de ces cookies, il faut réutiliser les scripts proposés par l’IAB (réadaptés ici). Au passage, je salue le fait que ces scripts soient mis à disposition sur Github avec une licence MIT. Une alternative consiste à installer l’extension re:consent de Cliqz qui est aussi disponible sous Firefox et Chrome.

Une fois le cookie décodé, on ne peut lire que des numéros de finalités. Or si l’IAB fournit une nomenclature pour les finalité 1 à 5, certains éditeurs et/ou fournisseurs de bandeaux font référence à des finalités non définies. Le cookie contient la liste des finalité auxquelles l’utilisateur a consenti. Donc pour proposer un opt-out complet : il suffit d’encoder un cookie avec une liste vide de finalités.

Next steps

Pour améliorer l’extension, il faudrait qu’elle soit compatible avec plus de bandeaux. La solution qui me paraît la plus simple pour offrir un opt-out sur tous les sites utilisant le framework de l’IAB est donc d’encoder un cookie avec aucune finalité. Reste la partie un peu plus compliquée qui est celle de la détection de tous les bandeaux compatibles avec le framework IAB. A ma connaissance, il n’y a pas de solution simple, la meilleur solution serait de détecter le cookie après coup ce qui est moins pratique.

La prochaine amélioration apportée consistera à empêcher que le bandeau ne réapparaisse une fois que l’on s’est opposé. N’hésitez pas à contribuer au code ou à donner des idées ici : https://github.com/vtoubiana/QookieFix/issues

In fine, ça restera sans doute une solution temporaire. Les autorités de protection des données vont sans doute clarifier les règles sur ce qui est acceptable et ce qui ne l’est pas, et après Safari et Brave, Firefox va activer une protection anti-tracker par défaut. Compte tenu des récents développements du navigateur de Google,  je ne serais pas étonné que Chrome en face de même.

 

 

 

 

Se mettre en conformité avec la réglementation sur les cookies via les « Content Security Policy »

Ce post explique brièvement comment les « Content Security Policy » peuvent être utilisées pour mettre votre site en conformité.

La réglementation sur les cookies

La réglementation sur les cookies impose aux éditeurs de site web d’obtenir un consentement informé des utilisateurs avant de déposer des cookies sur leurs terminaux. Un site doit donc vérifier qu’un consentement a été préalablement obtenu avant de déposer ses propres cookies et le même traitement s’applique pour toutes les tierces parties présentent sur ce site web. Si il est assez simple pour un site web de vérifier qu’il a obtenu le consentement au moyen d’un cookie, cette tâche s’avéré plus difficile pour les tiers car ils ne peuvent pas accède aux cookies de consentement déposés sur des domaines autres que le leur.
Par conséquent c’est souvent à l’éditeur du site de vérifier qu’il a obtenu le consentement avant d’appeler le contenu des tierces parties. Les outils de gestionnaires de Tag sont une solution élégante pour conditionner le dépôt de cookie à l’obtention du consentement correspondant. Une solution moins fine consiste à détourner le mécanisme des « Content Security Policy » pour empêcher l’appel des contenus tiers tant que le consentement n’a pas été obtenu.

Introduction aux “Content Security Policy”

Une “Content Security Policy” est une politique définit par l’auteur d’une application ou d’une page web et qui informe le client des sources qui seront autorisées à charger du contenu sur le site (“declarative policy that lets the authors (or server administrators) of a web application inform the client about the sources from which the application expects to load resources”). Cette politique peut être vue comme une liste de contenus qui peuvent être chargés par le navigateur lors du chargement d’une page. Ces politiques peuvent être déclarées de deux façons: soit via le header HTTP, soit par le champ http-equiv présent dans l’entête HTML d’un document.

Déclaration d’une politique

Pour se mettre en conformité et empêcher que des contenus tiers ne soient déposés avant l’obtention du consentement, un site web peut déclarer une politique qui bloque le contenu provenant de sites tiers. Notez que cette approche n’est pas « cookie-centric » puisqu’elle permet de bloquer tous types de contenus et que par conséquent elle empêche aussi le chargement des services de calcul d’empreinte.
Une solution rapide de “cookie consent” consiste à vérifier au moment du traitement d’une requête si le consentement a été obtenu et d’adapter la CSP en fonction. Si le consentement n’a pas été obtenu la CSP n’autorisera que les ressources provenant de l’éditeur et bloquera les ressources provenant des tiers, si le consentement a été obtenu la CSP usuelle du site sera chargée.
Le plus simple pour un éditeur est d’utiliser une simple balise JavaScript pour insérer un champ http-equiv dans l’entête HTML du document (bien que cela ne soit pas forcément recommandé). Les quelques lignes ci-dessous devraient faire l’affaire:

if ( document.cookie.indexOf('hasConsent') < 0 ) {
 var hostname = window.location.hostname;
 if (hostname.indexOf("www.") ===0) hostname = hostname.substring(5);
 var meta = document.createElement('meta');
 meta.httpEquiv = "content-security-policy";
 meta.content = "script-src 'self' 'unsafe-inline' *." + hostname + "; img-src *." + hostname + "";
 document.getElementsByTagName('head')[0].appendChild(meta);
 }

Une solution légèrement plus compliquée consiste à utiliser le header HTTP. Le code pour accomplir cela est très proche et reste assez semblable mais l’approche est alors plus spécifique au serveur que vous utilisez. Par exemple si vous fonctionnez sur un environnement PHP le code devrait ressembler à cela :

if(!isset($_COOKIE["hasConsent"])) {
 $allowed_hosts = "*.unsearcher.org";
 header("Content-Security-Policy: script-src 'self' 'unsafe-inline' " . $allowed_hosts . "; img-src 'self' " . $allowed_hosts);
 }

Compatibilité

Le standard “Content Security Policy » est en cours de validation mais n’est toujours pas supporté par tous les navigateurs. A l’heure actuelle, Chrome et Safari supportent toutes les fonctionnalités requises, dont le support du tag http-equiv. Firefox supporte les politiques définies dans l’entête http mais ne tiennent pas compte du tag http-equiv. Enfin si Internet Explorer devrait bientôt supporter toutes les fonctionnalitésne actuellement ni l’entête HTTP ni l’entête HTML ne sont supports.

Quelques tests

En utilisant le proxy BURP il est possible de modifier le header HTTP d’un page afin de voir à quoi elle ressemblerait si cette approche était implémentée (c’est-à-dire en bloquant le contenu tiers) :

New York Times

 LeMonde

 

 

Conclusion

Cette solution n’est pas parfaite et présente l’inconvénient majeur de ne pas être supporteé par tous les navigateurs. Cependant elle permet de bloquer assez simplement tous les contenus tiers dans l’attente d’un consentement et est par conséquent complémentaire à la solution proposé sur le site de la CNIL et qui permet d’obtenir le consentement pour Google Analytics (le type de cookie first partie le plus utilisé).

L’impact de la Politique de Confidentialité de Google sur la publicité en ligne

Prés de deux ans après que Google ait annoncé la mise en place de sa nouvelle “Politique de Confidentialité”,  la CNIL sanctionne Google d’une amende de 150.000 euros. Google devra aussi publier un communiqué sur Google.fr pendant 48h. Si le montant peut sembler faible au regard des revenus de Google, il faut savoir que cela est dû au blocage du nouveau règlement européen qui aurait permit d’aller jusqu’à 2% du CA de Google (blocage dont le conseiller Privacy de Google en France  se  frotte les mains).

Dans ce post, je souhaite revenir sur l’impact qu’a eu la politique de Google sur le Web. La mise en œuvre des outils de traçage que cette politique de confidentialité autorise fut assez longue et n’est sans doute pas finie. Je m’intéresse uniquement à ce que cette politique permet en terme de croisement de données sur le Web, c’est à dire que je considère seulement les informations de votre profile Google or cela ne représente qu’une infime partie des données dont Google dispose.

Le croisement d’information avec DoubleClick

DoubleClick, la principale régie publicitaire sur le Web,  appartient à Google depuis 2007. Un récent papier des chercheurs de l’INRIA montre que DoubleClick est présent sur 50% des principaux sites Web. Concrètement Google vous suit, via cette régie publicitaire, sur prés d’1 site sur 2 que vous visitez. Quand Google a annoncée sa nouvelle politique de confidentialité, une phrase dans la politique de confidentialité laissait sous-entendre que Google ne croiserait pas de donner provenant des comptes Google avec les données issues du traçage via DoubleClick (“Le recoupement de données en provenance de cookies DoubleClick avec des données permettant de vous identifier n’est possible qu’avec votre accord explicite.”).

Beaucoup ont compris que Google garderait les donnée provenant de DoubleClick et celles provenant de Google complétement isolées. De fait, les profiles publicitaires construits par Google à cette époque ne semblaient pas provenir de données précises et comportaient souvent des erreurs. Malheureusement cette phrase ne couvre que le croisement de donnée directement  identifiantes et, une fois l’attention retombée, Google a corrigé les données utilisée pour le ciblage publicitaire.

 

Utilisation d’information en provenance du profile Google

En effet, plusieurs mois après l’annonce de sa nouvelle politique, Google a commencé à croiser les données provenant des profile Google avec les données issues du ciblage publicitaire. Ainsi, les publicités affichées par DoubleClick sont non-seulement adaptées aux sites web que vous visitez mais aussi aux données que vous avez indiquées lorsque vous avez créé votre compte Gmail (principalement Age et Sexe). Pour vous en apercevoir il suffit de se rendre sur la page de gestion des pub en étant logué sur votre compte GMail.

Page sur laquelle sont décrits comment vous êtes perçus par les publicitaires

Au début, cette personnalisation avancée ne se faisait que si vous aviez consenti via la page de “personnalisation des +1”  (voire ci-dessous) . Cela n’était pas évident car il était indiqué que vos pubs seraient personnalisées en fonction de vos “+1″ et des autres informations de profile”). Mais depuis quelques mois cela n’est plus le cas, Google se passe de votre autorisation pour croiser ces données.

En effet,  Google considère que votre autorisation n’est pas requise puisque ces données ne sont pas identifiantes. Pire, il n’est plus possible de refuser que Google utilise votre age déclaré dans ses pubs sans s’opposer à toute personnalisation.

Page qui permettait de vous opposer à la personnalisation des pubs en fonction de votre profile

Publicité ciblée en fonction de votre navigation sur d’autres sites

La politique de Google ne les empêche pas non plus d’enregistrer dans votre profile Google, les pages web que vous avez visitées et sur lesquelles étaient présentes des publicités DoubleClick. En pratique, vous verrez sur le moteur de recherche de Google, des publicités basées sur les sites web que vous avez visités. Cette fonctionnalité passe par la création de “Listes de Reciblage pour Publicité sur le moteur de Recherche” (RLSA en anglais) et permet aux annonceurs de vous afficher une pub sur Google Search si vous avez visité leur site.

Techniquement, Google a besoin de bidouiller pour que cela puisse marcher car quand vous visitez un site externe à Google, vous n’envoyez souvent que votre identifiant de cookie DoubleClick . Or vous avez un identifiant attribué par DoubleClick qui est différent de celui attribué par Google. Quand vous vous rendez sur le site de Google, vous montrer un identifiant différent donc Google ne devrait pas pouvoir savoir  quel site vous avez visité.

La bidouille de Google consiste à vous rediriger depuis le domaine doubleclick.net vers le domaine google.com. Du coup, vous présentez à la fois votre identifiant DoubleClick et votre identifiant Google, et Google saura où vous êtes allé  et pourra vous cibler en fonction de vos visites sur d’autres sites. Conclusion

Bien que Google ne soit pas en droit de combiner des informations identifiantes avec des informations obtenues via DoubleClick:

– Ils utilisent des informations provenant de votre compte Google pour vous ciblez en fonction de votre age et sexe sur les sites affiliés à DoubleClick.

– Ils enregistrent vos visites sur les sites affiliés à DoubleClick sur votre compte Google.

En bref, la politique de Google concernant la publicité en ligne se résume à ça:

  • [Ils] ne communiquent pas aux annonceurs les informations permettant d’identifier les utilisateurs.
  • [Ils] n’autorisent pas les annonceurs à diffuser des annonces comportant des informations à caractère sensible, telles que l’origine ethnique, la religion, l’orientation sexuelle, la santé, certaines catégories liées à l’argent, etc.