Tiers

Il est assez rare qu'un site Web soit entièrement autonome. L'almanach Web HTTP montre que la plupart des sites Web (environ 95 %) contiennent du contenu tiers.

Selon l'Almanach, le contenu tiers est un contenu hébergé sur une origine publique et partagée, ce qui est largement utilisé de sites, sans être influencé par le propriétaire d'un site donné. Il peut s'agir d'images ou d'autres contenus multimédias tels que des vidéos, des polices ou des scripts. Les images et les scripts représentent plus que tout le reste ensemble. Le contenu tiers n'est pas essentiel pour le développement d'un site, mais cela pourrait aussi bien être ; vous utiliserez très certainement quelque chose chargé à partir d'un serveur partagé public, qu'il s'agisse de polices Web, des iFrames intégrés 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 mesurer des analyses avec Google Analytics ; vous avez peut-être ajouté des boutons "J'aime" ou "Se connecter avec" sur les réseaux sociaux ; vous intégrez peut-être des cartes ou des vidéos, ou gérez vos achats par le biais de services tiers. vous pouvez suivre les erreurs et pour 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. en particulier un script tiers, est diffusé à partir d'une origine partagée et publique et est largement utilisé comme illustré, mais il est également écrit. par une personne autre que le propriétaire du site. Les informations relatives à l'auteur tierces sont essentielles lorsque vous réfléchissez à la manière de protéger vos des utilisateurs la confidentialité des autres. Cela vous mènera à réfléchir aux risques existants, puis à décider comment ou si vous devez utiliser un une ressource tierce sur la base de ces risques. Comme nous l’avons déjà vu, ces éléments vous aideront à comprendre le contexte et donc de comprendre quels compromis 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 le tiers est vraiment une question sur le contexte dans lequel quelque chose est utilisé. Un script chargé à partir d'un autre site Web est un script tiers et la requête HTTP qui charge le script peuvent inclure des cookies, mais ces derniers ne sont pas vraiment des "cookies tiers". il ne s'agit que de cookies, et s'il s'agit de cookies "tiers" ou "propriétaires" varie selon que le script est chargé sur un une page de votre site ou une page du site du propriétaire du script.

Pourquoi utilisons-nous des ressources tierces ?

Les tiers constituent un excellent moyen d'ajouter des fonctionnalités à votre site. Il peut s'agir de caractéristiques visibles par les utilisateurs ou invisibles. à des fonctions de développement telles que le suivi des erreurs, mais elles réduisent votre charge de développement et les scripts eux-mêmes sont conservés. par quelqu'un d'autre: l'équipe de développement du service que vous incluez. Tout cela fonctionne grâce à la composabilité du Web: être capable d’assembler des parties pour former un tout supérieur à leur somme.

L'almanach Web des archives HTTP donne une belle description:

Les tiers fournissent une collection sans fin d'images, de vidéos, polices, outils, bibliothèques, widgets, outils de suivi, annonces et tout autre élément que vous pouvez imaginer et intégrer dans nos pages Web. Cela permet même les moins techniques pour être capable de créer et de publier du contenu sur le Web. Sans tiers, le Web serait probablement être un support universitaire très ennuyeux, basé sur du texte et non sur la plate-forme riche, immersive et complexe qui fait partie intégrante de notre vie. d'un grand nombre d'entre nous aujourd'hui.

Que peuvent faire les ressources tierces ?

Accéder à certaines informations

Lorsque vous utilisez une ressource tierce sur votre site Web, quelle qu'elle soit, certaines informations lui sont transmises. Par exemple, si vous incluez une image provenant d'un autre site, la requête HTTP envoyée par le navigateur de l'utilisateur transmet un référent contenant l'URL de votre page, ainsi que l'adresse IP de l'utilisateur.

Suivi intersites

Reprenons le même exemple. Lorsque l'image est chargée depuis le site tiers, elle peut inclure un cookie, lequel sont renvoyés au tiers lorsque l'utilisateur demande ensuite cette image. Cela signifie que le tiers peut savoir que son est utilisé sur votre site et peut renvoyer un cookie, potentiellement associé à un identifiant unique pour cet utilisateur. Cela signifie que la prochaine fois que l'utilisateur consultera votre site ou tout autre site incluant une ressource de ce tiers, que et le cookie d'ID sera de nouveau envoyé. Cela permet au tiers de créer un journal des pages sur lesquelles cet utilisateur visite: votre site, les autres sites qui utilisent la même ressource tierce, sur tout le Web.

Il s'agit du suivi intersites, qui permet à un tiers de collecter un journal de l'activité d'un utilisateur sur de nombreux sites Web, dès lors que ces sites web utilisent tous une ressource provenant du même tiers. Il peut s'agir d'une police, d'une image, d'une feuille de style, etc. Il peut également s'agir d'une ressource dynamique: un script, un bouton de réseau social ou une publicité. Le script inclus peut collecter d'informations, car elles sont dynamiques: elles peuvent inspecter le navigateur et l'environnement de l'utilisateur et transmettre ces données à son créateur. Tout script peut faire cela dans une certaine mesure, tout comme les ressources dynamiques qui ne se présentent pas sous la forme d'un script, comme une intégration de réseau social ou une annonce ou un bouton de partage. Si vous regardez les détails d'une bannière de cookies sur des sites Web populaires, vous pouvez voir une liste des organisations qui peuvent ajouter un cookie de suivi à vos utilisateurs pour créer une image de leurs activités et créer un profil de cet utilisateur. Il y peut en compter des centaines. Si un tiers propose un service sans frais, l'une des façons dont il peut est qu'ils collectent, puis monétisent ces données.

Le modèle de menace pour la confidentialité cible constitue un guide utile pour identifier les types de problèmes liés à la confidentialité contre lesquels un navigateur doit protéger ses utilisateurs. Il s'agit d'un document encore en cours de discussion au moment de la rédaction, mais il donne quelques classifications générales des types de de menaces qui existent. Les risques liés aux ressources tierces sont principalement la "reconnaissance intersite indésirable", lorsqu'un site Web peut identifier un même utilisateur sur plusieurs sites et la "divulgation d'informations sensibles", qui permet à un site informations qu'un utilisateur considère comme sensibles.

Il s'agit d'une distinction clé: la reconnaissance intersites non désirée est nuisible, même si le tiers ne collecte pas d'autres données sensibles. des informations, car cela empêchait un utilisateur de contrôler son identité. Accéder à l'URL de provenance et à l'adresse IP d'un utilisateur et les cookies constituent une mention indésirable en soi. L'utilisation de ressources tierces s'accompagne d'une composante de planification de la façon dont vous utiliserez tout en protégeant la confidentialité. Une partie de ce travail vous incombe en tant que développeur du site, tandis que d'autres sont effectuées par le navigateur. en tant que user-agent, c'est-à-dire, l'agent travaillant au nom de l'utilisateur pour éviter la divulgation d'informations sensibles et une reconnaissance intersites non désirée lorsque cela est possible. Nous allons maintenant examiner plus en détail les stratégies d'atténuation des risques et les approches adoptées pour un navigateur. et le développement du site.

Code tiers côté serveur

Notre définition précédente d'un tiers a délibérément modifié l'approche plutôt côté client de l'almanach HTTP (selon le cas, pour leur rapport !), d'inclure la paternité d'un contenu tiers, car du point de vue de la confidentialité, un tiers désigne toute personne sur vos utilisateurs qui n'est pas vous.

Cela inclut les tiers qui fournissent les services que vous utilisez sur le serveur, ainsi que le client. Depuis une page de confidentialité il est également important de comprendre ce qu'est 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 les bibliothèques incluent également "phone home" à leurs auteurs, elles peuvent être en mesure de porter atteinte aux droits d'auteur confidentialité et doivent donc être audités. Vous devez généralement transmettre les données utilisateur à un tiers basé sur un serveur. les données auxquelles il est exposé est davantage sous votre contrôle. En revanche, un tiers basé sur un client (un script ou une ressource HTTP sur votre site Web et récupérées par le navigateur de l'utilisateur, peuvent collecter certaines données directement auprès de l'utilisateur, sans que ce processus de la collecte que vous utilisez pour votre médiation. Dans ce module, nous verrons en grande partie comment identifier ces tiers côté client. vous avez choisi d'inclure et d'exposer vos utilisateurs, précisément parce que vous avez moins de médiation possible. Mais cela vaut la peine envisagez de sécuriser votre code côté serveur afin de comprendre les communications sortantes qu'il génère et de pouvoir consigner ou bloquer toute sont inattendues. Les détails sur la façon exacte de procéder sortent de notre champ d'application ici (et dépendent beaucoup de la configuration de votre serveur), mais c'est un autre aspect de votre position de sécurité et de confidentialité.

Pourquoi devez-vous faire attention aux tiers ?

Les scripts et fonctionnalités tiers sont très importants et notre objectif en tant que développeurs Web doit être d'intégrer ce genre de choses, de ne pas s'en détourner ! Mais il y a des problèmes potentiels. Les contenus tiers peuvent engendrer des problèmes de performances peuvent également créer des problèmes de sécurité, car vous intégrez un service externe à l'intérieur de votre limite de confiance. Mais les tiers contenu peut également 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) lorsqu'un tiers peut dérober des données à votre entreprise, ce qui contraste avec les problèmes de confidentialité, qui sont (entre autres) lorsqu'un tiers que vous avez inclus vole ou obtient l'accès aux données des données sans votre consentement (ou sans votre consentement).

Un exemple de problème de sécurité est quand les "web skimmers" voler les informations de carte de paiement, une ressource tierce qui est incluse sur une page sur laquelle un utilisateur saisit les informations d'une carte de crédit peut potentiellement voler ces informations et les renvoyer vers au tiers malveillant. Les créateurs de ces scripts font preuve d'une grande créativité lorsqu'ils cherchent à les dissimuler. Un résumé décrit comment les scripts Skimmer ont été cachés dans des contenus tiers tels que les images utilisées pour les logos de sites, les favicons et les réseaux sociaux ; bibliothèques populaires comme jQuery, Modernizr et Google Tag Manager, les widgets de site comme les fenêtres de chat en direct, et les fichiers CSS.

Les problèmes de confidentialité sont légèrement différents. Ces tiers font partie de votre offre ; pour maintenir l'expérience utilisateur confiance en vous, vous devez être sûr que vos utilisateurs peuvent leur faire confiance. Si un tiers que vous utilisez collecte des données sur vos utilisateurs et en font un usage abusif, rendent difficile leur suppression ou leur découverte, sont victimes d'une violation des données ou ne respectent pas les vos utilisateurs perçoivent probablement cette différence au niveau de leur confiance envers votre service, et non simplement tiers. C'est votre réputation et votre relation en ligne. C'est pourquoi il est important de vous demander si vous avez confiance avec les tiers que vous utilisez sur votre site ?

Pouvez-vous me donner des exemples de tiers ?

Nous parlons de « tiers » généralement, mais il en existe en fait différents types et ils ont accès à différentes quantités de données utilisateur. Par exemple, si vous ajoutez un élément <img> à votre code HTML, chargé depuis un autre serveur, ce serveur disposera d'informations différentes. sur vos utilisateurs que l'ajout d'un <iframe> ou d'un élément <script>. Il ne s'agit pas d'une liste exhaustive, mais d'exemples, utiles pour comprendre les différences entre les différents types d'éléments tiers que votre site peut utiliser.

Demander une ressource intersites

Une ressource intersites correspond à tout ce qui, sur votre site, est chargé à partir d'un autre site et n'est pas de type <iframe> ni <script>. Exemples incluent <img>, <audio>, <video>, les polices Web chargées par CSS et les textures WebGL. Elles sont toutes chargées via une requête HTTP, et comme décrits 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 comme URL de provenance. Toutes les requêtes tierces incluaient traditionnellement ces données par défaut, même si des efforts sont nécessaires pour réduire ou isoler les données transmises à des tiers par différents navigateurs, comme indiqué dans la section Protections des navigateurs tiers" plus loin.

Intégrer un iFrame intersites

Un document complet intégré dans vos pages via un <iframe> peut demander un accès supplémentaire aux API du navigateur, en plus du trifecta de cookies, adresse IP et URL de provenance. Les API disponibles pour les pages <iframe> et la façon dont elles demandent l'accès dépendent du navigateur utilisé. et est en cours de modification: consultez les règles relatives aux autorisations. pour connaître les efforts en cours pour limiter ou surveiller l'accès aux API dans les documents.

Exécuter du code JavaScript intersites

L'inclusion d'un élément <script> permet de charger et d'exécuter le code JavaScript intersite dans le contexte de premier niveau de votre page. Cela signifie que qui s'exécute dispose d'un accès complet à tout ce que font vos propres scripts propriétaires. Les autorisations du navigateur gèrent toujours ces données, Par conséquent, demander la position de l'utilisateur (par exemple) nécessitera tout de même un accord de l'utilisateur. Mais toute information présente sur la page ou disponibles, car les variables JavaScript peuvent être lues par ce type de script, y compris les cookies transmis au tiers dans la demande, mais aussi les cookies destinés uniquement à votre site. De même, un script tiers chargé sur votre peut effectuer les mêmes requêtes HTTP que votre propre code, ce qui signifie qu'elle 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 inclura probablement également des dépendances tierces, qui ne peuvent pas être distinguées des vôtres le code sous sa puissance ; du 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 les mêmes données que votre autre code.

Connaître les tiers

Vous devez donc connaître votre liste de fournisseurs tiers et connaître leurs règles de confidentialité, de collecte des données vos expériences et vos règles. Cette compréhension fait alors partie de votre série de compromis: l'utilité et l'importance est le service, contre le caractère intrusive, gênant ou inquiétant de leurs demandes pour les utilisateurs. Tierce le contenu apporte une valeur ajoutée en vous permettant de vous concentrer sur vos compétences essentielles ; Il est donc utile de faire ce compromis et de sacrifier le confort et la confidentialité de l'utilisateur pour une meilleure expérience utilisateur. Il est important de ne pas confondre l'expérience utilisateur avec celle du développeur : "Notre équipe de développeurs peut créer plus facilement le service » n'est pas une histoire convaincante pour les utilisateurs.

La façon d'obtenir cette compréhension est le processus d'audit.

Auditer vos tiers

Comprendre ce que fait un tiers correspond au processus d'audit. Vous pouvez le faire à la fois techniquement et non techniquement, et pour un tiers 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, et certains documents pourront utiliser certaines des approches adoptées. avec des mises en garde spécifiques dans les modules précédents, comme des déclarations trop générales et sans aucune indication comment et quand les données collectées seront supprimées. Il est important de comprendre que du point de vue de l'utilisateur, toutes les données sont collectées sur votre site, y compris par des tiers, sont régies par ces règles de confidentialité. Même si vous faites lorsque vous indiquez vos objectifs de façon transparente et que vous dépassez les objectifs en termes de confidentialité des données et sensibilité, les utilisateurs peuvent vous tenir responsable de tout ce que les tiers choisis font également. S’il y a quoi que ce soit dans leurs propres politiques de confidentialité, ce qui ne serait pas nécessaire dans vos propres politiques, car cela réduirait le nombre d'utilisateurs et la confiance, demandez-vous s'il existe un autre fournisseur.

Cela peut être utile avec l'audit technique abordé plus loin, car ils permettent une autre. Vous devez connaître les ressources tierces que vous intégrez pour des raisons commerciales (par exemple, les réseaux publicitaires ou contenu intégré), car il existera une relation commerciale. C'est un bon point de départ pour une discussion non technique audit. L'audit technique est également susceptible d'identifier des tiers, en particulier ceux qui sont concernés pour les questions techniques plutôt que pour des raisons métier (composants externes, analyses, bibliothèques d'utilitaires), et cette liste peut être ajoutée à la liste pour les tiers axés sur l'activité. L'objectif est que, en tant que propriétaire du site, vous compreniez ce que la troisième que vous ajoutez à votre site, et vous devez pouvoir présenter votre conseiller juridique avec cet inventaire de tiers pour vous assurer que vous respectez toutes vos obligations.

Effectuer un audit technique

Pour un audit technique, il est important d'utiliser les ressources en place dans le cadre du site Web ; en d'autres termes, ne chargez pas de dépendance dans un harnais de test et de l’inspecter de cette façon. Assurez-vous de voir comment vos dépendances agissent dans votre site Web réel, déployé sur l'Internet public plutôt qu'en mode test ou développement. Il est très instructif de voir votre propre site web comme un nouvel utilisateur. Ouvrez un navigateur dans un nouveau profil vierge afin de ne pas être connecté et de n'avoir aucun contrat enregistré, puis essayez d'accéder à votre site.

Inscrivez-vous sur votre propre site pour créer un compte, si vous fournissez des comptes utilisateur. Votre équipe de conception aura organisé ce nouvel utilisateur du processus d'acquisition du point de vue de l'expérience utilisateur, mais l'approche peut être illustrée du point de vue de la confidentialité. Ne vous contentez pas de cliquer "Accepter" sur les conditions d'utilisation, l'avertissement relatif aux cookies ou les règles de confidentialité ; vous permettre d'utiliser votre propre service sans divulguer d'informations personnelles ni utiliser de cookies de suivi, et voir si vous pouvez le faire et à quel point il est difficile de le faire. Il peut également être utile d'utiliser les outils pour les développeurs du navigateur pour voir à quels sites les utilisateurs accèdent 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"), dont vous pouvez Il s'agit de requêtes regroupées par type (HTML, CSS, images, polices, JavaScript, requêtes initiées par JavaScript). Il est également possible d'ajouter une colonne indiquant le domaine associé à chaque demande et le nombre de lieux contactés. et il se peut qu'une "demande de tiers" pour n'afficher que les tiers. Il peut également être utile d'utiliser Content-Security-Policy afin d'effectuer un audit continu (voir ci-après).

L'outil "Request Map Generator" de Simon Hearne offre également une vue d'ensemble les sous-requêtes effectuées par une page accessible au public.

C'est également à ce stade que vous pouvez inclure les tiers spécialisés dans l'entreprise 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 ici est pour établir une correspondance entre la liste de tiers que vous pensez utiliser (informations financières et juridiques) et la liste dont vous disposez (en examinant les requêtes HTTP tierces envoyées par votre site Web). Vous devez être en mesure d'identifier chaque troisième l'entité à laquelle les requêtes techniques sortantes sont envoyées. Si vous ne parvenez pas à identifier les demandes dans l'audit technique pour un tiers identifié par votre relation commerciale, il est important de déterminer pourquoi et de vous en servir pour réaliser vos tests. Il peut s'agir la ressource n'est chargée que dans un pays donné, sur un type d'appareil en particulier, ou pour les utilisateurs connectés. Cela permettra d'agrandir votre des zones de site à auditer et de s'assurer que vous voyez tous les accès sortants. (Ou peut-être qu'il identifie un tiers ressource pour laquelle vous payez et que vous n'utilisez pas, ce qui rehausse toujours le service financier.)

Une fois que vous avez réduit la liste des demandes à des tiers que vous souhaitez inclure dans l'audit, cliquez sur un individuelle affiche tous les détails la concernant et, en particulier, les données qui ont été transmises à cette requête. Il est également très fréquent qu'une requête tierce envoyée par votre code puise ensuite à de nombreuses autres requêtes de tiers. Ces tiers supplémentaires sont également "importés" dans vos propres règles de confidentialité. Cette tâche est laborieuse mais précieuse, et il peut souvent être inséré dans des analyses existantes, votre équipe de développement de l'interface devrait déjà auditer les demandes (peut-être à l'aide d'outils existants tels que WebPageTest ou Lighthouse) et l'intégration d'une et l'audit de confidentialité peuvent faciliter ce processus.

<ph type="x-smartling-placeholder">
</ph> Carte de requêtes web.dev.
Un plan de requêtes (drastiquement simplifié) pour web.dev, montrant les sites tiers qui demandent d'autres sites tiers, etc.

À faire

Ouvrez un navigateur avec un nouveau profil utilisateur propre, de sorte que vous n'êtes pas connecté et que vous n'ayez pas de contrat stocké. puis ouvrez le navigateur outils de développement dans le panneau "Réseau" pour voir toutes les requêtes sortantes. Ajoutez une colonne indiquant le domaine de chaque requête, puis vérifiez "demandes de tiers" pour n'afficher que les tiers, le cas échéant. Ensuite :

  • Accédez à votre site.
  • Créez un compte si vous fournissez des comptes utilisateur.
  • Essayez de supprimer le compte que vous avez créé.
  • Effectuez une ou deux actions normales sur le site. Notez que tout dépendra de ce que fait votre site, mais choisissez les actions courantes que la plupart des utilisateurs effectuent.
  • Effectuez une ou deux actions dont vous savez qu'elles impliquent des dépendances tierces en particulier. Il peut s'agir de partager du contenu avec sur les réseaux sociaux, en lançant un processus de paiement ou en intégrant du contenu d'un autre site.

Lors de chacune de ces tâches, enregistrez les ressources demandées à des domaines qui ne vous appartiennent pas dans le panneau "Network". comme décrit dans la description. Voici quelques-uns de vos tiers. Un bon moyen d'y parvenir est d'utiliser les outils réseau du navigateur pour capturer le réseau dans un fichier HAR.

Fichiers HAR et capture d'écran

Un fichier HAR est un format JSON standardisé de toutes les requêtes réseau effectuées par une page. Pour obtenir le fichier HAR correspondant à une page spécifique, accédez aux ressources suivantes:

Chrome

Ouvrez les outils de développement du navigateur (Menu > Plus d'outils > Outils de développement), accédez au panneau "Réseau", chargez (ou actualisez) la page, puis cliquez sur la flèche vers le bas pour enregistrer le symbole en haut à droite, près du menu déroulant "Aucune limitation".

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

Ouvrez les outils de développement du navigateur (Menu > Plus d'outils > Outils pour les développeurs Web), accédez au panneau "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**.

Panneau réseau des outils pour les développeurs Firefox avec l&#39;option &quot;Enregistrer tout au format Har&quot; mise en évidence
Safari

Ouvrez les outils de développement du navigateur (Menu > Développer > Afficher l'inspecteur Web). Si vous n'avez pas de menu "Développement", activez-le dans Menu > Safari > Préférences > Paramètres avancés > Afficher le menu "Développement" dans la barre de menu), accéder au panneau "Réseau", charger (ou actualiser) la page, et cliquez sur Export (Exporter) en haut à droite (à droite de "Preserve Log" (Conserver le journal). Vous devrez peut-être agrandir la fenêtre).

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

Pour obtenir plus de détails, vous pouvez également enregistrer ce qui est transmis à des tiers (dans la section Demande), bien que ces données soient souvent obscurcies et pas interprétables efficacement.

Bonnes pratiques lors de l'intégration de tiers

Vous pouvez définir vos propres règles concernant les tiers utilisés par votre site: changer les fournisseurs d'annonces que vous utilisez en fonction de leurs pratiques, ou si le pop-up de consentement aux cookies est agaçant ou intrusif, ou si vous souhaitez utiliser des boutons de réseaux sociaux sur votre site ou liens de suivi dans vos e-mails ou liens utm_campaign à suivre dans Google Analytics dans vos tweets. L'un des aspects à prendre en compte le développement d'un site est la stratégie de confidentialité et de sécurité de votre service d'analyse. Certains services d'analyse échangent explicitement de la protection de la vie privée. Souvent, il existe également des moyens d'utiliser un script tiers qui renforce en lui-même la protection de la confidentialité: vous n'êtes pas la première équipe à chercher à améliorer l'expérience utilisateur confidentialité et de les protéger contre la collecte de données par des tiers. peuvent déjà être des solutions. Enfin, de nombreux fournisseurs tiers sont plus sensibles aux problèmes de collecte de données qu'auparavant, Voici quelques exemples :

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

Vous pouvez envisager d'intégrer directement les boutons HTML: le site https://sharingbuttons.io/ propose quelques exemples efficaces. Ou vous pouvez ajouter des liens HTML bruts. La contrepartie est que vous perdez le "nombre de partages" et votre capacité à classer vos clients dans vos données analytiques Facebook. 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 issu d'un tiers, il est souvent possible de fournir à la place un un lien vers ce tiers. Cela signifie que votre site ne propose pas l'expérience intégrée, mais que la décision de partage change des données avec le tiers, de vous à votre utilisateur, qui peut choisir d’interagir ou non comme il le souhaite.

Par exemple, vous pouvez ajouter des liens pour Twitter et Facebook afin 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, tandis 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 les 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 afin d'éviter le suivi des cookies. aux utilisateurs qui consultent la page d'intégration. Vous pouvez également cocher la case "Activer le mode de confidentialité avancé" lors de la génération Partagez/intégrez un lien à partir de YouTube. Il s'agit d'un bon exemple d'utilisation d'un mode plus protégeant l'utilisateur fourni par le tiers. Consultez la page https://support.google.com/youtube/answer/171780 pour en savoir plus. et d'autres options d'intégration spécifiques à YouTube.)

D'autres sites vidéo proposent moins d'options à cet égard: TikTok, par exemple, ne permet pas d'intégrer une vidéo sans suivi. au moment de la rédaction de ce document. Vous pouvez héberger les vidéos vous-même (à l'aide d'une autre solution), mais il peut s'agir beaucoup plus de travail, en particulier pour prendre en charge de nombreux appareils.

Comme pour les widgets interactifs évoqués précédemment, il est souvent possible de remplacer une vidéo intégrée par un lien vers le site Web qui la fournit. Cette option est moins interactive, car la vidéo ne peut pas être lue intégrée, mais l'utilisateur a le choix de la regarder ou non. Il peut s'agir utilisé comme exemple de "modèle de façade", nom permettant de remplacer de façon dynamique le contenu interactif par un élément nécessitant pour la 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 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 permettent d'intégrer facilement des vidéos sans suivi. De nombreux hébergeurs de vidéos sont compatibles avec oEmbed, une API qui, une fois fournie un lien vers une vidéo ou un contenu intégré, renverra des détails programmatiques le concernant, y compris une miniature et un titre. TikTok est compatible avec oEmbed (voir https://developers.tiktok.com/doc/embed-videos pour plus d'informations), ce qui signifie que vous pouvez transformer (manuellement ou programmatiquement) 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 vignette à afficher. WordPress l'utilise souvent pour demander oEmbed. des informations sur le contenu intégré, par exemple. Vous pouvez l'utiliser de manière programmatique pour afficher une "façade" qui semble interactif et qui bascule vers une vidéo interactive ou un lien vers celle-ci lorsque l'utilisateur choisit de cliquer dessus.

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

Analytics est conçu pour collecter des informations sur vos utilisateurs afin de les analyser: c'est à cela que sert ce service. Les systèmes d'analyse sont essentiellement des services pour collecter et afficher des données sur les accès et les utilisateurs, effectuées sur un serveur tiers comme Google Analytics pour plus de simplicité de mise en œuvre. Il existe également des systèmes d'analyse auto-hébergés comme https://matomo.org/, bien que cela représente plus de travail que l'utilisation d'un une solution tierce. L'exécution d'un tel système sur votre propre infrastructure vous aide toutefois à réduire la collecte de données, car elles ne quittent pas votre propre écosystème. D'un autre côté, gérer ces données, les supprimer et définir des règles pour celles-ci devient de votre responsabilité. Le suivi intersites est une source d'inquiétude principale. secrètement, ou comme effet secondaire de l'utilisation d'un service qui n'a pas besoin de contenir du tout de collecte de données. Les logiciels d'analyse sont ouvertement conçue pour collecter des données afin d'informer les propriétaires de sites sur leurs utilisateurs.

Historiquement, l'approche consistait à recueillir toutes les données possibles sur tout, comme un filet de pêche géant, et puis en l’analysant plus tard afin de trouver des modèles intéressants. Cet état d'esprit a, en grande partie, créé un sentiment de malaise et de gêne. sur la collecte de données qui a été abordée dans la partie 1 de ce cours. Aujourd'hui, de nombreux sites déterminent d'abord quelles questions poser et puis recueillir des données spécifiques et limitées pour répondre à ces questions.

Si votre site et d'autres sites utilisent un service tiers, et si vous pouvez inclure leur code JavaScript dans votre site pour qu'il fonctionne, et qu'elle définit des cookies pour chaque utilisateur, il est important de tenir compte du fait qu'il pourrait faire de la reconnaissance intersites non désirée. c'est-à-dire suivre vos utilisateurs à travers les sites. Certains peuvent et d'autres non, mais la politique de protection de la vie privée consiste ici à supposer que 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 c'est un point à prendre en compte lorsque vous évaluez les compromis à faire de leur utilisation.

Auparavant, le seul compromis en matière d'analyse était de choisir de les utiliser ou non: collecter toutes les données et compromettre la confidentialité en échange. pour obtenir des insights et une planification, ou abandonner complètement les insights. Toutefois, ce n'est plus le cas, et on peut désormais entre ces deux extrêmes. Consultez votre fournisseur de solution d'analyse pour connaître les options de configuration à limiter les données collectées, et de réduire la quantité et la durée de leur stockage. Comme vous disposez des données de l'audit technique décrites précédemment, vous pouvez réexécuter les sections pertinentes de cet audit pour vérifier que la modification de ces configurations de réduire réellement la quantité de données collectées. Si vous effectuez cette transition sur un site existant, vous pouvez ainsi une mesure quantifiable qui peut être écrite pour vos utilisateurs. Par exemple, Google Analytics propose un certain nombre d'options d'activation (donc désactivées par défaut). des fonctionnalités de confidentialité, dont la plupart peuvent être utiles pour respecter les lois locales sur la protection des données. Voici quelques options à envisager lors de la configuration Dans Analytics, vous pouvez par exemple 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. et l'activation de certaines solutions plus techniques, telles que l'anonymisation partielle des adresses IP (pour en savoir plus, consultez https://support.google.com/analytics/answer/9019185).

Utiliser des tiers tout en protégeant la confidentialité

Jusqu'ici, nous avons vu comment protéger vos utilisateurs des tiers lors de la phase de conception de votre application. vous planifiez ce que cette application fera. Décider de ne pas faire appel à un tiers en particulier fait partie de cette planification, et l'audit de vos usages entrent également dans cette catégorie: ils permettent de prendre des décisions concernant la politique de confidentialité. Toutefois, ces les décisions ne sont par nature pas très précises ; choisir de faire appel à un tiers ou de ne pas le faire n'est pas une décision nuancée. Il est beaucoup plus probable que vous souhaitiez quelque chose de milieu de gamme: avoir besoin ou prévu d'utiliser une offre tierce particulière, mais pour atténuer les risques de non-respect de la confidentialité (délibéré ou accidentel). Il s'agit de protéger les utilisateurs au "moment de la compilation" : l’ajout de mesures de protection pour réduire le préjudice que vous n’aviez pas prévu. Il s'agit de nouveaux en-têtes HTTP que vous pouvez fournir et qui incitent le user-agent à adopter certaines mesures de confidentialité ou de sécurité.

Règles relatives aux 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 "Referreur". lorsque vous créez des liens vers ces ressources ou lorsqu'elles sont chargées en tant que sous-ressources par une page:

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

Côté serveur, par exemple dans Express:

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

Si nécessaire, définissez une politique plus souple pour des éléments ou des requêtes spécifiques.

Pourquoi cela protège la confidentialité des utilisateurs

Par défaut, chaque requête HTTP effectuée par le navigateur transmet un en-tête Referer qui contient l'URL de la page à l'origine de 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, la mise à disposition de tiers leur transmet ces informations privées. Web.dev fournit quelques exemples des URL contenant des données privées. Le fait de savoir qu'un utilisateur a accédé à votre site à partir du https://social.example.com/user/me@example.com vous permet de savoir qui est cet utilisateur, ce qui est clairement une fuite. Mais même une URL qui n'expose pas d'informations privées elle-même révèle que cet utilisateur en particulier (qui vous connaissez peut-être, s'il est connecté) provient d'un autre site, ce qui révèle que cet utilisateur a consulté cet autre site. C'est en soi l'exposition de des informations que vous ne devriez peut-être pas connaître à propos de l'historique de navigation de votre utilisateur.

Fournir un en-tête Referrer-Policy (avec une orthographe correcte) vous permet de le modifier, de sorte qu'une partie ou aucune de l'URL de provenance ne soit transmise. MDN fournit tous les détails, mais la plupart des navigateurs ont a 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 à parties en tant qu'origine uniquement (https://web.dev au lieu de https://web.dev/learn/privacy). Il s'agit d'une protection de la confidentialité utile sans sans que vous ayez à faire quoi que ce soit. Mais vous pouvez renforcer encore davantage en spécifiant Referrer-Policy: same-origin pour éviter de transmettre de provenance à des tiers (ou Referrer-Policy: no-referrer pour éviter de les transmettre à qui que ce soit, y compris votre propre origine). (Cet exemple illustre bien l'équilibre entre confidentialité et utilité. La nouvelle valeur par défaut protège bien mieux la confidentialité qu'auparavant, fournit tout de même des informations générales à des tiers de votre choix, tels que votre fournisseur de solution d'analyse.

Il est également utile de spécifier explicitement cet en-tête, car vous connaissez alors la règle exacte au lieu de vous fier aux paramètres par défaut du navigateur. Si vous ne pouvez pas définir d'en-têtes, vous pouvez définir une règle en matière d'URL de provenance pour l'intégralité d'une page HTML à l'aide d'un élément Meta dans <head>: <meta name="referrer" content="same-origin">; Si des tiers spécifiques vous intéressent, vous pouvez également définir un referrerpolicy sur des éléments individuels tels que <script>, <a> ou <iframe>: <script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">

Content-Security-Policy

L'en-tête Content-Security-Policy, souvent appelé "CSP", détermine l'emplacement depuis lequel 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 l'injection de scripts, mais lorsqu'il est utilisé en plus de vos audits réguliers, cela peut également limiter où les tiers choisis peuvent transmettre des données.

Cette expérience utilisateur est potentiellement moins agréable ; si l'un de vos scripts tiers commence à charger une dépendance à partir d'un ne figure pas sur votre liste, la requête sera bloquée, le script échouera et votre application risque d'échouer. (ou au moins être réduits à sa version de remplacement pour laquelle JavaScript échoue). Ceci est utile lorsque CSP est implémenté pour des raisons de sécurité, C'est son objectif normal: vous protéger contre les problèmes de script intersites (et pour cela, utilisez une CSP stricte). Une fois que vous connaissez tous les scripts intégrés utilisés par votre page, vous pouvez en dresser la liste, calculer une valeur de hachage ou ajouter une valeur aléatoire (appelée "nonce"), puis ajoutez la liste des hachages à votre Content Security Policy. Cela empêchera tout script qui ne figure pas sur la liste d’être chargé. Cela doit être intégré au processus de production du site: les scripts de vos pages ont besoin pour inclure le nonce ou pour qu'un hachage soit calculé dans le cadre de la compilation. Pour en savoir plus, consultez l'article sur les fichiers CSS stricts.

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 enfreignent la règle fournie ne sera pas bloqué, mais un rapport JSON sera envoyé à l'URL fournie. Un tel en-tête pourrait se présente comme suit: Content-Security-Policy-Report-Only: script-src 3p.example.com; report-uri https://example.com/report/, et si le navigateur charge un script depuis un emplacement autre que 3p.example.com, la requête aboutira, mais un rapport être envoyée au report-uri fourni. Elle sert généralement à tester une règle avant de la mettre en œuvre, mais elle est aussi utile l'idée ici est de l'utiliser comme un moyen de réaliser un "audit continu". Outre l'audit habituel décrit précédemment, pouvez activer la création de rapports CSP pour voir si des domaines inattendus apparaissent, ce qui peut indiquer que vos ressources tierces sont en cours de chargement de leurs propres ressources tierces et que vous devez prendre en compte et évaluer. (Cela peut aussi indiquer l'existence des exploits de script ayant dépassé votre limite de sécurité, ce qu'il est également important de connaître !)

Content-Security-Policy est une API complexe et délicate à utiliser. C'est connu, et des travaux sont en cours pour construire la "nouvelle génération" de CSP qui répond aux mêmes objectifs, mais qui n'est pas aussi compliqué à utiliser.Ce n'est pas encore tout à fait prêt, mais si vous voulez savoir où vous en êtes, (ou si vous souhaitez participer et aider à 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 liste des domaines tiers demandés par votre site Web lorsque d'autres utilisateurs y accèdent. Mettez à jour l'en-tête Content-Security-Policy-Report-Only pour lister les domaines attendus, afin de voir à quel moment 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, de manière continue. L'audit technique initial que vous avez effectué liste des tiers auxquels votre site partage ou transmet les données utilisateur. Cet en-tête fera ensuite état de chaque demande de page identifier les tiers qui sont en cours de contact, et suivre les modifications au fil du temps. Vous êtes ainsi prévenu des changements par vos tiers existants, mais aussi les tiers ajoutés qui n'ont pas été ajoutés à l'audit technique. Il est important de mettre à jour l'en-tête pour ne plus générer de rapports sur les domaines attendus, mais il est aussi important de répéter des audits techniques de temps en temps (comme l'approche Content-Security-Policy ne signale pas quelles données sont transmises, seulement qu'une demande a été faite.)

Notez qu'il n'est pas nécessaire de l'ajouter aux pages diffusées à chaque fois, ni à chaque page. Réduisez le nombre de réponses reçues par vos pages l'en-tête afin d'obtenir un échantillon représentatif de rapports peu encombrés.

Règles relatives aux autorisations

Le concept de l'en-tête Permissions-Policy (introduit sous le nom Feature-Policy) est semblable à celui de Content-Security-Policy. mais il limite l'accès aux fonctions puissantes du navigateur. Par exemple, il est possible de limiter l'utilisation de matériel comme l'accéléromètre, un appareil photo ou des périphériques USB, ou pour limiter des fonctionnalités non matérielles telles que l'autorisation de passer en plein écran ou d'utiliser des XMLHTTPRequest synchrones. Ces restrictions peuvent être appliquées à une page de premier niveau (pour éviter que des scripts chargés ne tentent d'utiliser ces fonctionnalités) ou à pages en sous-cadre chargées via un iFrame. Cette restriction de l'utilisation de l'API ne concerne pas vraiment l'empreinte des navigateurs. il s'agit d'interdire aux tiers d'effectuer des actions intrusives (comme utiliser des API puissantes, afficher des fenêtres pop-up les fenêtres d'autorisations, etc.). C'est ce que le Target Privacy Threat Model qualifie de "intrusion".

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

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. cela permet à cette page et à tous ses sous-cadres d'utiliser l'API plein écran, et il interdit toute page, y compris cette page, d'utiliser une caméra pour lire les informations vidéo. Vous trouverez plus de détails ainsi qu'une liste d'exemples potentiels.

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

À faire

Les navigateurs qui prennent en charge Permissions-Policy interdisent par défaut les fonctionnalités puissantes dans les sous-cadres. Vous devez prendre les mesures nécessaires pour les activer. Cette approche est privée par défaut. Si vous constatez que des sous-cadres de votre site nécessitent ces autorisations, vous pouvez les ajouter de manière sélective. Toutefois, aucune règle d'autorisation n'est appliquée par défaut à la page principale, c'est pourquoi les scripts (y compris les scripts tiers) qui sont chargées par la page principale peuvent essayer d'utiliser ces fonctionnalités. C'est pourquoi il est utile d'appliquer Permissions-Policy à toutes les pages par défaut, puis ajoutez progressivement les fonctionnalités requises sur vos pages.

Exemples de fonctionnalités puissantes concernées par Permissions-Policy : demander la position de l'utilisateur, accéder aux capteurs (y compris l'accéléromètre, le gyroscope et le magnétomètre), l'autorisation de passer en plein écran, et l'accès à la caméra et au micro de l'utilisateur. Vous trouverez la liste complète des fonctionnalités (en évolution) en lien ci-dessus.

Malheureusement, pour bloquer toutes les fonctionnalités par défaut, puis les autoriser à nouveau de façon sélective, vous devez toutes les répertorier dans l'en-tête. ce qui peut sembler plutôt inélégant. Néanmoins, un tel en-tête Permissions-Policy est un bon point de départ. permissionspolicy.com/ dispose d'un générateur facilement cliquable pour créer un tel en-tête. Si vous l'utilisez pour créer un en-tête qui désactive toutes les fonctionnalités, cela se traduit par :

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

En plus de la "date et heure de compilation" et « temps de conception » mais il existe aussi des mesures de protection de la vie privée qui intervient "au moment de l'exécution" : implémentées dans les navigateurs pour protéger les utilisateurs. Il ne s'agit pas de fonctionnalités que vous pouvez contrôler ou utiliser directement en tant que site développeurs. Il s'agit de fonctionnalités du produit, mais il s'agit de fonctionnalités que vous devez connaître, car vos sites peuvent être concernés par ces décisions concernant le produit. dans les navigateurs. Pour vous donner un exemple de la façon dont ces protections de navigateur peuvent avoir un impact sur votre site, si vous utilisez un code JavaScript côté client qui attend pour qu'une dépendance tierce se charge avant de poursuivre la configuration de la page et que cette dépendance ne se charge jamais du tout, alors votre configuration de page peut ne jamais arriver à son terme et l'internaute voit donc 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 suivi dans Firefox (et son moteur, Gecko). Tous ces facteurs empêchent 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 se tenir informé. la liste de protections suivante sont correctes au moment de la rédaction. Les navigateurs peuvent également mettre en œuvre d'autres protections : ces listes ne sont pas exhaustives. Consultez le module sur les bonnes pratiques. pour vous tenir informé des modifications apportées ici, et assurez-vous d'effectuer des tests avec les prochaines versions du navigateur pour identifier les modifications susceptibles d'affecter vos projets. Gardez à l'esprit que les modes de navigation privée/navigation privée mettent parfois en œuvre des paramètres différents de ceux définis par défaut dans le 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 ne reflètent pas toujours l'expérience de navigation habituelle de la plupart des utilisateurs : ils n'utilisent pas la navigation privée. Gardez également à l'esprit que le blocage des cookies dans diverses situations peut signifier que d'autres solutions de stockage, telles que window.localStorage, sont également bloqués, pas seulement les cookies.

Chrome

  • Les cookies tiers sont susceptibles d'être bloqués à l'avenir. À l'heure où nous écrivons ces lignes, elles ne sont pas bloquées par défaut. (mais les utilisateurs peuvent l'activer): https://support.google.com/chrome/answer/95647 explique les détails.
  • Les fonctionnalités de confidentialité de Chrome, en particulier celles qui communiquent avec Google et des services tiers, sont décrits sur privacysandbox.com/.

Edge

  • Les cookies tiers ne sont pas bloqués par défaut (mais cette option peut être activée par les utilisateurs).
  • les blocs de fonctionnalités Tracking Prevention d'Edge les outils de suivi provenant de sites non consultés et les outils de suivi dangereux connus sont bloqués par défaut.

Firefox

Pour en savoir plus sur les éléments susceptibles d'être bloqués et pour vous aider à 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 la fonctionnalité Intelligent Tracking Prevention, Safari réduit l'URL de provenance transmise aux autres pages pour être 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/ résume ces fonctionnalités.)

Pour en savoir plus sur les éléments susceptibles d'être bloqués et pour vous aider à résoudre les problèmes, activez le mode débogage Intelligent Tracking Prevention. dans menu du développeur (sur ordinateur). (Pour en savoir plus, consultez https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/.)

Propositions d'API

Pourquoi avons-nous besoin de nouvelles API ?

Si les nouvelles fonctionnalités et règles de protection de la confidentialité intégrées aux produits pour navigateur contribuent à préserver la confidentialité des utilisateurs, elles présentent également des difficultés. De nombreuses technologies Web peuvent être utilisées pour le suivi intersites bien qu'elles soient conçues et utilisées à d'autres fins. Par exemple : de nombreux systèmes de fédération d’identité que nous utilisons chaque jour reposent sur des cookies tiers. Nombreuses solutions publicitaires proposées par les éditeurs pour générer des revenus aujourd'hui reposent sur les cookies tiers. De nombreuses solutions de détection des fraudes reposent sur le fingerprinting. Quoi quand les cookies tiers et le fingerprinting disparaissent ?

Il serait difficile et source d'erreurs pour les navigateurs de différencier les cas d'utilisation et de distinguer de manière fiable celles qui ne respectent pas la confidentialité des autres. C'est pourquoi la plupart des principaux navigateurs ont bloqué ou ont l'intention de bloquer les cookies tiers et le fingerprinting, afin de protéger les utilisateurs confidentialité.

Une nouvelle approche est nécessaire: étant donné que les cookies tiers sont abandonnés et que le fingerprinting est atténué, les développeurs ont besoin d'API sur mesure. qui répondent aux cas d'utilisation (qui n'ont pas disparu), mais qui sont conçus dans le respect de la confidentialité. L'objectif est de concevoir et de construire API non compatibles avec le suivi intersites Contrairement aux fonctionnalités de navigateur décrites dans la section précédente, ces technologies à devenir des API multi-navigateurs.

Exemples de propositions d'API

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

Exemples de propositions d'API pour 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 d'autres propositions sur lesquelles d'autres API peuvent s'appuyer à l'avenir sans cookies tiers:

En outre, un autre type de proposition d'API est en cours de développement et vise à mettre en place, jusqu'à présent, des mesures d'atténuation du suivi dissimulé propres aux navigateurs. C'est par exemple le cas de Privacy Budget. À travers ces différents les API initialement proposées par Chrome relèvent de la Privacy Sandbox.

Global-Privacy-Control est un en-tête qui vise à indiquer à 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 intention est semblable à l'option "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 sont déployées uniquement 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 collectent des discussions et des expériences pour déterminer si ces API sont utiles et s’ils font réellement ce pour quoi ils ont été conçus. Les développeurs, les fournisseurs de navigateurs et les autres acteurs de l'écosystème utilisent cette phase pour itérer la conception de l'API.

Pour vous tenir informé des nouvelles API proposées, nous vous invitons à consulter la liste des propositions du groupe chargé de la confidentialité sur GitHub.

Avez-vous besoin d'utiliser ces API ?

Si votre produit repose directement sur des cookies tiers ou des techniques telles que le fingerprinting, vous devez vous impliquer dans ces nouvelles API, les tester et partager vos propres expériences dans les 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 cet article, mais il est bon de savoir ce qui vous attend.