Vor weit mehr als einer Dekade, genauer im Jahr 1998, beschloss das W3C (World Wide Web Consortium), dass HTML nicht mehr weiterentwickelt werden soll. Die Grenzen der Sprache schienen erreicht, und die goldene Zukunft sollte dem XML zustehen. Die HTML-Version 4.01 blieb über einen sehr langen Zeitraum eingefroren und neuere Entwicklungen rund um die Darstellung insbesondere im Internet waren in erster Linie bei den Erweiterungen wie Adobe Flash oder einst dem RealPlayer zu finden. 2006 beschloss das W3C, dass es vielleicht etwas voreilig und sehr optimistisch war, davon auszugehen, dass die ganze Welt auf XML umsteigen würde und bereite HTML5 vor. Die jüngste HTML-Variante existiert in zwei Spezifikationen, da sie sowohl von der W3C als auch als auch von der WHATWG (Web Hypertext Application Technology Working Group) entwickelt wurde. Streng genommen basiert die W3C-Ausprägung auf dem WHATWG-Entwurf, an dem auch Firmen wie Microsoft, IBM und Apple beteiligt waren. Beim Design von HTML5 gab es drei Hauptziele:

• Kompatibles Verhalten aktueller Browser

• Fehlerbehandlung

• Weiterentwicklung der Sprache zur Vereinfachung des Web-Authorings

Da die Spezifikation ausgedruckt zirka 900 Seiten umfasst, möchten wir an dieser Stelle nicht näher auf HTML5 als solches eingehen. Wer sich für die verschiedenen Features interessiert, findet mehr Informationen in unseren HTML5 FAQ. Wir beschränken uns hier auf die relevanten Änderungen, die sich auf die Sicherheit beziehen.

Erst Kekse - jetzt die ganze Torte?

Kaum eine technische Einrichtung ist so oft fehlinterpretiert worden, wie die "Cookies" des Browsers. Viele vermeintliche Sicherheitsprogramme lassen die Alarmglocken ertönen, sobald auch der kleinste "Cookie" entdeckt wurde. Ebenso häufig liest der aufmerksame Internet-Benutzer dann aber auch, dass die "Kekse" ganz harmlos seien. Faktisch handelt es sich bei einem "Cookie" um eine kleine Datei, die dafür sorgt, dass der Computer und der davor sitzende Anwender beim erneuten Besuch einer Webseite wiedererkannt werden. Der Besuch einer Internetseite hinterlässt somit eine Spur dieser "Krümel". Das kann entweder sehr sinnvoll sein, weil es beispielsweise die Anpassungen an die Wünsche des Benutzers zulässt, oder auch nicht - wenn es nur darum geht, das Verhalten des Internetnutzers zu durchleuchten, um ihn mit passenden Werbeeinblendungen zu versorgen (was aber auch nicht immer negativ sein muss).

Da sich heute viele Benutzer auf Webseiten mit dem Login von Facebook & Co. anmelden, ist die Wiedererkennung für die Webseitenanbieter deutlich eleganter geworden, als die "Krümelspur des Browsers" aufzulesen. Die Gefahr, dass unerwünscht persönliche Daten übermittelt werden, ist bei diesen typischen Anmeldevorgängen deutlich höher, als die Cookie-Leserei.

Alter Hut: Tracking mit Web Bugs

Ob der Browser Cookies überhaupt annimmt oder nicht, bestimmt der Anwender über die Optionen in der Browsersoftware. Mitunter kommt es nach dem Abschalten jedoch zu sehr vielen "Warnhinweisen", dass Cookies eingeschaltet sein müssten. Um der Deaktivierungswut der Benutzer zu entgehen, haben sich die "Datensammler" schnell etwas Neues überlegt: Kleine, nur 1x1 Pixel große transparenter GIF-Dateien, die so genannten "Web Bugs", die man nicht abschalten kann.

Doch noch einmal zurück zum Cookie aus Sicht des Webseitenentwicklers: Um kleine Info auf dem PC zu hinterlassen, ist nur eine Zeile JavaScript-Code erforderlich. Jeder Cookie hat eine "Lebensdauer" in Tagen. Möchte der Entwickler den Cookie wieder löschen, so muss er dieses Verfallsdatum auf null setzen, da es nicht einmal einen Löschbefehl gibt. Da Cookies, außer durch den Einsatz spezieller Tricks, nur an die Seite zurückgesendet werden, von denen sie auch erzeugt wurden, ist für den heimischen PC die Gefahr durch ein Cookie eher gering. Anders sieht es bei Verwendung des Browsers in einer öffentlichen Einrichtung auf. Für den Webentwickler gab es im Zusammenspiel mit Cookies in der Praxis mehr Probleme, als so mancher denkt. Entschied sich der Anwender beispielsweise zwei unterschiedliche Flugtickets in zwei Fenstern eines Browsers gleichzeitig zu bestellen, so war es für den Entwickler sehr schwierig sicherzustellen, dass sich die Daten der Fenster nicht gegenseitig beeinflussten.

Web Storage, Local Storage oder Session Storage?

Die Cookies brauchen aufgrund der vielen Probleme, die bei ihrer Verwendung entstehen, einen verbesserten Nachfolger. Dieser heißt bei HTML5 "Web Storage" - das klingt nicht nur größer, das ist auch wirklich deutlich größer. Während der Microsoft Internet Explorer beispielsweise nur 20 Cookies pro Domäne mit einer maximalen Größe von 4 KB pro Cookie annahm, gibt es für Web Storage keine Maximalbegrenzung. Die Gesamtgröße des Web Storages ist beim Mozilla Firefox, Google Chrome und Opera auf 5 MB pro Domäne begrenzt. Microsoft gönnt dem Internet Explorer bis zu 10 MB Speicherplatz. Im Bedarfsfall fragt die Software den Anwender, ob sie einen größeren Speicher allokieren darf.

Alle aktuellen Browser können die neuen Speicherbefehle korrekt interpretieren:

• Mozilla Firefox 3.5 und höher

• Microsoft Internet Explorer 8 und höher

• Safari 4 und höher

• Google Chrome 4 und höher

• Opera 10.50 und höher

Die HTML5-Spezifikation bietet mehrere Varianten der Speicheroptionen. Der "Web Storage" in den Ausprägungen sessionStorage und localStorage und die "Web SQL Database". Während es sich bei der Web SQL Database um ein komplexes Datenbanksystem zur Ablage von Informationen handelt, ist der Web Storage ein einfaches Verfahren zur Speicherung von Daten auf dem Client-Rechner mit Schlüssel- und Datenfeld.

Der sessionStorage gilt, wie der Name schon erahnen lässt, nur innerhalb der Browsersitzung. Der localStorage speichert die Daten so ähnlich ab, wie dies zuvor bei den Cookies geschah. Allerdings ist das Verfahren nicht identisch: Cookies werden bei beinahe jeder Interaktion zwischen Client und Server hin- und hergeschickt. Der sessionStorage oder der localStorage werden jeweils durch explizite Anfragen ausgelesen oder gespeichert. Dadurch wird das permanent zu versendende Datenvolumen eher geringer als größer.

Viele Anwender fragen sich nun, ob die Tatsache, dass jetzt ein Webserver mehrere MB an Daten auf der Festplatte des lokalen PCs abspeichern kann und somit Zugriff auf die lokale Hardware besitzt, nicht deutlich höheres Sicherheitsrisiko bedeutet. Für diejenigen Internetnutzer, die bereits mit der Annahme eines Cookies ein Problem hatten, ist diese Einschätzung sicherlich richtig. Strenggenommen ist es jedoch kein wirklich größeres Risiko. Genau wie bei den Cookies, so kann auch hier nur die Domäne die Informationen einlesen, die diese auch angelegt hat. Ein Querzugriff auf andere Daten ist per Definition nicht möglich. Greift ein Skript auf den lokalen Speicher zu, erzeugt der Browser ein Fehlercode, sofern es sich nicht um dasselbe Fenster- oder Dokumentenobjekt handelt, das die Daten abspeicherte.

Wer sich für die Syntax und die Quellcodes im Detail interessiert, der sei auf die Spezifikation des W3C, Einführung zu DOM-Storage auf der Microsoft Webseite oder auf die Demo-Webseite von Toralf Tepelmann hingewiesen. Im Vergleich zu den bisherigen Kämpfen rund um die Cookies, ist die Verwendung der neuen Zwischenspeicherung aus Sicht des Webdesigners deutlich angenehmer.

Schutz gegen Cookies und Storage

Alle sessionStorage-Daten gehen automatisch verloren, sobald das letzte Browserfenster geschlossen wird. Das gilt allerdings nicht für localStorage-Informationen. Wer sich gegen die Abspeicherung der Daten schützen möchte, kann dies mit den bisherigen "Cookie-Deaktivierungen" vornehmen. Für den Browser macht es keinen Unterschied, ob er Cookies ablehnt oder die Speicherung im localStorage unterbindet. Wie Sie das beim Firefox, Chrome und Internet Explorer einstellen, zeigen die Abbildungen 8 bis 10 in unserer Bilderstrecke im Detail.

Der Internet Explorer hat im Zusammenhang mit dem Löschen der Cookies ein recht eigenwilliges Verhalten. Benutzer können lokale Speicherbereiche jederzeit löschen, indem sie im Internet Explorer die Option "Browserverlauf löschen" im Menü "Extras" aktivieren, anschließend das Kontrollkästchen "Cookies" aktivieren und dann auf "OK" klicken. Dadurch werden Sitzungs- und lokale Speicherbereiche für alle Domänen gelöscht, die nicht im Ordner "Favoriten" enthalten sind. Um wirklich alle Speicherbereiche zu löschen, muss der Benutzer das Kontrollkästchen "Bevorzugte Websitedaten beibehalten" deaktivieren.

Weitere HTML5-Neuerungen

Die Modernisierung des Cookie-Systems ist zweifelsohne eine der größten Veränderungen von HTML5. Doch auch in anderen Bereichen wurde die Internet-Sprache auf den neuesten Stand gebracht. Das <video>-Tag beispielsweise erlaubt nach vielen Jahren endlich, dass ohne den Zugriff auf Drittanbieter über das <object>-Element ein Video angezeigt wird. Zwar ist es nun möglich, ohne einen fremden Player Video- und Audioinhalte direkt im Browser darzustellen, jedoch konnten sich die Firmen bei der Spezifikation nicht auf ein Standard-Codec einigen. "H.264" dürfte der derzeit akzeptierteste Dialekt sein, da er von beinahe allen Browsern verstanden wird. Diese Quasi-Standardisierung hat für den Anwender den Vorteil, dass er keine fraglichen Codec-Pakete mehr installieren muss.

Eine weitere Neuerung - das <canvas>-Element, eine Möglichkeit direkt im Browser Zeichnungen zu erzeugen - erspart wiederum die zusätzliche Installation von Add-Ins. Vor einigen Jahren war SVG der angesagte Kandidat für grafische Darstellung. In HTML5 sinkt die Notwendigkeit, SVG einzusetzen. Tief unter der Haube wartet jedoch eine besondere Neuerung: Offline-Webapplikationen - was ist, wenn das Web einmal nicht erreichbar ist? Das ist jedoch ein eigenes Thema, auf das wir in diesem Zusammenhang nicht eingehen.