SPDY hält Einzug in den Firefox

SPDY ist schon seit längerem im Chrome im Einsatz – hält sich dort aber im Hintergrund. Der Browser schaltet automatisch von HTTP um, wenn Daten von einem Google Server abgerufen werden. Da SPDY wie HTTP auf TCP aufsetzt, bedarf es in der Infrastruktur keiner Anpassung, allerdings muss der Webserver das Anfrageprotokoll unterstützen. Bisher tun das die wenigsten Webserver. Aber das könnte sich bald ändern.

Wie bekannt gegeben wurde, wird SPDY in den Mozilla Sourcecode aufgenommen und soll ab Version 11 freigegeben werden – also im ersten Quartal 2012. Damit kommt der potentielle HTTP-Nachfolger weltweit schlagartig auf 50% Marktanteil. Das macht es für die Hersteller von Webservern attraktiv, sich mit dem neuen Protokoll zu beschäftigen. Google hat bereits vorgelegt und ein bislang wenig verbreitetes Modul für den Apache Webserver und auch für NodeJS veröffentlicht.

Im Wesentlichen ist SPDY dem Hypertext Transfer Protocol überlegen, weil es sich besser an den aktuellen Anforderungen orientiert. Durch die steigende Komplexität von Webseiten werden pro Seitenaufruf mehr unterschiedliche Ressourcen (Text, Grafiken, Styles, Skripte…) benötigt. SPDY kann pro Anfrage mehrere Ressourcen auf einmal anfragen, führt eine Priorisierung ein und sorgt durch Komprimierung für weniger Traffic bei gleichzeitig hoher Sicherheit (durch Verschlüsselung). Darüber hinaus kann der Webserver den Client kontaktieren, um Ressourcen nachzuliefern.

Für Neugierige: Wie Golem berichtet, lässt sich SPDY im Tree „mozilla-inbound“ bereits aktivieren. Über about:config reicht dazu ein Eintrag true bei network.http.spdy.enabled.

Verschlüsselung für Google Calendar

Google ist ein zweischneidiges Schwert. Die kostenosen Services GMail, Docs&Sheets, die App Engine und etliche weitere, sind zweifelsfrei mehr als brauchbar. Mit zunehmendem Maß an möglicherweise sensiblen Daten, Sie dem Suchmaschinenriesen überlassen, sollte auch das gesunde Misstrauen steigen, was damit geschieht.

Um sicher zu gehen, dass Google trotz seines Grundsatzes „Don’t do evil“ nichts Ungewolltes mit Ihren Kontakten, Mails, Terminen etc anfängt, empfiehlt sich der Aufwand, die Daten unkenntlich zu machen. Dies ist bei Google Calendar besonders einfach. Die Kalenderapplikation lässt sich via API mit unterschiedlichen Clients ansprechen, seien es fertige Programme wie Mozillas Sunbird/Thunderbird oder Programmierschnittstellen, beispielsweise zu PHP. Das folgende Beispiel zeigt die Anpassungen an der Mozilla Thunderbird Erweiterung „Provider for Google Calendar“, die Ihre Termine für Googles Augen wie Müll aussehen lässt, ohne Sie in Ihrer täglichen Handhabe einzuschränken. Voraussetzung für das Beispiel ist, dass sowohl Thunderbird als auch die Erweiterungen Lightning und „Google Provider“ installiert sind und ein Google-Kalender eingebunden ist (siehe Installationsanleitung , siehe Abbildung 1).

Implementierung

Die Suche nach den zentralen Stellen im Code von Google Provider zu Ver- und Entschlüsseln führt uns in die JavaScript-Datei calGoogleUtils.js im Unterordner profile/extensions/{id}/js, genauer gesagt zu den Funktionen ItemToXMLEntry und XMLEntryToItem. Mit der ersten Funktion wird ein internes Kalenderobjekt zum Transport zu Google in ein XML Format verpackt. Die zweite Funktion ist das Gegenstück zur Umwandlung in ein Objekt. Exemplarisch kodieren wir hier lediglich den Titel eines Eintrages. Sinnvoll ist dieses Vorgehen aber auch für den Ort und die Beschreibung (siehe Abbildung 2). Aus der Zeile

entry.title = aItem.title;

in ItemToXMLEntry wird dann beispielsweise

entry.title = "{enc}"+Base64.encode(aItem.title);

Wir wählen hier im Beispiel eine simple – und nicht besonders sichere – Base64 Kodierung. Eine Implementierung dieses Algorithmus findet sich im Link weiter unten. Die Klasse kann einfach am Ende der Datei calGoogleUtils.js angefügt werden. Der Phantasie des Entwicklers ist hier jedoch keine Grenze gesetzt, so dass auch bekannte Verschlüsselungsvertreter wie AES oder Blowfish schnell zum Einsatz kommen können. Eine Ressourcenliste zu JavaScript-Implementierungen dieser Algorithmen ist nebenstehend zusammengefasst. Da wir die Verschlüsselung auch rückgängig machen wollen, sind an dieser Stelle Einweg-Algorithmen wie MD5 oder SHA ausgeschlossen.

Wenn Sie das obige Beispiel unverändert einsetzen, sieht ein beispielhafter Termin wie etwa

"Dies ist ein Testtermin"

für Google und alle Kalenderbenutzer, die sich direkt auf der Webseite von Google Calendar einloggen, so aus (siehe auch Abbildung 3):

{enc}RGllcyBpc3QgZWluIFRlc3RzdHRlcm1pbg==

Das Präfix {enc} ist nicht zwingend notwendig. Es ist an dieser Stelle nur eingefügt, weil wir beim Dekodieren unterscheiden wollen, ob ein Termin verschlüsselt ist oder nicht.

In der Funktion XMLEntryToItem machen wir dazu aus der Zeile

item.title = aXMLEntry.title.(@type == 'text');

das folgende if-Konstrukt:

var decodeString = aXMLEntry.title.(@type == 'text');
if (decodeString.substring(0,5) == "{enc}") {
item.title = Base64.decode(decodeString.substring(5));
} else {
item.title = decodeString;
}

Nicht verschlüsselte Termine werden somit unverarbeitetet in Thunderbird angezeigt (aber mit obiger Änderung beim nächsten Speichern verschlüsselt. Eine geeignete Anpassung beim Verschlüsseln verschafft Abhilfe.). Kodierte Termine landen allerdings genauso im Klartext auf Ihrem Bildschirm.

Unser Beispiel lässt viel Platz für Erweiterungen. Base64 ist nicht zu empfehlen, wenn Sie die Verschlüsselungsanforderung ernst nehmen. Besser geeignet sind oben genannte Algorithmen. Wenn Sie darüber hinaus die verschlüsselten Termine in Ihrem Google Calendar durchsuchen wollen, ergibt sich die Zusatzanforderung nach einem zeichenbasierten Algorithmus. Dies könnte der Fall sein, wenn Sie den Online-Terminspeicher mit unterschiedlichen Applikationen ansprechen (siehe PHP API). Ein solcher Vertreter ist etwa die XOR-Verschlüsselung (Vernam Cipher).

Links