Tiers

Qu'est-ce qu'un tiers ?

Il est assez rare qu'un site Web soit totalement autonome. Le HTTP Web Almanac montre que la plupart des sites Web (environ 95 %) comportent du contenu tiers.

Il définit un contenu tiers comme étant hébergé sur une origine partagée et publique, largement utilisé par une variété de sites et non influencé par un propriétaire de site individuel. Il peut s'agir d'images ou d'autres supports tels que des vidéos, des polices ou des scripts. Les images et les scripts représentent plus que tout ce qui est additionné. Le contenu tiers n'est pas essentiel au développement d'un site, mais c'est peut-être aussi le cas. Vous utiliserez très certainement un élément chargé à partir d'un serveur partagé public, qu'il s'agisse de polices Web, de cadres iFrame de vidéos, d'annonces ou de bibliothèques JavaScript. Par exemple, vous utilisez peut-être des polices Web diffusées par Google Fonts ou vous mesurez les données analytiques avec Google Analytics. Vous avez peut-être ajouté des boutons "J'aime" ou "Se connecter avec" à partir de réseaux sociaux, vous pouvez intégrer des cartes ou des vidéos, ou gérer les achats via des services tiers, et vous pouvez suivre les erreurs et la journalisation de vos propres équipes de développement via des outils de surveillance tiers.

Pour des raisons de confidentialité, il est utile d'envisager une définition légèrement différente et moins large: une ressource tierce, et en particulier un script tiers, est diffusée à partir d'une origine partagée et publique et largement utilisée comme illustré, mais elle a également été créée par une personne autre que le propriétaire du site. L'aspect des droits d'auteur de tiers est essentiel lorsque vous envisagez de protéger la vie privée de vos utilisateurs. Cela vous mènera à réfléchir aux risques présents, puis à décider comment ou s'il faut utiliser une ressource tierce en fonction de ces risques. Comme nous l'avons déjà vu, ces éléments vous aideront à comprendre le contexte et, par conséquent, à comprendre les compromis que vous devez faire et ce qu'ils signifient.

Ce n'est pas tout à fait ce que l'on entend par "ressources tierces" en général: la distinction entre les données propriétaires et tierces concerne en fait le contexte dans lequel un élément est utilisé. Un script chargé depuis un autre site Web est une ressource tierce. La requête HTTP qui charge le script peut inclure des cookies, qui ne sont pas réellement des "cookies tiers". Ce ne sont que des cookies, et leur état varie selon que le script est chargé sur une page de votre site ou sur celui de son propriétaire.

Pourquoi utilisons-nous des ressources tierces ?

Les applications tierces sont un excellent moyen d'ajouter des fonctionnalités à votre site. Il peut s'agir de fonctionnalités exposées aux utilisateurs ou de fonctions de développeur invisibles telles que le suivi des erreurs, mais elles réduisent votre charge de développement et les scripts eux-mêmes sont gérés par quelqu'un d'autre: l'équipe de développement du service que vous incluez. Tout cela grâce à la composabilité du Web, c'est-à-dire à la possibilité d'assembler des parties pour former un tout supérieur à leur somme.

L'almanac Web des archives HTTP en donne une belle description:

Les tiers fournissent une collection sans fin d'images, de vidéos, de polices, d'outils, de bibliothèques, de widgets, d'outils de suivi, d'annonces et de tout ce que vous pouvez imaginer intégrer dans nos pages Web. Cela permet même aux utilisateurs les moins techniques de créer et de publier du contenu sur le Web. Sans tiers, le Web serait probablement un support académique textuel très ennuyeux plutôt que cette plate-forme riche, immersive et complexe qui fait partie intégrante de la vie de nombreux d'entre nous aujourd'hui.

Quel est l'intérêt des ressources tierces ?

Accéder à certaines informations

Lorsque vous utilisez une ressource tierce sur votre site Web, quel qu'en soit le contenu, certaines informations lui sont transmises. Par exemple, si vous incluez une image provenant d'un autre site, la requête HTTP effectuée par le navigateur de l'utilisateur transmet un en-tête "Referer" avec l'URL de votre page, ainsi que l'adresse IP de l'utilisateur.

Suivi intersites

Reprenons le même exemple. Lorsque l'image se charge à partir du site tiers, elle peut inclure un cookie, qui sera renvoyé au tiers la prochaine fois que l'utilisateur demandera cette image. Cela signifie que le tiers peut savoir que son service est utilisé sur votre site et qu'il peut renvoyer un cookie, potentiellement avec un identifiant unique pour cet utilisateur. Cela signifie que la prochaine fois que l'utilisateur visitera votre site ou tout autre site incluant une ressource de ce tiers, ce cookie d'ID unique sera de nouveau envoyé. Cela permet au tiers de créer un journal indiquant les endroits où cet utilisateur visite: votre site, les autres sites utilisant la même ressource tierce, partout sur le Web.

Le suivi intersites permet à un tiers de collecter un journal de l'activité d'un utilisateur sur de nombreux sites Web, à condition que ces sites utilisent tous une ressource provenant du même tiers. Il peut s'agir d'une police, d'une image ou d'une feuille de style : il s'agit de ressources statiques. Il peut également s'agir d'une ressource dynamique: un script, un bouton pour les réseaux sociaux ou une publicité. Le script inclus peut collecter encore plus d'informations, car il est dynamique: il peut inspecter le navigateur et l'environnement de l'utilisateur, et transmettre ces données à son origine. N'importe quel script peut effectuer cette opération dans une certaine mesure, de même que les ressources dynamiques qui ne se présentent pas comme un script, comme une intégration de réseau social, une annonce ou un bouton de partage. Si vous examinez les détails d'une bannière de cookie sur les sites Web populaires, vous pouvez voir une liste des organisations susceptibles d'ajouter un cookie de suivi à vos utilisateurs afin d'établir une image de leurs activités et de créer un profil de cet utilisateur. Il peut y en avoir des centaines. Si un tiers offre un service sans frais, cela peut être économiquement viable pour lui de collecter, puis de monétiser ces données.

Le modèle "Target Privacy Threat Model" constitue un guide utile sur les types de problèmes liés à la confidentialité qu'un navigateur doit protéger pour ses utilisateurs. Ce document est encore en cours de discussion au moment de la rédaction de ce document, mais il donne des classifications générales sur les types de menaces qui pèsent sur la confidentialité. Les risques liés aux ressources tierces sont principalement la "reconnaissance intersites indésirable", qui permet à un site Web d'identifier le même utilisateur sur plusieurs sites, et la "divulgation d'informations sensibles", qui consiste à collecter des informations qu'un utilisateur considère comme sensibles.

Il s'agit d'une différence clé: la reconnaissance intersite non désirée n'est pas efficace, même si le tiers ne collecte pas d'informations sensibles supplémentaires à partir de celle-ci, car elle lui retire le contrôle de son identité. Accéder à l'URL de provenance, à l'adresse IP et aux cookies d'un utilisateur est, en soi, une divulgation indésirable. L'utilisation de ressources tierces s'accompagne d'un composant de planification qui vous permet de savoir comment les utiliser dans le respect de la confidentialité. Certaines de ces tâches vous incombent en tant que développeur du site, d'autres sont effectuées par le navigateur en tant qu'user-agent, c'est-à-dire l'agent agissant pour le compte de l'utilisateur afin d'éviter la divulgation d'informations sensibles et la reconnaissance intersites indésirable dans la mesure du possible. Nous examinerons ci-dessous plus en détail les mesures d'atténuation et les approches à adopter au niveau du navigateur et du développement d'un site.

Code tiers côté serveur

Notre précédente définition d'un tiers a délibérément modifié l'approche plutôt côté client de l'almanach HTTP (comme c'est le cas pour son rapport !), afin d'inclure les informations relatives à l'auteur d'un tiers. En effet, du point de vue de la confidentialité, un tiers est toute personne qui n'est pas vous concernant vos utilisateurs.

Cela inclut les tiers qui fournissent des services que vous utilisez sur le serveur, ainsi que le client. En ce qui concerne la confidentialité, il est également important de comprendre l'utilisation d'une bibliothèque tierce (telle qu'un élément inclus dans NPM, Composer ou NuGet). Vos dépendances transmettent-elles des données en dehors de vos frontières ? Si vous transmettez des données à un service de journalisation ou à une base de données hébergée à distance, si vous incluez également le terme "phone home" pour leurs auteurs, ces bibliothèques risquent de porter atteinte à la vie privée de vos utilisateurs et doivent donc être auditées. Vous devez généralement remettre les données utilisateur à un tiers basé sur un serveur, ce qui signifie que les données auxquelles il est exposé sont plus sous votre contrôle. En revanche, un tiers basé sur un client (un script ou une ressource HTTP inclus sur votre site Web et récupéré par le navigateur de l'utilisateur) peut collecter certaines données directement auprès de l'utilisateur sans que vous ayez recours à la médiation. Dans ce module, nous verrons en grande partie comment identifier les tiers côté client que vous avez choisi d'inclure et auxquels vous avez choisi d'inclure et d'exposer vos utilisateurs, en raison de la diminution de la capacité de médiation que vous pouvez implémenter. Toutefois, il peut être utile de sécuriser votre code côté serveur afin de comprendre les communications sortantes qui en découlent, et de pouvoir consigner ou bloquer toute situation inattendue. Les détails de la procédure à suivre n'entrent pas dans le cadre de ce cours (et dépendent de la configuration de votre serveur), mais il s'agit d'un autre aspect de votre stratégie de sécurité et de confidentialité.

Pourquoi devez-vous faire preuve de prudence avec les tiers ?

Les fonctionnalités et scripts tiers sont très importants, et notre objectif, en tant que développeurs Web, devrait être d'intégrer ces éléments, et non de les quitter. Mais il existe des problèmes potentiels. Le contenu tiers peut entraîner des problèmes de performances et de sécurité, car vous intégrez un service externe dans votre limite de confiance. Mais le contenu tiers peut aussi poser des problèmes de confidentialité.

Lorsque nous parlons de ressources tierces sur le Web, il est utile de considérer les problèmes de sécurité comme (entre autres) où un tiers peut voler des données à votre entreprise et les problèmes de confidentialité, qui peuvent (entre autres) lorsqu'un tiers que vous avez inclus vole ou obtient l'accès aux données de vos utilisateurs sans votre (ou eux) consentement.

Voici un exemple de problème de sécurité : des "web skimmers" volent les informations de carte de crédit. Une ressource tierce incluse sur une page sur laquelle un utilisateur saisit des informations de carte de crédit peut potentiellement dérober ces informations et les envoyer au tiers malveillant. Les créateurs de ces scripts sont très créatifs pour trouver des endroits où les cacher. Un résumé décrit comment les scripts skimmer ont été masqués dans des contenus tiers, tels que les images utilisées pour les logos de sites, les favicons et les réseaux de réseaux sociaux, les bibliothèques populaires telles que jQuery, Modernizr et Google Tag Manager, les widgets de site tels que les fenêtres de chat en direct et les fichiers CSS.

Les problèmes de confidentialité sont un peu différents. Ces tiers font partie de votre offre. Pour préserver la confiance de vos utilisateurs, vous devez être sûr qu'ils peuvent leur faire confiance. Si un tiers que vous utilisez collecte des données sur vos utilisateurs, puis les utilise à mauvais escient, qu'il est difficile de les supprimer ou de les détecter, ou qu'il est victime d'une violation des données, ou encore qui enfreint les attentes de vos utilisateurs, ceux-ci perçoivent probablement cette baisse dans la confiance qu'ils portent à votre service, et pas seulement au tiers. Il s'agit de votre réputation et de votre relation en ligne. C'est pourquoi il est important de vous demander si vous faites confiance aux tiers que vous utilisez sur votre site.

Pouvez-vous me donner des exemples de tiers ?

En général, nous parlons des "tiers", mais il en existe en réalité différents types et ils ont accès à différentes quantités de données utilisateur. Par exemple, l'ajout d'un élément <img> à votre code HTML, chargé à partir d'un autre serveur, donnera à ce serveur des informations sur vos utilisateurs différentes de celles que l'ajout pourrait avoir sur vos utilisateurs avec <iframe> ou <script>. Il s'agit d'exemples plutôt que d'une liste complète, mais il est utile de comprendre les différences entre les différents types d'éléments tiers que votre site peut utiliser.

Demander une ressource intersite

Une ressource intersite désigne tout élément de votre site chargé depuis un site différent et qui n'est ni <iframe>, ni <script>. Exemples : <img>, <audio>, <video>, les polices Web chargées par le CSS et les textures WebGL. Elles sont toutes chargées via une requête HTTP et, comme décrit précédemment, ces requêtes HTTP incluent tous les cookies précédemment définis par l'autre site, l'adresse IP de l'utilisateur à l'origine de la demande et l'URL de la page actuelle en tant qu'URL de provenance. Toutes les requêtes tierces incluaient historiquement ces données par défaut, bien que nous ayons des efforts pour réduire ou isoler les données transmises à des tiers par différents navigateurs, comme décrit dans la section "Comprendre les protections des navigateurs tiers" plus loin.

Intégrer un iFrame intersite

Un document complet intégré à vos pages via un <iframe> peut demander un accès supplémentaire aux API de navigateur, en plus des trois points suivants : cookies, adresse IP et URL de provenance. Les API disponibles pour les pages <iframe>d et la façon dont elles demandent l'accès sont spécifiques à chaque navigateur. Elles sont en cours de modification. Consultez la section "Règles relatives aux autorisations" ci-dessous pour connaître les mesures actuellement prises pour limiter ou surveiller l'accès aux API dans les documents intégrés.

Exécuter du code JavaScript intersite

L'inclusion d'un élément <script> charge et exécute du code JavaScript intersite dans le contexte de premier niveau de votre page. Cela signifie que le script qui s'exécute dispose d'un accès complet à tout ce que font vos scripts propriétaires. Les autorisations de navigateur gèrent toujours ces données. Par conséquent, l'accord de l'utilisateur reste nécessaire pour demander la position de l'utilisateur (par exemple, pour demander la position de l'utilisateur). Cependant, toutes les informations présentes sur la page ou disponibles en tant que variables JavaScript peuvent être lues par un tel script. Cela inclut non seulement les cookies transmis au tiers dans le cadre de la requête, mais également les cookies destinés uniquement à votre site. De même, un script tiers chargé sur votre page peut effectuer les mêmes requêtes HTTP que votre propre code, ce qui signifie qu'il peut envoyer des requêtes fetch() à vos API backend pour obtenir des données.

Inclure des bibliothèques tierces dans vos dépendances

Comme décrit précédemment, votre code côté serveur comprendra probablement également des dépendances tierces, qui ne peuvent pas être distinguées de votre propre code en leur possession. Le code que vous incluez à partir d'un dépôt GitHub ou de la bibliothèque de votre langage de programmation (npm, PyPI, composer, etc.) peut lire toutes les données que votre autre code peut lire.

Connaître vos tiers

Par conséquent, vous devez bien comprendre votre liste de fournisseurs tiers, ainsi que leurs positions et règles en matière de confidentialité, de collecte des données et d'expérience utilisateur. Cette compréhension fait alors partie de votre série de compromis: le service est-il utile et important ? Il convient de trouver un juste équilibre par rapport à l'importance des demandes des utilisateurs, gênantes, gênantes ou inquiétantes. Le contenu tiers est utile, car il vous permet de vous concentrer sur vos compétences de base en tant que propriétaire du site et vous permet de vous concentrer sur vos compétences de base. Il est donc important de faire ce compromis et de sacrifier le confort et la confidentialité des utilisateurs au profit d'une meilleure expérience utilisateur. Il est important de ne pas confondre l'expérience utilisateur avec celle du développeur: "il est plus facile pour notre équipe de développement de créer le service" n'est pas convaincante pour les utilisateurs.

Le processus d'audit permet d'obtenir cette compréhension.

Auditer des tiers

Comprendre ce que fait un tiers est un processus d'audit. Vous pouvez le faire d'un point de vue technique ou non, mais aussi pour un tiers individuel et pour l'ensemble de votre collection.

Effectuer un audit non technique

La première étape n'est pas technique: lisez les règles de confidentialité de vos fournisseurs. Si vous incluez des ressources tierces, consultez les règles de confidentialité. Ils seront longs et remplis de textes juridiques. Certains documents pourront utiliser certaines approches contre lesquelles les modules précédents ont particulièrement mis en garde, telles que des déclarations trop générales, sans aucune indication sur la manière ou le moment de suppression des données collectées. Il est important de comprendre que du point de vue de l'utilisateur, toutes les données collectées sur votre site, y compris par des tiers, seront régies par ces règles de confidentialité. Même si vous faites tout correctement, si vous êtes transparent sur vos objectifs et que vous dépassez les attentes de vos utilisateurs en termes de confidentialité et de sensibilité des données, les utilisateurs peuvent vous rendre responsable de tout ce que font également les tiers que vous avez choisis. Si leurs règles de confidentialité contiennent des éléments que vous ne souhaitez pas mentionner dans vos propres règles, car cela diminuerait la confiance des utilisateurs, demandez-vous s'il existe un autre fournisseur.

Cela peut aller de pair avec l'audit technique abordé plus loin, car ils s'informent mutuellement. Vous devez connaître les ressources tierces que vous intégrez pour des raisons commerciales (réseaux publicitaires ou contenu intégré, par exemple), car il existera une relation commerciale. C'est le bon point de départ pour un audit non technique. L'audit technique est également susceptible d'identifier des tiers, en particulier ceux inclus pour des raisons techniques plutôt que commerciales (composants externes, analyses, bibliothèques d'utilitaires). Cette liste peut être jointe à celle des tiers axés sur les entreprises. L'objectif ici est que, en tant que propriétaire du site, vous compreniez les activités des tiers que vous ajoutez à votre site. En tant qu'entreprise, vous devez pouvoir présenter à votre conseiller juridique cet inventaire de tiers afin de vous assurer de respecter les obligations requises.

Réaliser un audit technique

Pour un audit technique, il est important d'utiliser les ressources in situ dans le cadre du site Web. En d'autres termes, ne chargez pas une dépendance dans un atelier de test et ne l'inspectez pas de cette manière. Assurez-vous de voir comment vos dépendances agissent sur votre site Web réel, déployé sur l'Internet public plutôt qu'en mode test ou développement. C'est très instructif de voir votre propre site web comme un nouvel utilisateur. Ouvrez un navigateur avec un nouveau profil, de sorte que vous n'êtes pas connecté et que vous n'ayez pas d'accord enregistré, puis essayez d'accéder à votre site.

Inscrivez-vous sur votre propre site pour créer un compte, si vous fournissez des comptes d'utilisateurs. Votre équipe de conception aura organisé ce nouveau processus d'acquisition d'utilisateurs du point de vue de l'expérience utilisateur, mais il peut être illustratif d'aborder ce processus du point de vue de la confidentialité. Ne vous contentez pas de cliquer sur "Accepter" dans les conditions d'utilisation, l'avertissement relatif aux cookies ou les règles de confidentialité. Définissez-vous la tâche d'utiliser votre propre service sans divulguer d'informations personnelles ni utiliser de cookies de suivi, et voyez si vous pouvez le faire et à quel point il est difficile de le faire. Il peut également être utile d'examiner les outils pour les développeurs pour navigateur afin de voir quels sites sont consultés et quelles données sont transmises à ces sites. Les outils pour les développeurs fournissent une liste de requêtes HTTP distinctes (généralement dans une section appelée "Réseau"). Vous pouvez y voir les requêtes regroupées par type (HTML, CSS, images, polices, JavaScript, requêtes lancées par JavaScript). Il est également possible d'ajouter une colonne pour indiquer le domaine de chaque requête, ce qui indiquera le nombre de lieux différents contactés. Une case à cocher "Demandes tierces" peut également s'afficher pour n'afficher que les tiers. (Il peut également être utile d'utiliser les rapports Content-Security-Policy pour effectuer un audit continu. Pour en savoir plus, consultez la suite.)

Le générateur de cartes des requêtes de Simon Hearne peut également fournir un aperçu utile de toutes les sous-requêtes envoyées par une page accessible au public.

C'est également à ce stade que vous pouvez inclure les tiers axés sur les activités identifiés dans le cadre de l'audit non technique (c'est-à-dire la liste des entreprises avec lesquelles vous entretenez une relation financière afin d'utiliser leurs ressources). L'objectif est de faire correspondre la liste des tiers que vous pensez utiliser (à partir des documents financiers et juridiques) et la liste que vous utilisez réellement (en examinant les requêtes HTTP tierces envoyées par votre site Web). Vous devriez être en mesure d'identifier, pour chaque entreprise tierce, les requêtes techniques sortantes qui sont effectuées. Si vous ne pouvez pas identifier de demandes dans l'audit technique pour un tiers identifié par une relation commerciale, il est important de déterminer pourquoi et de vous en inspirer pour vos tests. Peut-être que cette ressource tierce n'est chargée que dans un pays particulier, sur un type d'appareil particulier ou pour des utilisateurs connectés. Cela élargit la liste des zones de site à auditer et permet de garantir que vous voyez tous les accès sortants. (Il peut également identifier une ressource tierce que vous payez, mais que vous n'utilisez pas, ce qui est toujours encourageant le service financier.)

Une fois que vous avez réduit la liste des requêtes adressées à des tiers que vous souhaitez inclure dans l'audit, cliquez sur une requête individuelle pour afficher tous les détails la concernant et en particulier les données qui lui ont été transmises. De plus, il est très courant qu'une requête tierce lancée par votre code envoie ensuite de nombreuses autres requêtes tierces. Ces tiers supplémentaires sont également "importés" dans vos propres règles de confidentialité. Cette tâche laborieuse, mais précieuse, et peut souvent être insérée dans des analyses existantes. Votre équipe de développement de l'interface doit déjà procéder à un audit des demandes pour des raisons de performances (peut-être à l'aide d'outils existants tels que WebPageTest ou Lighthouse). Intégrer un audit des données et de la confidentialité dans ce processus peut faciliter ce processus.

Plan de requêtes web.dev
Un mappage de requêtes (dramatiquement simplifié) pour web.dev, montrant des sites tiers qui demandent l'accès à d'autres sites tiers, etc.

À faire

Ouvrez un navigateur avec un nouveau profil utilisateur correct, de sorte que vous n'êtes pas connecté et que vous n'ayez pas d'accord stocké. Ouvrez ensuite le panneau "Network" des outils de développement pour navigateur pour afficher toutes les requêtes sortantes. Ajoutez une colonne pour afficher le domaine de chaque requête, puis cochez la case "Demandes tierces" pour n'afficher que les tiers, le cas échéant. Ensuite :

  • Accédez à votre site.
  • créer un compte, si vous fournissez des comptes d'utilisateurs ;
  • Essayez de supprimer le compte que vous avez créé.
  • Effectuez une ou deux actions normales sur le site (la procédure exacte dépend des actions de votre site, mais choisissez des actions courantes que la plupart des utilisateurs effectuent).
  • Effectuez une ou deux actions qui impliquent, comme vous le savez, des dépendances tierces. Il peut s'agir de partager du contenu sur les réseaux sociaux, de lancer un processus de paiement ou d'intégrer du contenu à partir d'un autre site.

Lors de l'exécution de chacune de ces tâches, enregistrez les ressources demandées à partir de domaines qui ne vous appartiennent pas en consultant le panneau "Network" (Réseau), comme décrit ci-dessus. Voici quelques-uns de vos tiers. Pour ce faire, un bon moyen d'effectuer cette opération consiste à utiliser les outils réseau du navigateur pour capturer les journaux de requête réseau dans un fichier HAR.

Fichiers HAR et capture

Un fichier HAR est un format JSON standardisé de toutes les requêtes réseau effectuées par une page. Pour obtenir un fichier HAR pour une page spécifique, saisissez:

Chrome

Ouvrez les outils de développement du navigateur (Menu > More Tools > Developer Tools), accédez au panneau "Network" (Réseau), chargez (ou actualisez) la page, puis sélectionnez la flèche vers le bas en haut à droite à côté du menu déroulant "No throttling" (Aucune limitation).

Panneau réseau Outils pour les développeurs Chrome, avec le symbole &quot;Télécharger le fichier HAR&quot; encadré
Firefox

Ouvrez les outils pour les développeurs du navigateur (Menu > Plus d'outils > Outils de développement Web), accédez au panneau "Network" (Réseau), chargez (ou actualisez) la page, puis sélectionnez le symbole en forme de roue dentée en haut à droite, à côté du menu déroulant de limitation. Dans son menu, sélectionnez Save All As HAR (Enregistrer tout en tant que HAR)**.

Panneau réseau des outils pour les développeurs Firefox avec l&#39;option &quot;Save All As Har&quot; mise en surbrillance
Safari

Ouvrez les outils pour les développeurs du navigateur (Menu > Développer > Afficher l'outil d'inspection Web. Si vous n'avez pas de menu Développement, activez-le depuis Menu > Safari > Préférences > Avancé > Afficher le menu Développement dans la barre de menu), accédez au panneau "Réseau", chargez (ou actualisez) la page, puis sélectionnez Exporter en haut à droite (à droite de "Conserver le journal"). Vous devrez peut-être agrandir la fenêtre.

Panneau &quot;Réseau&quot; de Safari Web Inspector, avec l&#39;option d&#39;exportation au format HAR encadrée

Pour plus de détails, vous pouvez également enregistrer ce qui est transmis à des tiers (dans la section "Requête"), bien que ces données soient souvent obscurcies et peu interprétables.

Bonnes pratiques relatives à l'intégration de services tiers

Vous pouvez définir vos propres règles concernant les tiers utilisés par votre site: changer le fournisseur d'annonces que vous utilisez en fonction de leurs pratiques, ou déterminer si les fenêtres pop-up de consentement aux cookies sont agaçantes ou intrusives, ou si vous souhaitez utiliser des boutons de réseaux sociaux sur votre site ou des liens de suivi dans vos e-mails ou des liens utm_campaign pour suivre dans Google Analytics dans vos tweets. Un aspect à prendre en compte lors du développement d'un site est la stratégie de confidentialité et de sécurité de votre service d'analyse. Certains services d’analytique échangent explicitement sur la protection de la vie privée. Souvent, il existe également des moyens d'utiliser un script tiers qui ajoute une protection de la confidentialité en soi : vous n'êtes pas la première équipe à chercher à améliorer la confidentialité de ses utilisateurs et à les protéger contre la collecte de données par des tiers, et il peut déjà exister des solutions. Enfin, de nombreux fournisseurs tiers sont plus sensibles aux problèmes de collecte des données qu'auparavant, et vous pouvez souvent ajouter des fonctionnalités ou des paramètres permettant de renforcer la protection de l'utilisateur. Voici quelques exemples.

Lors de l'ajout d'un bouton de partage sur les réseaux sociaux

Envisagez d'intégrer directement des boutons HTML: vous trouverez des exemples bien conçus sur le site https://sharingbuttons.io/. Vous pouvez également ajouter des liens HTML bruts. En contrepartie, vous perdez la statistique "Nombre de parts" et ne pouvez plus classer vos clients dans Facebook Analytics. Il s'agit d'un exemple de compromis entre l'utilisation d'un fournisseur tiers et la réception de moins de données d'analyse.

Plus généralement, lorsque vous intégrez un widget interactif provenant d'un tiers, il est souvent possible de fournir à la place un lien vers ce tiers. Cela signifie que votre site ne propose pas l'expérience intégrée, mais que c'est l'utilisateur qui choisit d'interagir ou non avec lui.

Par exemple, vous pouvez ajouter des liens permettant à Twitter et Facebook de partager votre service sur monsite.example.com, comme suit:

<a href="https://facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Facebook" target="_blank" >Share on Facebook</a>
<a href="https://twitter.com/intent/tweet/?text=My%20cool%20service!&amp;url=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Twitter" target="_blank">Share on Twitter</a>

Notez que Facebook permet de spécifier une URL à partager et que Twitter permet de spécifier une URL et du texte.

Lors de l'intégration d'une vidéo

Lorsque vous intégrez des vidéos provenant de sites d'hébergement de vidéos, recherchez des options protégeant la confidentialité dans le code d'intégration. Par exemple, pour YouTube, remplacez youtube.com dans l'URL d'intégration par www.youtube-nocookie.com pour éviter que des cookies de suivi ne soient placés sur les utilisateurs qui consultent la page d'intégration. Vous pouvez également cocher la case "Activer le mode de confidentialité avancé" lorsque vous générez le lien Partager/Intégrer à partir de YouTube. C'est un bon exemple d'utilisation d'un mode plus protecteur de l'utilisateur fourni par le tiers. (https://support.google.com/youtube/answer/171780 décrit ce point plus en détail, ainsi que d'autres options d'intégration spécifiquement pour YouTube.)

D'autres sites de vidéos proposent moins d'options à ce sujet. Par exemple, TikTok, par exemple, ne permet pas d'intégrer une vidéo sans suivi au moment de la rédaction de cet article. Vous pouvez héberger les vidéos vous-même (il s'agit d'une alternative), mais cela peut s'avérer beaucoup plus complexe, en particulier pour prendre en charge de nombreux appareils.

Comme pour les widgets interactifs abordés précédemment, il est souvent possible de remplacer une vidéo intégrée par un lien vers le site web fournissant. Cette option est moins interactive, car la vidéo ne peut pas être lue en parallèle, mais l'utilisateur peut choisir de la regarder ou non. Il peut s'agir d'un exemple de "modèle de façade", qui désigne le remplacement dynamique du contenu interactif par un élément nécessitant une action de l'utilisateur pour le déclencher. Une vidéo TikTok intégrée peut être remplacée par un lien simple vers la page de la vidéo TikTok, mais avec un peu plus de travail, il est possible de récupérer et d'afficher une miniature pour la vidéo et d'en faire un lien. Même si le fournisseur vidéo choisi ne propose pas un moyen simple d'intégrer des vidéos sans suivi, de nombreux hébergeurs vidéo prennent en charge oEmbed, une API qui, lorsqu'elle fournit un lien vers une vidéo ou un contenu intégré, renvoie des détails programmatiques, tels qu'une miniature et un titre. TikTok est compatible avec oEmbed (voir https://developers.tiktok.com/doc/embed-videos pour en savoir plus), ce qui signifie que vous pouvez (manuellement ou par programmation) transformer un lien vers une vidéo TikTok https://www.tiktok.com/@scout2015/video/6718335390845095173 en métadonnées JSON concernant cette vidéo avec https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173, et donc récupérer une miniature à afficher. WordPress l'utilise souvent pour demander des informations oEmbed en contenu intégré, par exemple. Vous pouvez programmer l'affichage d'une "façade" interactive qui affiche une vidéo interactive ou un lien lorsque l'utilisateur décide de cliquer dessus.

Lors de l'intégration de scripts d'analyse

Analytics est conçu pour collecter des informations sur vos utilisateurs en vue de leur analyse. C'est justement ce à quoi il sert. Pour simplifier l'implémentation, les systèmes Analytics sont essentiellement des services permettant de collecter et d'afficher des données sur les accès et les utilisateurs. Ces services s'effectuent sur un serveur tiers tel que Google Analytics. Il existe également des systèmes d'analyse auto-hébergés, tels que https://matomo.org/, bien que cela représente plus d'efforts que l'utilisation d'une solution tierce. Toutefois, l'exécution d'un tel système sur votre propre infrastructure vous aide à réduire la collecte de données, car il ne quitte pas votre propre écosystème. D'un autre côté, la gestion de ces données, leur suppression et leur définition de règles relèvent de votre responsabilité. Une grande partie de l'inquiétude liée au suivi intersites concerne le fait qu'il est réalisé de manière insidieuse et secrète, ou lorsqu'il s'agisse d'un effet secondaire de l'utilisation d'un service ne nécessitant pas du tout de collecte de données. Le logiciel Analytics est ouvertement conçu pour collecter des données afin d'informer les propriétaires de sites sur leurs utilisateurs.

Historiquement, il existait une approche consistant à collecter toutes les données possibles sur tout, comme un grand filet de pêche, puis à les analyser par la suite pour identifier des tendances intéressantes. Cet état d'esprit a en grande partie créé le sentiment de malaise et d'inquiétude à propos de la collecte de données, qui a été abordé dans la première partie de ce cours. Aujourd'hui, de nombreux sites commencent par déterminer les questions à poser, puis recueillent des données spécifiques et limitées pour répondre à ces questions.

Si un service tiers est utilisé par votre site et par d'autres sites, que vous intégrez le code JavaScript dans votre site et qu'il définit des cookies pour chaque utilisateur, il est important de noter qu'il peut effectuer une reconnaissance intersite non désirée, c'est-à-dire suivre vos utilisateurs sur l'ensemble des sites. Certains peuvent et d'autres non, mais la politique de protection de la confidentialité consiste ici à supposer qu'un tel service tiers effectue en fait un suivi intersites, sauf si vous avez une bonne raison de penser ou de savoir autrement. Ce n'est pas en soi une raison d'éviter de tels services, mais cela doit être pris en compte lorsque vous évaluez les avantages et inconvénients de leur utilisation.

Auparavant, le compromis lié à l'analyse consistait uniquement à choisir de les utiliser ou non: collecter toutes les données et compromettre la confidentialité en échange d'insights et de planification, ou abandonner complètement des insights. Toutefois, ce n'est plus le cas et il y a souvent désormais un milieu à trouver entre ces deux extrêmes. Consultez votre fournisseur de solutions d'analyse pour connaître les options de configuration permettant de limiter les données collectées, ainsi que de réduire la quantité et la durée de leur stockage. Comme vous disposez des enregistrements de l'audit technique décrit précédemment, vous pouvez réexécuter les sections pertinentes de cet audit pour vérifier que la modification de ces configurations réduit réellement la quantité de données collectées. Si vous effectuez cette transition sur un site existant, cela peut vous donner une mesure quantifiable qui peut être écrite pour vos utilisateurs. Par exemple, Google Analytics propose un certain nombre de fonctionnalités de confidentialité activées (et donc désactivées par défaut), dont beaucoup peuvent s'avérer utiles pour respecter les lois locales sur la protection des données. Lorsque vous configurez Google Analytics, vous pouvez définir une durée de conservation des données collectées (Administration > Informations de suivi > Conservation des données) inférieure à la valeur par défaut de 26 mois ou activer certaines solutions plus techniques, comme l'anonymisation partielle des adresses IP (voir https://support.google.com/analytics/answer/9019185 pour en savoir plus).

Utiliser des tiers tout en protégeant la confidentialité

Jusqu'à présent, nous avons vu comment protéger vos utilisateurs contre les tiers lors de la phase de conception de votre application pendant que vous planifiez son utilité. Le fait de ne pas faire appel à un tiers en particulier fait partie de cette planification. L'audit de vos utilisations entre également dans cette catégorie: il s'agit de prendre des décisions concernant votre politique de confidentialité. Cependant, ces décisions ne sont pas très précises par nature. Choisir de faire appel à un tiers en particulier ou choisir de ne pas le faire n'est pas une décision nuancée. Il est beaucoup plus probable que vous ayez besoin d'un moyen intermédiaire: vous aurez besoin d'une offre tierce spécifique ou prévoyez d'utiliser celle-ci, tout en atténuant les tendances (délibérées ou accidentelles) qui ne respectent pas la confidentialité. Il s'agit de protéger les utilisateurs au moment de la compilation, en ajoutant des mesures de protection pour réduire les dommages que vous n'aviez pas anticipés. Tous ces en-têtes HTTP que vous pouvez fournir lors de la diffusion de pages indiquent au user-agent qu'il doit prendre certaines mesures de confidentialité ou de sécurité.

Règle d'URL de provenance

À faire

Définissez une règle strict-origin-when-cross-origin ou noreferrer pour empêcher d'autres sites de recevoir un en-tête "Referer" lorsque vous ajoutez des liens vers ces sites ou lorsqu'ils sont chargés en tant que sous-ressources par une page:

index.html:
<meta name="referrer" content="strict-origin-when-cross-origin" />

Ou côté serveur, dans la version Express, par exemple:

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

Si nécessaire, définissez une règle plus laxiste sur des éléments ou des requêtes spécifiques.

Pourquoi cela protège la confidentialité des utilisateurs ?

Par défaut, chaque requête HTTP envoyée par le navigateur transmet un en-tête Referer contenant l'URL de la page qui lance la requête, qu'il s'agisse d'un lien, d'une image intégrée ou d'un script. Cela peut poser un problème de confidentialité, car les URL peuvent contenir des informations privées, et ces URL accessibles à des tiers leur transmettent ces informations privées. Web.dev répertorie quelques exemples d'URL contenant des données privées. Si vous savez qu'un utilisateur est arrivé sur votre site depuis https://social.example.com/user/me@example.com, vous saurez de qui il s'agit, ce qui constitue une fuite claire. Cependant, même une URL qui ne divulgue pas d'informations privées indique que cet utilisateur particulier (que vous connaissez peut-être, s'il est connecté) est venu ici depuis un autre site. Cela révèle donc que cet utilisateur a visité cet autre site. Il s'agit en soi d'une exposition d'informations que vous ne devriez peut-être pas connaître sur l'historique de navigation de l'utilisateur.

Fournir un en-tête Referrer-Policy (avec l'orthographe correcte) vous permet de le modifier, de sorte que tout ou partie de l'URL de provenance soit transmis. MDN fournit tous les détails, mais la plupart des navigateurs ont désormais adopté la valeur supposée strict-origin-when-cross-origin par défaut, ce qui signifie que l'URL de provenance est désormais transmise à des tiers en tant qu'origine uniquement (https://web.dev au lieu de https://web.dev/learn/privacy). Cette protection de la confidentialité est utile, sans que vous ayez à faire quoi que ce soit. Toutefois, vous pouvez renforcer ce point en spécifiant Referrer-Policy: same-origin pour éviter de transmettre du tout des informations de provenance à des tiers (ou Referrer-Policy: no-referrer pour éviter de transmettre des informations à toute personne, y compris votre propre origine). Il s'agit d'un bel exemple d'équilibre entre confidentialité et utilitaires. La nouvelle valeur par défaut protège beaucoup plus la confidentialité qu'auparavant, mais elle fournit tout de même des informations générales aux tiers de votre choix, tels que votre fournisseur de solutions d'analyse.

Il est également utile de spécifier explicitement cet en-tête, car vous savez exactement quelle est la règle, au lieu de compter sur les valeurs par défaut du navigateur. Si vous n'êtes pas en mesure de définir des en-têtes, vous pouvez définir des règles en matière d'URL de provenance pour l'ensemble d'une page HTML à l'aide d'un méta-élément dans <head> : <meta name="referrer" content="same-origin">. Si vous ne souhaitez pas que des tiers spécifiques vous préoccupent, vous pouvez également définir un attribut referrerpolicy <script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer"> sur des éléments individuels tels que <script>, <a> ou <iframe> :

Règle de sécurité du contenu

L'en-tête Content-Security-Policy, souvent appelé "CSP", indique l'emplacement à partir duquel les ressources externes peuvent être chargées. Il est principalement utilisé à des fins de sécurité, en empêchant les attaques par script intersites et les injections de scripts. Toutefois, lorsqu'il est utilisé en parallèle de vos audits réguliers, il peut également limiter les endroits où les tiers que vous avez choisis peuvent transmettre des données.

L'expérience utilisateur n'est peut-être pas satisfaisante. Si l'un de vos scripts tiers commence à charger une dépendance depuis une origine qui ne figure pas sur votre liste, cette requête sera bloquée, le script échouera et votre application risque d'échouer avec elle (ou au moins d'être réduite à sa version de remplacement avec échec de JavaScript). Cette approche est utile lorsque CSP est implémenté pour assurer la sécurité, ce qui correspond à son objectif normal: se protéger contre les problèmes de script intersites (et pour ce faire, utilisez une CSP stricte). Une fois que vous connaissez tous les scripts intégrés utilisés par votre page, vous pouvez les répertorier, calculer une valeur de hachage ou ajouter une valeur aléatoire (appelée "nonce") pour chacun, puis ajouter la liste de hachages à votre Content Security Policy. Cela empêchera le chargement de tout script qui ne figure pas sur la liste. Cela doit être intégré au processus de production du site: les scripts de vos pages doivent inclure le nonce ou comporter un hachage calculé dans le cadre de la compilation. Pour en savoir plus, consultez l'article sur strict-csp.

Heureusement, les navigateurs acceptent un en-tête associé, Content-Security-Policy-Report-Only. Si cet en-tête est fourni, les requêtes qui ne respectent pas la règle fournie ne seront pas bloquées, mais un rapport JSON sera envoyé à une URL fournie. Cet en-tête peut se présenter comme suit : Content-Security-Policy-Report-Only: script-src 3p.example.com; report-uri https://example.com/report/. Si le navigateur charge un script depuis un emplacement autre que 3p.example.com, la requête aboutit, mais un rapport est envoyé au report-uri fourni. Normalement, cette approche est utilisée pour tester une stratégie avant de la mettre en œuvre, mais nous vous conseillons de l'utiliser comme un moyen d'effectuer un "audit continu". En plus de l'audit régulier décrit précédemment, vous pouvez activer les rapports CSP pour vérifier si des domaines inattendus apparaissent, ce qui peut signifier que vos ressources tierces chargent elles-mêmes des ressources tierces que vous devez prendre en compte et évaluer. (Cela peut également être le signe que des scripts intersites ont dépassé vos limites de sécurité, bien sûr, qu'il est également important de connaître !)

Content-Security-Policy est une API complexe et complexe à utiliser. C'est bien connu, et des projets sont en cours pour créer la"nouvelle génération" de CSP, qui atteindra les mêmes objectifs, mais ne sera pas aussi compliquée à utiliser.Ce n'est pas encore prêt, mais si vous souhaitez savoir où cela mène (ou vous impliquer et contribuer à sa conception), consultez la page https://github.com/WICG/csp-next pour en savoir plus.

À faire

Ajoutez cet en-tête HTTP aux pages diffusées: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://a-url-you-control. Lorsque le fichier JSON est publié sur cette URL, stockez-le. Examinez ces données stockées pour obtenir la collection des domaines tiers demandés par votre site Web lorsqu'ils y accèdent par d'autres utilisateurs. Mettez à jour l'en-tête Content-Security-Policy-Report-Only pour lister les domaines attendus, afin de voir quand cette liste change:

Content-Security-Policy-Report-Only: default-src 'self' https://expected1.example.com https://expected2.example.com ; report-uri https://a-url-you-control

Pourquoi

Cela fait partie de votre audit technique, en continu. L'audit technique initial que vous avez effectué vous fournit la liste des tiers auxquels votre site partage ou transmet des données utilisateur. Grâce à cet en-tête, les requêtes de page indiquent ensuite quels tiers sont contactés, ce qui vous permet de suivre les modifications au fil du temps. Cela vous avertit non seulement des modifications apportées par les tiers existants, mais également des nouveaux tiers qui n'ont pas été ajoutés à l'audit technique. Il est important de mettre à jour l'en-tête pour arrêter de signaler les domaines attendus, mais il est également important de répéter l'audit technique manuel de temps en temps (car l'approche Content-Security-Policy ne signale pas quelles données sont transmises, mais seulement qu'une demande a été effectuée).

Notez qu'il n'est pas nécessaire de l'ajouter aux pages diffusées à chaque fois ou à toutes les pages. Réduisez le nombre de réponses de page qui reçoivent l'en-tête afin de recevoir un échantillon représentatif de rapports, moins volumineux.

Règle sur les autorisations

L'en-tête Permissions-Policy (introduit sous le nom Feature-Policy) présente un concept semblable à Content-Security-Policy, mais il limite l'accès aux fonctionnalités puissantes du navigateur. Par exemple, il est possible de restreindre l'utilisation du matériel de l'appareil, comme l'accéléromètre, l'appareil photo ou les périphériques USB, ou de restreindre les fonctionnalités non matérielles telles que l'autorisation d'afficher en plein écran ou d'utiliser une XMLHTTPRequest synchrone. Ces restrictions peuvent être appliquées à une page de premier niveau (pour éviter que des scripts chargés tentent d'utiliser ces fonctionnalités) ou à des pages sous-cadres chargées via un iFrame. Cette restriction de l'utilisation des API ne concerne pas vraiment la prise d'empreinte digitale dans le navigateur. Il s'agit d'empêcher les tiers d'effectuer des actions intrusives (comme l'utilisation d'API puissantes, l'affichage de fenêtres d'autorisation, etc.). Ce comportement est défini par le modèle Target Privacy Threat Model en tant que "intrusion".

Un en-tête Permissions-Policy est spécifié sous la forme d'une liste de paires (caractéristique, origines autorisées), ainsi:

Permissions-Policy: geolocation=(self "https://example.com"), camera=(), fullscreen=*

Cet exemple permet à cette page ("self") et aux <iframe> de l'origine example.com d'utiliser les API navigator.geolocation à partir de JavaScript. Il permet à cette page et à tous les sous-cadres d'utiliser l'API plein écran, et interdit à toute page, y compris cette page, d'utiliser une caméra pour lire les informations vidéo. Vous trouverez ici beaucoup plus de détails et une liste d'exemples potentiels.

La liste des fonctionnalités gérées par l'en-tête Permissions-Policy est volumineuse et peut être en cours de modification. La liste est actuellement disponible à l'adresse https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md.

À faire

Par défaut, les navigateurs compatibles avec Permissions-Policy n'autorisent pas les fonctionnalités puissantes dans les sous-frames. Vous devez les activer. Par défaut, cette approche est privée. Si vous constatez que des sous-cadres sur votre site nécessitent ces autorisations, vous pouvez les ajouter de manière sélective. Cependant, aucune règle d'autorisation n'est appliquée par défaut à la page principale. Les scripts (y compris les scripts tiers) chargés par la page principale peuvent donc tenter d'utiliser ces fonctionnalités. C'est pourquoi il est utile d'appliquer par défaut un Permissions-Policy restrictif à toutes les pages, puis d'ajouter progressivement les fonctionnalités requises par vos pages.

Parmi les fonctionnalités puissantes impactées par Permissions-Policy, citons la demande de la position de l'utilisateur, l'accès aux capteurs (y compris l'accéléromètre, le gyroscope et le magnétomètre), l'autorisation d'afficher en plein écran, et la demande d'accès à l'appareil photo et au micro de l'utilisateur. La liste complète des fonctionnalités (qui change) est accessible via le lien ci-dessus.

Malheureusement, pour bloquer toutes les fonctionnalités par défaut, puis les autoriser à nouveau de manière sélective, vous devez lister toutes les fonctionnalités dans l'en-tête, ce qui peut sembler peu élégant. Un tel en-tête Permissions-Policy constitue toutefois un bon point de départ. permissionspolicy.com/ dispose d'un générateur cliquable qui permet de créer un tel en-tête. L'utilisation de cet en-tête pour créer un en-tête qui désactive toutes les fonctionnalités produit les résultats suivants :

Permissions-Policy: accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), cross-origin-isolated=(),
display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(),
fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), navigation-override=(),
payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()

Comprendre les fonctionnalités de confidentialité intégrées dans les navigateurs Web

Outre les protections liées à la "durée de compilation" et au "moment de la conception", il existe également des protections de la confidentialité qui interviennent au moment de l'exécution, c'est-à-dire des fonctionnalités de confidentialité implémentées dans les navigateurs eux-mêmes pour protéger les utilisateurs. Il ne s'agit pas de fonctionnalités que vous pouvez contrôler directement ou utiliser en tant que développeur de site. Il s'agit de fonctionnalités produit. En revanche, vous devez connaître ces fonctionnalités, car elles peuvent affecter vos sites dans les navigateurs. Pour illustrer l'impact que ces protections du navigateur peuvent avoir sur votre site, si vous utilisez du code JavaScript côté client qui attend le chargement d'une dépendance tierce avant de poursuivre la configuration de la page, et que cette dépendance tierce ne se charge jamais du tout, la configuration de votre page risque de ne jamais se terminer et l'utilisateur verra s'afficher une page à moitié chargée.

Elles incluent la fonctionnalité Intelligent Tracking Prevention dans Safari (et le moteur WebKit sous-jacent) et la Protection renforcée contre le pistage de Firefox (et son moteur, Gecko). Dans tous ces cas, il est difficile pour les tiers de créer des profils détaillés de vos utilisateurs.

Les approches des navigateurs concernant les fonctionnalités de confidentialité changent fréquemment. Il est donc important de rester à jour. La liste de protections ci-dessous est correcte au moment de la rédaction de ce document. Les navigateurs peuvent également mettre en œuvre d'autres protections. Ces listes ne sont pas exhaustives. Consultez le module sur les bonnes pratiques pour suivre les modifications et veillez à tester les futures versions du navigateur pour détecter les modifications susceptibles d'affecter vos projets. Gardez à l'esprit que les modes de navigation privée mettent parfois en œuvre des paramètres différents de ceux par défaut du navigateur (les cookies tiers peuvent être bloqués par défaut dans ces modes, par exemple). Par conséquent, les tests en mode navigation privée peuvent ne pas toujours refléter l'expérience de navigation habituelle de la plupart des utilisateurs s'ils n'utilisent pas la navigation privée. Gardez également à l'esprit que le blocage des cookies dans différentes situations peut entraîner le blocage d'autres solutions de stockage, telles que window.localStorage, en plus des cookies.

Chrome

  • Les cookies tiers sont destinés à être bloqués à l'avenir. À ce jour, ils ne sont pas bloqués par défaut (mais l'utilisateur peut l'activer). Pour en savoir plus, consultez la page https://support.google.com/chrome/answer/95647.
  • Les fonctionnalités de confidentialité de Chrome, en particulier celles qui communiquent avec des services Google et des services tiers, sont décrites à l'adresse privacysandbox.com/.

Périphérie

  • Les cookies tiers ne sont pas bloqués par défaut (mais l'utilisateur peut l'activer).
  • La fonctionnalité Tracking Prevention d'Edge bloque les outils de suivi des sites non consultés et les outils de suivi dangereux connus sont bloqués par défaut.

Firefox

Pour identifier les éléments susceptibles d'être bloqués et résoudre les problèmes, cliquez sur l'icône en forme de bouclier dans la barre d'adresse ou accédez à about:protections dans Firefox (sur ordinateur).

Safari

  • Les cookies tiers sont bloqués par défaut.
  • Dans le cadre de sa fonctionnalité Intelligent Tracking Prevention, Safari réduit l'URL de provenance transmise à d'autres pages pour qu'elle soit un site de premier niveau plutôt qu'une page spécifique: (https://something.example.com au lieu de https://something.example.com/this/specific/page).
  • Les données localStorage du navigateur sont supprimées au bout de sept jours.

(https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ un résumé de ces fonctionnalités.)

Pour en savoir plus sur les éléments susceptibles d'être bloqués et pour vous aider à déboguer les problèmes, activez le mode de débogage"Intelligent Tracking Prevention" dans le menu des développeurs de Safari (sur ordinateur). (Consultez la page https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/ pour en savoir plus.)

Propositions d'API

Pourquoi avons-nous besoin de nouvelles API ?

Si les nouvelles fonctionnalités et règles de protection de la confidentialité des navigateurs et des utilisateurs contribuent à préserver la vie privée des utilisateurs, elles s'accompagnent également de défis. De nombreuses technologies Web peuvent être utilisées pour le suivi intersites, bien qu'elles aient été conçues et utilisées à d'autres fins. Par exemple, de nombreux systèmes de fédération d'identité que nous utilisons quotidiennement s'appuient sur des cookies tiers. De nombreuses solutions publicitaires sur lesquelles les éditeurs s'appuient aujourd'hui pour générer des revenus s'appuient sur les cookies tiers. De nombreuses solutions de détection de fraudes s'appuient sur le fingerprinting. Qu'advient-il de ces cas d'utilisation lorsque les cookies tiers et le fingerprinting disparaissent ?

Il serait difficile et sujet aux erreurs pour les navigateurs de différencier les cas d'utilisation et de distinguer de manière fiable les utilisations qui ne respectent pas la confidentialité des autres. C'est pourquoi la plupart des principaux navigateurs bloquent ou prévoient de bloquer les cookies tiers et le fingerprinting, afin de protéger la confidentialité des utilisateurs.

Une nouvelle approche est nécessaire: à mesure que les cookies tiers sont abandonnés et que le fingerprinting est atténué, les développeurs ont besoin d'API spécifiques qui répondent aux cas d'utilisation (qui sont encore présents) tout en protégeant la confidentialité. L'objectif est de concevoir et de créer des API inutilisables pour le suivi intersites. Contrairement aux fonctionnalités de navigateur décrites dans la section précédente, ces technologies aspirent à devenir des API multinavigateurs.

Exemples de propositions d'API

La liste suivante n'est pas exhaustive, c'est un aperçu de certains des sujets abordés.

Exemples de propositions d'API visant à remplacer les technologies basées sur des cookies tiers:

Exemples de propositions d'API pour remplacer les technologies basées sur le suivi passif:

Exemples de propositions sur lesquelles d'autres API peuvent s'appuyer à l'avenir sans cookies tiers:

En outre, un autre type de proposition d'API voit le jour afin d'essayer de mettre en place des mesures d'atténuation du suivi dissimulé propres à chaque navigateur. (Budget pour la confidentialité, par exemple). Dans ces différents cas d'utilisation, les API initialement proposées par Chrome font partie de la Privacy Sandbox.

Global-Privacy-Control est un en-tête qui indique à un site que l'utilisateur souhaite que les données à caractère personnel collectées ne soient pas partagées avec d'autres sites. Son objectif est semblable à celui de la fonctionnalité "Do Not Track", qui a été abandonnée.

État des propositions d'API

La plupart de ces propositions d'API ne sont pas encore déployées, ou ne sont déployées que derrière des indicateurs ou dans des environnements limités à des fins de test.

Cette phase d'incubation publique est importante: les fournisseurs de navigateurs et les développeurs recueillent des commentaires et des expériences pour déterminer si ces API sont utiles et s'ils font réellement ce pour quoi elles ont été conçues. Cette phase permet aux développeurs, aux fournisseurs de navigateurs et aux autres acteurs de l'écosystème d'itérer la conception de l'API.

Actuellement, la liste des propositions du groupe Privacy Group disponible sur GitHub est le meilleur endroit pour rester informé des nouvelles API proposées.

Avez-vous besoin de ces API ?

Si votre produit repose directement sur des cookies ou des techniques tiers comme le fingerprinting, vous devez vous impliquer dans ces nouvelles API, les tester et apporter votre propre expérience aux discussions et à la conception des API. Dans tous les autres cas, vous n'avez pas nécessairement besoin de connaître tous les détails de ces nouvelles API au moment de la rédaction de ce document, mais il est important de savoir ce qui vous attend.