DO_NOT_TRACK - Ein Standard für den Schutz der Privatsphäre

 (donottrack.sh)
2 Punkte von GN⁺ 1 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • DO_NOT_TRACK ist ein Vorschlag, die unterschiedlichen Methoden zum Deaktivieren von Telemetrie in CLI-Tools, SDKs und Frameworks in einer einzigen Umgebungsvariable zu vereinheitlichen
  • .NET, AWS SAM CLI, Azure CLI, Gatsby, Go, Google Cloud SDK, Homebrew, Netlify CLI und Syncthing deaktivieren Telemetrie jeweils über unterschiedliche Einstellungen oder Befehle
  • DO_NOT_TRACK=1 bedeutet, dass Werbetracking, Nutzungsberichte, Telemetrie, Crash-Reporting sowie Anfragen an Hersteller oder Dritte abgelehnt werden, sofern sie nicht für die Funktion zwingend erforderlich sind
  • Nutzer können export DO_NOT_TRACK=1 setzen und dies zu den Shell-Einstellungen von Bash, Zsh, Fish, PowerShell oder Windows CMD hinzufügen, um es auf alle Terminal-Sitzungen anzuwenden
  • Softwarehersteller sollen bei DO_NOT_TRACK = 1 jegliches Tracking deaktivieren und diese Variable zusätzlich zu bestehenden Deaktivierungsmethoden respektieren

Problem und Vorschlag

  • Viele CLI-Tools, SDKs und Frameworks sammeln standardmäßig Telemetriedaten, und jedes Tool hat eine andere Methode zur Deaktivierung
  • Zum Beispiel verwendet .NET DOTNET_CLI_TELEMETRY_OPTOUT=1, AWS SAM CLI SAM_CLI_TELEMETRY=0, Azure CLI AZURE_CORE_COLLECT_TELEMETRY=0, Gatsby GATSBY_TELEMETRY_DISABLED=1, Go go telemetry off, Google Cloud SDK gcloud config set disable_usage_reporting true, Homebrew HOMEBREW_NO_ANALYTICS=1, Netlify CLI netlify --telemetry-disable und Syncthing STNOUPGRADE=1
  • DO_NOT_TRACK wird als einheitliche Standard-Umgebungsvariable vorgeschlagen, die klar ausdrückt, dass Nutzer Folgendes ablehnen
    • Werbetracking
    • Nutzungsberichte, unabhängig davon, ob sie anonym sind oder nicht
    • Telemetrie
    • Crash-Reporting
    • Anfragen an Softwarehersteller oder Dritte, die nicht für die Funktion zwingend erforderlich sind
  • Nutzer können ihren Wunsch nach rein lokaler Software mit export DO_NOT_TRACK=1 ausdrücken
  • Wird dies in die Shell-Konfigurationsdatei aufgenommen, gilt es für alle Terminal-Sitzungen
    • Bash: export DO_NOT_TRACK=1 in ~/.bashrc
    • Zsh: export DO_NOT_TRACK=1 in ~/.zshrc
    • Fish: set -x DO_NOT_TRACK 1 in ~/.config/fish/config.fish
    • PowerShell: $env:DO_NOT_TRACK = "1" in $PROFILE
    • Windows CMD: setx DO_NOT_TRACK 1 als System-Umgebungsvariable

Softwarehersteller und verwandte Standards

  • Tools, die Telemetrie, Analytics oder Netzwerk-Anfragen ausführen, die nicht für die Funktion zwingend erforderlich sind, sollten die Variable DO_NOT_TRACK prüfen
  • Wenn DO_NOT_TRACK auf 1 gesetzt ist, sollte jegliches Tracking deaktiviert werden
  • Diese Variable sollte zusätzlich zu bestehenden Deaktivierungsmethoden respektiert werden
  • Statt Telemetrie standardmäßig zu aktivieren und anschließend eine Opt-out-Möglichkeit anzubieten, sollte auch ein Opt-in-Ansatz erwogen werden
  • no-color.org — NO_COLOR, ein Standard zum Deaktivieren farbiger Ausgabe
  • force-color.org — FORCE_COLOR, ein Standard zum Erzwingen farbiger Ausgabe

Verwandte Beiträge

1 Kommentare

 
GN⁺ 1 시간 전
Hacker-News-Kommentare

  • Es ist interessant, dass an diesem Punkt wohl niemand mehr überrascht wäre, wenn die Einwilligung zum Tracking der Standardzustand wäre
    Ein Flag wie DO_NOT_TRACK wirkt zwar sinnvoll, fühlt sich aber gleichzeitig so an, als würde es bedeuten, dass der Standardwert CONSENT_TO_TRACK=1 ist — ziemlich gruselig

    • Wann genau soll denn nicht getrackt werden? Dieses Flag wird gesendet, wenn mein Browser sich mit fremden Servern verbindet
      Das Internet ist groß geworden, weil Werbung und Geschäftsmodelle, bei denen Server abgeleitete Informationen aus Nutzern herausziehen, zum Mainstream wurden
      Das ist weder angenehm noch privat noch sicher, aber in den meisten Rechtsräumen und Branchen auch nicht illegal
      Dieses Flag ist keine märchenhafte Utopie, sondern eine Reaktion auf eine faktisch und rechtlich verfestigte Realität
    • Ich halte schon solche Flags an sich für problematisch
      Ich will überhaupt keine Informationen nach außen geben und selbstverständlich auch nicht getrackt werden, daher ist schon die Kennzeichnung über nur eine Umgebungsvariable unsinnig
      Ich kann nur schwer verstehen, warum jemand, der nicht getrackt werden will, gern genau diese Information preisgibt — in dem Moment, in dem man sie preisgibt, ist man bereits markiert

  • Ich benenne Variablen grundsätzlich positiv, daher wäre es in diesem Fall ALLOW_TRACKING=0
    Das schafft Konsistenz und vermeidet doppelte Verneinungen, wodurch sich leichter darüber nachdenken lässt
    Allerdings könnte „DO NOT TRACK“ bereits ein einigermaßen etablierter Begriff sein

    • Man könnte ALLOW_TRACKING auch als kommaseparierte Liste umsetzen, sodass nur bestimmte Anwendungen erlaubt sind
      Wenn man zum Beispiel Telemetrie mit go und brew teilen möchte, aber nicht mit aws und allem anderen, könnte man ALLOW_TRACKING=go,brew setzen

  • Wahrscheinlich wird das dasselbe Schicksal erleiden wie DNT im Browser
    Allerdings scheint es keine schlechte Idee zu sein, alle Umgebungsvariablen für „nicht tracken“ in einer einzigen Datei do_not_track.env zu sammeln

    • https://toptout.me gibt es bereits, und falls man nicht vorhat, etwas Neues zu bauen, nimmt einem das schon ziemlich viel von diesem Problem ab
      Wenn man sich an die Spezifikation auf dieser Seite halten und das mit nur einer simplen Umgebungsvariable lösen möchte, gibt es auch https://github.com/alloydwhitlock/do-not-track-cli
    • Die Werbeindustrie ignorierte DNT mit dem Argument, Microsoft habe es standardmäßig aktiviert und den Nutzern damit die Wahl genommen
      In Wirklichkeit hatten sie es vermutlich ohnehin nie vor zu respektieren
    • Mir gefällt diese Richtung
      Statt zu verlangen, dass alle ein universelles Ding verwenden, liegt die tatsächliche Lösung wahrscheinlich eher in so einem Ansatz
      Ich überlege, als Ausgangspunkt etwas in diese Richtung zu bauen

  • Zur Einordnung: Go-Telemetrie wird standardmäßig nur lokal gespeichert und nicht hochgeladen: https://go.dev/doc/telemetry

  • Ich war überrascht, wie schwierig es ist, die Python-Bibliothek transformers daran zu hindern, Hugging Face zu kontaktieren
    Ich habe HF_HUB_DISABLE_TELEMETRY=1 gesetzt und beim Aufruf von Wav2Vec2CTCTokenizer.from_pretrained auch ausdrücklich local_files_only=True angegeben, bekam aber trotzdem noch eine Warnung, dass kein gültiges HF_TOKEN vorhanden sei
    Erst als ich zufällig HF_HUB_OFFLINE=1 fand, war ich einigermaßen sicher, dass beim Laden eines wav2vec2-Modells von der Festplatte nicht doch jedes Mal eine Verbindung zu HF aufgebaut wird
    Ohne diese nervige HF_TOKEN-Warnung hätte ich womöglich nie bemerkt, dass das überhaupt passiert

    • HF ist berüchtigt dafür, Offline-Arbeit schwierig zu machen
      Selbst wenn alles Nötige lokal vorhanden ist, ändert sich ständig, wie man verhindert, dass durch Verbindungsversuche Zeit verschwendet wird
      Früher gab es auch Dinge wie TRANSFORMERS_OFFLINE und HF_DATASETS_OFFLINE
    • Könnte ein Tool wie Little Snitch so etwas erkennen und helfen, die Ziele dieser versteckten Kommunikation zu finden?

  • Das wirkt wie ein nützlicher Honigtopf
    Wenn ein Tool öffentlich bekanntgibt, dass es diese Spezifikation unterstützt, könnte man es als ein Tool ansehen, das ohnehin ohne ausdrückliche Einwilligung Telemetrie sammelt — und das man besser meidet

    • Unterstützung für DO_NOT_TRACK bedeutet nicht automatisch, dass Tracking nicht auf ausdrücklicher Einwilligung basiert
      Zum Beispiel kann Software abstürzen, und der Crash-Handler fragt dann, ob ein Dump gesendet werden soll
      Wenn DO_NOT_TRACK gesetzt ist, wird der Crash-Handler selbst deaktiviert — also keine Frage und kein Dump
      Falls sich das einigermaßen durchsetzt, wird es vermutlich eher so funktionieren
      Wer wie die Werbebranche finanziell von Tracking profitiert, wird solche Optionen eher nicht unterstützen
    • Die meisten Dienste sammeln ohnehin bereits Telemetrie, und die Ankündigung einer Unterstützung ändert nichts an dieser Tatsache
    • Man sollte besser nicht zu tief hineinschauen
      Sonst kann man viele moderne Tools nicht mehr verwenden

  • Während wir darauf warten, dass Unternehmen diesen Vorschlag sehr langsam umsetzen: Gibt es irgendwo eine zentrale Sammlung der Opt-out-Methoden für gängige Tools?
    Vorstellbar wäre sogar ein Shell-Modul, das sie direkt setzt und die Liste regelmäßig aktualisiert

  • Wahrscheinlich ist es einfacher, einen eigenen DNS zu betreiben und problematische Domains in eine Sperrliste aufzunehmen
    Es gibt gute Sperrlisten mit Millionen von Telemetrie-Domains. Zum Beispiel: https://github.com/hagezi/dns-blocklists

    • Noch besser wäre es, sich solchen Spyware-Müll gar nicht erst auf den Rechner zu holen
    • Das ist der richtige Weg, damit umzugehen
      Die Leute, die nach einem „Standard“ rufen, fügen nur noch einen weiteren Eintrag zu der langen Liste inoffizieller Alternativen hinzu

  • Ein globales Tracking-Verbot im Browser betrifft alle besuchten Websites und Tracking zu Werbezwecken, deshalb funktioniert es im Großen und Ganzen
    Aber Telemetrie ist ein völlig anderes Problem; eine Standardsperre kann zwar eine Option sein, aber eine einzige Standardvariable zu verwenden, um die Absicht für alle Tools auszudrücken, ist in der Praxis schwierig

  • Schon vor ein paar Jahren gab es denselben Vorschlag, aber daraus wurde nichts
    https://web.archive.org/web/20200613155957/https://consoledo...