Mis à jour le 1 octobre 2019 Avec ITP 2.3, il semble que Safari réduise l’utilité de localStorage De plus, l’utiliser comme solution alternative aux problèmes de persistance ne devrait pas être considéré comme pérenne. cette solution devrait ne pas être considéré comme pérenne.

Actualisé 12 mars 2019 avec quelques petites précisions..

Le 21 février 2019, WebKit a annoncé la sortie de la dernière itération de Safari Prévention du suivi intelligent (ITP), connu sous le nom d’ITP 2.1. Depuis un certain temps maintenant, Safari cible le suivi intersite avec ITP, en commençant d’abord par les cookies dans des contextes tiers, puis en resserrant l’étau après l’émergence d’un certain nombre de solutions de contournement, et enfin avec la dernière itération ciblant les cookies qui ont été déplacés d’un contexte tiers à un contexte propriétaire.

ITP 2.1 a une caractéristique spécifique qui va nous faire trembler, nous les web analytics :

Avec ITP 2.1, tous les cookies persistants côté client, c’est-à-dire les cookies persistants créés via document.cookie, sont plafonnés à un expiration de sept jours.

Du blog WebKit, j’insiste sur le mien.

Cela signifie que tout Bibliothèque JavaScript voulant stocker un cookie dans le navigateur Web, ce cookie sera limité à une durée de vie de sept jours. Sept jours après la création du cookie, le cookie expirera et sera supprimé du navigateur.

Dans cet article, je souhaite explorer les implications que cela a sur l’analyse Web et ce que nous pouvons faire pour éviter de perdre l’intégrité de nos données.

Brève introduction à ITP

Dans les chapitres suivants, j’utiliserai ces deux termes :

• Contexte tiers signifie qu’une ressource est demandée à partir d’un domaine externe à celui sur lequel se trouve actuellement l’utilisateur (c’est-à-dire qu’il ne partager le même eTLD + 1), et cette requête tente d’accéder aux cookies définis sur ce domaine externe. Étant donné que le domaine diffère de celui sur lequel se trouve l’utilisateur (doit être un domaine racine différent, en gros), l’interaction avec ce domaine externe se produit dans un contexte tiers.

• Contexte de première partie signifie qu’une ressource est demandée à partir du domaine (parent) actuel (eTLD + 1) sur lequel se trouve l’utilisateur. Étant donné que l’utilisateur se trouve dans le même environnement de domaine, toutes les requêtes effectuées se produisent dans un contexte de première partie.

PTI 1.0

Lorsque Safari a introduit pour la première fois Intelligent Tracking Prevention, sa mission était assez claire. Safari voulait empêcher les domaines classés comme ayant des capacités de suivi de suivre les utilisateurs sur différents sites à l’aide cookies tiers.

Un exemple classique est la façon dont les services de technologie publicitaire peuvent établir un profil d’audience de leurs utilisateurs en observant sur quels sites l’utilisateur visite. Pour ce faire, ces sites appellent le domaine AdTech avec une demande de pixel ou quelque chose de similaire, et un cookie tiers stocké sur le domaine AdTech pourra ainsi créer un profil de l’utilisateur basé sur les sites où le pixel a été demandé. au.

ITP a rendu cela plus difficile en exigeant que les utilisateurs interagir avec le domaine tiers dans un contexte propriétaire afin que le domaine soit autorisé à récolter ses données dans un contexte tiers. S’il n’y avait pas interaction significative comme charger la page et cliquer sur un bouton, un algorithme d’apprentissage automatique classerait le domaine comme ayant des capacités de suivi intersites, et par conséquent cloison les cookies sur ce domaine, les empêchant d’être utilisés pour le suivi intersite.

N’oubliez pas : le principal d’ITP mode opératoire est empêcher le suivi intersite. C’est intelligent Suivi La prévention, pas l’intelligence Biscuit La prévention.

Naturellement, pour AdTech, c’est gênant. Tout l’intérêt du suivi des pixels est qu’il est transparent et discret. Que penseriez-vous si vous étiez soudainement redirigé vers, par exemple doubleclick.net et vous a demandé s’il était acceptable que Google continue à créer un profil d’audience à partir de votre comportement de navigation sur le Web ?

Mais les cookies tiers peuvent également être utilisés pour à des fins autres que le suivi, telles que la gestion d’une session d’authentification unique (SSO). C’est pourquoi l’ITP d’origine a introduit une période de grâce de 24 heures pendant laquelle le cookie SSO pouvait être utilisé dans un contexte tiers. Après cela, les cookies doivent être stockés dans un contexte de première partie ou, de préférence, en se déplaçant vers Biscuits HTTP (plus à ce sujet plus tard) pour éviter complètement ces problèmes.

Les cookies seraient partitionné pendant 30 jours. Cela signifiait que les cookies utilisés à des fins de suivi obtiennent un stockage unique à double clé pour le domaine demandant le cookie (le domaine propriétaire) et le domaine définissant le cookie (domaine tiers). Ainsi, par exemple, un cookie tiers défini par google.com pendant simoahava.com ne seraient accessibles que lors de la navigation sur simoahava.com. Si l’utilisateur est allé à younggoodmanahava.comun magasin de cookies distinct sera créé pour cette origine.

Le partitionnement des cookies de cette manière signifiait que les cookies tiers pouvaient toujours être utilisés pour des choses comme la gestion de l’état de connexion. Étant donné que les partitions sont uniques à chaque combinaison d’origine, le suivi intersite serait effectivement neutralisé.

Si l’utilisateur visitait le domaine de suivi dans les 30 jours suivant la dernière interaction, la période de grâce de 24 heures et le minuteur de partition de 30 jours seraient réinitialisés.

Si la limite de 30 jours expirait sans interaction avec le domaine de suivi, tous les cookies seraient supprimés du domaine de suivi.

ITP 1.0 n’a pas eu beaucoup d’impact pour nous, utilisateurs de Google Analytics. GA fonctionne dans un contexte de première partie, donc les mises à jour d’ITP ne nous concernaient pas.

ITP 1.1 et API d’accès au stockage

Avec PTI 1.1 et l’API d’accès au stockage, ITP a fait certaines concessions aux services tiers servant du contenu intégré, tels que les connexions sociales ou les services vidéo. Il serait bizarre que l’utilisateur visite ces services dans un contexte de première partie, car tout le but de l’intégration de contenu est de le faire en douceur tout en restant sur le même site. Les API d’accès au stockage était la solution, où le contenu intégré aurait accès aux cookies stockés sur le domaine tiers tant que l’intégration suivait certaines règles :

L’API d’accès au stockage n’a demandé rien à l’utilisateur – c’était la principale concession de WebKit.

Étant donné que l’API d’accès au stockage autorisait l’accès aux propres cookies non partitionnés du domaine tiers, le partitionné les cookies conservés pour des choses comme la gestion de l’état de connexion ont été rétrogradés à cookies de session, afin qu’ils soient purgés une fois le navigateur fermé. Cela signifiait que l’API d’accès au stockage était le principal moyen d’accéder aux données persistantes dans un contexte tiers.

Toujours aucun problème avec l’analyse Web de première partie, ouf !

PTI 2.0

Mi-2018, lancement de WebKit PTI 2.0.

ITP 2.0 a complètement supprimé la période de grâce de 24 heures. Désormais, les cookies seraient partitionnés immédiatement après leur création, si le domaine était classé comme ayant des capacités de suivi intersites.

Une autre chose importante qu’ITP 2.0 a faite a été de rendre l’API d’accès au stockage basée sur les invites. Au lieu de permettre au contenu intégré d’accéder aux cookies définis dans un contexte tiers en vertu des règles établies dans le chapitre précédent, Safari demanderait désormais explicitement à l’utilisateur d’accéder au contexte tiers. Si l’utilisateur a donné l’accès, le consentement persisterait et le délai de 30 jours serait actualisé.

En d’autres termes, le API d’accès au stockage était désormais le principal moyen pour les domaines classés comme ayant des capacités de suivi intersite d’accéder à leurs cookies lorsqu’ils sont intégrés ou demandés dans un contexte tiers.

L’analyse Web de première partie est toujours sûre. Mais pas pour longtemps.

PTI 2.1

ITP 2.1 a été annoncé le 21 février 2019 et entrera en vigueur dès que iOS 12.2 et Safari 12.1 sortir de la bêta.

Mise à jour 8 mars 2019: Il semble que les fonctionnalités qui sont maintenant regroupées en tant qu’ITP 2.1 soient déjà déployées depuis le début de cette année.

ITP 2.1 supprime complètement les cookies partitionnés. Désormais, si un domaine classé comme ayant des capacités de suivi intersite a besoin d’avoir accès à ses cookies dans un contexte tiers, le API d’accès au stockage devoir être utilisé, même s’il est utilisé pour des choses comme la gestion de l’état de connexion. L’objectif principal de ce changement est de réduire la quantité de surcharge de mémoire que les cookies partitionnés (de session) introduisent sur un site donné.

Mais de loin le plus grand changement dans ITP 2.1, celui qui a conséquences directes sur le web analytics first party sont les nouvelles mesures imposées cookies internes défini avec JavaScript côté client.

ITP ne se contente plus d’attaquer les entreprises AdTech qui s’appuient sur le suivi intersite pour créer des profils d’audience. Désormais, les cookies sont définis avec document.cookie seront également ciblés pour éviter qu’ils ne soient récoltés sur des sous-domaines différents de celui sur lequel ils ont été définis.

Comme dans l’exemple ci-dessus, n’importe lequel des sous-domaines de simoahava.com peut écrire un cookie propriétaire sur ce domaine racine, après quoi quelconque sous-domaine de simoahava.com peut accéder à ce cookie. Ce n’est pas nouveau – c’est ainsi que les cookies définis sur un domaine racine ont toujours fonctionné.

Cependant, ITP cible désormais les cookies définis avec JavaScript document.cookie car il est devenu évident que certains vendeurs (par exemple un dont le nom rime avec livre de dentelle) ont commencé à réaffecter les cookies propriétaires pour les aider dans leurs intentions de suivi intersites. Ils profitent également du scénario décrit dans l’image ci-dessus. Même si vous avez limité le déclenchement des pixels de ces fournisseurs uniquement sur un sous-domaine spécifique, ils pourraient toujours accéder aux cookies sur des noms de domaine de niveau supérieur.

L’impact sur l’analyse Web est brutal, en fonction bien sûr de la part de Safari dans votre trafic. Prenons l’exemple suivant :

• Jour 1: Visites d’utilisateurs www.simoahava.comles _ga cookie est écrit sur simoahava.com. Il est fixé à une expiration de 7 jours (plutôt que les 2 ans par défaut d’analytics.js).

• Jour 3: Visites d’utilisateurs blog.simoahava.com. Les _ga cookie se trouve sur simoahava.com, sa valeur est donc disponible sur blog.simoahava.com et l’expiration de 7 jours est réinitialisée.

• Jour 13: Visites d’utilisateurs www.simoahava.com. Les _ga cookie a expiré, donc un nouvel identifiant client est généré dans un nouveau _ga cookie, et le visiteur est traité comme un nouvel utilisateur dans Google Analytics.

Google Analytics utilise document.cookie pour définir le cookie dans le navigateur. Il n’a vraiment pas d’autre choix. Il s’agit d’une bibliothèque JavaScript fournie, téléchargée à partir des serveurs de Google, elle n’a donc pas la capacité de définir, par exemple, des cookies HTTP sur simoahava.com, car ils seraient définis dans un contexte tiers.

Curieusement, ITP 2.1 supprime la prise en charge de la Ne pas suivre signal dans Safari, marquant la fin de cette misérable expérience dans WebKit. Si davantage de sites avaient respecté le DNT pour déterminer si les visiteurs devaient être suivis ou non, nous n’aurions peut-être pas vu ITP 2.1 dans sa forme actuelle.

Mais parce qu’on ne peut pas faire confiance aux sites pour gérer seuls la confidentialité et la prévention du suivi, Safari doit maintenant prendre les rênes et le faire pour eux.

Implications techniques et solutions

Tout d’abord, ITP 2.1 n’impacte vraiment que cookies du navigateur Fixé avec document.cookie. Ce sera ne pas impact sur d’autres stockages DOM (tels que localStorage), car ceux-ci sont uniquement de même origine, et n’ont donc pas la capacité de travailler sur plusieurs sous-domaines. De même, il va ne pas les cookies d’impact définis avec des réponses HTTP, c’est-à-dire en utilisant le Set-Cookie en-tête dans la réponse HTTP.

Les cookies HTTP nécessitent un script côté serveur (ou un cache périphérique / solution sans serveur) pour modifier la réponse HTTP, c’est donc une décision délibérée du propriétaire du site de définir les cookies dans le contexte de première partie plutôt qu’une bibliothèque JavaScript téléchargée à partir d’un CDN pouvant, à sa guise, définir et obtenir tous les cookies propriétaires qu’il souhaite. Je suppose que c’est pourquoi ils ne sont pas (encore) impactés par ITP.

localStorage pour la navigation sur le même domaine

Mise à jour 1 octobre 2019: Avec ITP 2.3, localStorage devraient ne pas être considéré comme une solution viable pour la persistance de l’état côté client.

Beaucoup ont suggéré d’utiliser localStorage pour conserver ces identifiants anonymes utilisés par Google Analytics, par exemple. Au lieu de déposer un cookie nommé _gautiliser window.localStorage.setItem() au lieu.

J’étais enthousiasmé par cette option et j’ai même écrit un article qui décrit cette possibilité en détail.

Cependant, le principal problème est que localStorage est uniquement de même origine. Le stockage dans www.simoahava.com ne sera pas disponible sur blog.simoahava.com.

Ainsi la seule chose qui localStorage résout en fait le fait de ne pas avoir le plafond d’expiration de 7 jours sur les données stockées sur un seul domaine. Étant donné que tout mon trafic Web se produit sur www.simoahava.com, localStorage est une bonne option pour moi, car il conserve bien l’ID client (mais avec quelques mises en garde néanmoins).

localStorage pour la navigation entre sous-domaines

Merci à Eike Pierstorff et Fujii Hironori pour avoir proposé cette solution.

Une option alternative au même domaine localStorage est de créer un boutique sur une page dans l’un de vos sous-domaines, puis chargez cette page dans un iframe élément, en utilisant le postMessage API pour obtenir et définir des valeurs de cookies persistants sur votre site.

Depuis le localStorage store partage le même domaine parent eTLD + 1 avec les pages faisant les demandes via l’iframe, l’interaction se produit dans un contexte de première partie, et le localStorage store est accessible sans l’API d’accès au stockage. Aussi dans contextes tiers, localStorage est transitoire dans Safari, ce qui signifie qu’il est purgé après la fermeture du navigateur. Dans un contexte de première partie, ce n’est pas le cas.

Le processus ressemblerait à ceci.

1. La page souhaitant accéder au magasin chargerait la page de suivi dans une iframe et lui enverrait un message demandant un ID client stocké.

2. L’iframe vérifie si l’ID client est stocké. Si c’est le cas, il le renvoie dans un message vers la page d’origine. Si ce n’est pas le cas, il renvoie une chaîne l’indiquant.

3. Sur la page d’origine, un écouteur écoute la réponse. Si la réponse a un ID client, celui-ci est utilisé dans les trackers exécutés sur la page. Si la réponse a un indicateur “null”, la page d’origine construit l’ID client et le renvoie finalement avec un autre message dans l’iframe pour le stockage.

Voici à quoi ressemblerait le script de la page parent :

// Create iframe var el = document.createElement('iframe'); el.src = 'https://www.maindomain.com/tracker.html'; el.setAttribute('style', 'width:0;height:0;border:0;border:none'); document.body.appendChild(el);  // Add listener to get the stored Client ID window.addEventListener('message', function(e) {   if (e.origin !== 'https://www.maindomain.com') { return; }   if (e.data === 'null') { generateTracker(null); }   else { generateTracker(e.data); } });  // Send request to get the Client ID el.contentWindow.postMessage('get', 'https://www.maindomain.com');  // Send message to set the Client ID after the tracker has generated one function trackerGeneratedCallback(clientId) {   el.contentWindow.postMessage(clientId, 'https://www.maindomain.com'); } 

Ici, l’iframe est généré, après quoi un message est envoyé à l’iframe pour obtenir l’ID client. Un écouteur sur la page attend ensuite que l’iframe réponde. Si l’iframe répond par un 'null' message, un nouveau tracker est généré (generateTracker) avec son mécanisme de génération d’ID client par défaut.

Si l’iframe répond avec l’ID client stocké, un nouveau tracker est généré avec cet ID client stocké à la place.

Si le traqueur fait générer un nouvel identifiant client, puis le trackerGeneratedCallback est appelé par la suite, et cela envoie l’ID client à la page de suivi pour le stockage.

Et voici à quoi ressemblerait la page iframe :

<html> <head> <meta name="robots" content="noindex,nofollow"> <script>   // Check the request comes from *.maindomain.com   var hostNameRegex = /^https:\/\/([^.]+\.)maindomain\.com/;      function processMessage(event) {     if (!hostnameRegex.test(event.origin)) {       return;     }          // If request is to get the clientId, send it as a message back to the source page     // or send 'null' if no Client ID is found.     if (event.data === 'get') {       event.source.postMessage(window.localStorage.getItem('ga_client_id') || 'null', event.origin);       return;     }          // Otherwise, set the Client ID in localStorage using the message content     window.localStorage.setItem('ga_client_id', event.data);     return,   }      // Add a listener to listen for postMessage messages   window.addEventListener('message', processMessage); </script> </head> <body> </body> </html>

De cette façon, vous pouvez conserver toutes les valeurs de cookie côté client dans le localStorage magasin du domaine où se trouve l’iframe. Cet exemple concerne uniquement un ID client arbitraire, mais vous pouvez l’étendre à toute valeur transmise dans le message.

N’oubliez pas les idiosyncrasies de chaque plate-forme. Avec Google Analytics, par exemple, des mesures supplémentaires doivent être prises pour gérer le suivi inter-domaines, l’expiration des cookies, etc.

En-têtes Set-Cookie dans un script côté serveur

Mise à jour 1 octobre 2019: C’est certainement le moyen le plus efficace de conserver l’état côté client. Voir cet article pour vous inspirer.

Au lieu de régler le _ga biscuit avec document.cookie, vous pouvez à la place le définir avec la réponse HTTP. Par exemple, si vous exécutez un node.js Serveur Express, vous pourriez avoir les lignes suivantes dans votre code :

app.get('/', (req, res) => {   // Check for existing cookie and use that if found   let ga = req.cookies['_ga'];      // Check for linker and use that if valid   if (req.query['_ga']) {     ga = getClientIdFromLinker(req.query['_ga']) || ga;   }      // Otherwise generate a new Client ID   if (!ga) {     ga = generateGAClientId();   }      res.cookie('_ga', ga, {domain: 'simoahava.com', path: '/', secure: true, expires: new Date(Date.now() + 1000*60*60*24*365*2), });      res.render('index'); }); 

Dans cet exemple, lorsque la page d’accueil est demandée au serveur, ses cookies sont analysés. Si la _ga cookie est trouvé, sa valeur est stockée en tant que variable locale. Ensuite, si la requête a également le paramètre de l’éditeur de liens inter-domaines, la validité du paramètre est vérifiée (en utilisant par exemple mon Gist) et s’il s’agit d’un paramètre valide, la variable locale est remplacée par l’ID client de l’éditeur de liens.

REMARQUE! Les allowLinker le script construit l’empreinte digitale en utilisant, entre autres, les API basées sur le navigateur window.navigator.plugins et window.navigator.language. Comme ceux-ci ne sont pas disponibles dans les en-têtes HTTP, vous devez les transmettre au serveur avec la charge utile de la requête que vous utiliseriez pour acheminer les cookies, puis modifier le allowLinker script pour utiliser ces paramètres de charge utile plutôt que le window.navigator Apis. Alternativement, vous pouvez créer votre propre solution de liens inter-domaines.

Enfin, si le _ga le cookie n’existait pas et si l’éditeur de liens inter-domaines était manquant ou cassé, un nouvel ID client est généré.

Dans la réponse HTTP, le _ga cookie est défini avec cette valeur et son expiration est réinitialisée à deux ans.

Ce type de configuration côté serveur devrait être simple à réaliser dans presque tous les environnements de serveur Web (PHP/Apache, React, Node.js, IIS, etc.). Mais vous avez besoin d’accéder au serveur Web et à ses gestionnaires de requêtes pour pouvoir le faire.

En-têtes Set-Cookie dans un cache périphérique

Si vous utilisez un service tel que Cloudflare, qui met en cache le contenu de votre serveur sur « la périphérie », vous pouvez également exécuter JavaScript pour intercepter et gérer les requêtes HTTP entre le navigateur et Cloudflare. Sur Cloudflare, cette technologie s’appelle Cloudflare Workers. Amazon a une solution similaire appelée [email protected].

L’idée est que lorsque la demande HTTP de contenu arrive, un script s’exécutant à la périphérie “réécrit” tous les cookies dans l’en-tête HTTP avec Set-Cookie,…