Détecter et analyser les cookies et autres traceurs

1. Principaux traceurs utilisés dans la publicité ciblée

Il existe plusieurs manières de tracer un internaute au cours de sa navigation sur le web. Les méthodes les plus utilisées ont été rencontrées par la CNIL lors de contrôles effectués ces dernières années auprès d’acteurs majeurs de l'Internet, que ce soit des sites éditeurs, annonceurs ou des sociétés spécialisées dans la publicité ciblée.

1.1 Pixel invisible

La technique dite du « pixel invisible » consiste à appeler une image, hébergée sur un serveur tiers, à la taille de 0 ou de 1 pixel, donc invisible de l’internaute. Lors de cet appel, des informations sont transmises en paramètre de la requête HTTP/GET correspondante.

Exemples de tag [portion de code HTML ou JavaScript] incluant un pixel invisible :

Dans ces exemples, en ouvrant la page web ou le courrier électronique qui contiendrait un de ces tags HTML, le navigateur de l’internaute effectue une requête de type GET vers le serveur-de-tracking.com. Il transmet alors un paramètre : un nom d’image (d690a7357b.png) ou un contenu de variable (pid=CAESEAZY8yBmmTLHS_0bBfHimto). Ce paramètre unique, permet alors de « reconnaître » l’internaute et donc de savoir qu'il a consulté telle partie d'une page internet ou qu'il a ouvert tel e-mail publicitaire.

1.1.1 Pixel invisible et dépôt de cookie

En réponse, le serveur web peut déposer un ou plusieurs cookies via l'instruction (en-tête) « set-cookie » du protocole HTTP. Dès lors, à chaque fois que l’internaute se rendra sur un site web contenant un tag redirigeant vers le domaine serveur-de-tracking.com, il sera pisté. Nous verrons, dans la partie cross-canal, comment les sites visités obtiennent alors l’adresse électronique de l’internaute, à des fins de sollicitation commerciale.

Cette technique requiert d’utiliser des cookies.

1.2 Cookies HTTP

Le cookie HTTP reste la technique la plus utilisée pour tracer les internautes.

Un cookie est défini dans la RFC 2965 [RFC6265] comme étant une suite d’informations envoyée par un serveur web à un client HTTP. Ce dernier retourne le contenu du cookie lors de chaque interrogation d’un serveur web associé au même nom de domaine (sous certaines conditions).

Les cookies ont été initialement prévus et utilisés à des fins techniques ou fonctionnelles. Ils permettent par exemple au protocole HTTP (nativement « stateless ») d’avoir la possibilité de gérer les sessions et de permettre certaines fonctionnalités. Cependant, leur usage initial a progressivement été complété par une utilisation à des fins de traçage publicitaire, car les cookies peuvent aussi stocker des informations relatives à la navigation de l’internaute ou un identifiant de « tracking ».

Le cookie se présente aujourd’hui sous différentes formes en fonction des navigateurs (cf. article de Cyrille Aubergier dans le MISC précédent) :

- Internet Explorer enregistre chaque cookie dans un fichier texte différent ;

- Mozilla Firefox et Google Chrome enregistrent les cookies dans une base de données SQLite ;

- Opera enregistre tous ses cookies dans un seul fichier et le chiffre — ce que ne font pas les trois autres.

1.3 Local Shared Objects (Cookies Flash)

Les local shared objects [LSO], connus également sous le nom de « cookies flash », sont des données enregistrées sur l’ordinateur de l'internaute, lors de l’exécution d’applicatifs Flash (Adobe Flash Player et Macromedia Flash MX Player).

Par défaut, l’applicatif Flash peut écrire sur le terminal de l’utilisateur sans avoir requis préalablement le consentement de l’utilisateur.

Où trouver les cookies Flash sur mon terminal :

Les cookies flash peuvent aussi être affichés dans un navigateur via l'URL suivante (qui permet aussi de régler les paramètres du FlashPlayer) : http://www.macromedia.com/support/documentation/fr/flashplayer/help/settings_manager07.html.

Le processus d’une application Flash lit directement ces cookies dans les répertoires où ils sont stockés.

À noter : Adobe Flash propose un « mode privé » où les cookies Flash ne sont pas sauvegardés. Celui-ci s’active dans les paramètres Flash lorsque l'on se trouve sur une page contenant un applet Flash.

1.4 Local Storage/Stockage web local (HTML5)

HTML5 apporte une nouveauté par rapport à ses prédécesseurs : la possibilité de stocker des données dans le navigateur sans utiliser de cookies. Cette technique, appelée « stockage web local » (ou local storage), permet de sauvegarder des volumes de données plus importants qu’avec les cookies (de l’ordre de 5 Mo à 10 Mo pour l’instant contre quelques kilo-octets pour les cookies).

Il existe deux types de stockage web local : le stockage local et le stockage de session, équivalent respectivement aux cookies persistants et aux cookies de session.

Par défaut, les informations contenues dans la base locale ne sont pas systématiquement renvoyées au serveur web à chaque requête. Elles sont cependant récupérables sur demande (par exemple via des instructions JavaScript).

Dans le cas de Mozilla Firefox, ces données sont stockées dans une base de données de type SQLite, nommée webappsstore.sqlite. Avec un logiciel permettant de lire une base de données SQLite, il est possible de consulter ces cookies (par exemple, avec l'extension Firefox SQLite Manager).

À ce jour, peu de sites utilisent cette technique pour identifier les internautes.

1.5 Fingerprinting

Le fingerprinting consiste à récupérer une « empreinte » du navigateur de l’internaute afin de l’identifier lors de connexions ultérieures.

Le fingerprinting fait l’objet d’un article dédié dans ce dossier.

2. Observer le tracking

La méthodologie décrite dans cette partie vise à observer et analyser les traceurs de type « pixels invisibles » et « cookies HTTP » qui demeurent encore de loin les plus utilisés.

Pour les besoins de l’article, nous avons réalisé un parcours de navigation sur Internet comprenant d'abord l’inscription sur quatre sites web d’éditeurs ou d’annonceurs ; puis la navigation sur deux sites de e-commerce avec la mise au panier d’articles ; enfin, la navigation sur un site d’annonceur avec affichage de publicités ciblées. L’objectif est d’illustrer le fait que certains aspects du traçage opéré par les publicitaires au moyen de cookies HTTP peuvent être simplement observés. La méthodologie étant reproductible et basée sur des extensions du navigateur Mozilla Firefox, le lecteur est invité à se livrer à la même expérience.

Les cookies déposés durant ce parcours, au nombre de 505, ont été examinés et sauvegardés avec l’extension Cookie Manager + [CookieManager +]. Par ailleurs, les en-têtes HTTP des échanges entre notre navigateur et les serveurs web distants ont été capturés au moyen de l’extension Live HTTP Headers [LiveHTTPHeaders]. Cette capture permet par exemple de constater d’autres transmissions de données, connexes à celles réalisées par les cookies :

- les transmissions opérées en cas d'appel de pixels invisibles ;

- le chaînage des appels de serveurs publicitaires et les dépôts/lectures de cookies qui en résultent dans le cadre d’une enchère publicitaire (RTB, voir article dédié dans ce dossier) ;

- les partages de cookies (Cookie Matching).

2.1 « Voir l’invisible » : la visualisation graphique avec Cookie Viz

La CNIL met à disposition de tous, sous licence libre (GPLv3), un outil de visualisation qui identifie en temps réel les requêtes HTTP vers des serveurs tiers et les cookies déposés par ces serveurs. Des alternatives à cet outil existent, comme Lightbeam. L’avantage majeur de CookieViz sur les autres outils similaires est qu’il est capable de visualiser les cookies de l'ensemble des navigateurs.

Concrètement, CookieViz analyse les interactions entre votre ordinateur, votre navigateur et les sites et les serveurs distants contactés au cours de la navigation.

 

 

2.2 L’analyse des caractéristiques des cookies avec Cookie Manager +

Pendant la vingtaine de minutes qu’a duré l’expérience, 505 cookies ont été déposés. La très grande majorité (378) sont des cookies tiers (« third party »), déposés par des serveurs web de domaines distincts du site web visité. Ils sont appelés suite à l’exécution de tags (images, code JavaScript) fournis par les prestataires et intégrés au code HTML de la page web. Une minorité (127) sont des cookies déposés et lus par les serveurs web des sites visités (« first party »). Cependant, certains de ces cookies peuvent avoir une finalité publicitaire (certains gros sites ont leur propre régie) ou être des « faux cookies internes », c’est-à-dire des cookies dont le domaine est celui du site, mais qui sont liés à des prestations réalisées par des tiers. C’est par exemple le cas des cookies de mesure d’audience « Google Analytics », présents sur la majorité des sites internet, et dans notre expérience, sur les 7 sites visités. Ils ont pour noms : _ga, _gat, _utma, _utmb, _utmc, _utmt, _utmv et _utmz. Ces derniers sont lus par le serveur web du site, mais d’autres requêtes HTTP transmettent leur contenu (par passage en paramètre) aux serveurs de Google. Un blocage des cookies tiers est donc inefficace pour bloquer ce type de cookies.

Certains des cookies tiers qui ont été déposés ont des finalités liées aux boutons de partage sur les réseaux sociaux ou à la mesure d’audience. La majorité de ces cookies semble en revanche avoir des finalités publicitaires et certains contiennent des identifiants uniques du navigateur de l'internaute. Si les noms de domaine peuvent faire apparaître des noms d’acteurs publicitaires, les noms des cookies peuvent également être parlants.

Ainsi, une simple recherche des cookies dont le nom contient la chaîne « uid » (pour « user id ») en fait apparaître 53. En voici quelques-uns :

 

 

Comme on peut le constater, ils contiennent en général des numéros identifiants uniques du navigateur de l’utilisateur en général au format décimal, hexadécimal ou chiffré. L’acteur publicitaire « reconnaît » ainsi le navigateur de l’utilisateur grâce à ce numéro, les données de navigation et d’analyse étant stockées en base, côté serveur.

Mais certaines régies peuvent faire le choix de stocker également une synthèse du profil publicitaire de l’internaute dans les cookies, côté client.

Ils sont en général dans des formats encodés :

D’une part, si les numéros d’identification de l’internaute sont propres à chaque acteur publicitaire, le cloisonnement des lectures et dépôts de cookies étant garanti par la « same-origin-policy » du navigateur, on peut remarquer que certains cookies de domaines différents utilisent le même identifiant. Comme évoqué dans l’article sur le RTB de ce dossier, c’est une conséquence du partage de cookies (« cookie matching » ou « cookie syncing ») sur laquelle nous reviendrons. À ce stade, ce point peut être facilement constaté en opérant un tri dans la colonne « Content » de Cookie Manager+ :

 

 

D’autre part, l’examen des durées de vie des cookies peut être également un indice sur une finalité de traçage dans le temps. Dans notre expérience, 219 cookies (soit 43 %) ont une durée de vie supérieure ou égale à un an, certains pouvant avoir des durées très longues :

2.3 Pour aller plus loin : l’analyse des en-têtes des requêtes HTTP

2.3.1 Dépôts et lectures de cookies de tracking dans les en-têtes HTTP

Les dépôts et lectures de cookies peuvent facilement être observés dans l’examen des en-têtes HTTP. Les dépôts et modifications de cookies apparaissent par le biais de l’instruction « Set-cookie » de la réponse du serveur web. Les cookies associés à un nom de domaine et déjà présents sur le navigateur sont systématiquement fournis (modulo des restrictions éventuelles sur les sous-domaines) dans le champ « Cookies » du navigateur. Par exemple, voici deux requêtes HTTP vers un serveur publicitaire :

On peut observer qu’en réponse à cette requête, deux cookies sont déposés, l'un d'eux contenant un identifiant unique (uuid2). Lors de la requête suivante vers la régie, les cookies seront donc « servis » par le biais de l'en-tête « cookie » des requêtes HTTP :

2.3.2 La mise en commun d’identifiants (le « cookie syncing » ou « cookie matching »)

Une recherche dans les captures HTTP de l'identifiant cookie observé précédemment et commun à plusieurs acteurs publicitaires, montre plusieurs requêtes. Par exemple celle-ci :

On peut voir que cette requête transmet, par passage en paramètre de l'URL, l'identifiant « 8186779241047110843 » et qu'en retour, le serveur web dépose un cookie avec le même identifiant, et cette fois associé à son nom de domaine.

On peut également observer, dans le fichier de capture, que de nombreuses autres requêtes transmettent cet identifiant en paramètre, mais sans dépôt de cookie en retour.

Dans tous les cas, il s’agit de partage/synchronisation de cookies opérés dans le cadre d’enchères publicitaires — le « matching » étant réalisé côté client ou côté serveur. Dans ce dernier cas, des tables de correspondance entre les identifiants des différentes régies et acteurs sont construites au niveau des échangeurs et/ou des régies elles-mêmes (ou d'autres acteurs intermédiaires). Cela n’est pas sans implication sur l’ampleur du traçage et sur le lien qui peut désormais être fait entre les différentes données collectées par les différents acteurs publicitaires. En effet, le cloisonnement des identifiants par acteur publicitaire, qui prévalait avant l'avènement du RTB, n'a aujourd'hui plus cours (voir article sur le RTB dans ce dossier).

2.3.3 Mise en évidence du RTB par le chaînage des requêtes

L'observation du chaînage des requêtes, par le biais du « Referer » du protocole HTTP qui indique la requête HTTP précédente ayant appelé celle-ci, peut servir à mettre en évidence les appels générés lors des enchères publicitaires (RTB) décrites dans un article de ce dossier. Par exemple la requête suivante :

Il s'agit d'une requête à destination du sous-domaine « bid » (bid=enchère) de « g.doubleclick.net », domaine de la régie publicitaire de Google. Elle est initiée à la suite d’une requête vers un sous-domaine de « exelator.com » qui apparaît dans le « Referer » et qui appartient à la société Exelate. Celle-ci fournit une offre de place des marchés publicitaires (marketplace ou échangeur). L'examen des requêtes met en évidence d'autres requêtes avec le même « Referer » et à destination d'autres acteurs publicitaires.

2.3.4 L’adresse électronique comme clé de voûte de l'identification : du « cross canal » au « cross device »

La navigation de l'internaute peut désormais être associée à son adresse électronique, rompant ainsi l’ « anonymat » (en fait pseudonymat) annoncé dans la plupart des politiques « cookies » des sites web. D’ailleurs, même sans l'utilisation des techniques décrites dans ce paragraphe, cet « anonymat » relatif du traçage opéré par les cookies peut être rompu par d’autres manières (cf. par exemple [MISC-Analyse]).

Le retargeting ou le re-ciblage publicitaire sur des articles consultés par l'internaute sur un site sur lequel il n’est pas inscrit est désormais possible par courriel (« e-mail retargeting »). Il recevra alors des publicités par e-mail pour des produits similaires ou semblables à ceux qu'il a consultés sur des sites internet.

L’internaute pourra par ailleurs être contacté sur un autre canal (cross canal) si la régie publicitaire dispose d’une base plus complète à même d'associer à l'adresse e-mail, l’adresse postale de l’internaute ou son numéro de mobile, ou si elle paye une prestation « d’enrichissement de base » auprès d’une société spécialisée.

Cette identification de l’internaute est réalisée par des dépôts de cookies contenant un haché (en général SHA1 ou MD5) de son adresse électronique. Ce dépôt s’effectue soit à l’ouverture d’un courrier électronique, soit à la connexion sur un site partenaire (« matching partner ») qui vend cette possibilité d’identification de l’internaute. Ce second cas est expliqué dans les schémas suivants :

 

 

 

 

 

 

Les captures HTTP réalisées mettent en évidence des requêtes et dépôts de cookie du domaine « emailretargeting.com ».

Set-Cookie: etuix=FVO9KtSlVspzVohjEoHNrb71FLhCPd9WYSont0N8uUO1r7CPikBnEA--; expires=Tue, 29 Dec 2015 20:12:07 GMT; path=/; domain=.emailretargeting.com

Les hachés d’adresses électroniques peuvent aussi être utilisés pour relier les différents terminaux d'un même utilisateur à des fins de prospection publicitaire (PC personnel, professionnel, smartphone, tablette, etc.). C’est ce qu’on appelle le « cross device ».

3. Quelques solutions simples pour arrêter (limiter) le traçage

On peut parfois (souvent) lire dans la rubrique cookies des sites internet que l'utilisateur peut s'opposer aux dépôts de cookies en les bloquant via les paramètres de son navigateur, mais qu'après cette action, certaines fonctionnalités du site (souvent essentielles comme la connexion au compte) seront inopérantes. C'est une incitation habile à accepter tous les cookies…

Voici donc quelques solutions simples, non exclusives, qui limitent fortement le traçage sans entraver la navigation de l'internaute :

1. Utilisation du mode de  navigation privée (« ne jamais conserver l'historique » sous Mozilla Firefox). Cela limite la « mémoire » du traçage à une session seulement.

2. Blocage des cookies tiers dans les paramètres du navigateur. Les cookies tiers étant dans la quasi-totalité des cas non techniques et non fonctionnels, cela n'entravera que très peu l'expérience de navigation. À noter que cette solution ne protège cependant pas des « faux cookies first party » comme ceux de Google Analytics par exemple.

3. Utilisation d'extensions limitant ou bloquant les traceurs, par exemple : DoNotTrackMe, Disconnect, Ghostery ou AdBlockEdge (qui bloque aussi l'affichage des publicités).

4. Limitation du traçage dans les paramètres d'Adobe Flash.

Pour plus de détails, le lecteur pourra se reporter à une rubrique dédiée sur le site Internet de la CNIL [CNIL-CONSEILS].

Enfin, l'e-mail devenant la clé de voûte d'un traçage plus étendu, et même si cela est plus complexe, car cela nécessite de posséder ou d'acheter son propre nom de domaine, il est recommandé à l'internaute qui souhaite vraiment se protéger d'utiliser un alias de son adresse e-mail propre à chaque site. Par exemple, sur le site « monjournal », on pourra fournir l'alias (redirection e-mail) « monjournal@domain » où « domain » correspond à notre nom de domaine. Cela permet de plus de détecter une revente indue de l'e-mail à un spammeur et de couper la redirection si nécessaire...

4. Appendice : quelques remarques sur la sécurité et les cookies

4.1 Les cookies apprécient aussi l’HTTPS − de l’utilité de l’attribut « secure »

La RFC 6265 définit l’attribut secure pour les cookies : cet attribut peut-être associé indifféremment à chaque cookie. Lorsqu’il est activé pour un cookie, ce dernier est transmis uniquement à travers un protocole sécurisé.

Certains sites ne chiffrent pas les données (potentiellement personnelles ou sensibles) contenues dans des cookies qu’ils déposent sur le terminal de l'internaute. Voici, par exemple, l’un des (nombreux) cookies tels que déposés après identification (via le protocole HTTPS). Il contient nom, prénom et e-mail de l'internaute :

Or, de nombreuses pages de « monsite.fr » ne sont pas accessibles en HTTPS. Ainsi, l’internaute, au cours de sa navigation, oscille entre des pages en HTTPS et des pages en HTTP.

Il en résulte que, sur les pages accessibles en HTTP, ce cookie, contenant un certain nombre de données personnelles, est transmis en clair.

Pour contrer ce phénomène, il existe plusieurs solutions. Il est possible d’utiliser l’attribut « secure » sur ce cookie. Ainsi, il sera transmis par le navigateur uniquement lors d’appels de pages utilisant un protocole sécurisé (RFC 6265).

Une autre solution, plus radicale, est de forcer l’utilisation du protocole HTTPS pour l’intégralité du site, via le HSTS.

4.2 Le HSTS − politique de chiffrement pour l’intégralité d’un domaine

Le protocole HTTP Strict Transport Security [HSTS] est un mécanisme de politique de sécurité proposé pour HTTP permettant à un serveur web d’indiquer au navigateur, s’il est compatible, qu’il doit communiquer avec lui en utilisant une connexion sécurisée.

Lorsque la politique HSTS est active pour un site web, le navigateur de l’utilisateur remplace automatiquement tous les liens non sécurisés par des liens sécurisés (http://www.mon-site.fr devient https://www.mon-site.fr). Ainsi, toutes les données transmises, y compris les dépôts et lectures de cookies, le sont sur un canal chiffré.

En cas d’impossibilité d’établir une connexion sécurisée, un message d’alerte est affiché à l’utilisateur.

4.3 L'attribut HTTPOnly

Les cookies sont fournis à chaque requête HTTP au serveur web correspondant. Par ailleurs, ils sont accessibles aux fonctions JavaScript qui s'exécutent dans la page. Cela peut représenter un danger et permettre par exemple à des « partenaires » ayant fourni ce type de code d'accéder à d'autres cookies que les leurs ou à un pirate de mener une attaque de type XSS pour « voler » des cookies.

Une bonne pratique, dès lors que le cookie stocke des données sensibles (cookie d'authentification, contenant des données personnelles, etc.), est d'utiliser l'attribut « HTTPOnly » qui indique que le cookie est uniquement accessible via HTTP(s).

Références

[LSO] Local Shared Objects (cookies flash) :

- https://fr.wikipedia.org/wiki/Objet_local_partag%C3%A9

- https://www.adobe.com/fr/special/products/flashplayer/articles/lso/

- https://www.adobe.com/fr/support/flashplayer/ts/documents/4c68e546.htm

[RFC6265] RFC 6265 (HTTP State Management Mechanism) : http://tools.ietf.org/html/rfc6265

 [HSTS] HSTS sur Wikipédia : https://fr.wikipedia.org/wiki/HTTP_Strict_Transport_Security

[CookieViz] Dépôt CookieViz sur GitHub : https://github.com/LaboCNIL/CookieViz

[CookieManager +] https://addons.mozilla.org/fr/firefox/addon/cookies-manager-plus/

[LiveHTTPHeaders] https://addons.mozilla.org/fr/firefox/addon/live-http-headers/

[MISC-Analyse] Article MISC n°76 (nov./déc. 2014) : « Analyse d'une inscription en ligne : comment vos données fuitent sur Internet ».

[CNIL-CONSEILS] Cookies : conseils pour les maîtriser, rubrique sur le site Internet de la CNIL accessible à l'URL : http://www.cnil.fr/vos-droits/vos-traces/les-cookies/conseils-aux-internautes/