© Zentilia / 123RF.com

Manch eine Software zwitschert ihren Erfindern, wie und wo sie zum Einsatz kommt. Das hilft zwar den Entwicklern bei ihrer Arbeit, greift aber in die Privatsphäre der Anwender ein. Mit einigen Kompromissen stimmt dem aber sogar die kritische Open-Source-Community zu.

Am 8. Februar 2023 veröffentlichte der Go-Maintainer Russ Cox in einem Blog-Beitrag ein kontroverses Vorhaben: Der offizielle Compiler für die Programmiersprache Go soll beim Aufruf Nutzerdaten sammeln und an die Entwickler senden. Die arbeiten wie Cox selbst überwiegend beim Suchmaschinengiganten Google, der derzeit die Weiterentwicklung von Go maßgeblich kontrolliert. Dementsprechend würde der Compiler also unablässig sensible Informationen einer bösen Riesendatenkrake zuschieben. Solche Projekte kommen in der Open-Source-Gemeinde grundsätzlich nicht besonders gut an.

Das musste bereits 2021 die Muse Group schmerzlich erfahren. Das Unternehmen hatte damals die Federführung über den Audioeditor Audacity übernommen. Als eine der ersten Maßnahmen wollte man die Software einige Nutzerdaten sammeln und an das Unternehmen zurückschicken lassen. Um die Auswertung sollten sich dann ausgerechnet die nicht gerade als datenschutzfreundlich bekannten Dienste Google Analytics und Yandex Metrica kümmern. Daraufhin entspann sich eine kontroverse Diskussion auf Github, die sogar vorübergehend zu mehreren Audacity-Forks führte [1].

Der Versand von Nutzerdaten ist weder eine neue Erfindung noch auf kommerzielle Software beschränkt. Viele Open-Source-Anwendungen wie Firefox und das Content-Management-System Joomla sammeln bereits seit Jahren fleißig Daten (Abbildung 1). Anders als bei der Muse Group folgte auch auf den Blog-Post von Cox kein großer Aufschrei. Diese erstaunliche Akzeptanz hat mehrere Gründe. Während die Muse Group ihre Anwender mit einem recht weitgehenden Vorhaben überraschte, erläuterte Cox zunächst in seinem Blogpost, warum die Go-Entwickler überhaupt Nutzerdaten benötigen [2].

Abbildung 1: Firefox sammelt fleißig Nutzungsdaten, die der Browser an die Entwickler schickt. Abschalten funktioniert nur explizit in den Einstellungen.

Hilfreiche Nutzerdaten

Die meiste Zeit tappen Entwickler im Dunkeln. Sie wissen nicht, welche Funktionen besonders gut ankommen, welche Features fehlen, wo die Bedienung hakt und wie häufig ihre Software abstürzt. Sie erfahren ebenso wenig, welche Distributionen und Hardwarekomponenten ihre Nutzer bevorzugt einsetzen. Verwenden die Anwender etwa oft Nvidia-Grafikkarten mit dem proprietären Treiber unter Ubuntu, dann sollten die Entwickler ihre Software möglichst gut auf solchen Systemen testen. Im Fall des Go-Compilers stand das Team unter anderem vor der Frage, ob sie die ARMv5-Architektur zukünftig ignorieren dürfen.

Gerade für kleine Open-Source-Teams mit eingeschränkten Kapazitäten erweisen sich solche Informationen als überaus wertvoll. Die durch den Wegfall einer Funktion frei gewordene Arbeitszeit kann das Team dann in andere Teile der Software investieren. Gleichzeitig gestaltet es sich für Open-Source-Entwickler allerdings sehr schwierig, an entsprechende Nutzerdaten zu gelangen. Anders als bei kommerzieller Software gibt es keine Vertragskunden, die man direkt interviewen könnte. Eine Möglichkeit bieten immerhin regelmäßige Umfragen. Häufig nehmen daran jedoch nur wenige Nutzer teil, was wiederum nur mäßig repräsentative Ergebnisse nach sich zieht.

Sackgasse Bug Report

Eine weitere wichtige Informationsquelle für Open-Source-Projekte liegt in Bug Reports. An ihnen können die Entwickler zumindest ablesen, welche Teile einer Software (wiederholt) Probleme bereiten. Allerdings reicht in der Praxis nur eine verschwindend geringe Zahl an Nutzern tatsächlich Fehlermeldungen ein. Spätestens, wenn der Bugtracker eine Registrierung erfordert, scheut der Großteil den Aufwand. Größere Projekte sind deswegen dazu übergangen, ihre Software halbautomatisch Fehlerberichte verschicken zu lassen. In den KDE Frameworks gibt es dazu beispielsweise die Komponente KCrash. Trotzdem lässt sich anhand solcher Bug Reports kaum herausfinden, wie häufig welcher Teil einer Software regelmäßig abstürzt.

Manches Problem bleibt tatsächlich unerkannt, weil es niemand als solches wahrnimmt. Beispielsweise musste das Go-Team Anfang 2020 das Paket für die MacOS-Version an die Signierungswerkzeuge von Apple anpassen. Durch die Änderungen verlangte der Go-Compiler unter bestimmten Bedingungen die Installation der kompletten Entwicklungsumgebung Xcode. Die Nutzer nahmen das als generelle Voraussetzung an und verzichteten dementsprechend auf Fehlermeldungen. Erst rund zwei Jahre später stolperte das Go-Team zufällig über diesen Bug. Ähnliches gilt für Vorschläge zu neuen Features: Obwohl Github und Konsorten das Einreichen von Verbesserungswünschen ermöglichen, finden sich bemerkenswert viele Anwender mit Unzulänglichkeiten ab. Wann haben Sie zuletzt eine fehlende oder umständlich zu bedienende Funktion an das entsprechende Entwicklerteam gemeldet?

Mit dem Aufkommen kostengünstiger Internet-Zugänge verbreitete sich daher unter Entwicklern rasch die Idee, die eigene Software nach Hause telefonieren zu lassen. Die Anwendung ermittelt bei ihrem Start kurzerhand den Namen des Betriebssystems, dessen Versionsnummer sowie andere interessante Eckdaten und schickt sie an die Entwickler. Solche Informationen über den Zustand einer Software bezeichnet man als Telemetriedaten.

Sammelleidenschaft

Theoretisch könnte ein Programm jede Aktion des Nutzers aufzeichnen und an seinen Hersteller senden. So weit treiben es die meisten Entwickler zwar nicht, die übertragenen Telemetriedaten greifen jedoch teilweise in die Privatsphäre ein.

Die Muse Group interessierte sich zum Beispiel für den Startzeitpunkt ihrer Software, die eingesetzten Audioeffekte und das Betriebssystem. Die von Microsoft bereitgestellten Binärdateien der quelloffenen Entwicklungsumgebung Visual Studio Code geben sich damit nicht zufrieden: Unter anderem funken sie nach Redmond, welche Funktionen die Anwender aufrufen und wie lange sie laufen. Der Web Components Compiler Stencil verrät seinem Hersteller zudem den kompletten Programmaufruf, einschließlich aller dabei genutzten Parameter, wie Abbildung 2 zeigt [3].

Abbildung 2: Die Stencil-Entwickler legen immerhin detailliert offen, welche Daten sie erheben. Wie bei den meisten Programmen findet sich darunter auch das Betriebssystem.

Beim Go-Compiler, bei Visual Studio Code und bei Stencil kommt hinzu, dass diese Werkzeuge beim Bau neuer Software helfen. Mit detaillierten Telemetriedaten bekämen ihre Entwickler theoretisch einen Einblick in den Entstehungsprozess von Programmen und somit eventuell sogar in Unternehmensgeheimnisse. Verständlich, dass Anwender gerade bei solchen Werkzeugen dem Datensammeln skeptisch gegenüberstehen.

Und es gibt noch ein Problem: Je mehr Informationen eine Software zusammenrafft, desto mehr Performance kostet die Aufzeichnung. Regelmäßig verschickte dicke Datenpakete stören obendrein Anwender, die nur über eine begrenzte oder schmalbrüstige Internet-Verbindung verfügen.

Minimalismus gewinnt

Um die Akzeptanz unter den Nutzern zu erhöhen, setzt Cox deshalb konsequent auf ein von ihm Transparent Telemetry genanntes Konzept: Anwendungen sollten so wenige Daten wie möglich aggregieren und gleichzeitig stets offenlegen, welche Informationen sie im Einzelnen übertragen.

Für die Go-Werkzeuge schlägt Cox vor, dass sie in einer Log-Datei rund eine Woche lang einige besonders interessante Dinge aufzeichnen. Der Compiler könnte beispielsweise die Aufrufe einer bestimmten Funktion mitzählen. Dabei gilt es, diese Zähler so zu wählen, dass sie keinerlei Rückschlüsse auf den Nutzer zulassen. Welche Werte die Go-Werkzeuge konkret sammeln, soll die Community im Rahmen einer öffentlichen Diskussion bestimmen.

Die von Cox vorgeschlagene Transparent Telemetry ist allerdings nicht neu. Unter anderem Stencil und Joomla gehen diesen Weg seit mehreren Jahren erfolgreich (Abbildung 3). Im Fall des CMS sehen Seitenbetreiber detailliert, welche Informationen zu den Joomla-Entwicklern wandern. Den Datenversand übernimmt bei Joomla zudem ein Plugin, dessen Quellcode jeder Interessierte einsehen kann. Bei Bedarf lässt es sich rückstandsfrei aus der Installation entfernen. Unter anderem wegen dieser Offenheit akzeptierte die Joomla-Community die Telemetrie äußerst schnell.

Abbildung 3: Joomla sammelt im Gegensatz zu vielen anderen Programmen erstaunlich wenige Informationen. Die Entwickler interessieren sich lediglich für die Versionen von Datenbank und Laufzeitumgebung.

Weiterverarbeitung

Die Nutzerdaten muss ein Programm nicht nur sammeln, sondern selbstverständlich auch irgendwo hinschicken. Im Fall von Audacity wollte die Muse Group die Telemetriedaten von Google Analytics und Yandex Metrica auswerten lassen. Wie die darauf folgenden Reaktionen der Anwender zeigten, schaffen solche Dienste alles andere als Vertrauen. In den meisten Fällen landen die Telemetriedaten jedoch auf den Servern der Entwickler.

Abbildung 4: Da einigen Anwendern von Visual Studio Code die weitreichenden Befugnisse von Microsoft ein Dorn im Auge waren …

Abbildung 5: … veröffentlichten sie einfach eine Fassung mit entferntem Telemetrieversand.

Auch die Go-Werkzeuge sollen nach Cox’ Willen einmal wöchentlich einen Bericht an einen eigenen Server senden – der allerdings bei Google steht. In späteren Diskussionen mit der Community kam dieses Detail erstaunlicherweise kaum auf. Vielleicht lag das auch daran, dass der Datenversand lediglich mit einer Wahrscheinlichkeit von 10 Prozent erfolgen soll. Die Go-Werkzeuge kontaktieren den Server folglich im Schnitt nur rund fünf Mal pro Jahr. Darüber hinaus soll der Server die aus der Statistik bekannte Methode des Samplings (Datenstichprobe) einsetzen. Damit klopft jede Go-Compiler-Installation umso seltener beim Server an, je mehr Systeme an der Telemetrie teilnehmen.

Der Server bereitet die erhobenen Daten auf und veröffentlicht sie in Form von Statistiken auf der Go-Projektseite. Wie so etwas aussehen kann, zeigen die Joomla-Entwickler (Abbildung 6). Die von ihnen aus den Telemetriedaten erzeugten Statistiken präsentiert eine eigene, etwas versteckte Webseite [4]. Dank der Veröffentlichung kommen die Telemetriedaten unter anderem auch den Entwicklern von Erweiterungen zugute.

Abbildung 6: Wie die Auswertung der Telemetriedaten bei Joomla zeigt, nutzen erstaunlich viele Anwender noch eine extrem veraltete PHP-Version.

Erkennungsdienst

Selbst wenn man ausschließlich komplett anonyme Informationen überträgt, sieht der Server zwangsweise die IP-Adresse der Nutzer. Über die hätten im Fall von Audacity auch Google Analytics und Yandex Metrica die Anwender verfolgen beziehungsweise tracken können.

Die Joomla-Entwickler ignorieren zwar nach eigenen Angaben die IP-Adressen, ihr CMS würfelt aber nach der Installation eine eindeutige Identifikationsnummer aus. Die fließt grundsätzlich zusammen mit den übrigen Telemetriedaten zu den Joomla-Entwicklern. Folglich ließe sich jede Joomla-Installation über die Identifikationsnummer erkennen und verfolgen. So könnte der Server beispielsweise nachvollziehen, welche Installation wann die PHP-Version gewechselt hat. In den Einstellungen des zuständigen Telemetrie-Plugins lässt sich immerhin die Identifikationsnummer jederzeit neu generieren (Abbildung 7). Seitenbetreiber müssen das jedoch wissen und aktiv anstoßen.

Abbildung 7: In Joomla kümmert sich eine Erweiterung um den Datenversand, die sich bei Bedarf komplett entfernen lässt.

Des Problems der IP-Adressen ist sich Cox ebenfalls bewusst. Im Fall von Go soll der Server die IP-Adressen nicht zusammen mit den Berichten speichern. Zum Schutz vor DoS-Angriffen sollen sie getrennt in den allgemeinen Server-Logs landen. Für die Go-Werkzeuge würde darüber hinaus die entsprechende Datenschutzerklärung greifen, die schon für die Dienste Proxy.golang.org, Sum.golang.org und Index.golang.org gilt [5].

Dass das alles tatsächlich so läuft, müssen Go-Programmier Cox und Google schlicht glauben. Das gilt generell für alle Datensammler: Auch wer Firefox oder Joomla einsetzt, muss den Entwicklern beziehungsweise den dahinterstehenden Organisationen vertrauen.

Opt-in oder Opt-out?

Für die Entwickler gibt es noch ein Problem: Die meisten Nutzer schalten die Telemetriedaten schlichtweg nicht ein, selbst dann, wenn sie das Programm beim Start darum bittet. Im Ergebnis erreichen nur so wenige Telemetriedaten den Server, dass die Ergebnisse nicht mehr als repräsentativ gelten. Aus diesem Grund aktivieren Visual Studio Code und Firefox die Sammelei standardmäßig. Als Anwender muss man sie explizit in den Einstellungen abschalten (Opt-out).

Diesen Weg wollte Cox bei den Go-Werkzeugen ebenfalls gehen. Die von ihm dazu eigens auf Github angestoßene Diskussion konzentrierte sich schnell vor allem auf das geplante Opt-out [6]. Zum einen fühlen sich zahlreiche Nutzer generell beim automatischen Versand von Telemetriedaten unwohl. Zum anderen könnte das stillschweigende Einverständnis in einigen Ländern gegen Datenschutzverordnungen verstoßen.

Schließlich lieferte Cox selbst ein weiteres Argument gegen Opt-out: Viele Menschen unterscheiden offensichtlich nicht zwischen den verschiedenen Telemetriesystemen und wissen nicht, welche Daten genau sie übertragen. Wenn schon der sehr populäre Go-Compiler standardmäßig Informationen an die Entwickler überträgt, dann geht für den Großteil der Anwender ein deutlich datenhungrigerer Telemetrieversand in anderen Systemen genauso in Ordnung.

Aus diesem Grund votierten viele Community-Mitglieder vehement für ein Opt-in, bei dem die Nutzer explizit den Telemetrieversand erlauben müssen. Am Ende schloss sich Cox dem Wunsch der Community an [7]. Für die Entwickler bedeutet das Opt-in-Verfahren jedoch, dass sie für das Anknipsen der Telemetriedaten aktiv werben müssen.

Freie Wahlen

Darüber hinaus stellt sich die Frage, wie und wo man innerhalb der Software den Versand regelt. Versteckt man den passenden Schalter in den Tiefen der Einstellungen, übersehen ihn viele Anwender. Platziert man ihn prominent in der Benutzeroberfläche, stört er vermutlich.

Was den Go-Compiler angeht, ließe sich das Opt-in über einen Parameter oder eine Umgebungsvariable steuern. Das Go-Team hat hier offenbar bereits die Variable »GOTELEMETRY« im Auge. In jedem Fall müssen die Entwickler mit deutlich weniger Informationen auskommen. Außerdem beeinflusst diese Methode das geplante Sampling-Verfahren, sodass die Privatsphäre der Teilnehmer etwas schlechter geschützt ist.

Zwischen Opt-in und Opt-out existiert noch ein Mittelweg, den unter anderem Joomla (Abbildung 8) und teilweise Firefox (Abbildung 9) einschlagen. Diese Anwendungen bitten bei ihrem ersten Start um Erlaubnis, einige Telemetriedaten erheben und senden zu dürfen. Die Entscheidung lässt sich in den Einstellungen jederzeit nachträglich korrigieren. Durch die Wahlfreiheit erklären sich deutlich mehr Nutzer bereit, die Telemetriedaten zu erlauben.

Abbildung 8: Joomla nutzt das Opt-in-Verfahren: Solange der Seitenbetreiber den Versand nicht akzeptiert, sendet das CMS keine Telemetriedaten.

Abbildung 9: Firefox nutzt das Opt-out-Verfahren, weist aber seine Nutzer beim ersten Start darauf hin und bietet aktiv einen Sprung zu den passenden Einstellungen an.

Deswegen schlägt Cox ebenso vor, auch den grafischen Installationsassistenten von Go die entsprechende Bitte anbringen zu lassen. Allerdings kann man nicht immer den Nutzer direkt fragen. Beispielweise kommt der Go-Compiler in CI/CD- sowie anderen Build-Systemen zum Einsatz. Das Deployment erfolgt dort automatisch, was Rückfragen per se ausschließt.

Nicht fälschungssicher

Das Aufzeichnen und Verschicken der Telemetriedaten erfordert zusätzlichen Code, der je nach Sammelwut die Anwendungskomplexität erhöht. Das gilt insbesondere, wenn externe Bibliotheken oder Dienste hinzukommen. Für Go gibt es beispielsweise die Telemetry-Bibliothek [8], bei komplexen verteilten Systemen bietet sich der Einsatz von OpenTelemetry an [9].

Besonders wenn die Software unter einer Open-Source-Lizenz steht und somit der Quellcode offen liegt, lassen sich die Telemetriedaten prinzipiell fälschen oder manipulieren. Spammer könnten zudem den Empfangsserver mit Nonsens-Daten fluten. Die Entwickler müssen dementsprechend für eine fälschungssichere Erhebung und Übertragung der Daten sorgen, um den Statistiken tatsächlich vertrauen zu können.

Die Audacity-Entwickler rückten angesichts der scharfen Kritik übrigens komplett von ihrem Vorhaben ab. Der Audioeditor erhebt nach wie vor keinerlei Telemetriedaten. Die Nutzer müssen ihm sogar explizit erlauben, regelmäßig nach Aktualisierungen zu suchen. Wer die Entwickler unterstützen möchte, kann dazu einen Bericht erzeugen und dessen Inhalte vor dem Absenden kontrollieren. Dieser Weg von Audacity ist eine Empfehlung wert – schließlich bedeutet der Verzicht auf Telemetriedaten mittlerweile eine nicht zu unterschätzende Werbung.

Cox und das Go-Team halten an ihrer Strategie fest, die Werkzeuge der Go-Toolchain Telemetriedaten versenden zu lassen. Zu Redaktionsschluss war ihr System allerdings noch nicht in den Go-Compiler eingeflossen. Cox spielte Ende Februar 2023 noch mit dem Gedanken, das Telemetriesystem zunächst am LSP-Server von VS Code Go auszuprobieren.

Fazit

Telemetriedaten liefern Entwicklern wertvolle Informationen. Damit Anwender den Eingriff in ihre Privatsphäre akzeptieren, sollten die Entwickler alle erhobenen Daten offenlegen und das Sammeln optional gestalten. Unter keinen Umständen sollten sie eine entsprechende Funktion klammheimlich einbauen. Die wichtigsten Kriterien im Umgang mit Telemetriedaten fasst noch einmal der Kasten “Vermittlungskunst” zusammen. (csi)