blog@netplanet

Seit einiger Zeit gibt es im Funktionsumfang von normalen Google-Konten einen kleinen Einschnitt in Sachen Funktionsumfang. Dieser Einschnitt betrifft die Synchronisation von Daten zwischen dem Google Kalender und Adressbuch zu iPhone und/oder iPad. Konnte man nämlich Kalender und Adressbuch bei allen Konten bis dato per ActiveSync synchronisieren (dass unter iOS “Microsoft Exchange” heißt und auf Seiten von Google “Google Sync”), so ist das seit 30. Januar 2013 nur noch für Google-Konten möglich, bei denen bis zu diesem Datum Google Sync mindestens einmal eingerichtet wurde. Mit allen Google-Konten, die nach dem 30. Januar 2013 mit iPhone/iPad Kontakte und Kalender synchronisieren sollen, ist dieser Weg nun versperrt.

Aber: Es gibt Alternativen. Und zwar sehr gute, weil nämlich mit offenen Protokollen.

Kalender synchronisieren

Dazu sei an dieser Stelle nicht viele Worte verloren, weil ich hierzu vor einiger Zeit schon mal einen sehr umfangreichen Artikel geschrieben habe, der den Installationsweg ausführlich beschreibt:

• Terminsynchronisation zwischen iPhone und Google Calendar via CalDAV.

Aber jetzt: Kontakte synchronisieren via CardDAV

Das CardDAV-Protokoll gehört ebenfalls zur Familie der WebDAV-Protokolle und ist speziell auf die Synchronisation von Kontaktdatenbanken ausgerichtet. Die Synchronisationsmechanismen sind dabei ähnlich zu CalDAV bei Kalendersynchronisationen, grundsätzlich ist CardDAV aber ein eigenes und auch relativ neues Protokoll. So neu, dass es beim iPhone bzw. im iOS-Betriebssystem von Anfang an gar nicht im Funktionsumfang war. Erst ab iOS 5 wurde CardDAV standardmäßig in iOS implementiert und ist seitdem auch verfügbar. Die Einrichtung einer CardDAV-Verbindung zum eigenen Google-Konto ist dabei relativ simpel und auf keinen Fall schwerer, als bisher mit Google Sync.

Der Startpunkt auf dem iPhone sind, wie immer, die Einstellungen und dort der Punkt “Mail, Kontakte, Kalender”. Hier geht es auf “Account hinzufügen …”. Der nächste Schirm zeigt die möglichen Synchronisationstechnologien dazu an:

Alle DAV-Protokolle finden sich im letzten Menüpunkt, der etwas stillos unter dem Wort “Andere” versteckt ist. Deshalb bitte hier drauf tippen, um zum nächsten Schirm zu kommen:

Hier geht es nun richtig los, unter “Kontakte” findet sich die Auswahlmöglichkeit zur Einrichtung eines CardDAV-Accounts. Bitte diesen Menüpunkt antippen und dann geht es schon darum, die eigenen Zugangsdaten zu hinterlegen:

Die vorzunehmenden Einstellungen sind weitgehend selbsterklärend, deshalb nur im Schnelldurchlauf:

• Account: Muss selbstverständlich aktiviert werden, hier lässt sich später aber dann auch vorübergehend die Synchronisation anhalten, falls das mal notwendig sein sollte.
• Server: Ist die Gegenstelle, mit dem das iPhone-Gerät Verbindung zur Synchronisation aufnehmen soll. Das ist tatsächlich einfach nur “google.com”.
• Benutzername: Das ist der Google-Kontoname, also im Normalfall die eigene Gmail- bzw. Googlemail-Adresse.
• Kennwort: Selbsterklärend.
• Beschreibung: Das ist eine Beschreibung, die frei gewählt werden kann. Bei mehreren konfigurierten Konten auf dem iOS-Gerät macht eine eindeutliche Beschreibung durchaus Sinn…

Wir gehen jetzt aber noch nicht zurück (und drücken natürlich auch nicht auf “Account löschen”), sondern wählen noch den Menüpunkt “Erweiterte Einstellungen” für einen Kontrollblick aus. Der dortige Schirm sieht folgendermaßen aus:

Hier geht es um die Verschlüsselung der CardDAV-Übertragung. SSL sollte hier aktiviert werden, der Standard-Port hierzu ist 443.

Nach dieser Überprüfung oben auf den Pfeil nach links “Google Contacts” (oder wie auch immer die Beschreibung lautet) tippen, um zum vorherigen Schirm zurückzukommen. Dort dann nochmal auf den an der gleichen Stelle positionierten Pfeil tippen, der da lautet “Zurück”. Danach geht es nämlich nicht sofort zurück, sondern dann wird zunächst der Account geprüft. Hat alles seine Ordnung, erscheinen hinter allen Eingabefeldern kleine Häkchen und der Synchronisationsaccount ist erfolgreich eingerichtet.

Bitte dann einfach wieder zurück auf den Home-Bildschirm und mit einem Tippser auf die Kontakte-App gleich mal austesten, ob nun die ersten Adressen aus dem Google-Konto – sofern dort welche hinterlegt sind – eintrudeln.

Der Weg der Synchronisation

Ein spannendes Thema kommt an dieser Stelle: Hat man nämlich bisher Google Contacts nicht genutzt und sein Adressbuch ausschließlich auf dem iPhone gepflegt, dann passiert auch nichts. iOS synchronisiert ein lokales Adressbuch nicht ohne weiteres mit einem Adressbuch, das mit einem externen Dienst synchronisiert wird.

Damit also eventuell auf dem iPhone vorhandene Adressbestände ins Google-Contacts-Adressbuch kommen, müssen diese dorthin einmalig übertragen werden. Am einfachsten funktioniert das mit der iOS-App namens “My Contacts Backup”, die das Adressbuch auf iPhone/iPad als CSV-Datei exportieren kann. Diese kann man sich dann bequem per E-Mail an das eigene E-Mail-Postfach schicken lassen.

Hat man dann diese CSV-Datei, lässt sich diese auf der Website von Google Contacts unter https://www.google.com/contacts/ (ggf. zunächst anmelden) importieren. Auf der Hauptseite gibt es oben mittig angeordnet einen Button namens “Mehr” und in diesem Untermenü dann den Menüpunkt “Importieren”. Dort dann einfach die oben generierte CSV-Datei importieren und schon nach einigen Augenblicken stehen die exportierten Adressen in Google Contacts zur Verfügung.

Hilfe! Alles doppelt!

Tatsächlich kann es zunächst passieren, dass nach der ersten Synchronisation im iOS-Adressbuch alle Kontakte doppelt auftauchen. Insbesondere dann, wenn wie im letzten Absatz der bisher lokal verwaltete Adressbestand in Google Contacts importiert wurde. iOS verwaltet alle Adressbücher strikt getrennt voneinander, also damit auch das lokale Adressbuch getrennt vom Adressbuch, das nun per CardDAV synchronisiert wird. Dass es hier mitunter dann Dubletten gibt, juckt iOS herzlich wenig.

Meine Empfehlung ist da ganz klar: Wer jetzt sein Adressbuch mit CardDAV synchronisiert und auch die lokalen Kontakte in Google Contacts importiert hat, auch nur noch mit diesem Adressbuch arbeiten und die lokalen Kontakte ersatzlos löschen. Sie gehen ja, wenn sie in Google Contacts importiert wurden, nicht verloren, sondern werden jetzt eben über die Google Cloud synchronisiert und das macht technisch gesehen keinen Nachteil aus. Denn der Zugriff auf einen synchronisierten Adressbestand ist selbst dann möglich, wenn das iOS-Gerät vorübergehend z.B. keine Verbindung haben sollte. Eine eventuell notwendige Synchronisierung erfolgt immer dann, wenn eine Netzverbindung besteht.

Also: Wenn es tatsächlich Dubletten in Ihrem Adressbestand gibt, dann ist die Vorgehensweise folgende (Bitte machen Sie dennoch unbedingt sicherheitshalber ein Backup mit der obig empfohlenen App):

1. Schalten Sie vorübergehend die Synchronisation mit allen fernen Adressbüchern aus, sofern welche vorhanden und diese aktiv sind. Das können Sie bequem in den Einstellungen der einzelnen Adressbuchsynchronisationen tun, in dem sie den Schieber vorübergehend auf den “Off-Zustand” schieben (siehe oben).
2. Wenn Sie dann alle Adressbuchsynchronisationen ausgeschaltet haben, gehen Sie in die Kontakte-App und sehen hier dann logischerweise nur noch die Adressen, die tatsächlich lokal auf dem iOS-Gerät liegen. Wenn das dann tatsächlich die eine Hälfte der Dubletten ist, können Sie alle die lokalen Adressen hier getrost löschen.

Und wie lege ich nun neue Kontakte an?

Das ist jetzt nämlich echter Komfort: Es ist egal, wo Sie neue Kontakte anlegen – ob nun im iPhone, auf dem iPad (falls es auch mit Google Contacts synchronisiert), auf der Website von Google Contacts oder mit einem anderen Programm oder Gerät, das mit Google Contacts synchronisiert – sie haben nur noch eine Adressdatenbank und das ist die bei Google Contacts.

Sie machen es jetzt also wie die Profis mit dem Adressbuch – in der Cloud. Und wenn Ihnen aus irgendeinem Grund das iPhone abhandenkommt (sie es von der Ferne aus natürlich sperren), ist Ihnen wenigstens nicht Ihr Adressbuch abhanden gekommen, denn das liegt eben nun in der Cloud.

Da die Artikel zum Thema Google Sync und iPhone in meinem Blog die mit Abstand am häufigsten aufgerufenen Artikel sind, hier doch nochmal ein wichtiger Hinweis für alle, die zukünftig ihr iPhone oder iPod per Google Sync mit ihren Kalendern und Adressbüchern in ihrem Google-Account synchronisieren möchten. Denn Google Sync steht auf der Abschussliste bei Google und für viele Nutzer ist Google Sync ab 30. Januar 2013 nur noch Geschichte.

Google Sync und der technische Hintergrund

Das Ende von Google Sync ist relativ einfach zu erklären, wenn man sich anschaut, was dahintersteckt: Eine Synchronisierungstechnologie namens ActiveSync von Microsoft. Und dazu ist dann ein kleiner Exkurs recht interessant:

ActiveSync hat eine recht lange Geschichte und hat seine Wurzeln im Mobilbetriebssystem Windows Mobile und der Möglichkeit zur Synchronisieren von Smartphone-Inhalten mit Windows-Betriebssystemen ab Windows 95 und NT 4. Für diese Anforderung wurde ActiveSync entwickelt und das war schon zu den Zeiten, als Windows Mobile mit dem einst allmächtigen Betriebssystem PalmOS von US Robotics konkurrierte, revolutionär. Denn während Palm-Geräte im am PC angeschlossenen Zustand nur dann synchronisierten, wenn die Synchronisierung am Gerät oder an der Dockingstation (die “Cradle”) die Synchronisierung explizit der Knopfdruck gestartet wurde, erledigten Windows-Mobile-Gerätschaften die initiale Autorisierung direkt nach dem Anstecken an den PC und synchronisierten während der Verbindung permanent, selbstständig und zuverlässig. Wurde in Outlook ein neuer Termin eingetragen, erschien dieser Termin im gleichen Moment auch im angeschlossenen Windows-Mobile-Gerät. ActiveSync machte es möglich und nicht zuletzt diese Technologie war ein wichtiges Abgrenzungskriterium zur Palm-Welt.

Aufgebohrt wurde ActiveSync dann später, in dem das Protokoll als Basis für die Synchronisierung zwischen Windows-Mobile-Geräten und dem Microsoft-Exchange-Server diente und fortan Exchange ActiveSync hieß. Das Prinzip der Echtzeitsynchronisierung blieb, lediglich der Übertragungsweg und die Gegenstation änderte sich. Nicht mehr der Bürorechner auf dem Schreibtisch war das andere Ende, sondern der Exchange-Server des Unternehmens, der dann die zu synchronisierten Inhalte direkt mit dem Postfach des Nutzers synchronisierte.

Und obwohl ja Microsoft verschrieen ist als ein Unternehmen, das rücksichtslos seine eigenen Standards entwickelt und verbreitet – ActiveSync hatte schon sehr früh eine relativ offene Lizenzierungspolitik und konnte von Herstellern von Personal Digital Assistants, später dann Smartphones, aber auch Herstellern von Mailsystemen und Betreibern von Maildiensten (kostenpflichtig) lizenziert werden. Das hatte natürlich einen Hintergrund, denn neben den Einnahmen durch die Lizenzierung war durch den Einsatz von ActiveSync potentiell das jeweilige Produkt auch fähig zum Kontakt mit Windows-Mobile-Gerätschaften oder auf der anderen Seite mit dem Exchange-Server.

Und da ergaben sich dann die seltsamsten Allianzen. Während z.B. RIM mit dem Blackberry und dem dazugehörigen Protokoll sowohl Endgeräte als auch Synchronisierungssoftware mit dem Mailsystem aus einer Hand liefert, können z.B. iPhone und Android-Geräte per ActiveSync mit dem Exchange-Server synchronisieren. Vorteil: Diese Synchronisierung kostet den Nutzer nichts, während bei Blackberry lange Zeit der Synchronisierungsdienst Geld kostete und zwar nicht zu knapp. Dass also ActiveSync so zuverlässig funktioniert und für Hersteller von Smartphones recht freizügig lizenziert werden kann, ist mit einer der Gründe, warum Microsoft lange Zeit die eigene Mobilbetriebssystemstrategie hat schleifen lassen und es hat ihnen zumindest im Business-Bereich nicht sonderlich viel finanziellen Schaden beschert. Das Lehrgeld in der Smartphone-Jungsteinzeit haben tatsächlich andere bezahlt.

Google und ActiveSync

Auch Google gehört zu den ActiveSync-Lizenznehmern und das wiederum aufgrund einiger Umstände:

1. Google benötigt ActiveSync im hauseigenen Mobilbetriebssystem Android, um Android-Handys mit der Exchange-Welt synchronisieren lassen zu können.
2. Google muss seine eigenen Kalender- und Kontaktedienste mit Schnittstellen zu ActiveSync ausstatten, um Smartphones mit anderen Betriebssystemen als Android eine Synchronisierung zu ermöglichen. Dies gilt insbesondere für das iPhone, denn obwohl das iPhone direkt (ohne ActiveSync) mit Google Mail synchronisieren kann, wird ActiveSync wiederum zum Synchronisieren von Kalender und Kontakten benötigt, da das iPhone hier keine eigenen Schnittstellen zu den Google-Diensten hat (warum auch immer).

Punkt 2 muss man sich ob des Irrsinns auf der Zunge zergehen lassen – weil Apple und Google zu doof sind, iOS und Google-Dienste vollständig miteinander synchronisieren lassen zu können, muss ausgerechnet ein lizenzpflichtiges Microsoft-Protokoll den Lückenfüller machen.

Und weil genau das Kostenthema der ActiveSync-Lizenzierung für die (kostenlos nutzbaren) Google-Dienste eine Rolle spielen dürfte, ist ActiveSync nun wohl bei der Synchronisierung der Google-Accounts auf der Abschussliste. Immerhin gibt es aber einige begrenzende Ausnahmen für das Ende:

• Wird ein Google-Account bis zum 30. Januar 2013 noch mit ActiveSync synchronisiert, bleibt diese Möglichkeit für diesen Account auch darüber hinaus noch erhalten. Das Ende gilt also ab 30. Januar 2013 nur für bis dato noch nicht per ActiveSync synchronisierende Google-Accounts. Inwiefern es bis zu diesem Datum tatsächlich aktiv genutzt werden muss oder ob die Nutzung irgendwann in der Vergangenheit schon ausreicht, wird sich zeigen.
• Ebenfalls nicht betroffen von dem Ende sind Google-Accounts, die innerhalb der inzwischen auch kostenpflichtigen Google Apps angelegt sind. Google-Apps-Accounts werden also auch weiterhin per ActiveSync synchronisieren können und wer da noch das Glück hatte, in der vergangenen Kostenlos-Zeit einen Google-Apps-Account einzurichten, lebt immer noch komplett kostenlos.

Die kostenlosen Protokollalternativen zum Synchronisieren

Google beendet das Synchronisieren mit ActiveSync vor allem auch deshalb, weil es inzwischen kostenlose Protokolle zum Synchronisieren gibt, die auch hinreichend zuverlässig sind. Für das Synchronisieren von Kalender ist dies das CalDAV-Protokoll und für das Synchronisieren von Kontakten das CardDAV-Protokoll. Beide Protokolle sind (inzwischen offizielle) IETF-Standards und im Falle von CardDAV eine beschwerliche Geburt hinter sich.

Das ist auch einigermaßen nachvollziehbar, denn ein einheitlicher, herstellerübergreifender Standard liegt zunächst einmal nicht im Interesse der Hersteller von eigenen, proprietären Protokollen und da lange Zeit die Motivation an echten freien Protokollen fehlte, dauerte es auch dementsprechend, bis beide Protokolle jeweils die Hürden genommen hatten, um als IETF-Standard zu gelten – zumal alle involvierten Hersteller innerhalb der IETF auch an der Standardisierung beteiligt waren. Das Wort “Sabotage” will niemand in den Mund nehmen, aber IETF-Standardisierung ist mitunter auch interessant für Beobachter, die sich für Rudelbildungen im Tierreich interessieren.

Was zu tun ist … Empfehlungen

Also, grundsätzlich: ActiveSync muss niemand unbedingt einsetzen, der auch CalDAV und CardDAV einsetzen kann. Beide Protokolle sind gleichwertig funktional, wenn es um die Synchronisierung von Kalender- und Kontaktdatenbanken geht. Selbstverständlich ist ActiveSync deutlich mächtiger, allerdings richten sich viele Funktionen von ActiveSync vornehmlich an Unternehmen, die z.B. in einer Exchange-Infrastruktur alle Arten von Clients – vom Windows-Rechner mit Outlook bis zum iPhone – synchronisieren und zentral verwalten müssen.

Innerhalb von Google-Diensten ist ActiveSync bzw. der eigene Name “Google Sync” immer als bisher mehr oder weniger notwendige Alternative zu verstehen. Es besteht also kein Grund zur Panik und auch nicht zu übermäßiger Hektik in Sachen Synchronisierungen zum Google-Konto einrichten. Wer bis zum 30. Januar 2013 Google Sync bzw. ActiveSync nicht einsetzt, wird es auch danach nicht vermissen, den selbst das iPhone, die Ausgeburt an Apple-Scheuklappentum in Sachen offenen Standards, unterstützt CalDAV und CardDAV

Zu erledigende Aufgaben für Besim

Das inzwischen gewachsene Sammelsurium an Blog-Artikeln, die sich mit der Synchronisierung zwischen Google-Konto und iPhone beschäftigen, aktualisieren. Die Artikel, die Google Sync erklären, werden mit Hinweisen darauf versehen, dass Google Sync nicht mehr bei allen Arten Google-Accounts funktioniert, der Artikel zu CalDAV so überarbeitet, dass es wieder als Empfehlung gilt und ein Artikel zu CardDAV neu geschrieben, das ich bisher großflächig ausklammerte, weil die CardDAV-Unterstützung von Google vor zwei Jahren, als ich das erste und bis dato letzte Mal in dieser Konstellation mit CardDAV experimentierte, schlicht unmöglich war.

Manchmal hilft die wohltuende Wirkung der Zeit doch, dass Hersteller sich ihren Möglichkeiten zur Interoperabilität bewusst werden.

Eigentlich sollte dieser Artikel eine Fragestellung erörtern. Nämlich die, ob es in einem Wahlkampf sinnvoll ist, eine eigene Smartphone-App zu haben oder ob man lieber auf eine Web-App setzt, also eine Website, die funktional und optisch auf Smartphones so aussieht, als ob sie eine App wäre. Die Wahlkampf-Website so eine Web-App-fähige Website, die in einem responsive Webdesign erstellt ist und deren Ansicht sich der Bildschirmgröße des anzeigenden Gerätes anpasst.

Begonnen wurde die Obama-2012-Kampagne 2011 auch mit einer eigenen App für Smartphones, genauer gesagt für das iOS-Betriebssystem von iPhone und iPad. Als ich nun darüber bloggen wollte, stellte sich heraus, dass diese App schon seit längerer Zeit nicht mehr zur Verfügung steht. Und der Grund dazu ist herzlich einfach: Es gibt keine Notwendigkeit dafür.

Historische Ansichten in die Obama-2012-App.

Die Obama-2012-App als besonderes Highlight zu bezeichnen, wäre vermessen. Vom Prinzip her ist das Konzept das eines betriebseigenen Kiosks und keine der Inhalte, die in dieser App abgerufen werden können, sind wirklich exklusiv, da sie auch auf der Wahlkampf-Website zu finden sind. Die Startseite der App verweist schon auf alle Bereiche in der App:

“Latest News” führt auf einen Nachrichtenbereich, der exakt dieselben Nachrichten enthält, wie auf dem offiziellen Wahlkampf-Weblog. Mit einem Tippser auf eine Nachricht lässt sich diese dann lesen:

Die Rubrik “Photos & Videos” stellt auf einem Bildschirm eine Übersicht über Bilder und Videos im Wahlkampf zusammen:

Während die Videos recht anschaubar sind, sind die Fotos reine Makulator und eigentlich unansehnlich, weil völlig pixelig. Zudem fehlt jegliche Sortierung, so dass diese Bilderwand nicht viel mehr als Show ist:

Interessanter, aber auch nicht wirklich weltbewegend neu ist die Rubrik “Events”, die, wenn man der App in den Einstellungen den aktuellen Standort in Form des US-ZIP-Codes spendiert hat, passend zum aktuellen Ort die nächsten Events anzeigt. In meinem Beispiel wohnte ich z.B. im beschaulichen Honolulu auf Hawaii. Mit einem Tippser auf die Stecknadel lassen sich nähere Informationen zum jeweiligen Event anzeigen:

Dinge, die gegen und für eine App sprechen.

Tatsächlich war es eine gute Entscheidung, diese App nicht wirklich in den Wahlkampf mitzunehmen und schon nach wenigen Monaten einzustampfen, bevor wirklich Befürworter und Wähler mit dieser App enttäuscht werden könnten. Denn der Mehrwert gegenüber einer mobil gut erreichbaren Seite ist nahe Null. Mit einer Ausnahme, weshalb diese App vermutlich einst auch entwickelt wurde: Der Push-Service von iOS, der für die Verteilung der Nachrichten eingesetzt wurde. Mit dem Push-Service wurde wohl die Idee verfolgt, bei Neuigkeiten direkt über den Push-Service den Besitzer des iOS-Gerätes zu informieren.

Rein faktisch gesehen ist das aber nicht notwendig, weil neue Nachrichten im Wahlkampf-Weblog auch über die Twitter-Kanäle von Barack Obama angekündigt werden und hier mit vielen Twitter-Clients und dem Konfigurieren von bestimmten Regeln ein Push-Service einsetzen lässt. Oder auch über Facebook oder über gutes, altes Syndizieren via RSS-Feed.

Dass bei Barack Obama dennoch nicht auf ein Home-Symbol verzichtet werden muss, lässt sich anschaulich beobachten, wenn die Wahlkampf-Website mit Safari unter iOS (iPad und iPhone) aufgerufen wird. Tippt man dort (iOS 6) auf das Weiterleiten-Symbol, erscheint folgendes Menü und da ist der mittlere Button genau die gewünschte Ansage:

Bei solchen Apps darf man einen Punkt nicht verheimlichen: Wo App draufsteht, ist meist nicht viel mehr drin, als ein Webbrowser. Das gilt auch für die einstige Obama-2012-App und für viele andere Apps für SmartPhones, die lediglich aus Prestigegründen in Form einer App daherkommen, hinter den Kulissen aber die meisten Inhalte online aus dem Web beziehen.

Eine Web-App bzw. ein Widget ist die einzig konsequente Antwort für solche Informationsdienste, da so mit gängigen Technologien wie HTML 5, JavaScript und dem Document Object Model (DOM) ein wirklich plattformübergreifendes Angebot geschaffen werden kann, das auf allen gängigen Smartphone-Umgebungen von Hause aus läuft.

Mitt Romney geht App.

Das Team um Mitt Romney fährt nach wie vor eine App-Strategie und ist sogar mit zwei eigenen Apps im iOS-AppStore vertreten:

Die App “Romney-Ryan”.

Diese App ist die offizielle App und stellt sich wohl als Antwort auf die einstige “Obama-2012-App” dar. Und leidet genau unter den Krankheiten, die funktionsarme Apps von Hause aus haben – außer Prestige liefert die Apps nur Inhalte, die auf der Wahlkampf-Website von Mitt Romney sowieso zu finden sind:

Die Frage, warum das Team Romney auf Apps setzt, hat wohl mehrere Gründe und zeigt sehr schön, dass auch beim Verständnis in Sachen Mobile Computing das Team Romney nicht ansatzweise die gängigen Möglichkeiten ausschöpft:

• Eine App gilt als schick und modern, während eine Website als “zu normal” gilt – zumindest bei Menschen, die Smartphones und Mobile Computing vornehmlich als Statussymbol ansehen und weniger für echte Kommunikation. Das Herunterladen einer App aus dem AppStore und das Erscheinen eines eigenen App-Symbols auf dem iPhone-Home-Bildschirm ist nun einmal auch eine Art von Marketing.
• Zur Informationsvermittlung sind zwar Web-Apps gegenüber echten Apps weitgehend ebenbürtig, allerdings nur bei kommunikativen Anwendungen. Spiele und Anwendungen, die auf besondere Hardware eines Smartphones setzen wie z.B. die Kamera sind (derzeit zumindest) nur als App realisierbar. So hat ausgerechnet die ansonsten sinnfreie “With Mitt”-App durchaus ihre Berechtigung, weil die Kamera- und Bildbearbeitungsfunktion derzeit nur in einer App zu realisieren ist.

Die Nachteile der App-Strategie finden sich im Team Romney auch gleich und zwar alle zusammen:

• Die Wahlkampf-Website ist nicht mit einem responsive Webdesign erstellt und kennt nur eine Bildschirmgröße. Für mobile Webbrowser ist daher eine Weiche im HTML-Code eingebaut, die diese dann auf einen Server namens m.mittromney.com” schickt, auf der explizit eine mobile Website gehostet wird, die allerdings reichlich umständlich zu bedienen ist.
• Eine App funktioniert natürlich nur auf der Plattform, für die sie entwickelt wurde. Im Falle der Romney-Apps gibt es nur Versionen für iOS-Betriebssysteme und z.B. nicht für Android. Zwar können andere Betriebssysteme über dort installierte Webbrowser dennoch auf die mobilen Websites zugreifen, allerdings ist eine App-Strategie, die nur auf einzelne Plattformen zielt, eben nur eine unvollständige App-Strategie.

Die App “With Romney”.

Diese App ist nicht sonderlich ernstgemeint (hoffentlich zumindest!) und dient zur Erzeugung von “Unterstützerplakaten” aus eigenen Fotos. So kann der iPhone-Besitzer oder auch das zum Besitzer korrespondierende Haustier seine innige Zuneigung zu Mitt Romney mitteilen:

Ob so eine Nonsens-App, die sehr an die Idee mit dem “Hope”-Plakaten im Wahlkampf von Barack Obama im Jahr 2008 erinnert, tatsächlich neue Wählerschichten erschließt, darf bezweifelt werden. Eine eh schon schlechte Smartphone-Strategie wird dadurch jedenfalls nicht automatisch besser.

Alle Teile meines Dossiers zu Obama 2012 unter dem Stichwort “Obama 2012″.

Ich habe mehr oder weniger aus Jux und Dollerei gerade einmal probiert, ob der Mobile Safari, der Webbrowser auf iOS-Gerätschaften, FTP beherrscht. Und tatsächlich, ich war sehr gut beraten, die ansonsten eigentlich schon prädestine, museale Ausstattung des Mobile Safari nicht in einer Wette dazu zu nutzen, eine Gegenwette abzuschließen. Denn tatsächlich beherrscht der Mobile Safari FTP. Allerdings, und da bleibt sich Apple treu, so bescheuert schlecht, dass es doch schon wieder alle Vorurteile erfüllt.

Als Webbrowser FTP zu können, ist leichter gesagt, als getan. Denn im Gegensatz zum Web ist FTP vor allem eine Geschichte, die für gewöhnlich passwortgeschützt passiert. Hier mal mein Setup:

Meine Fritzbox hat einen angeschlossenen USB-Stick, das ich als Speicherlaufwerk einsetze. Mit der VPN-Funktionalität der Fritzbox habe ich auf diese Weise eine ziemlich praktische Home-Cloud, die ich aus dem Internet problemlos erreichen kann – per VPN und innerhalb meines LAN dann per SMB (“Windows Netzwerk) oder auch per FTP. Im Webbrowser gebe ich für diesen Zugriff einfach ein:

ftp://fritz.box/

Normale Webbrowser probieren den FTP-Zugriff und bekommen dann von meiner Fritzbox die Rückmeldung, dass der FTP-Zugriff nicht anonym erfolgen kann, sondern Zugangsdaten erforderlich ist. Normale Webbrowser kennen dieses Verhalten und fordern den Benutzer mit einem Passworteingabefeld auf, Zugangsdaten einzugeben, mit denen dann der FTP-Zugriff nochmals durchgeführt werden kann, nun eben mit Authentifizierung.

Für Apple scheint dies völlig neu zu sein. Denn gebe ich einfach die obige Adresse ein, fragt mich der Mobile Safari nicht etwa nach Zugangsdaten, sondern lässt mich im Regen stehen:

Keine Zugriffsrechte
Sie haben nicht die erforderlichen Zugriffsrechte, um “/” anzuzeigen.

Darauf wäre ich gar nicht gekommen.

Allerdings sind wir ja nicht vollkommen blöd, sondern wissen ja, wie das URL-Schema funktioniert. Und das URL-Schema hat feste Regeln, wie man neben einer Adresse auch Zugangsdaten übermittelt:

ftp://benutzername:passwort@fritz.box

Und siehe da: So funktioniert das sogar im Mobile Safari, danach bin ich auf meinem Speicherlaufwerk und kann Dateien herunterladen.

Eine ganze Reihe von Nachteilen gibt es, allesamt Mobile-Safari-Schwächen:

• Es wird nur FTP unterstützt, nicht die verschlüsselte Variante SFTP. Das ist freilich nur ein “weiches” Problem, denn SFTP unterstützen auch andere Webbrowser nicht. Damit ist der FTP-Zugriff per Webbrowser immer eine Geschichte, die man, wenn es um sensible Daten geht, nur mit einer zusätzlichen Transportverschlüsselung machen sollte. Da der FTP-Zugriff zu meiner Homecloud nur innerhalb meines LAN funktioniert und ich vom Internet aus zwangsläufig ein VPN nach Hause benötige, ein in diesem Szenario vernachlässigbares Problem.
• Mobile Safari kennt zwar das URL-Schema und die Art und Weise, wie in diesem Schema Zugangsdaten übermittelt werden, allerdings ist die Umsetzung halbherzig. Denn den obigen URL mit integriertem Passwort kann ich so nicht als Lesezeichen hinterlegen, sondern würde gern folgendes als URL verwenden:ftp://benutzername@fritz.boxMit diesem URL können nämlich alle anderen, FTP-fähigen Webbrowser etwas anfangen und fragen nur noch das Passwort ab, das für den Zugriff notwendig ist. Mobile Safari kann mit diesem URL nichts anfangen.
• Sehr, sehr wichtig: Mobile Safari führt, so wie jeder andere Webbrowser auch, einen URL-Verlauf, in dem alle aufgerufenen URL der letzten Zeit gespeichert werden. Leider speichert Mobile Safari hierbei auch Adressen, in denen sich Benutzernamen und/oder Passwörter befinden. Um das zu verschmerzen, gibt es zwei Möglichkeiten. Das so genannte “private Surfen” in den Safari-Einstellungen aktivieren oder an der gleichen Stelle den Verlauf löschen. Ist leider relativ umständlich, weil beide Dinge nicht direkt im Mobile Safari vorgenommen werden können, aber leider nicht unwichtig, wenn man sensible Zugangsdaten nicht im Verlauf herumspazieren möchte.

Nun gut, immerhin kann Mobile Safari FTP-Zugriff so auch mit Zugangsdaten, wenn auch auf eine ziemlich vorsintflutliche Weise. Schön sehen die Dateiauflistungen auch nicht aus, aber technisch funktioniert es und ich kann Inhalte aus meiner Homecloud auf iPhone/iPad herunterladen.

1.000 Tage sind in etwa der Zeitraum, in denen Hersteller von Mobiltelefonen die Firmware von Smartphones pflegen. Dabei ist “pflegen” ein sehr dehnbarer Begriff, bei dem sich die meisten Hersteller strikt darauf beschränken, aus der initial verteilten Firmware die Bugs herauszuoperieren und maximal nur sehr moderate Erweiterungen zu integrieren. Man will ja den Kunden nicht dadurch verlieren, dass er so zufrieden mit seinem Gerät wird, dass er kein neues Smartphone mehr kauft.

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.

Einer der Dinge, die mich  von Anfang an in Apples Mobilbetriebssystem iOS und auch in Android gestört haben, war eine fehlende ToDo-Verwaltung. Es ist mir unverständlich, wie man ansonsten alle PIM-Anwendungen wie Kalender, Kontakte, Notizzettel integrieren kann, dann aber eine simple ToDo-Verwaltung außen vor lässt.

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.

Als ich 2006 angefangen habe, meine altehrwürdige CD-Sammlung in Audiodateien umzuwandeln, wusste ich noch nicht so recht, wie praktisch das irgendwann sein könnte. Bereut habe ich es eigentlich kaum, denn obwohl ich lange Zeit so gar nichts mit mobiler Musik anfangen konnte, war es zumindest soweit praktisch, Musik immer per Knopfdruck am PC zu haben, ohne erst mal die CD zu suchen, einzulegen, abzuspielen und dann wieder die nächste usw. Irgendwann kommt man dann auch dahinter, wie das mit den Playlists funktioniert und wie der Windows Media Player anfängt, den Musikgeschmack zu lernen. Hübsch und gut.

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.

Die Artikel zum Synchronisieren zwischen Google Calendar und dem iPhone gehören weiterhin zu den absoluten Artikelschlagern hier im Blog. Das hat den Vorteil, dass die Artikel offensichtlich einigen Ratsuchenden eine Hilfe darstellen und einiges an Erfahrungen zusammenkommen, die leider in den offiziellen Google-Anleitungen nicht gut oder teilweise gar nicht dokumentiert sind.

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.

Update vom 2. März 2012: In der Zwischenzeit hat AVM mitgedacht und in dem kleinen Softwareprogramm “FRITZ!Fernzugang einrichten” eine Option eingebaut, mit der in einer zu erstellenden Konfiguration die Secure-Gateway-Funktion eingebaut werden kann. Dieser Artikel ist mit seiner komplexen Anleitung daher weitgehend hinfällig und steht hier nur noch aus historischen Gründen, dennoch gelten die technischen Hintergründe nach wie vor und sind aktuell.

Vor einiger Zeit habe ich versucht, meine AVM Fritzbox 7270 für eine verwegen klingende, aber gar nicht so unsinnige Funktion einzusetzen: Mit meinem iPhone wollte ich die die VPN-Funktionalität der Fritzbox nutzen, um zwischen iPhone und Fritzbox ein VPN aufzubauen. Über dieses VPN wollte ich nicht nur Rechner in meinem eigenen Netzwerk erreichen, sondern die Fritzbox so einsetzen, dass über sie auch der Datenverkehr abgewickelt wird, der vom iPhone ins Internet möchte. Die Idee dahinter war, auf diesem Weg dann auch ein offenes und unverschlüsseltes WLAN nutzen zu können, denn der gesamte Datenverkehr von und zum Internet könnte dann eben über diesen VPN-Tunnel abgewickelt werden.

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 192.168.178.0 255.255.255.255 192.168.178.202 255.255.255.0",
"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.