Und was Emerald angeht. Klar man kann sagen, die Möglichkeit den Schadscode einzubringen animiert zum Misbrauch. Mit gleichen Argumenten begegnet man die Internetsperren: Ist die Technik mal da, kann man sie schnell misbrauchen und nicht nur die Kinderpornographie im Internet sperren, sondern auch mit die politische Gegner.
Der kleine, aber feine Unterschied: Hier wurde bereits mehrmals nachweislich Schadcode eingebaut! Zwei mal wurde zugesagt, den Code zu entfernen, beim ersten mal war er weiter drin, nur die Lib wurde verschlüsselt. Das flog auf, weil jemand den Schlüssel geknackt hat und siehe da: das Zeug war immer noch drin. Beim zweiten mal wurde wiederum der Codeschlüssel erheblich verschärft, ob der Code weiterhin drin ist, ist für niemanden nachvollziehbar.
Notabene, wir reden ja nicht von Programmierfehlern und Sicherheitslücken, sondern von bewusst implementiertem Schadcode.
Das macht einen ganz erheblichen Unterschied. Sicher, auch in Windows kann theoretisch jemand Code einschleusen - allerdings dürfte der Codeaudit bei Microsoft etwas anders aussehen als bei ModSys. Dort wird der Code an einem Punkt geprüft, an dem die ursprünglichen Programmierer keinen Zugriff mehr haben.
Das ist bei ModSys nach Lage der Dinge und der Struktur nicht machbar. Die Leute, die den Code sehen, werden nicht in die Prüfung der Libs eingebunden, die sie als reine Binary bekommen. Dort spielen dann, so man LGG glauben schenkt, auch finanzielle Interessen einzelner eine Rolle - und da werde ich misstrauisch.
Ännlich denkt die GEZ, es reicht dass man ein empfangsfähigen Gerät im Hause hat, dass man es tatsächlich benutzt wird einem pauschal unterstellt. Und diese Argumentation trifft wiederum nicht immer auf Begeisterung.
Ein Vergleich von Äpfeln mit Autos stößt auch nicht überall auf Begeisterung.
Ich glaube es gibt einen Grundsatz, der ganz einfach lautet "Im Zweifel für den Angeklagten". Es ist nicht bewiesen worden dass Emerald sich böswillig verhält, außer dass da an wenig aussagekräftigen Information in die versendeten Bildern was eingepackt wird. Unehrenhaft hat sich das MS Team schon verhalten, mehrfach, aber bis jetzt ist das auch alles. Dem MS vorzeitig Böswilligkeit untestellen, halte ich an der Stelle aber für übertrieben.
Es war zweimal Code drin, der da nicht hingehört. Punkt. Beim erstenmal wurde gesagt: Ist entfernt, die Bibliothek wurde verschlüsselt. Der Schlüssel wurde geknackt. der Code war immer noch drin. Wiederum wurde zugesagt, das zu entfernen, diesmal wurde die Verschlüsselung sehr hoch gesetzt - ob der Code immer noch da ist, weis zur Zeit niemand außer dem Programmierer selbst.
Hier von "nicht nachgewiesen" zu reden, ist schon gewagt. Es hat drin gestanden und es hat deswegen Beschwerden gegeben. Es ist versucht worden, es trotzdem wieder einzubauen und durch Verschlüsselung unkenntlich zu machen. Es wurde wieder beanstandet, und es wurde hochverschlüsselt - ob Code noch enthalten ist, weis keiner.
Was muss eigentlich passieren, damit das als "nachgewiesen" gilt und man misstrauisch wird?
Noch ein Gedanke. Die DLL ist eigentlich eine Bibliothek von Funktionen. Also eine Menge von Funktionen, die vom Viewer aufgerufen werden um irgendeine Aufgabe zu erledigen. Man kann im Primzip schon in eine Funktion Schadscode hinzufügen, der zusätzlich ausgeführt wird, wenn die Funktion aufgerufen wird.
Aber dieser Code muss mit Informationen auskommen die der Viewer an die Funktion liefert, entweder direkt im Funktionsaufruf oder von einer anderen DLL. Und ich stelle mir vor, dass dann auch der Quellcode des Viewers selbst geändert werden müsste, der offen liegt, oder die gelieferten DLLs. Sprich, die Entwickler müssten eine unklare Quellcode-Anderung dann als Indiz erkennen können, wenn ein Schadscode installiert werden soll. Ich kann mich da aber irren.
Bibliotheksfunktionen sind im Grunde nichts anderes als Unterprogramme, die in eine externe Datei ausgelagert wurden. Da können - notabene: Können! - ausschließlich solche Subroutines drin sein, die nur auf externen Aufruf, ggf. mit Parametern, reagieren. Von "Das muss so sein" kann jedoch keine Rede sein.
Nur ein ausgesprochen primitives Beispiel:
In der Bibliothek ist irgendeine Subroutine, die regelmäßig vom Programm aufgerufen wird, z.B. der Aufbau des Fensters. Der Aufruf kommt vom Programm mit irgendwelchen Daten. Die Subroutine/Funktion ist jedoch einkompiliert und daher nicht mehr ohne weiteres nachvollziehbar. Sie kann ohne Probleme Code enthalten, der z.B. Daten des Fensters
zusätzlichirgendwohin übermittelt. Pech, wenn es das Login-Fenster ist. Es könnten auch Funktionen der Bibliothek ggf. weitere Funktionen innerhalb der Bibliothek aufrufen, die ihrereseits unerwünschten Code enthalten.
Schon etwas weniger primitiv:
Beim ersten Aufruf irgend einer beliebigen Funktion wird der Aufruf einer anderen Funktion z.B in den PC-Timer eingeklinkt. Die Funktion wird dann - ohne jede Aufforderung durch das Hauptprogramm - immer wieder automatisch ausgeführt. Daten kann so eine Funktion auch selbstständig sammeln, sie ist dazu nicht an das Hauptprogramm geknebelt.
Das wäre, da sich alles innerhalb der verschlüsselten Bibliothek abspielt, nicht nachvollziehbar. Nach außen hin führt die Lib dann ganz brav aus, was sie soll, ohne jede Änderung im Hauptprogramm. Das sie intern so ganz zufällig noch etwas mehr macht, sieht man nicht.
Das ist die böse Kombination, die hier gespielt wird: Wenige oder nur einer baut eine verschlüsselte Lib, die niemand kontrollieren kann - der Rest muss sie nutzen, ohne genau zu wissen, was neben den "Für SL optimierten" Funktionen noch verändert oder eingebaut wurde.
Dafür haben große Softwarefirmen einen Codeaudit - eben damit nicht einzelne etwas "drehen" können. das hat Emerald nicht. Da gibts nur einen, der den Code baut - und der hat bereits zweimal nachweislich etwas eingebaut, was da nichts verloren hat.
Wer in der Situation da weiter vertraut, möge das tun. Ich nicht.