Christian Dinse bloggt.

Seit heute Morgen macht eine wirklich zu Tränen rührende Story die Runde: ein praktisches, lauffähiges Beispiel des <video>-Tags in HTML5. Die Rede ist von der Möglichkeit, Videos in HTML einzubetten, ohne dafür zusätzliche Plugins wie Flash zu benutzen. Eigentlich ein Traum, den man vor 10 Jahren definitiv der heutigen Zeit zugeschrieben hätte. Leider ist es noch keine Realität.

Ein hervorragendes Beispiel ist aber nun endlich für jeden verfügbar: das französische Videoportal Dailymotion setz in seiner als “Pré Bêta” bezeichneten Seite auf Video ohne Flash.

Es läuft super und problemlos. Einzige Vorraussetzung ist momentan ein Browser mit HTML5-Unterstützung, was aktuell für die Firefox 3.5b4 zutrifft und ausserdem auch mit Safari 4 Beta.

Schon allein auf Grundlage meines Jobs habe ich prinzipiell nichts gegen Flash, aber trotzdem wäre ein Welt ohne derartige Browser-Erweiterungen sehr viel einfacher. Die Möglichkeiten die Javascript bietet, kombiniert mit dem HTML5-<video>-Tag, sind _theoretisch_ gleichbedeutend mit den meisten Dingen, die heutzutage in Flash umgesetzt werden. Von umfangreichen, grafischen Browsergames mal abgesehen.

Mir ist ja bewusst, dass man sensible Passwörter nicht im Browser speichern sollte, aber wieso Firefox auch in der aktuellsten Version diese Dinger noch immer in Plaintext (ohne Schutz) speichert, bleibt ein Rätsel.

Szenario:
- Google Chrome installiert
- Frage “Daten aus Firefox importieren”
- alles, auch gespeicherte Passwörter sind da

Gleicher Test, aber mit gesetztem Masterpasswort in Firefox:
Google Chrome hat alles importiert, aber keine Passwörter (gut!).

Sicherlich ist für ein automatisches Ausfüllen von Formularen der Plaintext unumgänglich, dennoch kann man aber auch dieses für Aussenstehende schwieriger auslesbar machen, in dem man die sensiblen Daten hashed, den zughöriger Schlüssel aber auch parat hat. Klingt wieder genauso unsicher, macht aber dann Sinn, wenn der Schlüssel auf Basis einer Zufalls-ID, dem Betriebsystem/Uhrzeit/irgendwelcher Profildaten des Benutzes am System/etc. erzeugt wurde.

Was man dann natürlich nicht machen darf (als Hersteller des Browsers) ist, die Funktion offen zu legen, wie der Hash erzeugt wurde bzw. wie genau er anzuwenden ist. Auch die Stelle, an der man den Hash findet sollte “geheim” bleiben. Es gibt zahlreiche Stellen, an denen man solche Dinge gut verstecken kann. Nichts spricht gegen ein Reinkompilieren (während der Installation) des Hashes in eine Datei des Browserpaketes.

Generell macht sich über sowas aber keiner Gedanken. Das höchste ist ja schon, wie man Maleware, selbst vom Browser, besser erkennen lassen kann. Schade, irgendwie.