DO_NOT_TRACK - un standard pour protéger la vie privée

 (donottrack.sh)
2 points par GN⁺ 1 시간 전 | 1 commentaires | Partager sur WhatsApp
  • DO_NOT_TRACK est une proposition visant à unifier, via une seule variable d’environnement, les différentes façons de désactiver la télémétrie selon les outils CLI, SDK et frameworks
  • .NET, AWS SAM CLI, Azure CLI, Gatsby, Go, Google Cloud SDK, Homebrew, Netlify CLI, Syncthing désactivent chacun la télémétrie avec des réglages ou des commandes différents
  • DO_NOT_TRACK=1 signifie refuser le suivi publicitaire, les rapports d’usage, la télémétrie, les rapports de plantage, ainsi que les requêtes adressées aux éditeurs ou à des tiers qui ne sont pas indispensables au fonctionnement
  • Les utilisateurs peuvent définir export DO_NOT_TRACK=1 et l’ajouter à la configuration de leur shell dans Bash, Zsh, Fish, PowerShell ou Windows CMD afin de l’appliquer à toutes les sessions de terminal
  • Les éditeurs de logiciels doivent désactiver tout suivi si DO_NOT_TRACK vaut 1, et respecter cette variable en plus des méthodes de désactivation existantes

Problème et proposition

  • De nombreux outils CLI, SDK et frameworks collectent par défaut des données de télémétrie, et chaque outil propose une méthode différente pour les désactiver
  • Par exemple, .NET utilise DOTNET_CLI_TELEMETRY_OPTOUT=1, AWS SAM CLI utilise SAM_CLI_TELEMETRY=0, Azure CLI utilise AZURE_CORE_COLLECT_TELEMETRY=0, Gatsby utilise GATSBY_TELEMETRY_DISABLED=1, Go utilise go telemetry off, Google Cloud SDK utilise gcloud config set disable_usage_reporting true, Homebrew utilise HOMEBREW_NO_ANALYTICS=1, Netlify CLI utilise netlify --telemetry-disable, Syncthing utilise STNOUPGRADE=1
  • DO_NOT_TRACK est proposé comme une variable d’environnement standard unique qui exprime clairement que l’utilisateur refuse les éléments suivants
    • le suivi publicitaire
    • les rapports d’usage, qu’ils soient anonymes ou non
    • la télémétrie
    • les rapports de plantage
    • les requêtes adressées à l’éditeur du logiciel ou à des tiers qui ne sont pas indispensables au fonctionnement
  • Les utilisateurs peuvent indiquer qu’ils ne veulent qu’un logiciel local en définissant export DO_NOT_TRACK=1
  • En l’ajoutant au fichier de configuration du shell, cela peut s’appliquer à toutes les sessions de terminal
    • Bash : ~/.bashrc avec export DO_NOT_TRACK=1
    • Zsh : ~/.zshrc avec export DO_NOT_TRACK=1
    • Fish : ~/.config/fish/config.fish avec set -x DO_NOT_TRACK 1
    • PowerShell : $PROFILE avec $env:DO_NOT_TRACK = "1"
    • Windows CMD : setx DO_NOT_TRACK 1 dans les variables d’environnement système

Éditeurs de logiciels et standards associés

  • Les outils qui effectuent de la télémétrie, des analyses ou des requêtes réseau non indispensables au fonctionnement doivent vérifier la variable DO_NOT_TRACK
  • Si DO_NOT_TRACK est défini à 1, tout suivi doit être désactivé
  • Cette variable doit être respectée en plus des méthodes de désactivation existantes
  • Au lieu d’activer la télémétrie par défaut avec un mécanisme d’exclusion, il est aussi envisageable d’adopter un fonctionnement en opt-in
  • no-color.org — NO_COLOR, standard pour désactiver la sortie en couleur
  • force-color.org — FORCE_COLOR, standard pour forcer la sortie en couleur

À lire aussi

1 commentaires

 
GN⁺ 1 시간 전
Commentaires Hacker News

  • Il est intéressant qu’à ce stade, plus personne ne semble surpris même si l’état par défaut est le consentement au suivi
    Un indicateur comme DO_NOT_TRACK a l’air bien, mais en même temps ça donne l’impression que la valeur par défaut est CONSENT_TO_TRACK=1, ce qui fait froid dans le dos

    • À quel moment demande-t-on de ne pas suivre ? Cet indicateur est envoyé par mon navigateur lorsqu’il se connecte au serveur de quelqu’un d’autre
      Si Internet a grandi ainsi, c’est parce que le modèle économique dominant reposait sur la publicité et sur des serveurs qui extraient des informations dérivées des utilisateurs
      Ce n’est ni agréable, ni privé, ni sûr, mais dans la plupart des juridictions et des secteurs, ce n’est pas non plus illégal
      Cet indicateur n’est pas un idéal de conte de fées, mais une réponse à une réalité déjà solidement installée, de fait comme en droit
    • Je pense que ce genre d’indicateur est en soi problématique
      Je ne veux transmettre aucune information, et bien sûr je ne veux pas être suivi, donc le simple fait d’exprimer cela via une variable d’environnement n’a déjà pas de sens
      J’ai du mal à comprendre les gens qui disent ne pas vouloir être suivis tout en aimant fournir cette information, et au moment même où ils la donnent, c’est déjà signalé

  • J’essaie toujours de nommer les variables de manière positive, donc ici ce serait ALLOW_TRACKING=0
    Cela apporte de la cohérence et évite la double négation, ce qui rend le raisonnement plus simple
    Cela dit, le nom « DO NOT TRACK » est peut-être déjà un terme relativement établi

    • On pourrait implémenter ALLOW_TRACKING comme une liste séparée par des virgules, afin de ne désigner que les applications autorisées
      Par exemple, si je veux partager de la télémétrie avec go et brew, mais pas avec aws ni le reste, je pourrais mettre ALLOW_TRACKING=go,brew

  • Cela risque de connaître le même destin que le DNT du navigateur
    En revanche, rassembler toutes les variables d’environnement de type « ne pas suivre » dans un seul fichier do_not_track.env ne semble pas être une mauvaise idée

    • https://toptout.me existe déjà et, sauf si l’idée est d’en créer un nouveau, ce site traite déjà une bonne partie du problème
      Si l’on veut respecter la spécification de cette page tout en gérant cela avec une simple variable d’environnement, il y a aussi https://github.com/alloydwhitlock/do-not-track-cli
    • Le secteur publicitaire a ignoré le DNT de Microsoft en affirmant que l’activer par défaut privait les utilisateurs de leur liberté de choix
      En réalité, il est très probable qu’ils n’avaient de toute façon aucune intention de le respecter
    • J’aime bien cette direction
      Plutôt que d’exiger l’usage d’une solution universelle, une vraie solution ressemblera probablement davantage à cela
      Je pense essayer d’en faire quelque chose comme point de départ

  • À noter que la télémétrie de Go est stockée localement par défaut et n’est pas envoyée : https://go.dev/doc/telemetry

  • J’ai été surpris de voir à quel point il est difficile d’empêcher la bibliothèque Python transformers de contacter Hugging Face
    J’ai défini HF_HUB_DISABLE_TELEMETRY=1 et j’ai aussi précisé local_files_only=True lors de l’appel à Wav2Vec2CTCTokenizer.from_pretrained, mais j’avais quand même un avertissement disant qu’aucun HF_TOKEN valide n’était présent
    Ce n’est qu’après être tombé par hasard sur HF_HUB_OFFLINE=1 que j’ai eu un minimum de certitude qu’aucune connexion vers HF n’était faite à chaque chargement du modèle wav2vec2 depuis le disque
    Sans cet agaçant avertissement HF_TOKEN, je n’aurais probablement même pas su que cela se produisait

    • HF a la réputation de rendre le travail hors ligne pénible
      Même le fait d’éviter de perdre du temps à essayer de se connecter alors que tout ce qu’il faut est déjà en local change constamment de mécanisme
      Avant, il y avait aussi TRANSFORMERS_OFFLINE, HF_DATASETS_OFFLINE, etc.
    • Un outil comme Little Snitch pourrait-il aider à repérer ce genre de choses et à identifier ce qui fait des communications cachées ?

  • Cela ressemble à un pot de miel utile
    Si un outil annonce publiquement qu’il prend en charge cette spécification, on peut aussi y voir le signe qu’il collecte de la télémétrie sans consentement explicite au départ, donc qu’il vaut mieux l’éviter

    • Le support de DO_NOT_TRACK ne signifie pas nécessairement que le suivi n’était pas déjà basé sur un consentement explicite
      Par exemple, il arrive qu’un logiciel plante et qu’un gestionnaire de crash demande s’il doit envoyer un dump
      Si DO_NOT_TRACK est présent, le gestionnaire de crash lui-même pourrait être désactivé, donc pas de question et pas de dump
      Si cela est adopté dans une certaine mesure, c’est probablement ainsi que cela fonctionnerait
      Les acteurs qui tirent un profit financier du suivi, comme la publicité, ne prendront probablement pas en charge ce type d’option
    • La plupart des services collectent déjà de la télémétrie, et le fait d’annoncer qu’ils la prennent en charge ne change rien à cette réalité
    • Mieux vaut ne pas trop creuser
      Sinon, on risque de ne plus pouvoir utiliser beaucoup d’outils modernes

  • En attendant que les entreprises implémentent cette proposition à un rythme très lent, existe-t-il un endroit qui centralise les méthodes de désinscription des outils courants ?
    On pourrait même imaginer un module shell qui les configure et met régulièrement la liste à jour

  • Il est probablement plus simple d’exploiter son propre DNS et d’ajouter les domaines problématiques à une liste de blocage
    Il existe aussi de bonnes listes de blocage contenant des millions de domaines de télémétrie. Par exemple : https://github.com/hagezi/dns-blocklists

    • Mieux encore, ne pas laisser entrer ce genre de saletés de spyware sur sa machine
    • C’est la bonne manière de gérer le problème
      Ceux qui crient au « standard » ne font qu’ajouter une option de plus à une longue liste d’alternatives non officielles

  • L’interdiction globale du suivi dans le navigateur vise le suivi publicitaire sur tous les sites visités, et cela fonctionne globalement
    Mais la télémétrie est un problème totalement différent, donc un blocage par défaut peut être une option, alors qu’utiliser une seule variable standard pour exprimer l’intention sur tous les outils est difficilement réaliste

  • La même proposition existait déjà il y a quelques années, mais elle n’a abouti à rien
    https://web.archive.org/web/20200613155957/https://consoledo...