Das Web ist nicht vertrauenwürdig. Die Inhalte sind vielfach gelogen bzw.
Propaganda. Ein Körnchen Wahrheit zu finden, wird mehr und mehr zur Suche nach
der Nadel im Heuhaufen. Zu allem Überfluß ist das Web zunehmend mit Schadcode
durchsetzt, der sich Ressourcen bemächtigt, die mir im Traum nie einfielen
ihm zu überlassen.
Meine lokalen Ressourcen gehören mir, und ich alleine soll darauf Zugriff haben.
Dies gilt für einzelne Dateien in gleichem Maße wie für den Platz im allgemeinen.
Weder ist es akzeptabel, daß Webseiten ungefragt Daten auf meinem Rechner
abspeichern und auch wieder auslesen können, noch ist es akzeptabel, daß
Webseiten ungefragt Informationen an zig Third-Parties verteilen.
Mit jedem Browser-Update kommen heute neue Sicherheitslücken hinzu. Die Browser
werden nicht mehr sicherer sondern tendenziell unsicherer weil immer mächtiger.
Zu jedem gestopften Sicherheitsloch kommen in Form neuer Features gleich wieder
zig neue Sicherheitslöcher hinzu.
Browser
Ein Browser ist zunächst ein reines "Zeigs mir" und kein "Machs mir". Gucken
ist Gucken und Machen ist Machen. Das sind zwei verschiedene Paar Stiefel. Die
will ich strikt getrennt haben. Wenn ich mich von zunächst nur Gucken zu jetzt
etwas Machen entschließe, dann will ich explizit etwas umschalten. Ich gehe ja
auch nicht mit den Hausschuhen auf die Straße, sondern ziehe richtige Schuhe
an, bevor ich aus dem Haus gehe.
So lange ich nur gucke, und dies ist es, was ich die meiste Zeit im Browser tue,
sind eine ganze Reihe von Fähigkeiten völlig überflüssig.
- Eine normale Webseite braucht keinerlei JavaScript
- Eine normale Webseite braucht keinerlei Standortinformationen
- Eine normale Webseite braucht keinerlei Zugriff auf lokale Ressourcen
- Ein normales Formular mag per JavaScript die Eingaben der Formular-Felder
auf Fehler prüfen, darüber hinausgehende Befugnisse für JavaScript sind
in einem normalen Formular nicht erforderlich
- Eine normale Webseite und ebenso ein normales Formular brauchen keinerlei
Datentransfer wie z.B. Cookies an eingebette Ressourcen fremder Quellen.
Nur wenn die fremde Quelle eine Zugriffsverweigerungsfehlermeldung oder
ähnliches sendet, soll der Browser nachfragen, ob er Cookies der fremden
Quelle im Kontext der aktuellen Seite akzeptieren bzw. zurücksenden oder
weiterhin verweigern soll.
Webanwendungen
Anwendungen brauchen anders als Webseiten mehr Möglichkeiten, aber nicht jede
Anwendung braucht alle Möglichkeiten, sondern sie sollte nur die Möglichkeiten
bekommen, die sie im Interesse des Anwenders tatsächlich braucht.
Wenn ich mich im Wald verirrt habe und kein Mobilfunk mehr erreichbar ist,
dann brauche ich natürlich eine Anwendung, die meine Standortinformationen
nutzt, um im Web nachzusehen, wo ich hin laufen muß, um wieder ins Web zu
kommen. In allen anderen Fällen brauchen Webanwendungen keine
Standortinformationen. Und selbst dafür ist das noch die Frage, ob die
Anwendung tatsächlich wissen muß, daß es sich um meinen Standort handelt,
oder es nicht völlig ausreicht, wenn ich das weiß, daß der Ort, zu dem ich
Informationen einhole, zufällig mein Standort ist. Statt per JavaScript meinen
Standort abzufragen, könnte man ja auch ein normales Formular mit einem
Eingabefeld vom Typ Geokoordinaten (kommt in HTML 5 leider nicht vor) verwenden,
so daß der Browser dann seinerseits anbietet das Feld mit den Koordinaten meines
aktuellen Standorts oder eines Ortes aus einer Liste von Orten, nach denen ich
öfter frage, zu befüllen. So passiert dann nicht mehr ungefragt irgendwas,
sondern nun mache ich explizit etwas, indem ich dem Browser explizit sage, daß
er das Feld mit den und den Koordinaten befüllen möge. Was das dann für
Koordinaten sind, wissen dann nur mein Browser und ich, das Gegenüber im Web
erfährt es nicht, ob es sich um die Koordinaten meines Standorts handelt oder
um andere Koordinaten.
Same-Origin-Policy
Die Same-Origin-Policy soll m Browser für Sicherheit sorgen, indem sie allen
Ressourcen aus der vermeintlich gleichen Quelle vertraut und entsprechende
Zugriffsrechte gewährt. Das Problem dabei ist, daß die ganze Domain als gleiche
Quelle angesehen wird, obwohl in Wahrheit jeder Autor eine eigene Quelle ist
mit unterschiedlicher Vertrauenswürdigkeit. Das beste Beispiel ist diese
Blogseite, die Sie gerade lesen.
Diese Seite enthält Inhalt aus unterschiedlichen Quellen. Da ist ein bißchen
Text von mir – dieser ist harmlos – und extrem viel Code von der
blogger-Plattform. Ist der ganze blogger-Plattform-Code vertrauenswürdig,
nur aufgrund dessen, daß er in der selben Domain steht, wie mein Text? Und
wenn ich nun Kommentare zulasse und jemand einen Kommentar mit JavaScript darin
schreibt; ist dann dieses fremde JavaScript vertrauenswürdig nur weil es in der
selben Seite wie mein harmloser Text steht?
Wenn es um die Berechtigungen geht, ist sehr viel mehr Hirn erforderlich als diese
vorsintflutliche schon immer unbrauchbare Same-Origin-Policy. Eigentlich würde
ich hier gerne meinen Text signieren und jeglichen Script-Zugriff darauf
unterbinden. Zum bloßen Lesen ist auch der ganze blogger-Plattform-Code
überflüssig; was die Seite schön macht, ist ganz wenig CSS, der Rest vom
blogger-Plattform-Code ist beim Lesen zu nichts nutze.
Die Same-Origin-Policy bietet keinerlei Sicherheit, sondern gaukelt allenfalls
eine Scheinsicherheit vor. Die Aufteilung des Browsers in zwei Modi, einen
Lesemodus und eine Anwendungsmodus, wobei der Lesemodus der Standard für jede
neue URI sein soll und im Lese-Modus die oben genannen Beschränkungen bestehen,
und der Anwendungsmodus bei jedem Aufruf der URI erneut explizit einzuschalten
ist, wäre ein ähnlich technisch einfaches Modell wie die Same-Origin-Policy,
würde die Sicherheit gegenüber der Same-Origin-Policy aber erheblich erhöhen.
Webanwendungen würden dann immer erst funktionieren, sobald man aus dem Lesemodus
explizit in den Anwendungsmodus schaltet.
Was genau beim Umschalten in den Anwendungsmodus zu geschehen hat, gilt es noch näher
zu erarbeiten. Die primitivste Form, wäre das Nachladen der zuvor blockierten
Teile, Anwenden der Same-Origin-Policy wie bisher, Ausführen der Scripte und
feuern der Events, so als wäre die ganze Seite erst jetzt bei der Umschaltung
angefordert und geladen worden.
Quellen
Eine Quelle ist grundsätzlich ein unveränderliches Fragment eines einzelnen Autors
einer Ressource einer einzelnen URI. Wurde ein Fragment verändert, dann ist es eine
neue Quelle. Eine ganze Domain als eine einzige Quelle anzusehen, wie dies die
Same-Origin-Policy tut, ist eine fahrlässige Vereinfachung, die nicht der Realität
enstpricht.
Da die Ressource, die von einer URI repräsentiert wird, gegebenenfalls aus mehreren
Quellen besteht, bzw. andere Quellen referenzieren kann, sind die Zugriffsrechte
der einzelnen Quellen unter einander explizit zu regeln. Alle Zugriffe, die nicht
explizit erlaubt wurden, sind grundsätzlich zu unterbinden. Eine Quelle kann
anderen jeweils konkret zu benennenden Quellen explizit vertrauen und einzelne
konkret zu benennende Dinge erlauben. Grundsätzlich kann eine Quelle anderen
Quellen nur solche Dinge erlauben, die sie selber darf. Die Zugriffserlaubnis
auf Ressourcen des Anwenders (Speicherplatz, Dateien, Anwendereingaben etc.)
bedarf der Zustimmung des Anwenders in jedem konkreten Einzelfall. Vor jeder
Zustimmung kann der Anwender Quelltexteinsicht in die zugehörigen Code-Teile
verlangen.
Es liegt daher im Interesse der Anwendungsautoren die Anzahl der Quellen klein und
den Code für den Anwender kurz und dennoch verständlich zu gestalten, da er sonst
die Anwendung gegebenenfalls verärgert beendet.