GitHub CLI erfasst jetzt pseudonymisierte Telemetrie

 (cli.github.com/telemetry)
2 Punkte von GN⁺ 7 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • GitHub CLI sendet jetzt pseudonymisierte Telemetrie, um die Sichtbarkeit der Funktionsnutzung zu verbessern und Produktverbesserungen zu unterstützen
  • Anhand der Nutzung von Subcommands und Mustern bei der Verwendung von Flags werden Prioritäten für die Arbeit festgelegt, bewertet, ob Nutzeranforderungen erfüllt werden, und Discoverability sowie Design erneut überprüft
  • Durch die Open-Source-Implementierung kann der Telemetrie-Code direkt im Repository cli/cli geprüft werden; im Logging-Modus lässt sich der tatsächliche JSON-Payload vor dem Versand einsehen
  • Opt-out ist über die Umgebungsvariablen GH_TELEMETRY=false, DO_NOT_TRACK=true oder gh config set telemetry disabled möglich; Umgebungsvariablen haben Vorrang vor der Konfiguration
  • Telemetrieereignisse werden an die interne Analyseinfrastruktur von GitHub gesendet; diese Seite behandelt nur die clientseitige Datenerfassung von gh, Extensions und Copilot CLI sind separat zu betrachten

Telemetrie

  • GitHub CLI sendet pseudonymisierte Telemetrie, um Produktverbesserungen zu unterstützen
  • Es werden Informationen bereitgestellt, damit Nutzer verstehen können, welche Daten gesendet werden und warum

Warum Telemetrie erfasst wird

  • Es wird auf die Notwendigkeit hingewiesen, Sichtbarkeit über die Nutzung von GitHub-CLI-Funktionen zu gewinnen, insbesondere vor dem Hintergrund der zunehmenden agentischen Nutzung, um zu verstehen, wie das Tool tatsächlich verwendet wird
    • Das Team nutzt diese Daten, um Arbeitsprioritäten festzulegen
    • Es bewertet damit, ob Funktionen die tatsächlichen Anforderungen der Nutzer erfüllen
  • Als weiterer Zweck wird genannt, die Akzeptanz neuer Subcommands nach ihrer Veröffentlichung zu prüfen
    • Wenn sie kaum genutzt werden, müssen Discoverability oder Design der Funktion möglicherweise überdacht werden
    • Wenn zusammen mit bestimmten Flags eine hohe Nutzung festgestellt wird, lässt sich erkennen, wo sich Investitionen in eine bessere Experience lohnen

Prüfung der Telemetrie

  • GitHub CLI ist Open Source, und die Telemetrie-Implementierung kann direkt im Repository cli/cli geprüft werden
  • Um die Daten zu sehen, die gesendet würden, ohne sie tatsächlich zu übertragen, kann der Logging-Modus verwendet werden
    • Unterstützung per Umgebungsvariable
      • export GH_TELEMETRY=log
    • Unterstützung per CLI-Konfiguration
      • gh config set telemetry log
  • Im Logging-Modus wird der JSON-Payload, der normalerweise gesendet würde, auf stderr ausgegeben
    • So können einzelne Felder geprüft werden, bevor entschieden wird, ob Telemetrie aktiviert bleiben soll
    • Als Beispielbefehl wird GH_TELEMETRY=log gh repo list --archived genannt
  • Es wird angegeben, welche Ereignisinformationen im Beispiel-Payload enthalten sind
    • Ereignistyp command_invocation
    • Als dimensions-Felder enthalten: agent, architecture, command, device_id, flags, invocation_id, is_tty, os, timestamp, version
    • Als Beispielwerte werden architecture: arm64, command: gh repo list, flags: archived, os: darwin, version: 2.91.0 gezeigt
  • Der betreffende Befehl kann nur die Telemetrie für den genau ausgeführten Befehl und dessen Kontext protokollieren
    • Bei Änderungen an Umgebungsvariablen können sich die im Payload enthaltenen Events und Event-Dimensions ändern
    • Auch beim Wechsel des authentifizierten Kontos können sich enthaltene Elemente unterscheiden

Opt-out-Möglichkeiten

  • Für die im Logging-Modus geprüfte Telemetrie ist ein Opt-out möglich
  • Unterstützung per Umgebungsvariable
    • export GH_TELEMETRY=false
    • Als falsy-Werte können 0, false, disabled oder eine leere Zeichenfolge verwendet werden
    • Auch die Konvention DO_NOT_TRACK wird unterstützt; als Beispiel wird export DO_NOT_TRACK=true genannt
  • Unterstützung per CLI-Konfiguration
    • gh config set telemetry disabled
  • Umgebungsvariablen haben Vorrang vor dem Konfigurationswert

Wohin die Daten gesendet werden

  • Telemetrieereignisse werden an die interne Analyseinfrastruktur von GitHub gesendet
  • Für weitere Informationen zur Datenverarbeitung wird auf das GitHub General Privacy Statement verwiesen

Weitere Informationen

  • GitHub CLI unterstützt Funktionserweiterungen durch die Installation von GitHub- und Drittanbieter-Extensions, einschließlich Agents
  • Diese Extensions können eigene Nutzungsdaten erfassen
    • Dies wird nicht durch die Opt-out-Einstellungen gesteuert
    • Ob und wie Telemetrie gemeldet wird und ob sie deaktiviert werden kann, muss in der Dokumentation der jeweiligen Extension geprüft werden
  • Diese Seite behandelt nur die clientseitige Datenerfassung von GitHub CLI gh
    • Sie gilt nicht für GitHub Copilot und Copilot CLI
    • Copilot CLI verarbeitet die Datenerfassung separat
    • Als zugehörige Informationen werden Using GitHub Copilot CLI und Responsible Use of the GitHub Copilot CLI genannt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 7 일 전
Hacker-News-Kommentare

  • Ich frage mich, warum Unternehmens-Entwicklerteams Nutzer immer mit Telemetry durchleuchten wollen.
    Ich würde gern fragen, ob gutes Engineering und gutes Design allein nicht ausreichen.
    Git funktioniert seit über 20 Jahren gut, ohne detailliert zu analysieren, wer welche Features und Befehle nutzt; daher frage ich mich, ob Telemetry es wirklich besser gemacht hätte oder nur noch mehr verstreute Daten erzeugt hätte.

    • Früher dachte ich auch, dass das unnötig ist, aber nachdem ich selbst ein Startup aufgebaut habe, hat sich meine Sicht geändert.
      Ohne Analytics fühlt es sich an, als würde man mit verbundenen Augen fahren.
      Man weiß nicht, was Nutzern wirklich wichtig ist, welche Abläufe man optimieren sollte, und der Unterschied zwischen dem, was Menschen sagen, und der Art, wie sie Software tatsächlich benutzen, ist erstaunlich groß.
    • Entwickler und Nutzer haben unterschiedliche Bedürfnisse und Sichtweisen, deshalb reicht gutes Design allein meiner Meinung nach nicht aus.
      Oft ist es auch schwer, von Menschen gutes Feedback zu bekommen, und selbst wenn alle die Idee für Feature X gut finden, kann es sein, dass es in der Praxis überhaupt nicht genutzt wird.
      Außerdem kann es lautstarke Fans geben, ohne dass sich das in Umsatz oder realer Nutzung niederschlägt.
      Ich denke, dass Git mit Telemetry sehr wahrscheinlich besser geworden wäre.
      Git ist bekanntlich UI-mäßig schlecht.
      Man hätte früh in den Daten gesehen, wie oft Menschen am Anfang scheitern, und Verbesserungen wie git restore wären vermutlich viel früher gekommen statt unintuitiver Befehle wie git checkout -- foo.txt.
    • Leider liegt dieses Phänomen meiner Meinung nach daran, dass es viele nichttechnische Entscheidungsträger gibt.
      Wenn Leute, die das Tool nicht selbst benutzen, nicht verstehen, wie es tatsächlich verwendet wird, verlangen PMs für Entwicklerwerkzeuge solche Daten, um ihre Arbeit machen zu können.
      Das wirkt wie dieselbe Struktur, in der ein E-Commerce-PM massenhaft Tracking-Skripte auf das Frontend packt.
      Früher konnten Ingenieure die Interaktion mit Nutzern auch allein entwerfen, aber seit dem VC-Zeitalter hat sich das Paradigma verfestigt, dass technische Produkte tiefgehend von Nichttechnikern geführt werden.
      Am Ende landen die Daten bei ihnen, und irgendjemand rechtfertigt damit dann das PM-Gehalt.
    • Ich finde nicht, dass man einfach selbstverständlich sagen kann, Telemetry hätte Git nicht geholfen.
      Für mich ist das nicht eindeutig.
    • Git ist meiner Meinung nach in Design und Usability miserabel.
      Es wirkt wie ein Paradebeispiel dafür, dass Ingenieure Interfaces für Ingenieure bauen und es keine gute Feedback-Schleife gab.
      Ironischerweise zeigt genau dieses Beispiel, dass Entwickler besser verstehen müssen, wie ihre Produkte tatsächlich genutzt werden.
      Das Nutzungsszenario im Kopf des Entwicklers unterscheidet sich meist deutlich von der Realität.

  • Ich denke, das Opt-out-Problem beim gh-CLI ist komplizierter, als es scheint.
    gh läuft auch in CI/CD-Pipelines oder Serverumgebungen, und dort möchte man aus Netzwerkeinschränkungen, nicht nur aus Datenschutzgründen, möglicherweise überhaupt keine Verbindung zu github.com.
    Wenn Telemetry dort standardmäßig aktiviert ist, kann CI scheitern oder ein Bastion Host GitHub gar nicht erreichen.
    Git selbst arbeitet dagegen vollständig lokal, bis der Nutzer explizit pusht.
    Das ist also ein anderes Vertrauensmodell.
    Git telefoniert standardmäßig nie nach Hause, solange man es nicht konfiguriert, während gh als Wrapper um die GitHub-API funktional natürlich Aufrufe machen muss.
    Unabhängig davon sollte man aber separat diskutieren, ob zusätzlich noch Nutzungsmuster von Befehlen erfasst und hochgeladen werden müssen.

    • Ich glaube nicht, dass das Programm mit einem harten Fehler abstürzt, nur weil die Übermittlung von Telemetry nicht klappt.
    • Ich frage mich, ob gh ohne Verbindung zu GitHub.com faktisch nutzlos ist.
      Oder ist die Verbindung zu Enterprise GitHub der Hauptanwendungsfall?

  • Wenn drei Entwickler 80 Prozent ihrer Zeit in einen bestimmten Bereich der Codebasis stecken, dieser aber gar nicht genutzt wird und realistischerweise wohl auch künftig nicht stärker genutzt werden wird, wäre es vielleicht besser, diese Leute anders einzusetzen oder das Feature grundsätzlich zu überdenken.
    Das Problem bei solcher Analytics ist allerdings, dass man zwar harmlos damit umgehen kann, aber mit eindeutigen Kennungen und Verhaltensmustern per Machine Learning auch Identitäten rekonstruieren kann.
    Mit Zeitstempeln wird es noch heikler.
    Deshalb fände ich es gut, wenn genau offengelegt würde, wann welche Telemetry gesendet wird.
    Zum Beispiel könnte es eine Option geben, die nichts sendet, aber in einem Verbose-Modus zeigt, was gesendet würde, damit Nutzer das prüfen und dann entscheiden können, ob sie es aktivieren.
    Ein Modell wie die Steam Hardware Survey, die zeigt, was übertragen wird, erscheint mir sinnvoll.

  • Alle gh-Befehle sind letztlich nur Wrapper um die GitHub-API, und genau dadurch wirkt diese Debatte noch verwirrender.

  • Ich mag so kurze PRs.
    https://github.com/cli/cli/pull/13254
    Der Inhalt ist auch einfach: Ich lese das so, dass die Env-Var entfernt wird, mit der man Telemetry blockieren konnte, und damit auf standardmäßig aktiviert umgestellt wird.

    • Es sieht nicht nur standardmäßig aktiviert aus, sondern eher so, als ließe es sich gar nicht deaktivieren.
      Außer für Enterprise scheint es faktisch zwangsweise eingeschaltet zu sein.

  • Ich bin wirklich zufrieden damit, letzten Monat gitea in meinem Homelab ausgerollt zu haben.
    Es gibt auch eine Importfunktion von GitHub, und ehrlich gesagt fühlt es sich schneller an als GitHub und hat auch bessere Uptime.
    Claude funktioniert ebenfalls gut mit tea CLI und Git, und insgesamt wirkt es fast wie eine GitHub-Kopie, bisher aber eher besser.

    • Ich nutze Forgejo, und da derselbe Core-Code geteilt wird, finde ich es ebenfalls großartig.
      Es ist schnell und die Uptime ist gut.
      Es läuft sogar auf einem Pi 4 im Schrank neben meinem Schreibtisch und funktioniert deshalb auch weiter, wenn das Internet ausfällt.
      Backups schicke ich mit borg und syncthing sogar offsite.
      Das Setup braucht etwas Arbeit, aber danach ist der Wartungsaufwand fast null.
      Etwa alle zwei Wochen logge ich mich per SSH ein und prüfe nur den SSD-Platz, die RAM-Nutzung, apt update, upgrade und größere Versions-Upgrades.

  • Fragen sich die Leute nicht, ob GitHub ohnehin schon alle Anfragen sammelt und aggregiert, die auf den eigenen Servern eingehen?
    Schließlich besteht der ganze Zweck des gh-CLI darin, mit genau diesen Servern zu interagieren.
    Wenn man überhaupt kein Request-Tracking möchte, müsste man vermutlich viel mehr abbestellen als nur diese eine Einstellung.

    • Da die Daten auf dem Server vorhanden sind, nehme ich an, dass sie sie natürlich bereits anschauen.
      Diesmal scheint man aber zusätzlich Client-seitige Metriken zu erfassen, um nicht nur Flows Richtung GitHub besser zu verfolgen, sondern auch solche zu GitLab, Codeberg und anderswohin.

  • Aus GitHub-Sicht ist das vielleicht sinnvoll.
    Jedes Unternehmen braucht solche Daten, manche nutzen sie zur Produktverbesserung, andere für weniger erfreuliche Zwecke.
    Ich weiß, dass HN-Nutzer Telemetry nicht mögen, aber wenn man selbst einmal SaaS gebaut hat, merkt man, dass Telemetry praktisch unverzichtbar ist.

    • GitHub CLI ist kein SaaS, sondern ein Kommandozeilenprogramm.
    • Man sollte die Nutzer vielleicht zuerst direkt fragen.
      Mir geht es letztlich darum, dass Gespräch fehlt.
    • Ich frage mich, was die Best Practice ist, um den Telemetry-Inhalt eines Tools zu verifizieren.
      Der Kern steckt in den Details, und ich überlege, ob es vielleicht eine vertrauenswürdige Vermittlungsinstanz geben könnte, die eine für Nutzer und Produkthersteller gleichermaßen akzeptable Mitte schafft.
      Ich erwähne, dass ich mit Hilfe von Claude Recherche dazu in einem Gist zusammenstelle.
    • Ich finde, die Sprechweise von AI-Befürwortern klingt alle gleich.

  • Das erinnert mich an Microsofts Embrace, extend, extinguish.
    Die ersten beiden Schritte sind schon passiert, und ich erwarte, dass GH CLI in fünf Jahren der einzige Weg sein wird, mit GitHub-Repositories zu interagieren.
    Dann wäre auch der dritte Schritt abgeschlossen und der Zyklus beendet.

    • Auf diese Vorhersage würde ich gern wetten.
      Sie wirkt so realitätsfern, dass ich fast fragen möchte, um welchen Einsatz es geht.
    • Solche Behauptungen ermüden mich wirklich.
      Leute haben WSL, GPU-Support, WSLg und PowerShell ständig ebenfalls in den EEE-Frame gepresst, aber passiert ist das nie.
      Auch jetzt nicht, und es gibt nicht einmal wirkliche Spuren dafür, dass so etwas geplant wäre.
      Das ist nichts, das man aus dem Bauch heraus deuten sollte; ich möchte Belege dafür sehen, wo genau die wiederholbare Methode, die Microsoft in den 90ern tatsächlich genutzt hat, heute reproduziert wird.
      Es gibt weder ein Microsoft Git, das mit mehr Features als Open Source abschottet, noch etwas Vergleichbares wie ein Microsoft Linux.
      GitHub ist ein Wrapper auf Git mit dem grundlegenden Design eines Git-Servers über HTTP und SSH.
      Diese Grundlage aufzubrechen und den Repository-Zugriff nur noch über gh zu erzwingen, wäre eine viel zu große Änderung und erscheint mir unrealistisch.
      gh ist nur ein Tool, das API-Aufrufe bequemer macht, und die meisten GitHub-Nutzer wissen nicht einmal, dass es existiert.
      Wenn GitHub kaputtgeht, dann wahrscheinlich nicht durch böswilliges EEE, sondern durch inkompetentes Management.
      Wegen Führungskräften, die Nutzer und Produkt nicht verstehen, halte ich einen Niedergang für wahrscheinlicher.
    • Ich bin gegenüber dieser Vorhersage nicht völlig skeptisch.
      Manche Repositories fühlen sich schon heute ohne gh umständlich an, und ich denke, dass sich nach und nach erzwungene Abläufe einschleichen.
      Ich weiß nicht genau, welchen Mehrwert gh liefert, weil ich es nicht benutze, aber für mich reichen die Standard-Git-Befehle aus.

  • Ich bin verwirrt, ob mit pseudonymous telemetry pseudonyme Telemetry gemeint ist oder ob eigentlich nicht-anonyme Telemetry gemeint ist.
    Die beiden Formulierungen sind nahezu gegensätzlich, und so wie es jetzt dasteht, klingt es eher so, als würde identifizierbare Datenerfassung angekündigt.

    • Auf der betreffenden Seite steht nur pseudonymous, während pseudoanonymous offenbar eine Wortschöpfung des HN-Posters ist.
    • Ich verstehe das so, dass es nicht mit der Identität einer Person oder einem GitHub-Konto verknüpft ist, man aber dennoch sämtliche Telemetry von einer Maschine zusammen sehen kann.
      Offenbar bekommt jede Maschine eine UUID, anhand derer die Maschine identifiziert wird.