Zusammenprall der Welten

Tatsächlich leidet unter diesem Zusammenprall der Welten Google mit seinem Betriebssystem Android am meisten. Android hat einen vergleichsweise hohen Entwicklungsschub, was für Google typisch ist. Wird in ein Produkt von Google Energie hineingesetzt, dann hochkonzentriert und stark. Das ist für einen Software-Hersteller natürlich kein so wirklich großes Problem, denn Software-Herstellung verläuft deutlich weniger “schweinezyklisch”, wie Hardware-Herstellung. Ist ein Bug in der Software, wird er eben gefixt. Das Internet unterstützt dieses Paradigma zudem. Ein Software-Update ist heute – wenn überhaupt – nur noch einen Klick weit entfernt.

In Sachen Hardware-Fertigung sieht das alles noch ganz anders aus. Planung, Entwicklung, Kalkulation, Fertigung, Verkauf, Distribution sind alles Dinge, die aufeinander aufbauen, gehörige Vorbereitungen und gewaltigen Einsatz in Sachen Finanzierung und Personal bedeuten und jeder Schritt muss passen. Die Software des Smartphones ist der Teil eines solchen Spektakels, mit dem der Endanwender am meisten Spaß oder Ärger hat, dementsprechend konservativ gehen Hardware-Hersteller mit diesem Thema um. Diese konservative Vorgehensweise der Hardware-Hersteller ist dann auch das zentrale Problem von Android, denn es gibt keinen einheitlichen Rollout einer Android-Version. Und noch viel schlimmer ist, dass Interimsversionen, die vornehmlich Bugfixing als Ziel haben, ebenfalls teilweise stark verzögert auf Smartphones landen – wenn überhaupt.

Auch wenn die Android-Entwicklung und spätere Anpassung auf Smartphones eine Geschichte ist, die man eben nicht mal so nebenbei erledigt: Der Konsument hat dafür immer weniger Verständnis und so bald sich der (gern subjektive) Eindruck breitmacht, dass ein Mobiltelefon in Sachen Software nicht gut gepflegt ist, ist der Wechsel zu einem anderen Mobiltelefon tatsächlich nicht mehr weit. Und noch viel schlimmer: Hat sich so ein Eindruck beim Endkunden manifestiert, ist nicht nur der Smartphone-Hersteller in seinem Ruf hier beschädigt, sondern auch gleich noch Android.

Apple, ja Apple

Besitzer von iPod, iPhone und iPad sind es gewohnt, in regelmäßigen Abständen Firmware-Updates zu bekommen, die allesamt sitzen und praktisch keine Kompatibilitätsprobleme aufweisen. Das ist auch verhältnismäßig einfach zu bewerkstelligen, denn Apple baut hier eine Software auf die eigene Hardware und hat von der Hardware auch verhältnismäßig wenig Versionen zu berücksichtigen.

Aber auch hier gilt die 1.000-Tage-Regel und spätestens nach dem letzten Update der Firmware beginnt ein Smartphone, an Nutzen zu verlieren. Immer mehr Hersteller von Apps berücksichtigen alte Firmware-Versionen nicht mehr und von weiteren Entwicklungen sind natürlich auch die hauseigenen Apps wie Webbrowser und Mail-Programm betroffen. Damit könnte man ja noch leben, aber das größte Problem bei so einem definierten Ende des Produktzyklus sind später entdeckte Fehler und Bugs. Die fixt für so abgekündigte Produkte natürlich auch keiner mehr. Lost in Translation.

Entkoppelung von Hard- und Software

Wäre es nicht schön, wenn es mir egal sein könnte, ob Samsung für mein wunderbares Galaxy S2 zukünftig Softwareupdates liefert oder nicht? Immer ein Smartphone zu haben, das eine aktuelle Software so lange einsetzt, wie ich das möchte, unabhängig davon, ob Samsung nun den Support einstellt oder nicht? Traum? Ich persönlich glaube, dass die Zeiten der Koppelung von Hard- und Software auf Smartphones zukünftig eher Ausnahmen sein werden. Okay, Apple wird sich aus religiösen Gründen nicht davon trennen (können), die Software-Entwicklung aus der Hand zu geben, aber alle anderen Smartphone-Hersteller, die kein eigenes Betriebssystem einsetzen? Ein Traum, ein Smartphone mit entkoppelter Hard- und Software zu haben?

Nein, kein Traum, sondern Realität. Und wenn man es genau nimmt: Schon seit Jahren.

“Firmware-Cooking”

Dass bei Smartphones Software immer der Hardware hinterherhinkt, ist kein Phänomen, das erst mit Android auf die Welt kam. Windows Mobile hat daran in seiner Inkarnation in Version 5 und 6 ständig gekrankt. Der Hauptgrund war, dass Windows Mobile in Version 5 und 6 zwar ein leistungsfähiges, aber ein hoffnungslos veraltetes Betriebssystem war und quasi alles, was machbar war, dadurch verhagelte, dass es nur schwer zu bedienen war. Dazu kam ab Version 6 die aufkommende Touch-Bedienung, die vornehmlich HTC mit Windows Mobile zu implementieren versuchte und dazu eigene Software-Module beisteuern musste. So entstanden zwar hardware-technisch recht ausgereifte Geräte, die jedoch durch Windows Mobile unglaublich katastrophal zu bedienen waren.

Schon zu dieser Zeit, wir schreiben da den Zeitraum von 2005 bis 2007, gab es Menschen, die “eigene” Firmware-Pakete “kochten”. Dazu nahmen sie bestehende Update-Pakete, extrahierten daraus die Treiber und gerätespezifischen Anpassungen und backten diese in offizielle Windows-Mobile-Distributionen ein. Natürlich alles hochgradig illegal und oft auch in zweifelhafter Qualität, aber Microsoft verstand bemerkenswert gut, dass diese halblegal-illegale Subwelt gar nicht schlecht war, denn immerhin benutzten sie Windows Mobile und kauften solche Geräte auch, so dass die Betriebssystemabgabe schon beim Kauf des Gerätes geleistet wurde. Die ganzen Köche, die in ihrer Freizeit Firmwares auf Basis von Windows Mobile backten, bekamen auffällig wenig Ärger von Microsoft und wurden, glaubt man Gerüchten, teilweise sogar direkt von Microsoft mit Insiderinformationen und internen Dokumentationen versorgt, um etwaige Fehler in der Do-it-yourself-Firmware auszumerzen.

Wenn man will, war dieses Hobbykochen der erste Schritt zu dem, wie ich mir die Smartphone-Welt zukünftig vorstelle.

Firmware als Abo-Modell

Ich bin inzwischen überzeugt davon, dass der Versuch von Smartphone-Herstellens, Hard- und Software weiterhin aus einer Hand anzubieten, zukünftig immer weniger funktionieren wird. Schon heute ist der Produktezyklus sehr hoch und während heute ein Hersteller ein Smartphone einer bestimmten Preisklasse neu verkauft, ist die nächste Generation in der konkreten Entwicklung und die übernächste in der Planung. Und auch schon heute kommt die Software-Entwicklung kaum noch nach, so dass die ersten Versionen einer Firmware oft genug noch Beta sind, wenn man sie knallhart nach gängigen Qualitätssicherungskriterien bewerten würde.

Im Gegenzug könnten sich Hersteller von Smartphones, wenn sie sich nur noch auf Hardware beschränken würden, wieder auf das beschränken, was sie eigentlich wirklich gut können – gute Hardware bauen. Vernünftige, ausgewogene Leistungsdaten und durchdachte Schnittstellen, sowohl zur Firmware, als eben auch über die Bedienelemente zum Benutzer.

Die Software wiederum ist in einem Abo-Modell bestens aufgehoben. Wer eine Basis-Firmware braucht, dem genügt vielleicht schon eine ganz einfache Firmware, die weitgehend nur das Telefonieren ermöglicht. Wer Wert auf ausgefeilte Funktionen und Feintuning legt, wird sich am ehesten auch darauf einlassen, für so eine Firmware Geld auf den Tisch zu legen, wenn denn eben auch sichergestellt ist, dass die Software mit dem Gerät funktioniert und im Idealfall auch harmoniert.

Utopie? Schwer zu sagen. Es müsste einfach mal ein Hersteller offensiv probieren. Dass man sich in der Hardware-Welt dem Thema nicht verschließt, beweisen SonyEricsson und Samsung, die dem bemerkenswerten CyanogenMod-Projekt, das für viele Geräte eine ausgereifte Android-Distribution zur Verfügung stellt, die jeweils aktuellen Smartphones zu Entwicklungszwecken zur Verfügung stellt. Der nächste, konsequente Schritt wäre die Monetarisierung eines solchen Vertriebsmodells als Firmware-Abo. Wer sich da als erster traut, wird – meiner Meinung nach – nicht enttäuscht werden.

• 

Das Ergebnis auf beiden Plattformen ist dementsprechend desolat: Es blühen die Todo-Anwendungen von Drittanbietern und sie blühen in der Regel mehr schlecht als recht. Die eine Gruppe an solchen Apps macht es mit der Verwaltung entweder zu einfach oder viel zu kompliziert, die meisten Apps synchronisieren mit keinem gängigen Dienst und die wenigsten Apps sind kostenlos und im Gegenzug dafür sogar richtig unverschämt teuer. ToDo-Verwalten für 5 oder gar mehr Euro?

Meine private und geschäftliche ToDo-Verwaltung läuft unter Google Tasks, das von Google bis vor kurzem noch ziemlich stiefmütterlich behandelt wurde, inzwischen aber sogar eine offizielle API hat. Wenn man mit dem Umstand lebt, dass Google Tasks kein eigenes Webinterface hat und derzeit nur via Google Mail oder über ein Widget in iGoogle bedienbar ist, kann man damit ganz gut leben. Seine Klasse spielt Google Tasks schon allein dadurch aus, dass es extrem simpel ist und die Verschachtelung von Aufgaben einfach dadurch realisiert, in dem Aufgaben einfach “unter” bestehende Aufgaben geschoben werden und mit frei definierbaren Aufgabenkategorien gearbeitet werden kann. An umfangreiche Priorisierungen hat man einfach keinen Gedanken verschwendet, das realisiert man einfach durch das Verschieben von Aufgaben nach oben oder nach unten oder vergibt Aufgaben einen festen Fälligkeitstermin. So einfach kann es gehen.

Wenn man Google Tasks mit einer iOS- oder Android-App synchronisieren will, fällt glücklicherweise der größte Teil der ToDo-Apps gleich durchs Raster – die meisten nutzen Google Tasks nicht zum synchronisieren. Das macht die Auswahl dann auch gleich leichter. Gelandet bin ich dann bei zwei Apps namens “GoTasks”. Witzigerweise heißt nämlich die beste App für die Synchronisierung von Google Tasks für iOS genauso wie die App für Android, obwohl beide Apps miteinander nichts zu tun haben und jede App von einem anderen Programmierer gepflegt wird, die dann wiederum aber beides Russen sind. Zufälle.

Beide Apps kosten nichts, beide sind werbefrei, beide funktionieren sowohl auf Smartphones, als auch auf Tablets und beide funktionieren zuverlässig, auch mit Google-Apps-Konten:

• GoTasks für Android von Vadim Milyukov
• GoTasks für iPhone/iPad von Evgeniy Shurakov

Einen kleinen Wermutstropfen gibt es lediglich für GoTasks für Android: Offenbar lässt sich die App nicht auf allen Android-Gerätschaften finden. Auf meinem Samsung Galaxy S2 mit Android 2.3.4 ist es nicht auffindbar und im Web-Market wird angezeigt, dass mein Gerät nicht kompatibel sei. Es funktioniert aber, wenn man die App schon vorher installiert hat, sie ist also soweit kompatibel. Falls jemand mit Android die App nicht findet, bitte einfach mal kurz melden.

• 

(Gleich eine Vorwarnung an den geneigten Leser: Ein technischer, spezieller Artikel zu Google Apps und E-Mail-Migration. Darf man gern bis zum Ende lesen, wenn man sich dafür interessiert, muss man aber nicht, wenn nicht. )

Nachdem ich nach RSS-Reader, Kalender und Kontaktedatenbank alle mir wichtigen Organisationsdinge in die “Cloud” bei Google eingebracht habe und das alles sogar zuverlässig mit dem iPhone synchronisiert, war es nun mehr als notwendig, dass das älteste Relikt meiner Online-Identität diesen Weg ebenfalls geht – die gute, alte E-Mail.

Bis dato habe ich E-Mails per IMAP abgerufen, sowohl auf dem PC, als auch auf dem Notebook und dem iPhone. Das ist insofern praktisch und brauchbar, weil ich E-Mails nicht überall herunterladen muss, sondern quasi in die Mailbox hineinschauen kann. Wirklich heruntergeladen habe ich E-Mails traditionell immer nur am heimischen PC, auf dem ich dann alle ein- und ausgehenden E-Mails nach Jahrgängen archiviert. Technisch also alles kein Problem. Allerdings organisationstechnisch.Das Problem ist nämlich immer wieder, dass ich am Notebook auf ältere E-Mails zurückgreifen müsste, das aber nicht kann, weil die eben auf dem PC liegen. Sicherlich, ich kann den PC per Wake-on-LAN hochfahren, mich remote einloggen und das tun, was getan werden muss, aber es ist umständlich.

Ein zusätzliches Thema bei einer Migration: Der Umfang meiner Mailarchive. Die gehen zurück bis 1997, enthalten rund 45.000 E-Mails und belegen knapp einen Gigabyte an Speicherplatz. Früher einmal war das eine Herausforderung, heute ist das eher eine Bürde. Denn 1 Gigabyte lässt sich in jeder modernen Festplatte bequem einbunkern, allerdings hat das Archivieren solcher E-Mail-Berge ganz andere Anforderungen: Lesbarkeit der Archive, Durchsuchbarkeit und vor allem Datensicherung. Ich schlenkere Mailarchive auf meiner normalen Festplatte herum, auf meiner NAS und sicherheitshalber nochmal auf einem externen Datenträger. Das ist alles schön und gut, aber im Cloud-Zeitalter einfach Käse.

Google Apps als Lösung.

Der Einsatz von Google Apps war schon seit langem eine Überlegung und wurde jetzt einfach dringend notwendig. Die Gründe dafür liegen auf der Hand: Google ist zuverlässig, Google ist flott, Google hat alle notwendigen Dienste und Google Apps kostet mich für meinen Bedarf nichts. Tatsächlich: Nichts. Denn Google Apps ist in der Basisfassung mit 10 (bis Ende der ersten Maiwoche noch 50) User-Accounts und jeweils 7 GB (anwachsendem) Speicherplatz kostenlos. Also: Tun!

Die zentrale Entscheidung ist erst einmal, zwischen dem kostenpflichtigen “Google Apps for Business” und dem einfachen “Google Apps” zu unterscheiden. Der Link hier führt zur kostenlosen Version. Dort geht es dann mit einem Klick auf den Erste-Schritte-Buttons sogleich los.

Neben den Kontaktdaten (das kann eine Firma sein, aber eben auch eine Einzelperson) sind vor allem zwei Dinge wichtig. Die Domain, unter der man später Mailadressen einrichten möchte und die Anlage eines neuen Google-Accounts. Es ist dabei tatsächlich ein neuer Google-Account notwendig, bestehende Google-Accounts können aus administrativen Gründen nicht benutzt werden. Und hier gibt es in vielen Fällen auch schon ein Problem, wenn nämlich die gewünschte Adresse für diesen neu einzurichtenden Google-Account schon für den bisherigen genutzt wird. Ist das der Fall, muss tatsächlich für den bisherigen Google Account eine andere Mailadresse gewählt werden, um die entsprechende Adresse dann für den neu einzurichtenden Google-Account zu nutzen.

Exkurs: Ein Google-Account oder lieber zwei?

Auch eine Sache, die man sich vorher überlegen muss: Nutzt man bereits Google-Dienste und möchte diese aus bestimmten Gründen weiterhin auf dem bisherigen Google-Account beibehalten (was Sinn machen kann, wenn man z.B. den Google-Apps-Account geschäftlich nutzen möchte), gibt es die Möglichkeit, sich mehrfach einloggen zu können. Aktiviert man diese Möglichkeit im bisherigen Google-Account, kann man sich demzufolge mit einem weiteren Google-Account einloggen und hat dann rechts oben im Browserfenster, dort wo die Mailadresse steht, mit der man aktuell eingeloggt ist, die Möglichkeit, schnell per Auswahl den anderen Account auszuwählen. Funktioniert nach meinem Test in vielen Google-Diensten, aber leider nicht in allen. Es macht also Sinn, sich ggf. tatsächlich über eine vollständige Migration der wichtigsten Dienste Gedanken zu machen, ganz unten gibt es einige Gedanken dazu.

Das Dashboard.

Zugegeben – wer es bisher gewohnt ist, dass Google-Dienste absolut einfach sind und ohne Denken funktionieren, der könnte bei Google Apps enttäuscht werden, denn es ist Mitarbeit gefragt. Benutzer müssen angelegt werden (natürlich nur, wenn man mehr als einen Benutzer einrichten möchte), und später muss für die Domain, die man für Mails nutzen möchte, auch die MX-Einträge geändert werden. Das ist nicht jedermanns Sache und die Google-Hilfe ist, sagen wir mal so, ausbaufähig. Der Hilfe-Assistent ist soweit brauchbar, allerdings muss man wissen, was man tut und das DNS sollte man auch kennen. Und leider muss man bei vielen Hilfe-Themen auf englischsprachige Artikel zurückgreifen, weil es an vielen Stellen keine deutsche Übersetzungen gibt.

Ansonsten, wenn es um einen einzigen Benutzer geht, sind die Einstellungen soweit schon mal brauchbar.

In Sachen Migration übrigens eine Empfehlung: Ruhig mal anfangen, sich in Google Apps umzuschauen, ohne gleich die eigene Domain auf Google Apps zu drehen. Das ist erst dann erforderlich, wenn man auch tatsächlich E-Mails dort live empfangen möchte. Zum Umschauen ist das noch nicht notwendig und auch noch nicht dann, wenn man Mailarchive importieren möchte. Und wer unbedingt schon mal den Empfang testen möchte, kann auf die segensreiche Möglichkeit der Test-Domain zurückgreifen, die Google Apps bei der Einrichtung automatisch anlegt (ist dann im Dashboard genau beschrieben).

Mail in Google Apps.

Wer bisher schon Google Mail genutzt hat, wird den Mail-Client kennen, denn es ist das Google-Mail-Frontend. Und Google Mail besitzt bekanntlicherweise auch eine Möglichkeit, per IMAP-Protokoll kontaktiert zu werden, so dass über diesen Weg auch bestehende Mailarchive importiert werden können (IMAP-Einstellungen gibt es in der Hilfe). Für die Outlook-Benutzer gibt es übrigens den angenehmen Nebeneffekt, dass es hier einen eigenen Importer gibt und auch der Import von PST-Postfachdateien funktioniert. Alle anderen Mailbenutzer müssen, wenn sie Mailarchive importieren möchten, den Weg über IMAP gehen.

Der IMAP-Transfer funktioniert, ist allerdings langsam. Sehr langsam. Für rund 75 % meiner Mails – das sind bis jetzt rund 35.000 E-Mails – habe ich rund 10 Stunden gebraucht und es sei angemerkt, dass das nur rund 250 MB Datentransfer war! Der Import größere Mailarchive ist also eine sehr zeitintensive Geschichte und es macht Sinn, durchaus zu überlegen, ob man wirklich alle E-Mails importiert haben möchte.

Ansonsten bietet IMAP alle Annehmlichkeiten, die man beim Archivieren haben kann, vor allem nämlich die Anlage von Unterordnern. Ich habe dazu im Archiv meines Postfaches einfach Unterordner mit der entsprechenden Jahreszahl angelegt und darin jeweils einen Ordner für Posteingang, Postausgang und jeweils für Mailinglisten. In die habe ich dann die entsprechenden Mails aus meinen Mailarchiven kopiert.

Im Google-Mail-Frontend, das bekanntlicherweise nicht mit Ordnern, sondern mit so genannten Labels arbeitet, erscheinen diese Unterordner dann alle im Format “Archiv/(Jahreszahl)/Eingang” und sind in der Label-Ansicht auch nicht verschachtelt, da Labels nicht verschachtelt werden können. Aus der Navigationsansicht bekommt man die vielen Labels übrigens problemlos ausgeblendet, dazu einfach den Link “Labels verwalten” anklicken und ausblenden.

Und noch eine Eigenart, die das Labeling mitbringt: Vorsicht mit der Möglichkeit, Mails mit mehreren Labeln zu versehen. Die erscheinen dann nämlich in der IMAP-Ansicht tatsächlich in den entsprechenden Ordnern mehrfach. Und auch Vorsicht mit E-Mails, die gar kein Label besitzen, wie sie normalerweise im Posteingang nach dem Empfang erscheinen. Die kann man zwar problemlos mit Labels versehen – nur wenn man das nicht macht, wird man sie, wenn man sie wegsortiert, kaum mehr finden, da Google Mail zwar eine Suchfunktion für Mails mit Labels bietet, dummerweise aber kein Suchkriterium kennt, um Mails zu finden, die kein Label tragen.

Empfehlung meinerseits, von einem alten Backup-Hasen: Do not delete your Backup. Auch wenn der Import der Mailarchive funktioniert, sollte man seine lokalen Mailarchive nicht löschen. Vielleicht gefällt einem Google Apps nicht, vielleicht geht etwas beim Import schief, vielleicht löscht man aus Versehen ein Verzeichnis in der Cloud (was wirklich Datenverlust bedeutet) und da ist ein lokales Backup die beste und einzige Lebensversicherung. Ich habe es hiermit gesagt!

Migration des Google Reader, Google Calendar und Google Contacts

Bei der Migration von Google Diensten ist leider Handarbeit gefragt. Bei all diesen drei Diensten, die ich bisher einsetze, müssen die Inhalte jeweils im bisherigen Google-Account exportiert und im neuen Google-Account wieder importiert werden. Das ist insofern problemlos, allerdings gehen beim Google Reader die Trend-Informationen, die während der Nutzung des Google Readers entstehen, verloren, da diese nicht ex- bzw. importiert werden. Ärgerliches, kleines Manko.

Beim Google Calendar gibt es zudem noch Pflegeaufwand, wenn in einem Konto noch zusätzliche Kalender abonniert sind oder gemeinsame Kalender mit anderen Benutzern geführt wird. Hier macht es Sinn, im alten Google-Account zunächst die Mailadresse des neuen Google-Accounts hinzuzufügen und sich dann mit dem neuen Google-Account einzuloggen, um die gemeinsamen Kalender auch dort verfügbar zu haben.

Migration und externe Clients

Was man bei der Anlage eines neuen Google-Accounts und einer eventuellen Migration von Diensten auch berücksichtigen muss: Überall, wo man Google-Dienste bisher verwendet hat, müssen nun die neuen Google-Account-Daten hinterlegt werden, also z.B. auf Smartphone, iPad etc. und dort dann auch in eventuelle Apps, die Google-Dienste nutzen. Funktioniert hier zwar alles weitgehend reibungslos, ist aber auch Zeitaufwand.

• 

Was damals mangels vernünftiger Alternative ein Schritt war, war die Entscheidung auf ein Musikformat. MP3 fiel heraus, weil mich MP3 nie wirklich von der Klangqualität überzeugte (ja, ich habe tatsächlich einmal Unterschiede heraushören können) und so landete ich bei Windows Media Audio. Ein Schritt, den man bedauern kann. Nicht, weil das Format nicht hochklassig wäre – das ist es nämlich nach wie vor – sondern weil WMA ein Problem hat: Das Apple-Reich will das Format nicht kennen. Schick wäre es allerdings, Musik auf dem iPhone haben zu können, immerhin habe ich ja sowohl für die Musik, als auch für das iPhone Geld bezahlt.

Also wartete der Schritt eigentlich nur darauf, einen Formatewandel durchzuziehen. MP3 fiel weiterhin aus, aber MP4 alias AAC ist dann die Antwort. Das ist das Hausformat von iTunes und inzwischen auch vom Windows Media Player 11 unter Windows 7. AAC wird zwar aufgrund höherer Lizenzkosten bei weitem noch nicht von allen Musikabspielgeräten eingesetzt, aber darf man trotzdem AAC als potentiellen Nachfolger von MP3 nennen? Falls nicht, ist es mir auch egal.

Also durften die noch bei mir im Besitz befindlichen CD wieder eine Runde im PC drehen, um ihren Inhalt als M4A-Dateien auf meine NAS auszuwürgen. Kurzfristig vermisste ich dann mal ungefähr 70 Alben und begann, das Haus zu durchsuchen, bis mir schwante, dass diese 70 Alben vielleicht schon längst nicht mehr in meinem Besitz sind, was sie auch tatsächlich nicht mehr sind. Nennen wir es mal “natürlich Auslese”, die da im Laufe der Jahre passiert ist.

Nun also: M4A alias AAC. Versteht nach wie vor die PS3, versteht auch das iPhone, iTunes kann mit meiner Buffalo-NAS korrespondieren, auf der die Audiodateien liegen und der Windows Media Player auch. Die nächste Stufe kann kommen.

• 

Bei der Verfassung der Anleitung zum Synchronisieren des Google Calendar mit dem iPhone hat sich ursprünglich das Verhalten gezeigt, dass über dem offiziellen Verfahren namens “Google Sync” (das auf dem ActiveSync-Verfahren von Microsoft beruht) nur der Hauptkalender eines Google-Calendar-Accounts synchronisiert werden kann und offenbar nicht eventuell eingerichtete Sub-Kalender. Meine Alternative war die Anleitung zur Synchronisierung per CalDAV. Das funktioniert zwar, ist aber deutlich langsamer.

Nun, kurzum, es funktioniert doch mit Google Sync, wenn man sich von einer Fehlermeldung von Google, die auf einem simplen Sprachproblem basiert, nicht ins Boxhorn jagen lässt. Dementsprechend habe ich die Anleitungen auf Basis von Google Sync dementsprechend aktualisiert und der einzig wahre und perfekte Artikel ist folgender:

• Terminsynchronisation zwischen iPhone und Google Calendar.

Und wer es dann trotzdem noch per CalDAV machen möchte, weil er ActiveSync aus politischen Gründen nicht nutzen kann, nimmt halt diese Anleitung, die jetzt einen neuen Titel hat:

• Terminsynchronisation zwischen iPhone und Google Calendar via CalDAV.

Und wer beides nicht nutzt, also weder Google Calendar, noch iPhone, der kann trotzdem etwas per Flattr spenden, war nämlich alles richtig viel Dokumentationsarbeit. Alles nicht so einfach im Leben.

• 

So weit, so gut. Was mit größeren Gerätschaften funktioniert, funktionierte jedoch nicht mit der Fritzbox. Zwar konnte ich über den VPN-Tunnel mein Netzwerk erreichen, jedoch keinen Datenverkehr ins Internet routen. Das blockte die Fritzbox ab und das ließ sich auch mit einigem Gefrickel in der Konfiguration nicht ändern.

Um es kurz zu machen: Nun geht es! Mit dem Firmware-Update vom September 2010 wurde die VPN-Funktionalität offenbar entsprechend angepasst, so dass nach einer kleinen Änderung der VPN-Konfigurationsdatei, die für den Import in die Fritzbox bestimmt ist, die Fritzbox als Secure Gateway für VPN-Verbindungen von einem iPhone (und natürlich auch einem iPad) genutzt werden kann. Hier mal alles Notwendige Schritt für Schritt.

Schon eine VPN-Konfiguration auf der Fritzbox?

Dann bitte Vorsicht walten lassen, denn wenn jetzt die neu erstellte VPN-Konfigurationsdatei hochgeladen wird, werden alle bestehenden VPN-Konfigurationen entfernt. Wenn also eine bestehende VPN-Konfiguration vorhanden ist und die auch noch benötigt wird, dann müssen beide VPN-Konfigurationen in einer Datei zusammengeführt werden. Hier sollte bitte das oben genannte Programm “FRITZ!Fernzugang einrichten” zum grundlegenden Aufbau der VPN-Konfiguration eingesetzt werden, damit die Verschachtelung der einzelnen Konfigurationen korrekt bleibt. Die notwendigen Änderungen für die VPN-Verbindung des iPhone lässt sich dann immer noch nachträglich hinzufügen.

VPN-Konfiguration auf der Fritzbox

Die Fritzbox hat nach wie vor auf ihrer Benutzeroberfläche keine eigene Einstellungsmöglichkeiten für VPN-Verbindungen, diese müssen also weiterhin als VPN-Konfigurationsdatei importiert werden. Solche VPN-Konfigurationsdateien können mit einem kostenlosen Programm namens “FRITZ!Fernzugang einrichten” (gibt es bei AVM im Download-Bereich) erstellt werden. Da wir jedoch für die VPN-Geschichte vom iPhone die so erstellte VPN-Konfigurationsdatei sowieso nochmal anpassen müssen, hier eine VPN-Konfigurationsdatei in ganzer Länge zum Herauskopieren und Anpassen. Ist zwar nicht schön formatiert, erfüllt aber seinen Zweck. Einfach den folgenden eingerückten Teil in einen Texteditor kopieren. Infos zu den rot markierten Bereichen gibt es weiter unten:

vpncfg {
connections {
enabled = yes;
conn_type = conntype_user;
name = "Accountname";
always_renew = no;
reject_not_encrypted = no;
dont_filter_netbios = yes;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remoteip = 0.0.0.0;
remote_virtualip = 192.168.178.202;
remoteid {
key_id = "Accountname";
}
mode = phase1_mode_aggressive;
phase1ss = "all/all/all";
keytype = connkeytype_pre_shared;
key = "sharedsecret";
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = yes;
use_cfgmode = no;
xauth {
valid = yes;
username = "Accountname";
passwd = "Kennwort";
}
phase2localid {
ipnet {
ipaddr = 0.0.0.0;
mask = 0.0.0.0;
}
}
phase2remoteid {
ipaddr = 192.168.178.202;
}
phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
accesslist =
"permit ip any 192.168.178.202 255.255.255.255";
}
}

Zu den rot markierten Bereichen:

• “name” und “key_id”
  Ein beliebiger Accountname, der in beiden Feldern gleich lauten muss. Keine komplizierten Sonderzeichen oder Leerschritte.
• “remote_virtualip” und “ipaddr”
  Das ist die virtuelle IP-Adresse, unter der das iPhone (bzw. der VPN-Client) später im lokalen Netzwerk der Fritzbox erscheinen wird. Wenn das LAN mit den Netzwerk-Standardeinstellungen betrieben wird, nutzt die Fritzbox das Netzwerk 192.168.178.x und für VPN-Clients IP-Adressen ab 201. (In diesem Fall habe ich jetzt die 192.168.178.202 ausgewählt, weil ich noch eine weitere VPN-Konfiguration nutze, die hier nicht aufgeführt ist.)
• “key”
  Hier ist der Shared Secret für die IPSec-Verschlüsselung einzutragen. Prinzipiell gehen hier auch Sonderzeichen, es genügt jedoch eine Zeichenfolge mit Groß- und Kleinbuchstaben, sowie Ziffern. Da dieses Shared Secret später auf dem VPN-Client auch nur einmal eingegeben werden muss, darf es gern länger sein, bei mir sind es 16 Stellen.
• “username” und “passwd”
  Das sind Benutzername und Passwort für die zusätzliche XAUTH-Authentifizierung. Hier empfehle ich für “username” den oben schon festgelegten Accountnamen, für “passwd” ist ein Passwort empfehlenswert, das nicht das Shared Secret ist und immerhin so aufgebaut sein sollte, dass man es sich einfach merken kann, da dieses Passwort bei jedem VPN-Verbindungsaufbau – zumindest auf dem iPhone – eingegeben werden muss.
• “accesslist”
  Die Zeile mit dem rot markierten Eintrag ist eminent wichtig dafür, wie der ausgehende Datenverkehr des VPN-Clients auf der Fritzbox behandelt werden soll. Hier ist wichtig, dass die rot markierte IP-Adresse genau die gleiche Adresse ist, wie weiter oben bei “remote_virtualip” und “ipaddr” angegeben.

Alles angepasst? Dann die Datei mit beliebigem Dateinamen und der Dateiendung “.cfg” abspeichern und diese Datei in die Fritzbox importieren. Das passiert in der Rubrik “Internet” unter “Freigaben” und dort in der Registerkarte “VPN”. Der Importvorgang dauert einige Sekunden und quittiert dann entweder mit einem erfolgreichen oder erfolglosen Import. Ist er erfolglos, stimmt mit ziemlicher Sicherheit etwas am Aufbau der VPN-Konfiguration nicht.

VPN-Konfiguration auf dem iPhone

Die VPN-Konfiguration auf dem iPhone ist weit weniger kompliziert, als es klingt. Zu finden ist sie in den Einstellungen unter “Allgemein”, dort unter “Netzwerk” und dort wiederum unter “VPN”. Hier auf “VPN hinzufügen” tippen und den Button “IPSec” wählen. Es erscheint folgendes Fenster:

Auch hier kurz die einzelnen Punkt ausführlich:

• Beschreibung
  Die Beschreibung kann frei gewählt werden und dient lediglich zur Kennzeichnung der VPN-Verbindung auf dem iPhone.
• Server
  Hier kommt die Adresse hinein, unter der die Fritzbox im Internet zu erreichen ist. Wer eine feste IP-Adresse hat, kann entweder die IP-Adresse oder den Hostnamen angeben. Wer keine feste IP-Adresse hat, kann sich mit einem DynDNS-Dienst behelfen.( Ich setze dyndns.org ein, die dazugehörigen Daten können bequem in der Fritzbox hinterlegt werden, so dass die Fritzbox selbstständig dafür sorgt, bei einem DSL-Verbindungsneuaufbau auch den DynDNS-Eintrag zu aktualisieren.)
• Account
  Hier kommt der Accountname ein, der oben in der VPN-Konfiguration festgelegt wurde.
• Kennwort
  Und hier eben das oben festgelegte Kennwort (nicht das Shared Secret!) hinein, wenn nicht bei jedem Verbindungsaufbau neu nach dem Kennwort für die Verbindung gefragt werden soll. Ich empfehle, das Kennwort hier nicht zu hinterlegen, so wie ich es immer bei mobilen Geräten handhaben würde, die VPN-Verbindungen in Netzwerke aufbauen können sollen, die nicht von einem eigenen Administrator, der im Ernstfall schnell die VPN-Konfigurationen deaktivieren kann, gehostet werden.
• Zertifikat verwenden
  Ausgeschaltet lassen, wir verwenden kein Zertifikat.
• Gruppenname
  Hier auch einfach den Accountnamen eintippen.
• Shared Secret
  Und hier kommt das Shared Secret hinein.
• Proxy
  Auf “Aus” gestellt lassen, wir verwenden keinen Proxy.

Das war es. Einstellungen sichern und gut.

VPN aufbauen

Das VPN lässt sich in den iPhone-Einstellungen mit dem nun neu eingeblendeten VPN-Schieber starten. Einfach den Schieber aktivieren und schon wird versucht, den Tunnel zu öffnen. Wird der Tunnel zur Fritzbox etabliert, erscheint nach einigen Sekunden die Passwortabfrage. Glückt diese, erscheint in der Infozeile des iPhone ein winziges VPN-Symbol, gleichzeitig ist auf der Benutzeroberfläche die nun aktive VPN-Verbindung zu sehen.

Wer ein Jailbreak-iPhone besitzt und das höchst empfehlenswerte Programmpaket SBSettings installiert hat, um damit einige grundlegende Funktionen des iPhone schnell zu aktivieren, kann in Cydia noch das zusätzliche Paket “SBSettings VPN Toggle” installieren, das dann einen zusätzlichen Button für das Aktivieren/Deaktivieren der VPN-Verbindung zu SBSettings hinzufügt. Komfortabler geht es dann kaum noch.

Die üblichen Hinweise, Fragen und Antworten

• iPad?
  Gute Nachricht: Funktioniert im Prinzip genau so, wie auf dem iPhone und ist auch genau so zu konfigurieren.
• VPN-Passwörter auf mobilen Geräten
  Wie oben kurz angerissen: VPN-Passwörter gehören nicht auf mobile Geräte, auch wenn diese Sperrfunktionen haben. Mit dem Shared Secret geht es nicht anders, das Passwort für die zusätzliche XAUTH-Authentifizierung muss man jedoch wirklich nicht auf dem iPhone hinterlegen, sondern gibt das bei jedem Verbindungsaufbau ein. Grundsicherungsmaßnahme.
• Absicherung der Fritzbox
  Ein paar Dinge müssen auch einfach hier klar sein. Die Fritzbox braucht ein vernünftiges Passwort, ein eingerichtetes WLAN-Netzwerk sollte verschlüsselt mit WPA2 und einem hinreichend langen Key arbeiten und wenn man die Fritzbox-Bedienoberfläche für Fernzugriffe aus dem Internet aktiviert, dann bitteschön SSL gesichert und mit gesondertem HTTP-Zugriffspasswort. Ein sicheres VPN lebt davon, dass sowohl Client, als auch Server gesichert sind.
• Ist der Tunnel sicher?
  IPSec ist grundsätzlich state-of-the-art und eine aktuelle und weit verbreitete VPN-Tunneltechnologie. Welche Algorithmen tatsächlich eingesetzt werden, habe ich aktuell nicht parat, es dürfte sich jedoch um grundsätzlich starke Verschlüsselung handeln, die noch mit einer zusätzlichen Benutzerauthentifizierung (“XAUTH”) ergänzt wird. In Sachen Tunnel gilt: Aufgebaut wird der immer nur zwischen Client und Server, also in diesem Fall zwischen iPhone und Fritzbox. Wenn also nicht gerade jemand eine Man-in-the-middle-Attacke fährt und beispielsweise den Endpunkt so manipuliert, dass dieser nicht auf der heimischen Fritzbox endet, sondern auf einem anderen Gerät, ist man also weitgehend sicher davor, dass der Tunnel von Dritten abgehört werden kann – wenn eben die Schlüssel hinreichend komplex sind.
• Kann man dem VPN-Client auf dem iPhone trauen?
  Das ist eine gute Frage. Pardon, kann ich nicht beantworten. Zum einen, weil ich kein Verschlüsselungsspezialist bin und zum anderen, weil die iOS-Software des iPhone/iPad nicht öffentlich zur Evaluation zur Verfügung steht. Dass “Cisco” draufsteht, ist zumindest ein Zeichen dafür, dass es sich nicht um ganz namenlose Software handelt und da viele Unternehmen auf Cisco-Router und -Software schwören, kann man sich zumindest ein Stück weit darauf verlassen, dass es nicht ganz so üble Software sein dürfte. Für Paranoiker gilt jedoch auch hier, dass sowohl Apple, als auch Cisco eben US-amerikanische Unternehmen sind.
• Performance und Stromverbrauch
  Die Performance der Fritzbox ist für VPN-Verbindungen ausreichend, selbst mehrere VPN-Verbindungen bedient meine Fritzbox 7270 problemlos. Da sie eine ADSL-Fritzbox ist, ist die Limitierung des ADSL-Anschlusses vermutlich schneller erreicht, als die VPN-Verschlüsselungsperformance. Auf dem iPhone gilt das grundsätzlich auch, nur ist hier zu beachten, dass alles, was zusätzliche Performance braucht, Energie verbraucht und die muss man sich auf einem iPhone immer gut einteilen. Es macht also Sinn, das VPN immer dann einzusetzen, wenn man es auch zwingend braucht und das ist immer dann der Fall, wenn ein drahtloses Netzwerk unverschlüsselt sendet und die zu übertragene Kommunikation das ebenfalls ist. Nutzt man über das iPhone beispielsweise SSL-gesichertes Banking oder Mailkonten auf Basis von ActiveSync oder verschlüsseltem IMAP, dann sind diese Kommunikationskanäle bereits verschlüsselt. Ebenso unproblematisch ist so Kommunikation wie beispielsweise der eingebauten Wetter-App, die niemand wirklich verschlüsselt braucht. Sinnvoll ist VPN-Verschlüsselung spätestens dann, wenn Apps über API auf Dienste zugreifen und hier befürchtet werden muss, dass dies nicht über HTTPS gesichert läuft. Kaum eine Social-Networking-App tut das nämlich oder bietet hierzu Optionen an. Spätestens hier ist der VPN-Tunnel gefragt und die investierte Energie eine gute Anlage.

• 

Kleiner Hinweis am Rande: Am gestrigen Montag hat Google nach langer Zeit seine eigene iPhone-App aktualisiert, die nun den iPhone-eigenen Push-Dienst für Google Mail und Google Calendar unterstützt. Das funktioniert relativ simpel dadurch, in dem in der App die Zugangsdaten zum Google-Konto hinterlegt werden und die App dann im Hintergrund die Verbindung zur Google-Cloud hält und entsprechende Meldungen als Push-Meldung anzeigt.

Sinnvoll ist das selbstverständlich nur dann, wenn der Anwender Google Mail bzw. Calendar nicht über die iPhone-eigenen Borddienste synchronisiert. Tut man das, ruft also Google Mail über die iPhone-Mailwendung und/oder Google Calender über den iPhone-Kalender ab, braucht es keinen zusätzlichen Push über die Google-App.

Und weil es inzwischen recht komplex geworden ist, hier nochmal sorgfältig sortiert alle korrespondierenden Artikel im Blog zur Google-iPhone-Synchronisation:

• Terminsynchronisation zwischen iPhone und Google Calendar.
• Synchronisation mehrerer Kalender zwischen iPhone und Google Calendar.
• Synchronisation von Kontakten zwischen iPhone und Google Contacts.

• 

Es darf also wieder munter synchronisiert werden, wobei die Arbeit, jetzt mal alle Geburtstage manuell zu prüfen, erst anfängt. Man glaubt es nicht, was man für ein Geschäft mit Adressen und Kontaktdaten haben kann. Echt wahr.

• 

Nun eben nicht mehr, mit jailbreakme.com können alle Geräte mit installiertem iOS 4.0 (und auch 4.0.1) gejailbreaked werden. Und das mit einer Leichtigkeit, die jegliche Sicherheitskompetenz Apples in Schutt und Asche fallen lässt, denn dieser Jailbreak muss nicht umständlich über ein am Computer verkabeltes iPhone vorgenommen werden, sondern funktioniert rein im MobileSafari des iPhones. Einfach mit dem iPhone die obige Website aufrufen, den Schieber nach rechts schieben, warten und nach ein, zwei Minuten ist das iPhone gejailbreaked und Cydia installiert. So einfach war es noch nie.

Was man mit einem Jailbreak und mit Cydia alles machen kann, bleibt jedem selbst überlassen. Ich habe ein paar Anwendungen, die vorzüglich einige Designmängel und Steve-Jobs-Privatprobleme beheben… FiveIconDocks, SBSettings, PrivaCy etc. Vor einer Weile habe ich mal meine Top-7 gebloggt, die probiert aber jede auf eigene Gefahr aus (Backgrounder und SMS Helper kann man sich übrigens inzwischen sparen).

• 

Die Blog-Leser und Kommentatoren Steve und Benjamin haben mich zu meinen Artikel zur Einrichtung der Synchronisation von Kontakten zwischen iPhone und Google Contacts darauf hingewiesen, dass es offensichtlich einen bösen Bug gibt, den ich so auch nachvollziehen kann. Kurz umrissen:

Synchronisation zwischen iPhone und Google Contacts funktioniert. Auf dem iPhone wird eine Adresskarte geändert, beispielsweise eine neue Telefonnummer hinzugefügt. Nach dem Abspeichern synchronisiert das iPhone ordnungsgemäß via Google Sync mit Google Contacts. Nun ist jedoch bei Google Contacts das Geburtsdatum um einen Tag in die Vergangenheit verschoben. Auf dem iPhone scheint das Datum auch nach dem übernächsten Synchronisieren weiterhin korrekt zu bleiben.

Dummerweise kaskadiert das Problem jedoch, wenn nun jemand in Google Contacts die betroffene Adresskarte öffnet und dort in guter Absicht etwas an den hinterlegten Daten ändert und übersieht, dass das Geburtstagsdatum falsch ist. Denn speichert er die veränderte Adresskarte ab, wird das falsche Geburtstagsdatum natürlich auch abgespeichert und der Kontakt zur Synchronisation freigegeben, so dass die Adresskarte beim nächsten Synchronisieren die Inhalte auf dem iPhone überschreibt und das Geburtstagsdatum dann ebenfalls abändert. Wird nun danach auf dem iPhone die Adresskarte nochmals bearbeitet und wieder synchronisiert, schiebt sich das Geburtstagsdatum auf diese Weise Tag für Tag in die Vergangenheit.

Laut einem Thread in einem Google-Forum ist das Problem bekannt und wurde bereits für das iPhone-OS 3.0 gefixt, tauchte aber unter iOS 4.0 wieder auf. Im obigen Link, das auf den aktuellsten Teil des Threads führt, ist das Problem am 23. Juli 2010 auch für iOS 4.0 gefunden und wird im nächsten Update von Google Contacts gefixt. Wann das Update stattfinden wird, wird allerdings leider nicht gesagt.

Das Problem kann man so lange leider nur dadurch umgehen, in dem man bis auf weiteres konsequent darauf achtet, Kontakte nur auf dem iPhone anzulegen bzw. bestehende Kontakte auch nur dort abändert. Und für eine Übersicht über die bevorstehenden Geburtstage sollte man derzeit dann eben eher nicht auf Google Calendar vertrauen, sondern nur auf den Kalender im iPhone.

•