Kategorie: iPad

Was tun bei Schadsoftware auf dem Smartphone?


Mobile Security – Virus auf dem Handy – Malware und Trojaner auf dem Smartphone

Ähnlich wie Windows auf dem Desktop ab Ende der 90er Jahre Ziel von Angriffen über das Internet wurde, blüht dieses Schicksal nun Android als dominierender Betriebssystemplattform für Smartphones. Aber auch Angriffe auf iPhones und iPads werden von uns zurzeit vermehrt beobachtet. Dabei handelt es sich überaschenderweise noch um XhostGhost.

Wie werden die Infektionen erkannt?

Wir bekommen vom DFN-Verein (Deutsches Forschungs-Netz, der Internet-Provider der Uni) automatisierte Warnmeldungen, wenn sich ein Computer oder ein Smartphone aus dem IP-Adressbereich der Uni Duisburg-Essen mit dem Kommandoserver eines bekannten Bot-Netzes verbinden will. In so einem Fall informieren wir die Nutzerinnen und Nutzer über den Befall und empfehlen den Besuch des e-Points bzw. des PC-Services um das Gerät von der Schadsoftware zu säubern.

malware

Viele Nutzer setzen Virenscanner auf Smartphones ein. Deren Wirksamkeit auf Smartphones wird aber von Experten stark angezweifelt. Virenscanner erfordern viele, wenn nicht alle, App-Rechte ein  und schaffen so möglicherweise neue Sicherheitslücken. Apple hat den Herstellern von Virenspanner den Vertrieb dieser Software über den iTunes-Store untersagt.

Was kann so eine Infektion anrichten?

Ist ein Smartphone erst einmal von Schadsoftware durchdrungen, ist es ein Leichtes, diese Geräte und so die Nutzer zu verfolgen, persönliche Kontaktdaten
und Passwörter abzugreifen oder das Telefon gar als Abhörwanze zu betreiben. Kein einziger Account und kein Passwort, welches jemals auf so einem Gerät eingegeben worden ist, ist dann noch vertrauenswürdig. Das gilt auch für die Zugänge zu den App-Stores, die möglicherweise auch Zahlungen mit Kreditkarten zulassen.

Vorsicht mit App-Rechten!

Man sollte sich immer bewusst sein, das jede App, die bestimmte Rechte, wie etwa auf die Kamera, oder das Mikrofon, einfordert die Kamera bzw. das Mikrofon zu jeder Zeit auch benutzen kann. Insofern vertraut man immer dem Programmierer bzw. Anbieter der App. Besonders vertrauenswürdig müssen Apps sein, die eine VPN oder eine zusätzliche Tastatureingabemethode realisieren, da sie alle Eingaben bzw. den gesamten Netzwerkverkehr auch anderer Apps belauschen können. Wenn man Bedenken wegen der geringen Anzahl der bisherigen Installationen oder den geforderten App-Rechten hat, sollte man lieber nach einer alternativen App suchen.

 Wie kommt die Schadsoftware auf das Smartphone?

Häufig installieren die Anwender die Schadsoftware selbst in Form von Spielen oder gefälschten Apps unklarer Herkunft. Google und Apple versuchen Schadsoftware aus dem Android Play Store bzw. dem iTunes App Store fernzuhalten, was ihnen aber nicht immer gelingt. Ganz besondere Vorsicht ist bei Apps aus alternativen App-Stores wie z.B. AndroidPit (Android) oder Cydia (für IOS-Geräte mit Jailbreak) geboten, da hier möglicherweise Apps mit sehr unklarer Herkunft gehandelt werden. Siehe auch diese Zusammenstellung von App-Stores für diverse Smartphone-Betriebssysteme. Viele Android-geräte werden bereits mit einem Zugang zu einem alternativen App-Store verkauft.

Die bei uns aktuell beobachteten Fälle mit XhostGhost haben gar eine manipulierte Entwicklungsumgebung für iPhone-Apps als Ursache. Diese manipulierte XCODE-Version wurde 2015 Entwicklern untergeschoben und hat dazu geführt, dass APPs wie WeChat oder die chinesische Version von “Angry Birds 2″ mit einem Trojaner infiziert worden sind.

Aber auch Sicherheitslücken in Smartphone-Betriebssystemen können die Ursache für eine Infektion mit Schadsoftware sein. Achten Sie darauf alle Sicherheitsupdates für Ihr Betriebssystem auch zu installieren. Auch die Apps sollten Sie regelmäßig aktualisieren.

Leider haben die Hersteller wenig Interesse daran, für Security-Updates zu sorgen, nachdem die Geräte erst einmal verkauft worden sind. Apple hat da ein abweichendes Geschäftsmodell und versorgt die sehr viel teureren IOS-Geräte recht lange mit Updates, während es bei Android-Geräten mit Updates eher mau aussieht. Android-Geräte, die von der alternativen Firmware LineageOS unterstützt werden (Geräteliste hier) können sehr viel länger sicher betrieben werden. Wer nachhaltig und IT-sicher agieren möchte, sollte nur Geräte kaufen, die in dieser Liste aufgeführt werden.

Einige Geräte sind „ab Werk“ mit vorinstallierten Apps des Herstellers  oder gar eigenen App-Stores (siehe oben) ausgestattet, die Sicherheitslücken enthalten. Preiswerte Geräte aus China stehen in Verdacht, schon „ab Werk“ Schnüffelsoftware mitzubringen, die den Anwender ausspioniert. Update: Hier noch zwei ganz aktuelle Fälle (Smartphones von Blue Products und Nomu).

Auf Smartphones laufen Webbrowser, die wir ihre Desktop-Pendants Sicherheitslücken haben können. Insofern können Sie sich  auch Schadsoftware per Drive-by-Download einfangen. Besonders perfide sind beispielsweise Pop-Ups auf Webseiten, die die Besucher zu Downloads überreden sollen. Sowohl für Android (Adblock Browser) als auch für IOS (Adblock Browser) gibt es mobile Adblocker, die die Gefahr von Drive-by-Downloads verringern.

Staatliche Malware – der Staatstrojaner

Eher ein politisches Trauerspiel ist es, dass nun auch Strafverfolgungsbehörden in Deutschland Sicherheitslücken ausnutzen oder für neue sorgen dürfen. Der Staatstrojaner soll Daten vor der sicheren Ende-zu-Ende-Verschlüsselung auf dem Gerät abgreifen. Das deutet auf ähnliche Technologien hin, wie Sie open bei VPN und Tastatur-Apps beschrieben worden sind. Auch solche durch Steuergelder finanzierte Trojaner können Sicherheitslücken enthalten, die möglicherweise von Kriminellen ausgenutzt werden.

Was tun bei einer erkannten Infektion?

Wenn die Infektion durch das ZIM erkannt wurde, bitten wir Sie  umgehend die WLAN-Verbindung in das eduroam unterbrechen und das eduroam-WLAN-Profil löschen. Dann sollten Sie versuchen persönliche Daten vom Smartphone auf einen vertrauenswürdigen Speicher zu kopieren. Wenn Ihre Google bzw. Apple Zugangsdaten gestohlen worden sind, ist auch der Cloudspeicher dort möglicherweise nicht mehr sicher.  Kopieren Sie alle Ihre persönlichen Daten (Kontakte, Fotos) auf einen PC oder die vertrauenswürdige Sciebo-Cloud (auch das Sciebo-Passwort müssen Sie nachher ändern!). Notieren Sie sich alle Zugangsdaten der installierten Apps/Dienste. Für Android-Gräte die OTG-fähig sind gibt es USB-Sticks, die sich für ein Backup auch direkt an der Mikro-USB-Buchse anschließen lassen. Alternativ tut es auch ein OTG-Adapter, an den schon vorhandene USB-Datensticks angeschlossen werden können.

Auch beim Verkauf eines Android Smartphones muss es hier auf den Werkszustand zurückgesetzt werden.

Auch beim Verkauf eines Android Smartphones muss es hier auf den Werkszustand zurückgesetzt werden.

Setzen Sie erst danach Ihr Smartphone auf die Werkseinstellungen zurück. Unter Android geht das so:  „Einstellungen“, „Sichern und Zurücksetzen“, „Auf Werkszustand zurück“.

Unter IOS müssen Sie nach Apples Anleitung vorgehen.

Ändern sie danach Ihr Uni-Passwort im Selfcareportal der Uni. Wir empfehlen Ihnen dringend auch die Passwörter der Google/Apple App-Store-Account und aller auf dem Smartphone verwendeter Dienste zu ändern! Dann können Sie Ihr Smartphone wieder neu mit Ihrem Google/Apple-Account einrichten. Sie sollten dann alle verfügbaren Updates herunterladen. Verzichten Sie darauf Ihr Smartphone mit Hilfe von Google „meine Daten sichern“ bzw. dem Pendant von Apple wieder automatisiert einzurichten, da Sie dann möglicherweise die Schadsoftware wieder automatisch installieren, wenn sie diese aus dem Google-play-Store installiert haben. Ignorieren Sie keinesfalls eine erkannte Infektion, da sowohl Ihre Privatsphäre als auch die Sicherheit des Uni-Netzes betroffen sind.

In 80 Zeilen um die Welt – Moving Map mit HTML5 Geolocation für iPhone,iPad und Android ohne Google ;-)


Das HTML5 Geolocation-Feature interessiert mich schon eine ganze Weile. Im Juli 2010 habe ich in meinem Blog eine Lösung basierend auf Openstreetmap, bzw. genauer dem großartigen Openlayers-Projekt, vorgestellt. Weil diese Seite recht viel Traffic über Google erzeugt, nun auch in meinem Blog einen ausführlicheren Artikel dazu.
Ich habe das Beispiel nun um eine Detektion der Screensize und eine live-Aktualisierung erweitert, so dass nun eine rein webbasierte ‘moving map’ a la Google maps plattformübergreifend zur Verfügung steht. Richtig spannend wird diese Seite erst wenn Sie sich bewegen (z.B mit mit einem Smartphone/iPad oder Netbook), der Browser aktualisiert dann Ihre Position!

Also in etwa die Google maps Funtionalität, rein HTML5-webbasiert und ohne Google. Das stimmt leider nicht wirklich, da beispielsweise im Firefox-Browser auch wieder Google als ‘embedded location provider’ eingetragen ist. Glauben Sie nicht? Einfach einmal about:config in die Adresszeile des Browsers eingeben (das ist die Browser-Konfiguration für Erwachsene ;-) ) und nach dem Schlüssel ‘geo.wifi’ suchen. Der Browser holt die Position per JSON bei Google https://www.google.com/loc/json ab. Wie genau Ihre Position bestimmt werden kann hängt vom Location Provider bzw. von der Implementierung Ihres Browsers und der eingeschalteten Quellen für die Lokalisation (WLAN/GSM/GPS) ab. Wenn diese Quellen nicht eingeschaltet sind, z.B. bei einem PC ohne WLAN, versucht Google die Position anhand der IP-Adresse bzw. anhand von Whois Records zu erraten. Das klappt erstaunlich genau.

Das Beispiel ist hier als iframe in mein Blog eingebettet und funktioniert auf allen HTML5 fähigen Browsern auch auf Android-Smartphones (ab 2.3 Gingerbread) und dem iPhone/iPad/iPod touch:

Benutzen Sie diesen Link um die Karte direkt auf Ihrem Android bzw IOS Smartphone anzuzeigen.

Nicht erschrecken, der Browser sollte beim Laden nun artig fragen ob diese Webseite Ihre Position erfahren darf. Dabei handelt es sich um ein HTML5-Geolocation-Feature.

Hier ist der einfache Quellcode zu sehen, ein bisschen Javascript meinerseits plus OpenLayer.js:

 

<html>
  <head>
    
    <style type="text/css">
      html, body, #basicMap {
          width: javascript(screen.width);
          height: javascript(screen.height);
          margin: 10;
      }
    </style>
 <!-- javascript(screen.width); //-->
  <!-- javascript(screen.height); //-->

    <script src="OpenLayers.js"></script>

    <script>
      function init() {
        map = new OpenLayers.Map("basicMap");
        var mapnik = new OpenLayers.Layer.OSM();
        var markers = new OpenLayers.Layer.Markers( "Markers" );
        
        map.addLayer(mapnik);
        //map = new OpenLayers.Map("basicMap");
        //var mapnik = new OpenLayers.Layer.OSM();
        //map.addLayer(mapnik);
        map.setCenter(new
        OpenLayers.LonLat(3,3) // Center of the map
          .transform(
            new OpenLayers.Projection("EPSG:4326"), // transform from WGS 1984
            new OpenLayers.Projection("EPSG:900913") // to Spherical Mercator Projection
          ), 15 // Zoom level
         );
        //var markers = new OpenLayers.Layer.Markers( "Markers" );
        map.addLayer(markers);
        var posss = new OpenLayers.Marker(0,0);
        markers.addMarker(posss);                    
                        

        navigator.geolocation.watchPosition(function(position) {       
            document.getElementById('anzeige').innerHTML="Latitude: " + position.coords.latitude + "   Longitude: " +
            position.coords.longitude + "<p>";
            var lonLat = new OpenLayers.LonLat(position.coords.longitude,
                                    position.coords.latitude)
                      .transform(
                                  new OpenLayers.Projection("EPSG:4326"), //transform from WGS 1984
                                              map.getProjectionObject() //to Spherical Mercator Projection
                                            );
            
            markers.clearMarkers();                                
            markers.addMarker(new OpenLayers.Marker(lonLat));
            //posss.lonlat(lonLat);
            map.setCenter(lonLat, 14 // Zoom level
            );
           
        });
            
      
      }
    </script>
  </head>

  <body data-rsssl=1 onload="init();">
<center>
HTML5 geolocation: 
<br />
    <div id="basicMap"></div>
<br />HTML5 geolocation<br />
<br />with Openstreetmap and OpenLayers<br />

For Android Froyo,iPhone,iPAD,iPod
<br />
Your position estimated by browser geolocation API:<p>
<div id="anzeige">(will be displayed here)<p></div>
<a href="http://www.dr-bischoff.de">Andreas Bischoff</a>

<br />(view source to see how it works, or <a
href="https://blog.robotnet.de/2011/03/30/html5-geolocation-with-openstreetmap-and-openlayers-for-android-iphone-ipad-and-ipod/">read my blog</a> ;-)
</center>
  </body>
</html>


Das Pediaphon mit neuem Touch-Interface für Android, iPhone, iPad und iPad


Weil die HTML5-Audiounterstützung nun auf Android 2.3 Gingerbread ebenso gut funktioniert wie unter iOS auf den Apple-Mobilgeräten, war ich neugierig ob sich die gemeinsame Basis der beiden Welten (der Android-Webbrowser basiert ebenso wie der Safari-Browser auf der freien Webkit Rendering Engine) für eine HTML-basierte, an die Touch-Bedienung angepasste, eigene Oberfläche eignet. Die Ansicht, die Entwicklung von plattformübergreifenden HTML-basieren Anwendungen gegenüber nativen APPs zu favorisieren, vertrete ich schon seit langem. Besonders für e- und m-learning Anwendungen ist eine Standardisierung nützlich um zu verhindern, dass im Hochschulbereich immer knappe Entwicklungskapazitäten an einzelne Endgeräte verschwendet werden. Wiederverwendbarkeit und langer Lebenszyklus sind bei Web-basierten Anwendungen eher sicherzustellen als bei nativen APPs.

Ich wollte ursprünglich Sencha Touch einsetzen  bin aber durch einen Kollegen auf iWebkit aufmerksam geworden. iWebkit besticht durch seine Einfachheit in der Anwendung, schon rudimentäre HTML-Kenntnisse reichen aus um eine iWebkit-Seite zu erstellen. Auf dem iPhone und iPad sehen iWebkit-Seiten aus wie eine native APP und sie laufen auch ganz fabelhaft  auf Android- Nokia S60- Palm Pre- und Openmocko, basierten Geräten.

Als beispielhafte Anwendung wird hier ein eigenes Pediaphon-User-Interface für Webkit-basierte Mobilbrowser vorgestellt. Die Audioausgabe wird hier mit HTML5 realisiert, für Android 2.2 Froyo basierte Telefone gibt es auch eine Flash Alternative.

Hier einige Screenshots vom GUI (Auf einem Android 2.3 Gingerbread Emulator, aber auch schon live mit einem Orange San Francisco getestet):

Screenshot 1 Pediaphon iWebkit auf AndroidScreenshot 2 Pediaphon iWebkit auf Android

Screenshot 3 Pediaphon iWebkit auf AndroidScreenshot 4 Pediaphon iWebkit auf Android

Ausprobiert werden kann das Pediaphon iWebkit-Interface hier in Deutsch und in Englisch, Spanisch, Französisch und Italienisch.

Plattformunabhängige Entwicklung von Mobile Learning Applikationen für iPhone und Android Smatphones


Die beiden Platzhirsche bei den Betriebssystemen für Touchscreen Smartphones sind derzeit unbestritten Googles Android auf Telefonen diverser Hersteller und Apples iOS auf dem iPhone. Um Applikationen für das iPhone zu entwickeln ist Apple MAC-Hardware zwingend erforderlich, auf anderen Betriebssystemen darf nicht entwickelt werden. Programmiert wird ausschließlich in Objective-C einer objektorientierten Variante C-Variante und nicht etwa im weiter verbreitertem C++. Die erstellten Applikationen (Apps) dürfen nur über den Apple Appstore vertrieben werden. Wesentlich offener gibt sich da Googles Android und setzt ganz auf die weit verbreitete Programmiersprache Java, in der bis auf wenige Ausnahmen die Apps erstellt werden. Zeitkritische Anwendungen können mit den Native Development Tools auch in C geschrieben werden. Es kann wahlweise unter Windows, Linux und MacOS für Android entwickelt werden.

Wahlverwandtschaften

Trotz dieser Unterschiede sind sich diese Plattformen in vielerlei Hinsicht doch sehr viel ähnlicher als man auf den ersten Blick vermuten würde. Der Android-Webbrowser basiert ebenso wie der Safari-Browser auf dem iPhone auf der freien Webkit Rendering Engine. Auch ein Großteil der Webbrowser weiterer mobiler Plattformen wie z.B. Nokia S60, Palm Pre, Openmoko und in Zukunft wohl auch Blackberry verwenden unter der Haube die schlanke Open Source Webkit Engine, die für die eigentliche Darstellung (das Rendering) der Webseiten sorgt. Die Benutzeroberfläche der Browser kann also durchaus verschieden sein, die einheitliche Rendering Engine sorgt dafür das Webseiten auf allen diesen Geräte gleich dargestellt werden bzw. die Unterstützung neuer Webstandards wie HTML5 ähnlich weit fortgeschritten ist.

Das ist übrigens nicht die einzige Gemeinsamkeit der beiden Welten. Die Apple iPhones arbeiten ebenso wie die Android Smartphones mit einer CPU die auf der ARM-Architektur beruht (Android kann sogar auf einem iPhone installiert werden;-)). Sowohl bei iOS als auch bei Android handelt es sich um UNIX-ähnliche Betriebsysteme. Android verwendet einen Linux-Kernel, iOS lässt sich geschichtlich über Mac OS X und Nextstep auf BSD-UNIX zurückführen.

Webkit

Ursprünglich als Rendring Engine für den Linux KDE-KHTML-Browser entworfen, dann von Apple unter dem Namen Webkit als Rendering Engine für Safari weiterentwickelt, arbeitet nun auch ein Google Team an Webkit für Google Chrome und dem mitgelieferten Browser im Android-Betriebssystem. Wenn Sie dieses Blog auf einem Mac, einem iPhone, einem iPad (Safari-Browser) oder auf einem Android-Smartphone lesen, wird die Darstellung der Seite durch Webkit erledigt. Ein sehr schlanker und empfehlenswerter Webkit-basierter Browser für Linux und Windows ist übrigens Midori.

Plattformunabhängigkeit

Die Entwicklung von plattformübergreifenden HTML-basieren Anwendungen ist meiner Ansicht nach immer gegenüber nativen APPs zu favorisieren. Besonders für E- und M-Learning Anwendungen ist eine Standardisierung nützlich um zu verhindern, dass die im Hochschulbereich knappen Entwicklungskapazitäten an einzelne Endgeräte verschwendet werden. Wiederverwendbarkeit und langer Lebenszyklus sind bei webbasierten Anwendungen eher sicherzustellen als bei nativen Apps. Eine Ausnahme ist die Erstellung von Content für bestehende Apps, die auf mehreren Plattformen verfügbar sind (siehe z.B. hier).

Der Erfolg des iPhones hat mehrere Entwickler dazu inspiriert die Benutzeroberfläche des iPhones webbasiert nachzubauen oder eigene Touchscreen-Interfaces für Webseiten zu entwickeln. Ursprünglich erschien mir Sencha Touch, ein plattformübergreifendes Touch-API für mobile Browser, sehr geeignet eine Touch-Oberfläche zu entwickeln, dann bin ich aber durch meinen Kollegen Dr. Daniel Biella auf iWebkit aufmerksam geworden. iWebkit besticht durch seine Einfachheit in der Anwendung, schon rudimentäre HTML-Kenntnisse reichen aus um eine iWebkit-Seite zu erstellen. Auf dem iPhone und iPad sehen iWebkit-Seiten aus wie eine native App und sie laufen auch ganz fabelhaft auf Android- Nokia S60- Palm Pre- und Openmoko-basierten Geräten.

Ein Beispiel

Ob sich die gemeinsame Basis der beiden Smartphone Welten Android und iPhone für eine HTML-basierte, an die Touch-Bedienung angepasste, eigene Oberfläche eignet habe ich anhand eines alten Projektes aus meiner Zeit an der FernUniversität in Hagen, dem Pediaphon, einer Sprachausgabe für die Wikipedia, ausprobiert. Als beispielhafte iWebkit-Anwendung wird hier ein eigenes Pediaphon-User-Interface für Webkit-basierte Mobilbrowser vorgestellt. Die Audioausgabe wird hier mit HTML5 realisiert (deshalb läuft es erst ab Android 2.3 Gingerbread), für Android 2.2 Froyo basierte Telefone gibt es auch eine Flash Alternative. Diese Einschränkung bezieht sich auf die HTML5-Audiounterstützung, nicht auf iWebkit selbst. Apple unterstützt HTML5-Audio schon seit iOS Version 4.

Hier einige Screenshots vom GUI (Auf einem Android 2.3 Gingerbread Emulator, aber auch schon live mit einem Orange San Francisco getestet):

IWebkit Pediaphon Touch-Interface
IWebkit Pediaphon Touch-Interface

Ausprobiert werden kann das Pediaphon iWebkit-Interface hier in Deutsch und in Englisch, Spanisch, Französisch und Italienisch.

 

WLAN-Lokalisation a la Apple, die neuen Datenschutzrichtlinien – noch ein Datenkrake


Hier der zweite Teil des Hands-On, sollte eigentlich nur zum Geolocation API sein, aber aus aktuellem Anlass auch zu Location based Services und Privatsphäre.
Das HTML5 Geolocation API funktioniert im Safari auf dem iPad ganz ausgezeichnet.
Artig fragt hier der Safari um Erlaubnis, gibt aber wohl (wie auch Google-Maps mobile, hatte ich schon im März 2009 vermutet, ganz unten im Artikel) die SSID aller WLANs in der Umgebung an Apple weiter.

Leider gibt es das iPad nur mit verspiegeltem Display, also zum arbeiten nicht zu gebrauchen, schade.

Die Aufregung in der Fachwelt verwundert mich ein wenig. Die Anbieter solcher Location based Services wären doch ohne solche Informationen von den mobilen Clients gar nicht in der Lage ihre Datenbanken aufzufüllen. Den betroffenen Nutzern sollte aber klar sein, dass solche Dinge immer Auswirkungen auf die Privatsphäre haben. Außerdem sind ja nun anscheinend die iPhone- und iPod-Nutzer als Wardriver unterwegs, spüren WLAN-Netze auf und geben diese Informationen an Server in den USA weiter. Mit deutschen Datenschutzgesetzen ist das mit Sicherheit nicht vereinbar. Aber ohne SSID-Datenbanken keine Funktionalität, so einfach ist das. Wer aber nicht möchte das Informationen über seinen Aufenthalt publik werden könnten, darf diese Daten nicht an Google oder Apple weitergeben. Was einfach fehlt ist, wie auch bei sozialen Netzwerken, Sachverstand und ein verantwortungsvoller Umgang mit diesen Techniken.

HTML-Geolocation kann hier (auch einmal ohne Google Maps ;-) ) ausprobiert werden: Openstreetmap HTML5 Geolocation, optimiert für kleine Displays, Android Froyo, iPhone, iPad, iPod touch.

Hands-On Apple IPhone 4 und iPad – HTML5 Audio


Am 8.7.2010 war die Firma Apple für ein Hands-On Kolloquium im ZIM zu Gast. Neben der Vorstellung der iPDU (iPhone Development at University) war auch Zeit für umfangreiche Tests mit den Geräten. Die Apple-Vertreter bewarben iTunes U (iTunes für Universitäten) als Plattform für eLearning Aktivitäten. Meiner Ansicht nach ist es aber Unsinn eLearning Content speziell für Apple-Endgeräte zu entwickeln, und damit andere Plattformen auszuschließen. Auch wegen Apples Preis- bzw. Providerpolitik wird man nicht davon ausgehen können, dass zukünftig alle Studierenden nur mit iPhones lernen, auch wenn viele Entscheider (die ihre Telefone üblicherweise nicht selber bezahlen) nun das mobile Internet über UMTS nutzen können (auch ohne zu wissen was ein APN ist).
Dennoch verfügen die Geräte mit Safari über einen sehr brauchbaren Browser der für webbasiertes mobiles eLearning (mLearning) gut geeignet ist. Der rein politische Boykott von Flash auf diesen Geräten treibt glücklicherweise die Unterstützung von HTML5 voran. Auch der Android-Browser verfügt über eine Webkit-Engine und kann ab Android 2.1 (Eclair) HTML5 interpretieren. Der Audio-Tag soll aber erst ab Gingerbread voll unterstützt werden, das aktuelle Froyo (frozen yogurt) ;-) spielt immer noch kein HTML5-Audio ab. Der eigentliche Tag wird unterstützt nur die Codecs fehlen noch im Browser (getestet mit http://html5test.com/). Also ist auch für Android HTML5-Audiounterstützung nur eine Frage der Zeit.

Leider konnte das mitgebrachte iPhone nicht wirklich ins Netz und hat nur Seiten der Uni angezeigt. Das Display des iPhone 4 ist wirklich erstklassig. Das Gehäuse sieht auch sehr viel besser aus als die alten iPhones, nur die Antennen hat Apple wohl vermurkst. Wer trotzdem schnell und problemlos (dauert nur zwei Wochen, ein Freund hat es ausprobiert) ein iPhone 4 ohne Simlock kaufen möchte kann dies recht komfortabel und sicher per Kreditkarte mit Rechnungsadresse in Deutschland (Steuer) im Apple-Shop-UK tun. (Mit Borderlinx von DHL, siehe auch bei teletarif.de)

Das Hands-On am ZIM (mit einem Koffer voller iPads) war eine gute Gelegenheit für mich in Ruhe mit dem HTML5 Audio-Feature auf dem iPad zu beschäftigen. Ich hatte vorher schon einmal bei einem Elektronik-Discounter das iPad kurz getestet nun konnte ich ohne Zeitdruck sorgfältig testen. Da Apple mit iOS4 nun nach dem mobilen Internet auch das Multitasking erfunden hat ;-) , kann auf dem iPAD die Audiowiedergabe in Safari starten ohne das der Browser wie beim iPhone < 4 und dem iPod touch zugunsten von Quicktime angehalten wird. Leider startet die Wiedergabe trotz korrekter HTML5 Auszeichnung nicht automatisch, auch das hat wohl politische Gründe um die Nutzer von Volumentarifen zu schützen. Leider benötigte ich immer mehrere Versuche um die Wiedergabe auf dem iPad zu starten, wenn es dann einmal lief klappte es danach immer sofort.

Mit Javascript kann man Autoplay aber auch auf dem iPad erzwingen.

Der Teufel steckt leider auch bei HTML5 Audio/Video im Detail, nämlich in der Unterstützung der Codecs. Während wie erwartet die ‘guten’ Mozilla Firefox, Opera und Google Chrome den open source OGG-Container für Audio unterstützen, setzen die ‘bösen’ (Apple Safari [OSX und auch iOS] und Microsoft IE9 ;-) auf MP3. Schade eigentlich, entweder also wieder hässliche Browserweichen in Javascript oder der Nutzer muss per Formular entscheiden wie jetzt beim neuen iPad-konformen Pediaphon.

Wer seinen (möglicherweise mobilen) Browser auf HTML5-Konformität testen möchte kann das bei http://html5test.com/ recht komfortabel tun.