Wenn du auf dieser Ebene angekommen bist, musst du fast alles an deinem Bedrohungsmodell und an dem, was du zu deinem Schutz tust, neu bewerten. Schon die kleinsten Dinge können einen Sturm an Problemen auslösen, wenn du es mit den falschen Leuten zu tun hast. Gerade eben im vorigen Abschnitt haben wir besprochen, wie quelloffene Software eine wirklich, wirklich gute Sache ist. Und jetzt müssen wir über einige Probleme damit sprechen und darüber, was du tun kannst, um diesen Problemen zu begegnen und sicher zu bleiben.
FOSS ist großartig, weil es uns erlaubt, den Code in seiner Gesamtheit zu betrachten und zu überprüfen, dass das, was wir sehen, auch das tut, was man uns glauben machen will. Aber damit diese Aussage zutrifft, müssen wir alles über den veröffentlichten Code verstehen. Ich zum Beispiel verstehe nicht, wie man irgendetwas außer einer einfachen Website in HTML programmiert, also muss ich mich auf das Wort anderer verlassen. Dieses Wort ist jedoch nur so gut wie die Leute, die es prüfen. Sagen wir also, wir planen, ServiceX (nur als Beispiel) zu nutzen, um sicher mit jemand anderem zu kommunizieren, aber ServiceX veröffentlicht Updates in recht zeitnahen (monatlichen) Abständen. Solange wir nicht wissen, wie man den Code selbst liest, versteht und validiert, brauchen wir eine andere vertrauenswürdige Person, die das kann. Außerdem muss diese Person das bei jedem veröffentlichten Update tun. Dann stellt sich die Frage, ob eine kompetente Person, die den Code prüft, ausreicht. Wenn diese Person etwas übersieht, das uns kompromittieren könnte, würden wir ServiceX bis zu dem Zeitpunkt nutzen, an dem jemand anderes diesen Fehler bemerkt. Auch wenn dieser Zeitraum nur ein paar Tage betragen mag, sind das Tage, an denen alles, was wir im Zusammenhang mit diesem Dienst tun, kompromittiert ist, was im Umkehrschluss uns und unser gesamtes Modell aus Sicherheit, Datenschutz UND Anonymität kompromittiert, das wir uns so mühsam aufgebaut haben.
Ein weiteres Problem mit Free, Open Source Software sind mobile Plattformen. Auf den meisten Betriebssystemen für Desktop-Computer können wir den Quellcode von GitHub (oder einer anderen Website zur Code-Veröffentlichung) nehmen und selbst bauen bzw. kompilieren, sofern er für unser Betriebssystem geschrieben wurde. Aber auf mobilen Betriebssystemen können wir das nicht so einfach. Und selbst in den Fällen, in denen wir es können, stehen wir immer noch vor einer riesigen Herausforderung, für die es noch keine magische Lösung gibt. Um eine Anwendung auf mein iPhone herunterzuladen, muss sie von dem Unternehmen, das die besagte Anwendung entwickelt hat, im App Store veröffentlicht werden. Ich kann nicht auf die Website von Open Whisper Systems gehen und Signal direkt auf mein Telefon herunterladen. Selbst wenn wir also den Quellcode des Dienstes bzw. der Anwendung prüfen (oder jemand anderen das für uns tun lassen), können wir trotzdem nicht validieren, dass dieselbe Anwendung an den App Store geschickt wird, damit wir sie herunterladen. Wäre das Unternehmen von einer Strafverfolgungsbehörde kompromittiert und zur Mitarbeit gezwungen worden, könnten sie ein sauberes Update auf GitHub veröffentlichen, mit leichten UI-Änderungen, um Verdacht zu vermeiden, dann aber eine mit einer Hintertür versehene Version derselben Anwendung an den App Store schicken, die Tausende Nutzer herunterladen. Das gilt in gewissem Sinne auch für Android-Geräte und den Google Play Store. Der einzige Weg, das beim Google Play Store zu umgehen, besteht darin, reproduzierbare Builds einzureichen, die die Öffentlichkeit einsehen und nutzen kann. Open Whisper Systems hat das gerade für Signal umgesetzt, und es wäre wirklich schön, wenn andere Dienste dasselbe täten (Hint Hint: ProtonMail, Tutanota, ChatSecure) https://github.com/signalapp/Signal-Android/tree/master/reproducible-builds. Da wir also nicht ohne Weiteres überprüfen können, dass die Anwendung, die wir auf unseren Telefonen nutzen, nichts Bösartiges tut, sollte es eine faire Annahme sein, dass es der beste Weg ist, mobile Geräte aufzugeben und ausschließlich Desktop-Versionen von Programmen zu nutzen, also solche, die wir aus dem Quellcode kompilieren und selbst überwachen können.
Code-Audits für Datenschutz-Tools
Selbst nachdem du all das oben Gesagte über Open Source Software gelesen hast, bleibt immer noch ein riesiges Problem, das überwunden werden muss, bevor wir sicher sein können, dass die Software, die wir nutzen, sicher ist. Es ist nicht fair anzunehmen, dass 100 % der Leute, die diesen Abschnitt lesen, in der Lage sein werden, den Code einer Anwendung selbst zu prüfen. Verdammt, es ist nicht einmal fair anzunehmen, dass 5 % der Leute, die das lesen, eine so gewaltige Aufgabe bewältigen könnten. Nimm zum Beispiel TrueCrypt. Die Code-Audits, die durchgeführt wurden, um sicherzustellen, dass es sicher war, dauerten Monate, von Leuten, die mir auf dem Gebiet der Verschlüsselung Lichtjahre voraus sind; einige davon mit Masterabschlüssen in dem Bereich und jahrelanger Erfahrung auf dem Buckel (cough, cough @matthew_d_green). Anzunehmen, dass eine einzelne Person so etwas tun kann, um sich selbst sicher zu halten, ist also albern. Code-Audits an den Anwendungen und Diensten, denen wir auf dieser Ebene unsere Sicherheit anvertrauen, sind entscheidend. Und sobald dieses Code-Audit abgeschlossen ist, musst du bedenken, dass das Audit für weitere Versionen der Anwendung nicht gültig sein wird. In dem Moment, in dem sie ein Update verschicken und du es installierst, bist du wieder bei null, es sei denn, jemand sieht sich die Änderungen an und verifiziert sie bei jedem Update.
Siehe: Die Bedeutung freier und quelloffener Software für Datenschutz-Tools