Si vous utilisez ChatGPT gratuitement, il y a de bonnes chances que votre navigateur se balade avec un affreux cookie baptisé __obi, posé là par OpenAI et avec une durée de vie de un an. Un chercheur qui publie sous le pseudonyme Buchodi a analysé son fonctionnement et publié un rapport très intéressant ce week-end dans lequel on apprend que ce cookie permet à OpenAI de choper des datas sur les sites marchands que vous visitez.

Le principe est celui du pixel publicitaire, exactement comme celui que Meta et Google vous font installer à l'insu de votre plein gré depuis des années. Une boutique qui achète de la pub dans ChatGPT colle un bout de code d'OpenAI sur ses pages, et ce code les prévient quand vous achetez un truc. Sauf qu'ici, comme __obi est configuré en SameSite=None, votre navigateur l'attache tout seul à la requête qui charge le script, avant que la moindre ligne de code ne s'exécute.

Et cet identifiant n'est pas anonyme ! En effet, sur chatgpt.com, il est généré aléatoirement puis signé par le serveur avec un jeton qui contient aussi l'identifiant de votre compte. Les deux voyagent ainsi collés-serrés l'un à l'autre, ce qui permet donc de vous identifier très précisément. Buchodi explique sur son site qu'il n'a cependant pas observé OpenAI faire le rapprochement côté serveur, mais que ces derniers ont tout ce qu'il faut pour le faire. Sur son mobile, un même __obi est utilisé depuis 12 boutiques, dont Wayfair, HelloFresh ou encore Coursera.

Et le plus rigolo dans tout ça, c'est qu'OpenAI documente absolument tout publiquement sur ce pixel. On lit par exemple dans la doc que le SDK considère que vous y avez consenti par défaut, et que l'annonceur doit écrire une ligne de code explicite pour dire le contraire. On y lit aussi ce que le pixel récupère tout seul depuis la page du marchand : il détecte ainsi votre email, votre téléphone et votre nom, les hash en SHA-256 dans le navigateur, et envoie aussi votre ville et votre code postal en clair. Woohoo \o/ !

Maintenant, le truc qui va faire bondir la secte des adorateurs du RGPD c'est que la politique de cookies d'OpenAI, classe __obi dans la catégorie des "Cookies analytiques". Hé oui, ce sont ces fameux cookies qui, je cite "les aident à comprendre comment leurs Services fonctionnent et sont utilisés". C'est même la seule entrée de cette section dans leurs cookie policy , alors que la catégorie marketing juste en dessous nous aligne du LinkedIn, du Google, du Reddit, du Meta, du Bing et du TikTok. Voilà, donc si vous avez accepté les statistiques en refusant le marketing, bah vous l'avez quand même. "Chè" comme dirait Sam Altman !

Buchodi a donc posé la question à OpenAI et "bizarrement", le support a accusé réception mais n'a jamais répondu...

Alors est-ce que vous êtes concerné par cette saloperie ?

Eh bien ça dépend de votre navigateur. Safari, le bienheureux, bloque tous les cookies tiers par défaut depuis 2020, et comme tous les navigateurs iOS tournent sur ce moteur, aucun d'entre eux ne laisse passer le cookie d'OpenAI. Firefox, le vrai navigateur des champions, quant à lui, range les cookies dans un conteneur séparé par site depuis 2022, ce qui casse totalement le recoupement sans péter les sites. Et Chrome, le navigateur des gens qui ne tiennent pas à leur vie privée, a lui renoncé en avril 2025 à supprimer les cookies tiers, et c'est justement sur Chrome sous Android que ce mécanisme d'OpenAI a été observé.

Alors que faire ?

La bonne nouvelle, c'est que la parade la plus solide est sans doute déjà en place chez vous. EasyPrivacy, la liste antipistage activée par défaut dans uBlock Origin , contient déjà les règles ||bzr.openai.com^ et ||bzrcdn.openai.com^. Comme elles bloquent le domaine entier, elles coupent aussi la requête qui pose le cookie au départ, sur chatgpt.com. Et si vous filtrez avec un DNS grâce à un Pi-hole ou NextDNS , ajoutez ces deux domaines et vous couvrez toute la maison, téléphone sur Wifi compris.

Par contre, ne comptez pas sur Safari ou Firefox pour tout régler par défaut car ils s'occupent du cookie, mais pas du reste. En effet, la requête vers OpenAI part quand même, avec votre adresse IP, votre code postal en clair et votre email hashé si le marchand a activé la détection automatique. Et le pixel a son grand frère côté serveur, une API appelée depuis les serveurs du marchand, qu'aucun réglage de navigateur n'atteindra malheureusement.

Et ne vous dites pas que c'est une histoire uniquement américaine puisque depuis fin août, ChatGPT Ads couvre la France et 30 autres pays européens. Les pubs ne s'affichent que sur les comptes Free et Go (moi j'ai pas de cookies __obi avec mon compte payant) et le cookie se synchronise aussi quand vous êtes déconnecté.

Bref, allez jeter un œil à vos filtres. Et si vous voulez voir votre cookie __obi, il traîne dans les cookies de .openai.com.

Source : l'enquête de Buchodi et la documentation du pixel OpenAI .

Voici une bonne nouvelle du côté de Chrome puisque ce dernier a commencé à enfermer la clé qui signe votre session dans la puce de sécurité de votre machine, c'est-à-dire le TPM sous Windows, ou la Secure Enclave sous macOS. Le serveur envoie un défi, le navigateur le signe, et la clé privée ne sort jamais du silicium. Ainsi, un cookie de session recopié ailleurs ne suffit donc plus à entrer dans votre compte.

Ça s'appelle DBSC, pour device-bound session credentials et comme le résume Scott Helme, qui vient de déployer le protocole chez Report URI : "*L'attaquant peut voler le cookie, mais il ne peut pas répondre à un défi DBSC en le signant avec la clé privée, qui reste en sécurité sur votre appareil *".

Depuis que la double authentification et les passkeys se généralisent, voler un mot de passe ne rapporte plus grand-chose et c'est pour cela que les attaquants sont passés au cookie de session, un bout de texte qui prouve au site que vous êtes déjà bien connecté.

Ils le récupèrent avec un infostealer, ou avec une page de phishing qui relaie votre vraie connexion, comme le faisait la plateforme Tycoon 2FA démantelée par Europol . Ensuite ils collent le cookie dans leur navigateur et héritent de votre session. Et votre bonne vieille 2FA n'y change rien, puisqu'elle est déjà passée.

Donc ce DBSC c'est une bénédiction, surtout que côté utilisateur, il n'y a rien à activer.

Google a basculé ses propres comptes dessus fin mai, sur Chrome pour Windows, et il n'existe ni réglage administrateur ni réglage utilisateur pour le couper. Pour le reste du web, il faut évidemment que le site ait implémenté le protocole de son côté, et Chrome ne l'ouvre encore qu'à une partie des utilisateurs (dispo à partir de la version 147 sous Windows et 150 sous macOS).

Pour vérifier si c'est en place chez vous, ouvrez les outils de développement (F12) sur un site où vous êtes connecté, votre compte Google par exemple, onglet Application, et cherchez "device bound sessions". Si la ligne apparaît, c'est que c'est actif. Sinon, c'est que le site, votre version de Chrome ou votre machine ne suivent pas encore, et Chrome retombe alors sur la session classique sans rien casser.

Sur Firefox, en revanche, il ne faudra pas l'attendre car Mozilla a acté début août une position officielle négative sur le sujet. Les deux reproches que fait Mozilla c'est que DBSC laisse une fenêtre ouverte pendant laquelle un cookie volé reste utilisable, et que son flux de réauthentification est un protocole ad hoc qui ne colle pas à la gestion normale des cookies.

Mozilla craint aussi qu'on finisse par exiger des sites une attestation matérielle, ce qui limiterait le choix du matos... Google répond que rien de tel n'est prévu, et que faire signer chaque requête s'est révélé infaisable à grande échelle. Mais bon, cette position négative n'interdit pas une implémentation future... On verra bien. Apple, elle, n'a jamais tranché, mais a prévenu que DBSC risquait de compliquer la restauration d'un appareil depuis une sauvegarde.

Bref, aujourd'hui, ça se joue donc sur Chrome, et seulement là où le site a implémenté DBSC, mais je pense que ça s'étendra de plus en plus à l'avenir.

Source