Im wesentlichen sind es zwei Projekte: in das eine habe ich schon viel Programmierzeit hinein investiert, das andere existiert im wesentlichen (wenn auch mindestens genauso lange) in meinem Kopf.
In diesem Thread will ich das erste Projekt, welches ich auf den Namen 101_browser getauft habe, erläutern. Gehostet ist es auf Github: github.com/nubok/101_browser
Um in wenigen Worten zu beschreiben, was es ist: ein Versuch meinen eigenen Webbrowser zu implementieren.
Nun aber die lange Geschichte:
Bei mir entstand eine zunehmende Frustration darüber, dass die existierenden Webbrowser immer mehr das WWW in Richtung Konsummedium propagieren. Dies lässt sich sehr gut an der Kette
Mozilla Suite -> Mozilla Firefox -> Google Chrome
von Browsern ablesen. Jede "Generation" lässt dem Anwender weniger Freiheiten bzw. versteckt die Konfigurationsoptionen immer mehr. Der Nutzer soll nicht basteln, sondern konsumieren.
Warum nicht stattdessen einen Browser schaffen, welcher dem Nutzer derart mächtige Freiheiten gibt, dass er für die Serverbetreiber gefährlich werden könnte? Nur um zu demonstrieren, dass ich vielleicht ein wenig Sprüche klopfe , aber nicht maßlos übertreibe: während der Entwicklung von 101_browser ist es mir gelungen mittels der bereits entwickelten Werkzeuge auf den Servern von Google eine Schwachstelle (auch wenn diese ehrlicherweise kaum für praktische Angriffe ausnutzbar ist) zu finden (welche allerdings längst beseitigt ist, da ich das Google Security Team (die wirklich kompetent sind) darüber informiert habe). Mehr dazu weiter unten.
Aber von Anfang an: wusstet ihr, wie viele Informationen euer Browser freiwillig über euch herausgibt: wer mutig ist , kann mal unter panopticlick.eff.org/ testen, wie identifizierbar er im Netz ist und wie viele Informationen der Browser über euch ohne Rückfrage ins Netz sendet (und dabei werden gar nicht mal Standard-Methoden zum Tracking, wie Cookies oder gar Supercookies etc. eingesetzt). Also ich würde eine Software, die solche Massen an Informationen über mich in alle Welt hinausposaunt und das ohne Rückfrage eher als Schadsoftware einstufen. Aber die Webstandards schreiben ein solches Verhalten vor...
Eine Möglichkeit, die ein Tracking auch durch fremde Firmen (ohne, dass der Seitenbetreiber die Daten weitergibt, was ihn datenschutzrechtlich in die Zwickmühle brächte - nein, euer Browser, der auf *eurem Rechner* läuft, macht das für euch) bildet die Tatsache, dass in den Webstandards es Ausnahmen zur Same-Origin-Policy gibt. Dass diese brav drinbleiben - darum wird sich schon gekümmert etc. - schließlich gibt es Firmen, die diese Ausnahmen brauchen, um Nutzer tracken zu können.
Interessanterweise führen diese immer wieder zu massiven Sicherheitslücken (z. B. XSS). Des Weiteren hat Microsoft im Rahmen eines Forschungsprojektes einen Browser namens Gazelle entwickelt: research.microsoft.com/apps/pubs/default.aspx?id=79655 , der überall Same-Origin-Policy einfordert.
Warum also nicht gleich so und mehr potentielle Sicherheit und Datenschutz auf einmal? Schließlich ist es meine Auffassung, dass Datenschutz wichtiger ist als Erfüllung von Webstandards.
Das Problem ist, dies würde zu Problemen mit existierenden Webseiten führen, die auf die Erfüllung der Standards seitens der Browser vertrauen. Meine Meinung dazu: dem Nutzer Möglichkeit geben für einzelne Websites Ausnahmen zu definieren (inklusive Möglichkeit des permanenten White- und Blacklistings von Servern). Anschließend sollen die Nutzer durch den dadurch bedingten Aufwand ruhig am eigenen Leib merken, wie sehr sie getrackt werden bzw. das möglich ist.
Doch auch die Funktionen, die eingeführt wurden, um Sicherheit bei dem (erlaubtem) Bruch der Same-Origin-Policy zu gewährleisten, sind nicht ohne. Es gibt in den Standards eine Funktion, die es erlaubt, dass der Server A für Ajax-Aufrufe auf Server B machen kann, nachdem Server B dem Browser bestätigt, dass es zulässig ist. Warum das eingeführt wurde? Es gibt Firmen, die haben ein Interesse daran.
Auf den ersten Blick scheint es mehr Sicherheit zu gewährleisten. Auf den zweiten Blick wird hierdurch eine Form von DRM im Web geschaffen - denn hierdurch hat der Serverbetreiber von Server B die Macht, dass nur "zahlende" Website-Betreiber auf seine Services zugreifen können. Wollt ihr das?
Nächster Punkt: Geolocation. Firefox, Opera und Chrome implementieren in ihren aktuellen Versionen eine Möglichkeit den Ort des Betrachters herauszufinden. Die technischen Details dazu (sowie deren Genauigkeit, Schwächen und Datenschutzprobleme) findet ihr am besten selbst heraus - ich möchte hier nicht weiter hetzen...
Meine propagierte Lösung (teilweise implementiert): viele GPS-Empfänger lassen sich mit ein paar Programmiertricks zu einer GPS-Mouse umfunktionieren. Dies ist sowohl erheblich präziser, als auch datenschutzfreundlicher, da keine Daten an den Provider des Geolocation-Services übertragen werden. Wer Geolocation als sinnvoll betrachtet, wird auch noch das Geld für einen GPS-Empfänger besitzen...
Ich könnte noch ewig darüber schreiben, aber ich habe ja oben versprochen, etwas zum Thema mächtige Möglichkeiten für den Nutzer zu notieren.
Erstes Beispiel: das Webframework Google Web Toolkit hat bei der Codeerzeugung die Eigenschaft, dass die Daten verifizierenden Codeteile zwei mal erzeugt werden: einmal für den Server Part (aus obligatorischen Sicherheitsgründen darf man grundsätzlich nicht darauf vertrauten, dass der Client keine maliziösen Daten sendet), aber ein zweites mal für den Client Part (damit die Webapplikation "schnell reagiert").
Auch bei Webapplikationen, die nicht auf Google Web Toolkit aufbauen, sind derartige Codeteile im Allgemeinen zwei mal vorhanden (allerdings werden sie dann meistens zwei mal programmiert).
Was hat dies für eine Konsequenz? Man kann den existierenden Code prima nutzen, um Strukturen zu erkennen. Wie wäre es beispielsweise, wenn aus dem Code automatisch UML-Diagramme o. ä. gebaut werden?
Zweites Beispiel: Ein sehr mächtiges Werkzeug zum Finden von Fehlern in Anwendungen ist das sogenannte Reverse Debugging. Bei klassischem Debugging führt man ein Programm aus und wartet, bis der Fehler auftritt. Anschließend versucht man (meistens durch noch mehrmaliges Ausführen) herauszufinden, wie es zu diesem Fehler kam.
Reverse Debugging funktioniert ein wenig anders (viel eleganter!): man lässt das Programm laufen, bis der Fehler auftritt. Wenn dies geschehen ist, lässt man von diesem Punkt das Programm rückwärts (!) laufen (z. B. schrittweise) und kann so direkt nachvollziehen, wie es zu diesem Fehler kommen konnte.
Das Prinzip selbst ist seit langem bekannt und Rechner sind heute längst leistungsfähig genug, dies umzusetzen. Warum also dem Nutzer nicht dieses mächtige Werkzeug zum Finden von Fehlern in Webapplikationen in die Hand geben?
Drittes Beispiel: während es üblich ist, dass man den (X)HTML-Code einer Webseite einfach betrachten kann, bieten existierende Browser kaum Möglichkeiten, andere Elemente (wie Grafiken) von Webseiten "wirklich zu analysieren". Ich werde mich mit dem Zitieren eines einzelnen Beispiels begnügen: de.wikipedia.org/wiki/Exchange…at#M.C3.B6gliche_Probleme
Warum bieten existierende Browser dies nicht an? Der technische Grund liegt darin, dass die meisten Browser für Zwecke wie Lesen von Rasterbildern auf fertige Bibliotheken vertrauen (z. B. libpng für PNG), die ein Lesen von solchen Dateien als problemloses "Fertigpaket" anbieten. Für Analysezwecke reicht in meinen Augen jedoch kein Fertigpaket, sondern man muss sich selbst an die Arbeit machen.
Es gäbe natürlich noch viel mehr zu erzählen, aber damit will ich es erst einmal auf sich beruhen lassen.
Falls ich euch neugierig gemacht habe und ihr unter genannter Webseite (github.com/nubok/101_browser) nachschauen wollt, sei euch aber gesagt: ganz vieles befindet sich noch in einer sehr frühen Phase. Glaubt mir wirklich: es ist noch kaum etwas da, was für Nichtprogrammierer interessant ist.
Dennoch für alle Interessierten:
Aktuell besteht das Projekt aus 24-25 Projekten (unter Windows; unter Linux sind es ein paar weniger), von denen einige jedoch sehr klein/veraltet etc. sind und daher verschwinden werden. Dafür werden andere hinzukommen. Hier eine kurze Beschreibung:
Algorithm: Implementierung von ein paar häufig benutzen Algorithmen, wie Binärsuche. Im Moment noch sehr klein
BasicDataStructures: sollte eigentlich das werden, was nun Algorithm und IO ist. Mittlerweile Müllhalde, die irgendwann abgebaut bzw. in andere Projekte eingegliedert wird
BigNumber: Bibliothek zum Umgang mit großen Zahlen. Wird immer dann erweitert
CompilerBackend: Private Tests für dynamische Codeerzeugung. Wird erst einmal dringelassen, da der Code sicherlich noch in Zukunft Verwendung finden wird - wenn auch in anderer Form
CoroutineWin/CoroutinePosix: da ich mich in letzter Zeit dafür entschieden habe, dass der Code stark auf Coroutinen (ein für viele Programmierer eher unbekanntes Feature) aufbauen soll, ist hier die Bibliothek dazu. Funktioniert seit ganz Kurzem sowohl unter Windows als auch unter Linux.
CPU: Testen der CPU auf Features. Zukunft ungewiss
FontServer: Verwalten von Schriften. Seit längerer Zeit nicht daran gearbeitet, aber zentrale Komponente
GeolocationBackendGarminWin: Nutzung von einigen Navigationssystemen der Firma Garmin als GPS-Mouse
GeolocationBackendGarminWinTest: Testcode für GeolocationBackendGarminWin, der, weil GeolocationBackendGarminWin und GeolocationBackendGarminWinTest noch nicht so weit sind, noch nicht in TestSuite aufgenommen wurde
GIF: Lesen von GIF-Dateien - vieles funktioniert schon, aber es muss noch daran gearbeitet werden
GuiWin/GuiX: Grafische Benutzeroberfläche. Seit längerem nicht daran gearbeitet; allerdings bietet es unter Windows das Feature der Unterstützung mehrerer Mäuse zugleich
HTML5: sollte selbsterklärend sein. Leider noch sehr viel daran zu arbeiten
IO: vereinheitlichte Bibliothek für alle Ein- und Ausgaben (Dateien, Netzwerk/Internet) und - ganz brandaktuell am daran arbeiten - Erstellen von Datenströmen zwischen Bibliotheken
JpegDecoder: zugleich halbes Testprogramm als auch Leser für JEG-Dateien; muss noch einiges daran gearbeitet werden und dann in diese beiden Teile aufgespalten werden
MiniStdlib: Wrapper um ein paar Headerdateien und Funktionen der Standard-Bibliothek
NetworkWin/network_posix: Testcode für Netzwerkfunktionen und http; unter Windows noch nicht auf Visual Studio 2010 portiert, da anderes erst einmal wichtiger ist
PdfReader: Lesen von PDF-Dateien. Kaum etwas vorhanden und lange nicht dran gearbeitet
PNG: Lesen von PNG-Dateien; wird weiterentwickelt, wenn RFC1950 und RFC1951 funktionieren
PNGTestSuite: Testcode für PNG; wenn PNG und PNGTestSuite soweit sind, wird es mit TestSuite verschmolzen
RFC1950: Implementierung des ZLIB-Standards. Wird natürlich RFC1951 (DEFLATE) bald als Ergänzung brauchen
SwfReader: Code zum Lesen von SWF-Dateien (Flash)
TestSuite: aktuell 2391 automatisch ausführbare Tests, die testen, ob sich das Programm (hoffentlich) fehlerfrei verhält
Unicode: aktuell nur Code zum Parsen der Datei PropList.txt des Unicode 6.0-Standards. Wird erweitert, wenn es sich als erforderlich erweist
XmlReader: Lesen von XML-Dateien. Praktisch nichts da.
Und dann noch: zlib (die Standard-Implementierung), die ich jedoch durch meine eigene Implementierung RFC1950 und RFC1951 ersetze, sobald diese funktionieren.
Erst wenn der letzte Programmierer eingesperrt und die letzte Idee patentiert ist, werdet ihr merken, dass Anwälte nicht programmieren können.