Dennoch hat es seine Schwächen. Wenn die Mailbox sehr groß wird, also richtig groß, dann wird der mount-Vorgang natürlich langsamer, wenn nicht gar schwierig bis system-kritisch. Irgendwann geht dann gar nix mehr. Dann ist der Moment gekommen, um andere Clients auszuprobieren. Und da ich aus frühen Tagen diese Komplettlösung Ximian Evolution kannte, dachte, da schaue ich mal wieder vorbei.

Doch Evolution ist nun anders. Aus der ehemals sehr schicken Oberfläche ist ein grausiges (weil Interface-diktiertes) Gnome-Programm geworden. Die Dialoge sind nun nicht mehr neat, sondern übersichtlich. Das muss wohl so sein im Gnome-Programm. Äh Moment mal, war da nicht was mit “Freiheit” bei Linux gemeint, höre ich schon die Unkenrufe. Abgespeckt erscheint es, und globig.

Probleme mit Exchange macht es ebenso. Die Mailbox öffnet sich nicht auf Anhieb, sondern nach etwas Bastelei. Mails löschen oder verschieben wird zum Problem-Fall. Der Papierkorb im Client entsprach leider nicht dem des Exchange-Servers. Und wenn man eine Mail wirklich löscht, so ist sie auf dem Server noch im Papierkorb. Super. Nach einem halben Jahr Evolution hatte ich dort zig tausend Mails rumliegen. Beim Ordner “Gesendet” ebenso. Es kann auch vorkommen, dass solche Vorgänge wegen Timeouts nicht durchgeführt werden. Dazu Ärger beim Annehmen und Aufsetzen von Terminen.

Da frage ich, was ist aus dem früher so geilen Evolution geworden? Als es mit einer aufgeräumten Tagesübersicht den Benutzer begrüßte? Da war ich zwar auch schon kmail-Nutzer, allerdings zollte ich vor Evolution Respekt. Naja, kmail oder Evolution: Irgendwie ist die “saubere” Auftrennung von I/O-Mappern, Service-Diensten und User-Interfaces nicht immer zugunsten der Benutzbarkeit ausgefallen. Wird ja vielleicht mal wieder.

Die Sicherheit eines Browsers sehe ich vor allem in zwei Bereichen:

1. Sicherheit gegenüber der Datenkrake (Browser-Hersteller überwacht Benutzer)
2. Sicherheit gegenüber einem oder mehreren Webservern (der Browser ist für Angriffe anfällig)

Sicherheit gegen eine permanente Überwachung

Zum 1. Punkt gab es in Version 5.0 insgesamt nur wenige Häkchen, die meines Erachtens dazu führten, dass der Benutzer irgendwie stetig unter Kontrolle stand: “Vorschläge für Navigationsfehler anzeigen”, “Phishing- und Malware-Schutz aktivieren” und “Helfen Sie mit, Google Chrome zu verbessern…Nutzungsstatistken…”. Diese Punkte standen recht offenkundig im Optionen-Menü und ließen sich schnell deaktivieren. Neben diesen Punkten sollte Google in keinem Falle nach Hause gefunkt haben. Sportliche Netzwerker würden hier, weil Google eben auch stark im Verdacht stand, sicherlich schon das ein oder andere Sniffing-Tool mitlaufen lassen haben. Bei positivem Test hätte es definitiv auch schon Aufruhr gegeben. Ich denke auch, dass sich Google im umstrittenen Browser-Gefecht solche gern aufgegriffenen Gegenargumente ersparen möchte, wenn Chrome sich langfristig etablieren soll.

Firefox ist an dieser Stelle übrigens nicht ganz so transparent: Zunächst muss man die versteckten Config-Einstellungen erst einmal finden: Man gibt hierfür in die Browser-Zeile “about:config” ein und bestätigt eine Warnmeldung “Blabla, ich bin nun selbst verantworlich…blabla…” und schließelich sucht man nach dem Schlüssel “safebrowsing.enabled” und schaltet diesen auf “false”.

In Alu-Version 6.0 sind noch diverse andere Optionen hinzugekommen. Unter anderem lässt sich nun das Verhalten bei Drittcookies steuern, welches ich dringend empfehle auf “keine Website” zu setzen. Denn auch Drittanbieter-Cookies führen zu einer schleichenden Dauerüberwachung. Ganz klar natürlich, wer sich Browser-Toolbars von Yahoo! oder Google installiert, der ist auf jeden Fall in “sicheren Händen”.

Neu in Version 6.0 ist die Autofill-Funktion. Hier kann man seine persönlichen Daten wie Adresse und Kreditkarten-Informationen fest im Browser hinterlegen. Auf Seiten mit entsprechend ausgestatteten Eingabefeldern kann Google Chrome dann diese zum Ausfüllen benutzen. Naja, wer’s braucht.

Sicherheit gegen Angriffe

Zur Sicherheit des Browsers gegenüber einem Webserver gilt zunächst, dass Google Chrome die Webkit-Engine nutzt und damit ein ausgereiftes Rendering anbietet. Daneben läuft jedes Tab in einem eigenen Prozess und kann daher den Browser oder andere Tabs nicht zum Absturz bringen. Das ist gut und trägt entscheidend zu einem sicheren Surfen bei. Obgleich nicht kommuniziert, hoffe ich, dass somit auch diverse Informationen eines Tabs aus einem anderen auf keinen Fall sichtbar sind.

Natürlich machen auch Google-Programmierer Fehler. Chrome als junges Produkt hat mit Sicherheit eine Menge Bugs im Quellcode versteckt. In den letzten Wochen fiel Google jedoch mit schnellen Bugfixes auf, ebenso sind Updates über das Repository sehr zeitnah im Umlauf. Da kann sich das Firefox (Iceweasel)-Team von Debian noch eine Scheibe abschneiden. Allerdings kennzeichnet Google den Chrome noch als Beta.

Die Java-Script-Engine V8 des Chrome ist sehr, sehr schnell. Für den Vergleich mit Firefox (lame!) nehme ich gern die Seite htmlspecialchars von PHP unter die Lupe. Ein Umschalten zwischen verschiedenen Tabs ist wie der Unterschied zwischen Tag und Nacht. Doch obgleich diese hohe Geschwindigkeit wirklich gut für ein angenehmes Arbeiten ist, habe ich hier die größten Bedenken. Werden genügend Bedingungen geprüft? Ist das Datenmodell ordentlich gekapselt oder eher auf Geschwindigkeit getrimmt?

Fazit

Google Chrome ist per se nicht unsicherer als andere Browser. Im Gegenteil: Durch das Auftrennen der Tab-Prozesse sollte sich das grundlegende Sicherheitslevel erhöht haben. Und wer die Optionen nicht sorglos wählt, darf davon ausgehen, seine Privatsphäre gegenüber dem Hersteller zu beschützen. Geschraubt haben der Riese auf jeden Fall an der Performance – die ist vorbildlich, und mir kommt es so vor, als ob 6.0 noch ein Zacken schneller startet als die 5.0. Dennoch ist Chrome noch Beta-Ware, und im jugendlichen Code werden im Laufe der Jahre garantiert eine Menge Lücken sichtbar werden. Auf Chrome’s Javascript werden wir meines Erachtens auf jeden Fall noch viele erfolgreiche Angriffe sehen. Ich hoffe, Google bleibt weiterhin ein fixer Bugfixer.

Profitieren von Web-Sockets werden in erster Linie Anwendungen mit Echtzeit-Charakter: Online-Kooperations-Software wie Google Docs oder Chat-Systeme, die eben im Sande verlaufene Google Wave könnte ebenso wieder auferstehen, und Online Games könnten schneller, aber schlanker werden. Denn der Browser muss für die Aktualisierung nicht ständig den Server befragen, ob es neue Daten gibt: Sobald diese da sind, kann der Server diese dem Client nachsenden.

Das ist eine ganz andere Art HTTP, als wir sie bisher kennen, aber es ist eine coole und smarte Art. Ich habe mal für einen Automobilkonzern in einem Software-Projekt gearbeitet, wo es um eine Dokumentation von Fahrzeugstrukturen ging. Durch die Tiefe der Strukturen (Module, Stücklisten, Assemblys) konnte praktisch ständig mit einer Änderung gerechnet werden. Hier hätte die Software auf Basis eines Web-Clients wohl nur noch gepingt und geflackert. Mit einem PUSH-Modus wäre ein Web-Client als Implementationsplattform viel attraktiver gewesen (als es dieses komische Enterprise Java anscheinend war ), und man hätte viele geniale und interaktive Dinge damit machen können.

HTML/HTTP als Entwicklungsplattform

Neben diesem Aspekt gewinnt HTML/HTTP als Implementationsplattform noch an einer anderen Stelle gegenüber “herkömmlichen” Widget-Sets an Charme: Die Standardisierung ist hier etwas ganz einzigartiges. Es gibt für kein Widget-Set der Welt eine internationale Norm: Weder für GTK+, noch für Qt, MFC oder ein anderes Framework. HTML als grafische Benutzer-Schnittstelle ist dabei nicht nur menschenlesbar (und damit im Fehlerfall vom Benutzer debugfähig und interpretierbar), es ist zum anderen auch komplett plattform-neutral, portabel und durch ein unabhängiges Gremium standardisiert.

Man kann also die Rendering Software (den Browser) ebenso wechseln wie die Maschine, dessen OS, Standort oder IP.  Ebenso lassen sich durch die flexible Architektur Inhalte für verschiedene Geräte unterschiedlich aufbereiten und sogar während der Benutzer-Sitzung anders implementieren, ohne dass die Software (was in diesem Fall eine Session wäre), neu gestartet werden muss. Insofern muss ich mal eine ganz dicke Lanze für HTML/HTTP für die Applikationsentwicklung brechen.

Rapid Prototyping, Internationalisierung et cetera – all inclusive

Ebenso unterstützt HTML/HTTP das Design-Prinzip Rapid Prototyping, und für verschiedene Layer wie Persistenz-Schicht, Models, Controller oder Views einer klassischen Programmierersicht gibt es diverse Hilfsmittel. Je nach dem, wie man arbeiten möchte, kann man von den Models automatisch Views und Persistenzen erzeugen lassen, wie auch andersherum. Mit Java, ASP, PHP oder Perl (und sogar C++) stehen dem Entwickler diverse Sprachen zur Verfügung, während dies für den Benutzer absolut transparent bleibt. Man könnte sogar einige Module in Perl, andere in Java oder ASP umsetzen. Neben einem Mini-System lässt sich die Applikation dann a) super-easy “deployen” – dieser Schritt entfiele ja fast – aber auch ebensogut horizontal skalieren, wenn die Benutzerzahl ansteigt.

Die Internationalisierung von Applikationen gestaltet sich besonders einfach, wobei der Browser mit Accept-Headern als Mittler zwischen Benutzer und dessen Sprachauswahl dient. Diverse andere Vorzüge, die mir dazu noch einfallen (Trennung von HTML, CSS und Javscript, der Rechner müllt nicht mit der Benutzer-Konfig zu, man braucht keine Installation, zentralisierte Datenspeicherung, etc.) lassen HTML/HTTP gegenüber anderen GUI-Frameworks immer öfter den Vorzug geben. Und schließlich kommen nun noch Web-Sockets um die Ecke und lassen das HTTP-Protokoll noch einmal kräftig zulegen.

Meiner Meinung nach läuten die Glocken ganz, ganz deutlich: Wer interaktive Applikationen schreibt, sollte ganz offensichtlich eine Online-Implementierung abwägen. Ich freue mich jetzt schon auf diverse neue Spielwiesen, die dabei entstehen werden.

Gratulation an dieser Stelle an die Perl-Gurus, die sich unter anderem mit neuen OOP-Features auf unbekannte Wiesen und Felder begeben können…ich wünsche auf jeden viel Spaß beim Coden.

PS: Ich bin mir ganz sicher: Eines Tages werden außerirdische Archäologen Perl-Code finden und ihn für prähistorische Hieroglyphen halten!

wir feiern heute wieder den System Administrator Appreciation Day. In diesem Sinne wünsche ich allen Linux-Administratoren alles Gute und immer kühle Nerven und Serverräume! Möge die Crontab mit Euch sein! (Die anderen haben ja ihre Turnschuhe ).

PS: Bitte diese Meldung weiter verbreiten!

* alternativer deutscher Pressedienst