Apfelhaltbarkeit

Warum beschleicht mich mehr und mehr das Gefühl, daß die Akkulebensdauer dieser Apfel-Gerätschaften, die jeder haben muß und deren Name mit i anfängt, nicht länger weilt als die Haltbarkeit eines Apfels im CA-Lager?

Das Web ist nicht vertrauenwürdig

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.