Partager via


Confidentialité de l’utilisateur

 

Mary Kirtland

Microsoft Corporation

14 février 2001

Dans ma dernière colonne, j’ai discuté de la définition de la vision du premier exemple de projet de l’équipe de conseils des services web, le service Favoris. Je m’excuse pour le long délai entre les colonnes; J’ai été dehors pendant la meilleure partie d’un mois avec un mauvais rhume. J’espère que les choses sont de nouveau sur la bonne voie maintenant pour les colonnes hebdomadaires régulières pour les prochains mois.

Pour récapitule, l’objectif du service Favoris est de fournir aux applications un moyen de stocker les liens favoris des utilisateurs finaux vers des sites Web dans un emplacement sécurisé et central, afin qu’un utilisateur puisse accéder à ses favoris via ces applications, quel que soit l’ordinateur utilisé par l’utilisateur. D’un point de vue technique, cela semble être un service assez simple à implémenter. Il s’agit essentiellement d’un magasin de données spécialisé.

À peu près au même moment où nous avons commencé à examiner le service Favoris, il y avait une quantité d’articles d’actualités sur la confidentialité des utilisateurs, en particulier sur les informations que des tiers pouvaient collecter par le biais de publicités sur les pages Web. Cela nous a fait réfléchir : l’ensemble du modèle des services web est basé sur une page Web qui utilise des services tiers, probablement à l’insu de l’utilisateur final. Y a-t-il des problèmes de confidentialité à craindre ?

Même sans une bonne définition de la confidentialité des utilisateurs, nous avons pu proposer quelques scénarios possibles que notre service Favoris proposé permettrait qui semblaient douteux. Sur la base de nos recherches initiales sur les problèmes, nous avons décidé d’implémenter le service Favoris par phases, en reportant les scénarios douteux à des phases ultérieures. Dans cette colonne, j’aborderai ce que nous avons découvert au cours de nos recherches initiales, les problèmes difficiles que nous avons différés, les problèmes de protection de la vie privée qui demeurent dans la première phase du projet, et l’impact de ceux-ci sur notre conception et notre mise en œuvre.

Confidentialité définie

Commençons par examiner ce que nous entendons par confidentialité des utilisateurs. Nous allons concentrer notre discussion sur la confidentialité des utilisateurs et le Web. Chaque fois que vous utilisez le Web, trois types d’informations peuvent être échangés entre l’application que vous utilisez (par exemple, un navigateur Web) et les sites Web auxquels l’application est connectée (comme les pages affichées dans le navigateur) :

  • Informations que vous créez à l’aide d’une combinaison d’applications, telles que le courrier électronique que vous écrivez, vos photos de vacances, vos dossiers financiers, etc.
  • Informations vous concernant, telles que votre nom, votre adresse, vos intérêts personnels, etc., collectées par une application afin de vous fournir des services.
  • Informations sur la machine et/ou la connexion réseau que vous utilisez, telles qu’une adresse IP, collectées par une application afin de vous fournir des services.

Le problème lié à la confidentialité des utilisateurs est la façon dont ces informations sont collectées, utilisées et distribuées. Si vous achetez un livre auprès d’une librairie en ligne, vous devrez bien sûr fournir votre nom, votre adresse et votre numéro de crédit carte afin que la librairie termine la commande. Mais que se passe-t-il si la librairie vide ces informations dans une base de données, ainsi que les enregistrements des livres spécifiques que vous avez achetés ? D’une part, il peut utiliser les informations pour fournir des services utiles, comme vous informer lorsque de nouveaux livres de vos auteurs favoris sont publiés. D’autre part, il pourrait vendre vos informations personnelles, ce qui entraînerait un flot de courrier indésirable indésirable. Qu’est-ce qui constitue une utilisation équitable de ces informations par les sociétés qui fournissent les applications que vous utilisez ?

Malheureusement, il n’y a pas de réponse universelle à cette question. La bonne chose à faire est difficile à déterminer, en particulier parce que la perception du public et les réglementations gouvernementales sont en constante évolution (et peuvent varier d’une juridiction légale à l’autre). La pratique courante pour les sites Web d’aujourd’hui consiste à publier une politique de confidentialité qui informe les utilisateurs des informations collectées et de la façon dont elles peuvent être utilisées et distribuées. Toutefois, il n’existe aucune norme quant à savoir si l’utilisateur doit lire la politique de confidentialité avant que les informations soient collectées ou avant que l’utilisateur puisse accéder au site Web.

La situation devient encore plus incertaine avec les services Web. L’utilisateur final ne sait probablement même pas que des services web sont utilisés. Si un service web collecte des informations qui peuvent être liées à un utilisateur final spécifique (appelés informations d’identification personnelle), comment le fournisseur de services informe-t-il l’utilisateur des informations collectées et de la façon dont elles peuvent être utilisées ou distribuées ? Les applications qui distribuent les informations personnelles aux services web doivent-elles les divulguer aux utilisateurs finaux ? Traditionnellement, les entreprises n’ont pas révélé qu’elles externalisent des aspects particuliers de leurs processus métier. Par exemple, une entreprise peut ne pas divulguer que l’exécution des commandes ou le support client sont externalisés, bien que la société de traitement des commandes et le support client organization aient accès à des informations personnelles sur les clients. Mais les règles peuvent être différentes en ligne. Seul le temps le dira...

Pratiques équitables en matière d’information

Des pratiques équitables en matière d’information permettent aux clients d’être informés et de contrôler leurs informations personnelles. Ces informations sont protégées contre l’utilisation, l’accès ou la distribution indésirables, afin que les clients soient confiants et satisfaits lors de l’utilisation des produits d’une entreprise. Notre première étape pour comprendre ce que la confidentialité des utilisateurs signifiait pour le service Favoris a été de lire les pratiques équitables de Microsoft en matière d’informations. Le groupe de confidentialité d’entreprise de Microsoft définit cinq éléments de pratiques équitables en matière d’information :

  • Avis. Votre entreprise doit définir une stratégie claire concernant la collecte, l’utilisation et la distribution des informations personnelles. Cette stratégie doit inclure l’utilisation primaire et secondaire des données, la distribution des données entre les divisions de l’entreprise, le partage de données avec les entreprises affiliées et non affiliées et les obligations contractuelles avec les fournisseurs qui prennent en charge les transactions commerciales. L’entreprise doit établir des lignes directrices pour les modifications de stratégie et l’impact des modifications sur les données collectées avant le changement. Vous voudrez travailler avec vos conseillers juridiques pour vous assurer que la stratégie est quelque chose que vous pouvez appliquer dans vos sites web et services Web. Mettre la stratégie à la disposition des clients et des utilisateurs via plusieurs canaux de distribution, y compris en ligne et hors connexion.
  • Consentement. Vous devez fournir des mécanismes flexibles et accessibles permettant aux utilisateurs de gérer leurs préférences en matière de collecte, d’utilisation et de distribution des données. Vous devez catégoriser les informations en regroupements raisonnables et significatifs afin que les utilisateurs puissent déterminer ce à quoi ils consentent et pour que la configuration des préférences ne prenne pas trop de temps. Il est important de réfléchir aux valeurs par défaut pour les préférences utilisateur. L’utilisateur doit-il activer explicitement une utilisation particulière des informations personnelles (appelée opting in) ou désactiver explicitement l’utilisation (appelée désactivation) ?
  • Accès. L’utilisateur doit être en mesure d’afficher et/ou de modifier toutes les informations personnelles que vous stockez, pour s’assurer qu’elles sont tenues à jour et pour gérer les préférences d’utilisation. Vous devez déterminer quelles informations l’utilisateur peut modifier et quelles informations peuvent uniquement être consultées. Par exemple, l’utilisateur peut ne pas être autorisé à modifier un identificateur d’utilisateur unique, mais il peut être autorisé à modifier un mot de passe. Dans l’idéal, les outils de gestion des informations personnelles seraient disponibles pour les utilisateurs en ligne et hors connexion.
  • Sécurité. Vous devez implémenter des mesures de sécurité appropriées pour protéger les informations personnelles des utilisateurs. Cela inclut des mécanismes d’authentification et d’autorisation pour protéger l’accès aux données stockées. Il peut également inclure des mécanismes de protection des données pendant la transmission entre machines. Les mesures de sécurité doivent être proportionnelles à la sensibilité des informations. Par exemple, vous serez beaucoup plus préoccupé par la sécurité si vous utilisez le compte bancaire ou les dossiers médicaux d’un utilisateur que si vous utilisez une liste de ses auteurs favoris.
  • Application. Il n’est pas utile d’avoir une politique de confidentialité si vous ne la suivez pas. Votre entreprise doit définir (et suivre) des procédures pour surveiller vos systèmes d’information afin de vérifier la conformité à vos politiques de confidentialité. Définissez des processus de résolution des différends pour tous les services d’information client et entretenez des relations de sécurité avec des organisations de certification tierces. Bien que l’application soit en grande partie externe au site web ou au service web lui-même, vous devez déterminer quels types d’informations d’audit doivent être conservés pour prendre en charge les processus d’application. Par exemple, vous pouvez vérifier si et quand les utilisateurs ont lu la politique de confidentialité, quand et comment un utilisateur a modifié les préférences utilisateur, et ainsi de suite.

Pratiques et favoris équitables en matière d’information

Tout cela semblait raisonnable en théorie, mais il n’était pas encore tout à fait clair pour nous comment cela s’appliquait à notre service Web, ni comment vous implémenteriez tous ces éléments pour les services Web en général. J’ai donc passé quelques heures à discuter des problèmes avec un membre du groupe stratégie d’entreprise. Nous avons commencé avec une liste de scénarios que le service Favoris pouvait potentiellement activer (en fonction de notre énoncé de vision initial) :

  1. Un utilisateur installe un complément sur Internet Explorer qui fournit un ensemble d’options de menu telles qu’Internet Explorer favoris, sauf que les favoris sont en fait stockés dans coldrooster.com. (Si vous lisez la dernière colonne, vous savez que nous avons défini un scénario métier autour d’un cabinet de conseil. Nous pouvons maintenant révéler que le nom de cette société de conseil fictive est Cold Rooster Consulting, en l’honneur du coq qui a traîné autour de notre bâtiment sur le campus Microsoft. D’où coldrooster.com.)
  2. Coldrooster.com fournit une application web qui permet aux utilisateurs de gérer leurs favoris.
  3. Un site Web, par exemple msdn.microsoft.com, fournit un bouton sur chacune de ses pages sur lequel un utilisateur peut cliquer pour ajouter cette page au favori de l’utilisateur stocké dans coldrooster.com.
  4. Msdn.microsoft.com fournit une page Web qui affiche les favoris d’un utilisateur, qui ont été initialement stockés par msdn.microsoft.com au nom de l’utilisateur.
  5. Msdn.microsoft.com fournit une application web qui permet à un utilisateur de gérer les favoris qui ont été initialement stockés par msdn.microsoft.com au nom de l’utilisateur.
  6. Cold Rooster Consulting prend régulièrement tous les favoris stockés, supprimés de toutes les informations qui les relient à un utilisateur particulier, et les vide dans une base de données distincte à des fins d’analyse.
  7. Msdn.microsoft.com fournit une page Web qui affiche tous les favoris stockés par un utilisateur, quel que soit le site Web qui a initialement stocké le favori au nom de l’utilisateur.
  8. Msdn.microsoft.com fournit une application web qui permet aux utilisateurs de gérer tous leurs favoris.
  9. Cold Rooster Consulting fournit un service web distinct que msdn.microsoft.com pouvez obtenir une licence. Ce service permet aux titulaires de licences de récupérer des informations telles que les « favoris favoris » ou « les personnes qui ont enregistré cette page ont également enregistré ces pages », mais uniquement pour le domaine msdn.microsoft.com.
  10. Cold Rooster Consulting fournit le service web décrit dans le scénario 9, sauf que les recommandations retournées à msdn.microsoft.com peuvent inclure des favoris provenant d’autres domaines.

Étant donné que nous devons lier les favoris d’un utilisateur à son identification personnelle, telle qu’une adresse e-mail ou un identificateur Microsoft Passport, afin de rendre tous les favoris de l’utilisateur disponibles via n’importe quelle application et n’importe quel ordinateur, les données des favoris de l’utilisateur entrent certainement dans la catégorie des informations d’identification personnelle. Si nous nous en sommes tenu à cette définition du service Favoris, nous devons implémenter des pratiques d’information équitables par le biais d’une combinaison de stratégie, de procédures et de code.

Au moment de notre discussion, il n’y avait aucune loi qui exigerait d’informer l’utilisateur avant de stocker des informations en son nom. Nous pourrions donc implémenter l’élément d’avis en publiant une politique de confidentialité sur coldrooster.com. Comment les utilisateurs savent-ils qu’ils doivent lire la stratégie ? Nous avons trouvé deux options : soit les utilisateurs doivent s’inscrire auprès de coldrooster.com avant de pouvoir stocker des favoris via notre service, soit les applications clientes doivent informer leurs utilisateurs que le service Favoris de Cold Rooster Consulting était utilisé, avec un pointeur vers notre politique de confidentialité.

Du point de vue de la sécurité , les favoris des utilisateurs n’entrent pas dans la même catégorie que les dossiers médicaux, mais un utilisateur souhaite toujours avoir un certain contrôle sur qui peut y accéder. Par exemple, en examinant les favoris que j’ai stockés sur mon ordinateur personnel, vous pouvez savoir quelles équipes sportives je supporte, quels types de livres j’aime lire, quels types de musique j’aime écouter, et où j’ai mes comptes bancaires - pas des informations auxquelles je veux que tout le monde dans le monde ait accès. Et si quelqu’un pouvait modifier mes favoris, il pourrait remplacer les liens que j’ai sélectionnés par d’autres sites (éventuellement à des fins malveillantes, comme l’interception d’informations confidentielles) ou ajouter de nouveaux liens à mes favoris. Nous aimerions donc certainement sécuriser l’accès aux favoris des utilisateurs. Et nous aimerions probablement permettre aux utilisateurs de spécifier quelles applications peuvent lire ou écrire quels favoris. Par exemple, je pourrais laisser MSDN modifier mes favoris pour le domaine msdn.microsoft.com, mais je ne voudrais pas que MSDN affiche même les liens de mes équipes sportives préférées. Pourquoi MSDN devrait-il s’en soucier ?

Pour permettre aux utilisateurs de contrôler quelles applications peuvent lire ou écrire les favoris, nous devons implémenter les éléments de consentement et d’accès des pratiques d’information équitables. Nous aimerions également probablement implémenter le code d’audit pour prendre en charge l’élément d’application .

Soudain, notre petit service web simple ne semble pas si simple! Quel niveau de contrôle devons-nous donner aux utilisateurs ? Devons-nous leur permettre de spécifier exactement quelles applications peuvent lire ou écrire des favoris à partir de chaque domaine ? Ou devons-nous regrouper des applications et des domaines dans des zones pour simplifier la configuration ? Parmi les scénarios répertoriés ci-dessus, lequel doit être activé par défaut ?

Notre expert en protection de la vie privée n’avait aucune préoccupation concernant les scénarios 1 à 5. La politique de confidentialité classique couvre ces scénarios. Toutefois, pour le scénario 2, nous devons déterminer si coldrooster.com devez être en mesure de gérer tous les favoris d’un utilisateur, quelle que soit l’application stockée pour l’utilisateur, ou uniquement les favoris ajoutés par les applications de Cold Rooster Consulting. Nous serions probablement prudents et disons que les applications de Cold Rooster Consulting ne peuvent gérer que les favoris des utilisateurs ajoutés via ces applications, sauf si l’utilisateur a explicitement spécifié que les applications peuvent être utilisées pour afficher ou modifier tous les favoris stockés au nom de l’utilisateur.

Même le scénario 6 n’est pas trop problématique, tant que la politique de confidentialité indique que nous pouvons utiliser les favoris des utilisateurs stockés pour une analyse plus approfondie. Là encore, nous devons déterminer si les données doivent être partitionnée (par domaine ou par l’application qui a fourni les données à l’origine) avant d’être analysées. Et étant donné que de nombreuses personnes se méfient du profilage des données, nous pourrions donner aux utilisateurs la possibilité de refuser que leurs favoris soient inclus dans les données mises en pool à des fins d’analyse.

Les autres scénarios deviennent de plus en plus désétents du point de vue de la confidentialité. Cela ne veut pas dire qu’ils ne doivent pas être implémentés, mais simplement qu’il serait plus difficile d’écrire une déclaration de stratégie précise mais compréhensible, et que les utilisateurs peuvent ne pas être à l’aise avec les scénarios, donc ils doivent probablement être désactivés par défaut (l’utilisateur doit accepter).

Le scénario 7 semble au départ assez inoffensive, mais ce qu’il signifie vraiment du point de vue du service Web, c’est qu’une application peut obtenir une copie de tous les favoris d’un utilisateur à partir du service Favoris. Une fois que l’application dispose d’une copie des données, elle peut en faire ce qu’elle veut. Si nous fournissons un service web qui prend en charge ce scénario, nous aimerions probablement restreindre l’accès au service web aux clients connus avec des stratégies de confidentialité qui répondent à des critères minimaux.

Le scénario 8 est encore plus problématique. Une fois qu’une application a la possibilité de modifier les favoris d’un utilisateur, qu’est-ce qui l’empêche d’ajouter des pages aléatoires à la liste de l’utilisateur ou de supprimer un favori pointant vers le site d’un concurrent ? En d’autres termes, comment le service Web peut-il distinguer les demandes de service valides effectuées par une application pour le compte d’un utilisateur final des demandes de service effectuées par une application dont l’utilisateur final n’a pas connaissance ? Les mécanismes de sécurité disponibles qui fonctionnent avec HTTP et XML ne prennent pas vraiment en charge ce type de scénario client/serveur/service directement. Nous devons implémenter une solution de sécurité personnalisée. Même avec le mécanisme de sécurité personnalisé, un travail supplémentaire serait probablement nécessaire pour fournir aux utilisateurs un moyen de spécifier quelles applications peuvent modifier les favoris.

Enfin, les scénarios 9 et 10 vont encore plus loin dans le domaine du profilage en ligne que le scénario 6. Les problèmes techniques ne sont vraiment pas différents de ceux déjà mentionnés, mais le niveau d’inconfort de l’utilisateur serait encore plus élevé.

Sur la base de cette analyse des scénarios, nous avons décidé de revenir en arrière et de repenser la vision de la livraison initiale du service Favoris. La nouvelle vision de la phase 1 se concentre sur les scénarios 3 à 5 ci-dessus. Pour l’essentiel, chaque application a son propre magasin privé pour les favoris des utilisateurs. Si j’accède à msdn.microsoft.com et que je stocke un lien vers cette colonne, je ne peux afficher ou modifier ce lien que via l’interface utilisateur msdn.microsoft.com fournit.

Cette approche élimine plusieurs problèmes difficiles. En fait, il élimine l’intégralité du problème de confidentialité des utilisateurs en ce qui concerne les favoris des utilisateurs ! Étant donné que chaque application qui utilise le service Favoris dispose effectivement d’un magasin distinct de favoris utilisateur , il n’est pas nécessaire d’utiliser un schéma d’identification d’utilisateur global que le service Favoris comprend. Chaque application peut utiliser le type d’identificateur qu’elle souhaite. Le service Favoris n’a aucun moyen d’interpréter ces identificateurs ou de mettre en corrélation les informations stockées par différentes applications. Étant donné que les données ne sont accessibles que par une seule application (ou, plus précisément, par un seul titulaire de licence du service Favoris), nous n’avons pas à nous soucier de fournir un moyen aux utilisateurs d’accepter ou de refuser différents scénarios. Nous avons effectivement délégué la question de la confidentialité des utilisateurs à l’application appelante.

Cela ne veut pas dire que nous ne nous soucions pas de résoudre les problèmes techniques soulevés dans notre analyse des scénarios ci-dessus. Nous voulons aborder ces problèmes dans une phase ultérieure du service Favoris. Nous voulons simplement prendre un peu plus de temps pour réfléchir et trouver une solution que nous nous sentons à l’aise de recommander à la communauté des développeurs.

Alors que se passe-t-il si vous avez besoin de résoudre le problème aujourd’hui ? Je ne vois aucun moyen d’implémenter un mécanisme de licence pour les utilisateurs et les applications. Les utilisateurs doivent s’inscrire pour obtenir un compte auprès de votre service. Cela signifie que vous disposez d’un site Web dans lequel ils peuvent lire votre politique de confidentialité, s’inscrire au compte et gérer leurs préférences. Les entreprises qui développent des applications doivent également s’inscrire pour obtenir une licence pour utiliser votre service web. Votre contrat de licence doit spécifier la façon dont les titulaires de licence informent leurs utilisateurs de l’utilisation de votre service web. Vous devez déterminer si vous pouvez faire confiance aux titulaires de licences pour utiliser uniquement le service Web de manière appropriée. Si c’est le cas, vous pouvez probablement vous en tirer en laissant le site Web collecter les informations d’identification de l’utilisateur et les transmettre à votre service web. Si ce n’est pas le cas, vous devez fournir du code que les titulaires de licences peuvent utiliser pour fournir un mécanisme sécurisé permettant de récupérer les informations d’identification de l’utilisateur et de les transmettre au service web. Quoi qu’il en soit, il y aura beaucoup de travail à faire.

Problèmes de confidentialité restants

Bien que nous n’ayons pas besoin de nous soucier de la confidentialité des utilisateurs en ce qui concerne les favoris des utilisateurs dans la phase 1, il existe toujours des problèmes de confidentialité à prendre en compte. Nous avons décidé d’obtenir une licence d’accès au service Favoris. Cela signifie que nous devrons conserver des informations de contact sur les titulaires de licence. Ces informations appartiennent à la catégorie des informations d’identification personnelle. Nous avons donc les problèmes de confidentialité standard auxquels toute application qui gère les informations de compte est confrontée.

Nous avons résolu ces problèmes à l’aide d’une combinaison de stratégie et de code. Le diagramme suivant fournit une vue d’ensemble de notre architecture système :

Figure 1. Architecture du service Favoris dans la phase 1

Notre service est implémenté avec une architecture en couches et est déployé sur deux niveaux physiques, la batterie de serveurs Web et le cluster de données. Les informations de compte du titulaire de licence sont stockées dans une base de données sur le cluster de données. Notre service web et le site Web par l’intermédiaire duquel les titulaires de licences gèrent les informations de leur compte sont déployés sur la batterie de serveurs Web. Il existe plusieurs couches de protection pour les informations du titulaire de licence :

  • Le cluster de données n’est pas accessible à partir de machines extérieures à Cold Rooster Consulting.
  • Le service Favoris n’a pas besoin d’accéder aux informations de contact du titulaire de licence. Il utilise donc un composant d’ouverture de session pour authentifier les titulaires de licence. Le composant Logon récupère uniquement les informations dont il a besoin.
  • D’autre part, le site Web de gestion des licences doit accéder aux coordonnées du titulaire de licence. Comment peut-il permettre au titulaire de licence de modifier les données ? Le site Web effectue tous les accès aux données via le composant Licences. Les contrôles d’accès sur le composant Licence empêchent tout autre chose que le site Web de gestion des licences d’appeler le composant.
  • Les contrôles d’accès sur la base de données du titulaire de licence empêchent tout autre chose que le composant Ouverture de session et le composant Licence d’accéder à la base de données.
  • Les e-mails de confirmation sont envoyés aux adresses spécifiées dans les informations de contact chaque fois que les informations de contact sont modifiées.

Effet net : Il devrait être très difficile pour les utilisateurs non autorisés d’accéder ou de modifier les coordonnées du titulaire de licence, sauf si l’identificateur et le mot de passe d’un titulaire de licence sont compromis. Même dans cette situation, si quelqu’un tentait de modifier ses coordonnées, le contact actuel en serait informé.

En outre, nous publierons une politique de confidentialité sur notre site Web. Nous pourrions également fournir la politique de confidentialité ainsi que d’autres documents que nous fournissons aux nouveaux titulaires de licence, comme la documentation sur la façon d’écrire des applications qui utilisent le service Favoris.

Conclusion

La confidentialité des utilisateurs est un problème épineux pour les développeurs de services Web et les applications qui les utilisent. Notre analyse du problème pour le service Favoris nous a amenés à repenser l’ensemble de l’objectif du service. Même avec la portée réduite, un nombre important d’exigences ont été ajoutées afin de s’assurer que les informations sur les utilisateurs étaient protégées contre toute utilisation inappropriée. L’exigence la plus importante était la nécessité de restreindre l’accès aux applications sous licence. La semaine prochaine, nous examinerons plus en détail les licences : les modèles d’entreprise que nous avons pris en compte, le modèle que nous avons sélectionné et l’impact du modèle sur notre conception et notre implémentation.

Si votre service web doit conserver des informations d’identification personnelle, vous avez beaucoup de travail à faire au-delà de l’implémentation des fonctionnalités de base de votre service. Vous devez aborder les cinq éléments des pratiques d’information équitables : notification, consentement, accès, sécurité et application. Vous devez déterminer quand vous devez les traiter directement avec les utilisateurs et quand vous pouvez reporter les problèmes de confidentialité aux applications qui utilisent votre service web. Je vous recommande vivement d’impliquer vos conseillers juridiques dans des discussions sur ces questions afin de vous assurer que vous êtes à jour en ce qui concerne les lois sur la confidentialité des utilisateurs, où que vos utilisateurs se trouvent. Les ressources suivantes fournissent des informations supplémentaires sur la confidentialité des utilisateurs :