Zweimal wird mit Backticks die Ausgabe eines Befehls in eine Variable eingelesen. Einmal ein simples echo, einmal ein ganzes Script, das ein paar verschachtelte if und case hat. Beim einfachen echo evaluiert grep korrekt zu true, beim Script nicht.

Ich habe jetzt einen Workaround, bei dem ich nicht per Übergabe eines Parameters die Startup-Scripte sagen lasse, was sie tun, sondern verwende speziell formatierte Kommentare, die ich direkt greppe. Das ganze ist Teil eines etwas umfangreicheren, modularen Mini-Linux, an dem ich gerade arbeite — mehr dazu in den nächsten Tagen.

Wer mit meinem Build der Busybox spielen möchte: busybox-1.13.2-static-ulibc-i686.tar.gz

• Starke Verschlüsselung: Das Backup muss sicherer sein als diese unsägliche ZIP-Verschlüsselung hinreichend sicher sein und ein statistischer Angriff soll keinen Erfolg versprechen.

• Gute Komprimierung: Ich möchte in kurzer Zeit das Backup klein eindampfen können und beim Zugriff effizient entpacken, also nur die Dateien, die ich benötige.

• Mountbares Backup: Ganz ohne vorheriges Entpacken soll ein sofortiger Zugriff auf alle Dateien im Backup möglich sein.

• Keine unverschlüsselten temporären Dateien: Weder beim Packen noch beim Entpacken sollen unverschlüsselte temporäre Dateien anfallen, einerseits aus Sicherheitsgründen, andererseits weil eine temporäre Datei auf einem zufällig verschlüsselten Dateisystem Prozessorlast erzeugt.

Bis vor kurzem habe ich einfach Archive mit Tarballs mit Twofish verschlüsselt (openssl bietet ein komfortables Subkommando) und diese auf DVD gebrannt. Neben den oben genannten Nachteilen kam das Problem dazu, dass auf einem ISO-9660-Dateisystem die Dateigrößengrenze bei 2GB lag.

Meine Lösung sah eine Kombination aus bekannten Technologien vor: Eine Containerdatei sollte per losetup zum blockorientierten Gerät mutieren, dort wiederum sollte mit cryptsetup ein verschlüsselter Datenträger entstehen, der wiederum ein komprimiertes Squashfs-Dateisystem aufnehmen sollte. Klingt kompliziert? Ist es aber nicht:

Benötigt werden die im Tutorial /home reisetauglich verschlüsselt erwähnten Pakete und die squashfs-tools sowie SquashFS-Module für den laufenden Kernel.

Anlegen des Containers und Befüllen mit Daten

Zuerst wird ein Container angelegt, verschlüsselt und dann mit Daten gefüllt

• Erstellen des Containers: Ein Sparse-File mit der maximal zulässigen Größe einer DVD5 (4700372992 Bytes oder 2295104 Blöcke — bei einer DVD9 müssten es 4150388 Blöcke sein) entsteht mit dem folgenden Befehl. Die Datei belegt am Anfang nur 2048 Byte, angezeigt wird dennoch die maximale Größe:

  dd if=/dev/zero bs=2048 count=1 seek=2295103 of=crypt_squash.data

• Erstellen eines Loop-Devices: Mittels losetup entsteht jetzt eine der Datei zugeordnete Blockdevice:

  losetup /dev/loop0 crypt_squash.data

  Sollte /dev/loop0 bereits besetzt sein, zeigt losetup -f freie Loop-Devices.

• Erstellen des Containers: Auf der Loop-Datei wird nun das verschlüsselte Blockgerät vorbereitet:

  cryptsetup luksFormat -c aes-cbc-essiv:sha256 -s 256 -y /dev/loop0

• Öffnen des verschlüsselten Gerätes: Nun wird die verschlüsselte Gerätedatei geöffnent. Das Resultat ist ein Blockdevide /dev/mapper/cryptdvd auf das geschrieben werden und von dem gelesen werden kann. Die Verschlüsselung erfogt hier komplett transparent:

  sudo cryptsetup luksOpen /dev/loop0 cryptdvd

• Erstellen des komprimierten Dateisystems: In /dev/mapper/cryptdvd entsteht nun das komprimierte Dateisystem SquashFS. Weil wir in eine Gerätedatei schreiben, muss explizit -noappend angegeben werden, um diese zu überschreiben. Die restlichen Parameter sind Kosmetik: Ich bevorzuge noch aus Kompatibilitätsgründen Komprimierung mit gzip und möchte nur einen Prozessor einspannen.

  mksquashfs Projekte WichtigeDaten /dev/mapper/cryptdvd  -nolzma -check_data -noappend -processors 1

Test des Containers

Nun ist der Test des Containers dran. Funktioniert das Backup so, wie wir es uns vorgestellt haben?

• Mounten des Containers: Das Cryptdevice existiert ja noch, mounten wir es einfach:

  mkdir /tmp/cryptdvd
  mount /dev/mapper/cryptdvd /tmp/cryptdvd/

  Falls ein unbekanntes Dateisystem angegeben wird, sollten Sie sicherstellen, dass das SquashFS-Modul geladen ist und gegebenenfalls den Dateisystemtyp angeben:

  mount -t squashfs /dev/mapper/cryptdvd /tmp/cryptdvd/

• Unmounten:

  umount /dev/mapper/cryptdvd

• Auflösen des Cryptdevices:

  cryptsetup luksClose /dev/mapper/cryptdvd

• Lösen des Loop-Devices: So stellen wir sicher, dass auch alle Daten im Container gelandet sind und wir gefahrlos brennen können:

  losetup -d /dev/loop0

Brennen der DVD

• Brennen der DVD: cdrecord ist es herzlich egal, was für Daten da gebrannt werden, es bannt unseren Container 1:1 auf den optischen Datenträger:

  cdrecord -v -speed=4 -dev=/dev/scd1 crypt_squash.data

Test der gebrannten DVD — Mounten und Unmounten des Backups

• Loop-Device erstellen: Zunächst entsteht ein Loopdevice auf der gebrannten DVD. Es könnte eigentlich auch ohne funktionieren:

  losetup /dev/loop1 /dev/scd1

• Öffnen des Crypt-Devices: Jetzt wird die Datei /dev/mapper/cryptdvd erzeugt, welche die Entschlüsselung transparent macht. Hier ist die Eingabe des Passwortes erforderlich:

  sudo cryptsetup luksOpen /dev/loop1 cryptdvd

• Mounten des Dateisystems: Möglicherweise ist die Angabe des Dateisystemtyps erforderlich:

  mount /dev/mapper/cryptdvd /tmp/cryptdvd/

• Unmounten wie oben:

  umount /dev/mapper/cryptdvd

• Lösen des Crypt-Devices:

  cryptsetup luksClose /dev/mapper/cryptdvd

• Lösen des Loop-Devices:

  losetup -d /dev/loop1

  Nun kann die DVD entnommen werden.

Die meisten der angegebenen Schritte lassen sich leicht automatisieren, so dass sichere Backups sehr einfach durchgeführt werden können und der Zugriff genauso einfach möglich ist. Ein Manko bleibt: Für das Hinzufügen neuer LUKS-Schlüssel muss der Container natürlich mit dd auf Festplatte transferiert und in ein Loop-Device überführt werden, bevor er neu gebrannt wird.

Nachtrag I: Ich stelle diesen Artikel hiermit unter BY-SA zur Verfügung. Wer möchte, kann ihn also per Copy und Paste ins UbuntuUsers-Wiki (oder andere Wikis) übernehmen und dort weiterbearbeiten, solange auf mich als Urheber verwiesen wird. Viel Spaß damit! creativecommons.org/licenses/by-sa/3.0/de/

Nachtrag II: Da einige Community-Wikis NC-BY-SA verwenden und BY-SA nicht nach NC-BY-SA überführt werden kann, zusätzliche Bereitstellung unter NC-BY-SA. Viel Spaß damit! creativecommons.org/licenses/by-nc-sa/3.0/de/

• Netbooks: Es ist nicht mehr schön: nun wird auch die Marke Commodore wieder ausgegraben. Boingboing titelt “Marken-Negrophilie”. Unterdessen starten die Chinesen mit ihrer eigenen Interpretation des 100$-Notebooks. Allerdings mit einem Prozessor mit MIPS-Befehlssatz, für den möglicherweise keine Lizenzen vorhanden sind (die dürften das Gerät dann nochmal fünf bis zehn Euro teurer machen). Das Dell Inspiron Mini 9 wird nun ausgeliefert — ohne F-Tasten und zunächst wohl auch ohne Ubuntu. Diese Woche habe ich ich einen EeePC 900A erhalten und werde in der Folge Ubuntu-Images auch für die Atom-Gerätchen anfertigen. Einen kleinen Blick in die Atom-Zukunft hat Engadget: Erst Herbst 2009 sollen die Pineview-Prozessoren mit integriertem Grafikkern erscheinen.

• Android: In der Android Developer Challenge stehen nun die Gewinner fest. Die Sieger-Apps verbinden auf geniale Art und Weise Kamera, Web und den per aGPS ermittelten Standort. Bitterer Beigeschmack: Google kannte bislang nur unser Surfverhalten, wer die vorgestellten Anwendungen intensiv nutzt (nur zu verlockend), liefert dem Suchmaschinengiganten auch seine Standortdaten frei Haus

• Unsere Server: Aus technischen Gründen laufen derzeit die meisten Sites auf der kleinen Maschine, die deshalb stellenweise zäh zu erreichen war. Nun ist der größte RAM-Nutzer identifiziert: Der hinter Jochens www.odsport.de steckende Kater will wenigstens 400MB für sich haben. Jochen musste deshalb schon auf die schnelle Maschine umziehen. Stattet ihm doch einen Besuch ab. Mittelfristig wandern alle Webserver auf die schnelle Maschine, die Mailsysteme auf die langsame, dann sollte es wieder mit gewohnter Geschwindigkeit gehen.

• Schräg: ZDnet hat herausgefunden, warum auch komlexe Captchas heute schnell geknackt sind: Da sitzen in Indien Menschen vor dem Computer, die Captchas in einer Rate von je bis zu fünfhundert Stück pro Stunde lösen. In diesem Fall helfen nur Textaufgaben wie : “Berechnen Sie die Summe aus der dritten Wurzel von siebenundzwanzig und dem Produkt aus fünf und der Quadratwurzel von einhunderteinundzwanzig!”

Was könnte in diesen Sprechblasen stehen?

Die Spielregeln sind einfach: Ihr füllt die Sprechblasen aus und hinterlasst Links, Trackbacks oder schickt mir Eure Interpretation per Mail. Nächsten Freitag werden wir im kleinen Team dann den Gewinner auslosen. Der oder die Gewinnerin bekommt einen Kasten Reudnitzer oder zwei Flaschen Wein von meinem Lieblingsweingut. Der Rechtsweg ist ausgeschlossen.

Zum Thema

• Herr Baschitzsch zur Interpretation des Logos von Thomas Vehmeier — ICH musste irgendwie sofort an die Afrikaner Weerstandsbeweging denken…
• Chrome-Diskussion im Lawblog

Trackbacks sind angeschaltet…

• Chrome hat Speicherhunger

  Die Ausführung jeder Webseite in einem eigenen Prozess hat zur Folge, dass der Speicherbedarf deutlich größer ist als bei Browsern, die einen Prozess mit mehreren Threads verwenden. Allerdings kann keine der beiden Ansätze vollständig überzeugen. Ein Kompromiss wäre die Zusammenfassung von Tabs, die gleiche JavaScripte verwenden in einem Prozess oder das Logging vom Verhalten von Scripten: Für Scripte, die häufig die Oberfläche blockieren gibt es Maluspunkte, für den flüssigen Einsatz asynchroner Kommunikation und kleiner Datensegmente Bonuspunkte. Seiten mit vielen Bonuspunkten werden künftig in einem Prozess zusammengefasst, Seiten mit Maluspunkten bekommen jeweils alleine einen Prozess.

• Der Browser als Online-Keylogger

  Bereits ab dem zweiten Buchstaben überträgt Google jede Eingabe in der Adresszeile unverschlüsselt an Googles “Vorschlagsserver” (siehe Screenshot, hier wurde “sp” getippt). So kommt der Suchmaschinengigant ganz nebenbei an angesurfte Domainnamen, aber auch bislang der Suchmaschine verborgene Pfade heran. Kritisch ist die Vorschlagsliste hinsichtlich in URLs kodierten Nutzernamen oder gar Passwörtern, die so auch bei Google landen und einen Personenbezug herstellen können. Abhilfe wäre einfach: Erst nach Eingabe eines Leerzeichens startet die Suche auf Googles Servern, zuvor wird lediglich lokal gesucht. So ist sichergestellt, dass nicht jede angesurfte Domain ins Web hinausposaunt wird, andererseits bleibt der Komfort erhalten. Der eingebaute Pornomodus ist ein Scheinargument: Oft möchte man Seiten ansurfen, die in der eigenen History gespeichert bleiben und deren Cookies Bestand haben, ohne dass Google etwas davon erfährt.

• Wo ist die Einstellbarkeit?

  Google ist bekannt für durchdachte User Interfaces, die meist wenig Anpassung erfordern. Allerdings ist ein Browser ein Programm, dass vielfältiger eingesetzt wird als ein Online-Mailclient oder eine Suchmaschine. Entsprechend unterschiedlich sind die Anforderungen an die Konfiguration. Doch Chrome bietet kaum Einstellmöglichkeiten und offenbart so Googles Arroganz (“Wir wissen, was gut für Dich ist!”). Klar, dass der größte Online-Werbeanbieter keinen komfortablen Cookie-Cruncher oder Adblocker einbauen möchte, doch wird Google wenigstens Programmierschnittstellen für die Erweiterung um derartige Funktionen einbauen müssen, um glaubwürdig zu machen, im Sinne des Nutzers zu handeln.

• Und Google ist doch böse

  Google wirbt gerne mit dem Motto “Don’t be evil!” und tatsächlich sind keine Anhaltspunkte für einen Mißbrauch von Daten zu erkennen. Google möchte einfach alles über seine Nutzer wissen, um ihnen die besten Anzeigen, die besten Suchvorschläge und irgendwann mit der richtigen Kombination aus Google Base und Google Maps die besten Restauranttipps unterbreiten zu können. Ich nehme Google sogar ab, dass alle Datensammlungen in einem technokratischen Glauben an den besten Nutzen betrieben werden. Doch das ändert nichts daran, dass Datenberge Begehrlichkeiten wecken: bei Geheimdiensten genauso wie bei korrupten Mitarbeitern. Ein glaubwürdiger Schritt zum Softwareanbieter sollte daher mit einer echten Selbstverpflichtung zu Datensparsamkeit und Datenschutz einhergehen — unterstrichen durch die detaillierte Darlegung, welche Daten wie, wo und wie lange verarbeitet werden. Eine solche Selbstverpflichtung steht derzeit noch aus.

• Der Tritt in den Hintern wirkt bereits

  Ich ging gestern darauf ein, dass Konzepte und Ideen aus Chrome schnell den Weg in andere Browser finden können. Heute wurde das Rennen um die schnellste JavaScript-Implementierung eröffnet. Eine um Debugging-Code bereinigte und einige Fehler korrigierte Version von Mozillas JavaScript-Beschleuniger TraceMonkey schlägt sich in vielen Benchmarks schon besser als Chrome. Nutzer der Browserplatzhirsche dürfen also damit rechnen, dass auch “ihr” Browser bald mittelbar von der neuen Vielfalt profitieren wird — in bewährter Konfigurierbarkeit, ohne den eingangs erwähnten Datenschutz-Implikationen.

Jeder der angesprochenen Kritikpunkte ist mit vertretbarem technischen Aufwand anzugehen. Seiteneffekte wie den hohen Speicherbedarf wird Google schneller angehen als der Ruf nach besserem Datenschutz. Die Frage ist daher, inwieweit Google dazu bereit ist, auf die berechtigten Schutzinteressen seiner Anwender einzugehen. Bei Google arbeiten smarte Leute, daher meine Mutmaßung: Google kalkuliert für sich ein Optimum aus dem (für den Suchmaschinengiganten) positiven Effekt einer hohen Verbreitung und dem negativen Effekt der pro Anwender weniger erhobenen Daten. Ein solches Optimum kann auch für den Anwender in einem Bereich liegen, der keinen stärkeren Impact auf die Privatsphäre hat als bei der Nutzung anderer Browser. Um das zu erreichen muss die Nutzerschaft jedoch ihre Mündigkeit beweisen und darf Chrome nicht im Alltagseinsatz verwenden — so verlockend die simple Nutzerschnittstelle und die hohe Geschwindigkeit auch sein mögen.

Zum Thema

• Cem sammelt Pros und Cons
• Screenshot (Wireshark, wie oben) von der Übertragung von UserID und MachineID bei der Update-Anfrage, natürlich unverschlüsselt per HTTP
• Golem: Abschalten der ID

Nachtrag, 6. September:

• Andreas (Smokinggun) erläutert die Übertragung der Eingaben für die Suchvorschläge detailliert und weist darauf hin, dass anhand der Installations-ID eine exakte Zuordnung möglich ist — auch wenn eine Cookie-Spur mal abreist.

• Laut Golem warnt das BSI vor dem Einsatz von Chrome und begründet das unter anderem mit Googles Datensammelwut — allerdings ohne auf Details einzugehen.

]]> http://blog.rootserverexperiment.de/2008/09/04/warum-normale-anwender-die-finger-von-chrome-lassen-sollten/feed/ 6 http://blog.rootserverexperiment.de/2008/09/03/warum-das-web-google-chrome-braucht/ http://blog.rootserverexperiment.de/2008/09/03/warum-das-web-google-chrome-braucht/#comments Wed, 03 Sep 2008 21:35:47 +0000 Administrator http://blog.rootserverexperiment.de/?p=121 Seit zwei Tagen ist Google mit einem eigenen Browser am Markt, der wie kaum ein anderes Produkt polarisiert.
Während die einen einen neuen Browserkrieg am Horizont ausmachen, ächzen andere über die vermeintliche Fragmentierung des Netzes.
Doch Chrome kommt gerade recht: Lesen Sie, warum bald jeder Surfer von Chrome profitieren wird, selbst wenn er den Google-Browser nicht einsetzt.

• Gebt den Entwicklern etwas zu spielen!

  Als vor fast zehn Jahren Netscape die Freigabe des Quellcodes beschloss, die Entwicklergemeinde Netscape 5 aber wegen seinen Altlasten zurückwies und stattdessen mit Gecko die komplette Neuimplementierung des Browsers begann, war der Grundstein für ein sehr innovatives Projekt gelegt. Viele der in den folgenden Jahren ausprobierten Konzepte waren nur dank der kleinen, aber aktiven Anwenderschaft möglich. Aus der Distanz betrachtet war der verlorene Browserkrieg ein Glücksfall für die Internetgemeinde. Heute ist Mozilla ein großes Projekt mit Millionen von Anwendern. Radikale Änderungen an der Nutzerführung oder dem internen Aufbau würden mit gewohnten Mustern brechen. Mit Chrome existiert wieder ein kleines, aber mit vielen Programmiereressourcen ausgestattetes Projekt, in dem neue Konzepte ausprobiert werden können ohne Nutzer zu verschrecken. Bewähren sich diese, werden sie ihren Weg in andere Browser finden.

• JavaScript mit V8 nutzt Programmierern und Anwendern

  Ein großes Problem aktueller Browser ist die JavaScript-Implementierung. Die Sprache war mit ihrer halben Objektorientierung eigentlich nur dazu gedacht, lokale aktive Inhalte zu platzieren, wo man mit HTML und CSS nicht beikam. Vor einigen Jahren kam dann mit AJAX die Möglichkeit auf, Inhalte dynamisch nachzuladen. Exzessiv eingesetzt lassen sich mit JavaScript und AJAX ganze Anwendungen erstellen, die viele JS-Interpreter an den Rand der Leistungsfähigkeit bringen. Die von Google in Auftrag gegebene virtuelle Maschine V8 soll JavaScript im Hintergrund mit Klassen ausstatten und Zwischencode generieren, der wiederverwendbar ist. Die Idee dahinter ist gut und vielleicht folgen daraus Vorschläge für die Erweiterung künftiger ECMA-Script-Versionen um eine echte Objektorientierung. Und möglicherweise gibt V8 anderen Browsern Impulse, eine virtuelle Maschine wie Parrot oder die .Net-Runtime für ECMA-Script zu erweitern und so das Konzept zu übernehmen. Eigentlich ist das aber nicht nötig: V8 soll unter eine BSD-Lizenz gestellt werden, mit derart lizenziertem Code hat nicht einmal Microsoft Probleme.

• Der Browser wird als Anwendungsplattform wahrgenommen

  In den Köpfen vieler Surfer ist der Browser ein Programm zur Anzeige von Webseiten. Tatsächlich ist er viel mehr, nämlich eine Plattform um Anwendungen auszuführen, die zufällig übers Internet geladen und aktualisiert werden. Chrome macht dies bewußt, dafür sorgen Aktionen wie Möglichkeit, einen Tab per Drag&Drop auf den Desktop zu ziehen oder AJAX-Anwendungen ganz ohne Titelleiste zu starten. Das regt auch Entwickler zum Nachdenken an: Wäre es nicht sinnvoll, wenn der Ersteller einer Seite dem Browser sagen könnte, dass er (beim herausgelösten) Start keine Titel- und Navigationsleiste braucht? Mozilla verfügt mit Prism über ein ähnlich gelagertes Projekt, das allerdings derzeit nicht den nötigen Fokus der Entwickler bekommt.

• HTML 5 wird vorangetrieben

  HTML 4 und das daraus abgeleitete XHTML 1 tragen noch viele Altlasten der frühen 1990er in sich. Beide sind auf einfaches Parsen optimiert, auf der Strecke bleibt vor allem die Semantik des Webs. HTML 5 verspricht die Erweiterung um zusätzliche semantische Elemente, insbesondere in der Struktur eines Dokumentes. Das kommt natürlich Suchmaschinenherstellern besonders zu Gute, die das Abstract eines Textes stärker gewichten können als den folgenden Fließtext. Den Surfer dürfte an HTML 5 eher interessieren, dass zusätzliche Lese- und Navigationshilfen möglich sind. So kann ein Browser, der ein langes HTML 5 Dokument anzeigt, auf Basis der Kapitelschachtelung einen Navigationsbaum aufbauen wie er in vielen PDF-Dokumenten integriert ist. Daneben bietet HTML 5 die vereinfachte Einbindung multimedialer Inhalte und zollt mit einer Programmierschnittstelle für die lokale Datenspeicherung der Wahrnehmung von Webseiten als Anwendungen Respekt. Mit Google als Schwergewicht dürfte die weitere Spezifikation von HTML 5 neuen Schwung bekommen. Vielleicht nicht mit allen tollen Vorschlägen, aber besser bald HTML 5 und wenig später mit HTML 5.1 eine Erweiterung als ein Spezifikationsprozess, der sich noch Jahre hinzieht.

• Mikroformate rücken ins Licht der Öffentlichkeit

  Tim Barners Lee hat das semantische Web bereits zum Web 3.0 erklärt: Webseiten müssen maschinenlesbar sein und die Kommunikation zwischen Diensten unterstützen. Was eigentlich massive Änderungen an bestehenden Konzepten erfordert (die auch mit HTML 5 nicht vollständig eingeführt sind), hat eine kleine Gruppe von Entwicklern auf Basis von HTML 4 ausgeheckt: Die Sematik wird hierbei völlig RFC-konform über Klassennamen eingebracht. Die Microformats genannte Erweiterung wird vor allem für Adressen, Termine und geographische Koordinaten eingesetzt — auf tausenden von Webseiten. Bislang braucht es Browsererweiterungen, um eine Adresse anzuklicken und die dahintersteckende Visitenkarte ins Adressbuch zu übernehmen oder das gleiche mit dem Termin des Konzerts der Lieblingsband zu machen. Google hat Mikroformate bis vor kurzem stiefmütterlich behandelt, importiert und exportiert sie aber heute. Eine gute Unterstützung für Mikroformate könnte den Komfort gerade im Umgang mit Web-Applikationen deutlich verbessern.

• SVG, was war das doch gleich?

  Das XML-Format “Scalable Vector Graphics” ist als Austauchsformat für — richtig geraten — Vektorgrafiken außerhalb des Webs längst Usus. Eingebettet in Webseiten ermöglicht es jedoch nicht nur die Anzeige beliebig skalierbarer Grafiken, sondern auch die Manipulation mit den bekannten DOM-Operationen: Grafiken interaktiv, maschinengeneriert, skalierbar, durch Suchmaschinen indexierbar, ohne Plugin. Die Unterstützung durch Browser ist derzeit etwas dürftig: Firefox kanns solala, IE gar nicht und Safari ganz gut. Mit Chrome kommt ein weiterer Browser dazu, der SVG ganz gut können wird. Auch mit diesem Feature wird Microsoft daran erinnert, was alles fehlt. Und Google Maps ist beileibe nicht die einzige Seite, die SVG nutzt. Bald könnten es mehr werden.

Insbesondere die Angst vor einem neuen Browserkrieg ist unberechtigt. Im Gegenteil: Google möchte keinesfalls einen Großteil der Websurfer ausschließen, sondern möchte mittelfristig die — in den Augen Google’s — sinnvollen Features in allen Browsern vorfinden. Dazu benutzt Google das Prinzip “Zuckerbrot und Peitsche”. Die Peitsche ist ein sauberes Konzept, die schnelle VM für ECMA-Script und die präsente Drohung “Wenn wir noch ein paar Millionen reinbuttern, braucht Euch keiner mehr.” Das Zuckerbrot ist die angekündigte Lizenzierung vieler Komponenten unter einer BSD- oder MIT-Lizenz (Webkit steht nach wie vor unter LGPL). Dabei steht für Google nicht die Dominanz auf dem Browsermarkt an erster Stelle: Es geht darum, sicherzustellen, dass 100% aller Browser gut mit Googles Anwendungen können — notfalls wird nachgeholfen. Für Webentwickler bedeutet das die Chance, jetzt auf den Zug aufzuspringen und ganz vorne dabei zu sein, wenn sich neue Konzepte durchsetzen. Es kann ja nicht angehen, dass alleine Google vom Fortschritt profitiert — tatsächlich gewinnen besonders Anwendungen und Geschäftsmodelle, die auf pfiffige Kombinationen der neuen Features setzen, aber ersteinmal zu klein erscheinen um auf dem Radar des Großen aufzutauchen.

Alles eitel Sonnenschein? Nicht ganz: Ich werde in den nächsten Tagen darauf eingehen, warum normale User sich mit dem Einsatz von Chrome noch zurückhalten sollten. Entwickler sollten aber zuschlagen und austesten, wo die Grenzen von Chrome liegen und welche Möglichkeiten der Browser für künftige Webanwendungen bereithält: Ihr könnt sicher sein, dass die etablierten bald nachziehen.

Zum Thema

• Robert Basic beschreibt, testet, lizenziert und bringt zum Absturz
• Golem hat einen Test und geht auf die Datenschutzproblematik ein
• Cem beschwört die Browserdämmerung, sammelt Testberichte und macht Impact aus
]]> http://blog.rootserverexperiment.de/2008/09/03/warum-das-web-google-chrome-braucht/feed/ 5