Microsoft ist mal wieder mit den Fingern im Honigtopf erwischt worden. Wer mit Visual Studio 2015 Programme in C++ entwickelt, liefert im Hintergrund Code mit, der zur Erfassung von Telemetriedaten dienen kann. War nur ein Versehen und wird beim nächsten Update wieder ausgebaut.
Anzeige
Eine Diskussion bei Reddit als 'Stein des Anstoßes'
Erste Hinweise auf dieses Verhalten, welches wohl in Visual Studio 2015 bei C++ auftritt, findet sich seit ca. einem Monat bei Reddit.com. Einem russischen Entwickler war aufgefallen, dass seine C++-Programme bei der Ausführung Funktionsaufrufe der Art: __telemetry_main_invoke_trigger(nullptr); in den Laufzeitcode einbinden. Bei infoq.com hat man sich des Themas angenommen und das Ganze bestätigt. Hier ein Auszug eines minimalen Programms (Quellcode links, Maschinencode rechts), welches kaum etwas tut.
(Quelle: infoq.com)
Beim Aufruf wird ein Zeitstempel oder das Module Load-Ereignis per Event Tracing for Windows (ETW) in eine Protokolldatei geschrieben. Das sind zwar nur lokale Einträge, die aber über Telemetriefunktionen leicht nach "außen" übertragen werden können. Das Pikante: Der Code wird ungefragt eingebaut und kann nur über einen Linker-Parameter notelemetry.obj stoppen.
Alles nur ein Versehen, man hat die Implikationen nicht bedacht
Nachdem das Ganze ruchbar wurde, meldete sich Steve Carroll, Entwicklungs-Manager beim Visual C++-Team, im Reddit-Tread und entschuldigte sich:
Anzeige
Der Code soll beim Update 3 für Visual Studio 2015 wieder "ausgebaut" werden. Idee hinter dem Ansatz war "ein Framework zu brauen, welches Performance Probleme analysieren helfen sollte". Dabei habe man übersehen, dass dies "nicht jedem Recht sei" und zu Spekulationen bezüglich der Verwendung führen könnte.
Interessant: Dokument, wo man Datentransfer an MS-Server stoppen kann
Im Posting von Carroll findet sich übrigens noch ein interessanter Link auf diese Microsoft-Seite, die sich mit dem Thema "Datenübertragung an Microsofts Server" unter Windows 10 befasst und aufzeigt, wie man diese Kommunikation über Registrierungseinträge stoppen können soll.
Meine 2 Cents
Wollen wir den Ausführungen von Carroll mal Glauben schenken, dass das alles unabsichtlich passierte. Aber ich kann mir nicht helfen: Vertrauen schafft dieses Verhalten Microsofts hier bei mir nicht. Woher weiß ich denn, ob nicht der nächste Simpel bei Microsoft in seinem "Cubicle" mal wieder einen Knopf drückt, um ein Stückchen Code in diesem Windows 10 zu compilieren, die solche Einstellungen umgeht (natürlich unbewusst).
Wäre ja nicht das erste Mal, dass da etwas bezüglich der Datenschutzeinstellungen bei einem Windows 10-Update gründlich was schief ging. Wenn ich so die Kommentare bei heise.de zum Thema durchgehe, geht die Post ab. Dieser Kommentator bringt das Ganze auf den Punkt: Die Funktion kam per Update rein, soll wieder per Update ausgebaut werden und kommt irgendwann vielleicht wieder über die Hintertür rein. Und hier weist jemand darauf hin, dass die Eula von VS 2015 künftig das Decompilieren des C++-Codes verbiete – ist zwar Ironie, aber wer weiss, ob das nicht bald Realität wird.
Eine Entschuldigung für so etwas kommt zwischenzeitlich Microsofts Leuten leicht über die Lippen (ist ja nicht das erste Mal). Ein Konzept für ein explizites Opt-In zur Telemetrie- und andere Datenerfassung habe ich bei Microsoft jedenfalls noch nicht gesehen. Und noch was: Das Telemetriezeugs wird in Windows 7/Windows 8.1 ja ständig per Update nachgerüstet. Ist zwar ewig her, dass ich programmiert habe, aber jeder Funktionsaufruf, der irgend ein Event-Log schreibt, kostet Ressourcen. Wenn ich mir so ansehe, was da zwischenzeitlich an Events ungefragt und ungewollt geloggt wird, ist es kein Wunder, dass die Rechner langsam werden. Irgendwie ist das alles ziemlich kaputt.
Nachtrag: In den heise.de-Kommentaren gibt es zwar den Beitrag "Schwacher Artikel", der sich nach Boah anhört. Geht aber am Kern vorbei. Es mag ja sein, dass es bessere Möglichkeiten zum Tracken gibt. Aber: a) ist es eine Sauerei, wenn solche Aufrufe ungefragt in den Code eingebunden werden und b) was soll denn diese für Endanwender nutzlose Trackerei im Event-Log? Jeder Aufruf schreibt mir irgend etwas in die Protokolldateien – mehr als "flüssig" – nämlich überflüssig. Und im Kontext: MS weiß selbst nicht, was die linke/rechte Hand tut, ändert sich nichts an der Kernbotschaft. Oder wie seht ihr das? (via)
Anzeige
Es ist zumindest wesentlich professioneller (und ungefährlicher), wenn man solche Erweiterungen auch zu Testzwecken als Opt-In einbaut, zum Beispiel über eine Compilerdirektive.
Das vermeidet die böse Falle, dass man vergisst, beim Release nicht gewollten Code wieder auszubauen oder zu deaktivieren. Da sind in letzter Zeit auch anderen Entwicklern schon größere Pannen passsiert, wenn zum Beispiel bei jedem Connect zu einer Datenbank das Passwort unverschlüsselt auf der Console angezeigt wurde.
Und das Wort Telemetrie entwickelt sich in letzter Zeit ohnehin immer mehr zum Unwort des Jahres im IT-Bereich.
einmal kann ja Zufall / Pech sein.
aber so langsam hat das Ganze System und niemand glaubt mehr an Zufall und
MSFT testet die Grenzen wie weit sie gehen können.
Mit WMI (Windows Management Instrumentation) zur Überwachung der Leistung von Diensten in Windows 2000 fing es an. Darauf setzte dann ab Vista SQM (Software Quality Metrics) auf und in Windows 10 und nachgerüstet in 7 und 8.1 ist dann ein eigener Dienst dazugekommen und weitere Bestandteile. Überwachen lässt sich damit nun prinzipiell alles, egal ob es das Anwenderverhalten oder die eingesetzte Software ist.
Meiner Meinung nach riecht das Ganze mittlerweile nach einer Riesen-Sicherheitslücke.
Ich frage mich zwischenzeitlich echt, was mich reitet, noch solche Artikel zu posten. Scheinbar ist das Ausspionieren von Anwendern in Amiland Gang und gäbe. Neuester Schwank: Community verhindert Spyware in Eclipse (bei heise.de). Ich fasse es nicht.