Werner Keil 21. April 2015

Apache DeviceMap

Mobile Geräteerkennung mit DeviceMap. © depositphotos.com / violetkaipa

Tag für Tag überschwemmen mehr Mobiltelefone, Tablets und ähnliche Geräte den Markt. Die Spezifikation jedes Einzelnen genau zu verfolgen, ist ein Knochenjob. Diese Mühe kann man reduzieren, wenn ein sogenanntes Device Description Repository – kurz DDR – beigesteuert wird und Anwender dieses selbst verwalten können.

Apache DeviceMap entstand als Kooperation von OpenDDR und anderen, um ein umfassendes Open Source Daten-Repository mit Geräteinformationen, Bildern und anderen relevanten Informationen für alle Arten von mobilen Geräten zu schaffen, gleich ob Smartphones, Tablets, Smart-TV oder Automotive.

Mobile Geräteerkennung ist beinahe so alt wie die ersten mobilen Geräte mit Netzanbindung. Viele frühen Mobiltelefone nutzten dazu längere Zeit den so genannten WAP-Standard (Wireless Application Protocol). 1999 wurde WAP in der Version 1.1 veröffentlicht, der insbesondere XHTML-Konventionen einbezog. Mit WAP 1.1 konnte sich der Standard auf dem Endgerätemarkt entscheidend durchsetzen und es wurde bald fast jedes datenfähige Mobiltelefon mit einem WAP-Browser ausgestattet. Das nur kurz darauf vorgestellte WAP 1.2 stellte in erster Linie eine Verbesserung von WAP 1.1 dar - darunter Erweiterungen wie etwa der Push-Service und sogenannte User Agent-Profile für WAP-Browser, die es erlaubten, übertragene WAP-Inhalte in ihrer Formatierung komfortabel an die jeweils verwendete Browser-Software anzupassen.

Zu dieser Zeit ging aus dem WAP-Umfeld ein anderes Protokoll hervor: WURFL (Wireless Universal Resource FiLe). Auch wenn das Geschwister-Protokoll WAP mit der Smartphone-Ära praktisch in Vergessenheit geriet, war das bis Mitte 2011 quelloffen gepflegte WURFL-Format relativ beliebt.

Kommerzielle Anbieter

Dass das berühmte „Wall Street“-Zitat „Greed is Good“ von Gordon Gecko die WURFL-Mitbegründer um Luca Passoni veranlasste, das System in die Versenkung zu stoßen, klingt wie der wahrscheinlichste Grund für die Zerstörung des Open Source-Projektes. Ob PHP-Webframeworks wie Zend und Typo3 oder Java Enterprise Frameworks von Spring MVC Mobile bis Red Hat JBoss Mobile, alle namhaften Open Source-Projekte kehrten nach dem proprietären Lizenz-Schluss von WURFL im August 2011 diesem sehr rasch den Rücken – um ihre Nutzer nicht in Lizenz-Konflikt oder gar von WURFL-Vertreiber ScientiaMobile aufgestellte Abo-Fallen zu locken.

Tabelle 1 bietet eine Übersicht über die gängigsten kommerziellen Produkte am Markt. Während kommerzielle Mitbewerber und bis zu gewissem Grad sicher „Vorbilder“ für WURFL etwa noch APIs oder sogar vom Umfang her eingeschränkte Device Repositories unter fair nutzbaren Open Source-Lizenzen von LGPL bis Mozilla anbieten, erlaubt die AGPL gewisser WURFL APIs bestenfalls deren Nutzung gemeinsam mit dem proprietären und kostenpflichtigen WURFL-Service, ist also nicht mehr als eine Open Source-Mogelpackung. Die Tatsache, dass seit 2011 keine WURFL-Java-APIs mehr im zentralen Sonatype Maven Repository zu finden sind, spricht Bände. Und zeigt, dass abgesehen von kommerziellen Produkten oder Abos und direkt damit erwerbbaren proprietären APIs WURFL sonst so gut wie tot ist.

Tabelle 1: Übersicht kommerzieller Systeme zur Geräteerkennung

Projekt	Schwächen	Stärken	Lizenz
MaDDR Projekt	Device Repository funktioniert nur mit kommerziellem mobileAware DDR. APIs beinhalten einfaches Beispiel DDR. Das maDDR Projekt bietet keine adaptive Technologie für optimierte Geräte-Erkennung.	Kompatibel zu W3C Standard	Repository: Nur kommerzielle Lizenz API: Kommerzielle Lizenz oder Simple DDR API mit LGPL Lizenz
DeviceAtlas	Nur kommerzielle Lizenz	Kompatibel zu W3C Standard, Daten werden von verschiedenen, führenden Partnern aus der Industrie geliefert	Repository: Kommerzielle Lizenz API: Kommerzielle Lizenz
Volantis (ab Feb 2011 Antenna, seit Okt 2013 Pegasystems)	Nur kommerzielle Lizenz. Unklare Zukunft nach doppelter Übernahme.	Relativ breite Geräteabdeckung	Repository: Kommerzielle Lizenz API: Kommerzielle Lizenz
WURFL	Die Lizenz erlaubt keine Nutzung des Repositories ohne das kommerzielle API. Die API erlaubt keine Nutzung in Projekten mit eigener Lizenz!	Ehemals gemeinschaftliches Projekt (bis Aug 2011)	Repository: Nutzung ohne WURFL API unzulässig API: Kommerzielle Lizenz, „Alibi“ AGPL, kommerzielle Nutzung unzulässig
51Degrees.mobi	Eingeschränkter Umfang und Nutzungsmöglichkeit freier Daten	Vorhersehbare Produktpalette, .NET Unterstützung	Repository: MPL oder Kommerziell („Pro Edition“) API: Mozilla Public Lizenz
NetBiscuits		Service-basierend. Offenbar recht einfach zu integrieren, so lange man sich auf JavaScript beschränkt.	Repository: N/A API: Kommerzielle Closed Source Lizenz

So gut wie jeder kommerzielle Mitbewerber von WURFL macht wie in Tabelle 1 ersichtlich einen solideren und seriöseren Eindruck. Jene, die wie etwa DeviceAtlas oder Volantis jahrelang mit kommerziellen Partnern, Mobilgerätehersteller u. dgl. kooperiert haben, können dadurch ein teilweise beachtliches Maß an erkennbaren Geräten bieten. Bei Volantis muss erwähnt werden, dass es bereits Anfang 2011 vor der WURFL-Abschottung an Antenna verkauft wurde. Dieses Unternehmen ging wiederum im Oktober 2013 an Pegasystems. Seit der ersten Übernahme fand sich auf der Antenna-Website nie ein Hinweis auf Volantis oder Produkte auf W3C DDR Basis. Es wird also offenbar nicht mehr vertrieben. Andere, insbesondere DeviceAtlas oder MaDDR sind wie die Open Source-Vertreter OpenDDR bzw. Apache DeviceMap zum W3C DDR Standard kompatibel. Und sowohl MaDDR als auch 51Degrees.mobi bieten zumindest in beschränktem Umfang auch Open Source-Daten oder APIs, deren Nutzung nicht durch Knebelverträge oder proprietäre Lizenzen auf „Non Profit“ o.ä. eingeschränkt ist, wie bei praktisch allen anderen kommerziellen Anbietern.

Die Preislisten und -politik der kommerziellen Anbieter können teilweise stark schwanken und sind speziell im Enterprise Segment oft intransparent. In zahlreichen Fällen wurde uns von früheren WURFL-Unterstützern und -Nutzern sogar berichtet, dass deren Vertreter praktisch wie ein Steuerfahnder nach Umsatz oder Gewinn fragte und man die monatlichen Abo- oder Lizenzkosten gerne danach ausrichtet. Dies kann gerade für Start-Ups sehr gefährlich sein, wenn diese mit der Zeit größere Gewinne machen sollten. Daher kann hier nur sehr bedingt darüber Auskunft gegeben werden, was diese Produkte tatsächlich kosten.

Eine Stichprobe bei DeviceAtlas auf Rückfrage im Q&A-Teil eines kürzlich gehaltenen Vortrags ergab, dass der monatliche Lizenz- oder Abo-Preis dort bei ungefähr 400-500 € für „Kleine Systeme“ beginnt. Das deckt nur 1 oder 2 Entwickler ab, sowie eine gewisse Anzahl Geräteerkennungen pro Monat. Kommt man über das hinaus, weil etwa der Blog oder die Website plötzlich populärer wird, dann kostet es natürlich mehr. Auch DeviceAtlas schreibt bei größeren Sites und Unternehmenskunden nur „Auf Anfrage“, dazwischen liegen für „Mittlere Systeme“ Preise von eher 4.000-5.000 €, also rund das 10-fache der Einstiegsklasse. Eine frühere Stichprobe auf der WURFL-Seite von ScientiaMobile brachte grob vergleichbare Ergebnisse, der Einstiegspreis dürfte dort aber noch etwas höher liegen, wobei langfristige Benutzer sagen können, ob man für soviel mehr Geld als selbst angestammte kommerzielle Mitbewerber wirklich vergleichbare oder bessere Ergebnisse bekommt.

Offenbar durch Druck verschiedener Mitbewerber, insbesondere auch durch Open Source Angebote, bietet ScientiaMobile jüngst einen kostenlosen Einstiegs Service namens WURFL.JS an, der sich technisch sehr stark an NetBuiscits orientiert. Die Lizenzbedingungen verbieten jedoch jegliche kommerzielle Nutzung, womit diese "Einstiegsdroge" nur wenig vom sonstigen WURFL/ScientiaMobile Angebot abweicht. Freizeit-Bloggern oder Betreibern strikter Non-Profit-Webseiten mag es aber genügen, sofern ihre Seiten die Traffic-Limits dieses Angebots nicht überschreiten.

W3C DDR

Das World Wide Web oder W3 Konsortium (W3C) hat neben sehr bekannten Standards und Empfehlungen wie HTML5 oder CSS auch etwas weniger bekannte Beispiele hervorgebracht. Darunter die vor etwas über 10 Jahren gestartete Initiative zur Schaffung eines einheitlichen Device Description Repository (DDR). Die W3C Empfehlung „Device Description Repository Simple API“ wurde Ende 2008 verabschiedet [1].

Bevor man dort vom Open Source-Gleis abkam, waren in einigen der W3C DDR-Arbeitsgruppen auch Namen von Leuten zu lesen, die nun WURFL geschlossen hatten und kommerziell zu vertreiben versuchten. Allerdings gaben diese auf Anfrage recht klar zu verstehen, dass selbst das einst noch nach Open Source-Methode entwickelte WURFL (pre 2011) zu keiner Zeit wirklich kompatibel zum W3C DDR-Standard war.

OpenDDR

Als Reaktion auf die Enteignung der Open Source-Gemeinschaft durch die WURFL-Verhüllung unterstützte ich eine Gruppe von Open Source-Entwicklern und Webdesignern, die davor bei WURFL aktiv mitgeholfen hatten und sich durch dessen „Mauerbau“ um die Früchte ihrer jahrelangen Arbeit betrogen fühlten, beim Aufbau einer offenen Alternative. OpenDDR war geboren. Obwohl die wohl einzig vergleichbaren Informationen Dinge wie schlichte Geräte-Signaturen oder „User Agent“-Zeichenfolgen mobiler Browser sind, die jegliches Device Repository in wie auch immer gearteter Form beinhaltet, versuchten die WURFL-Händler, die Entwicklung und Pflege des OpenDDR-Datenbestandes zu sabotieren. GitHub kam dem Take down-Ansuchen zwar anfangs nach, doch wurde nicht zuletzt dank der Natur von Git rasch auf Basis von Forks durch andere Anwender Ersatz geschaffen. Selbst die Open Source „Baseline“ der WURFL.xml-Datei ist bis heute an einigen wenigen Orten im Netz zu finden, speziell bei GitHub. Was lizenzrechtlich völlig legitim ist. Ebenso wie das Angebot von OpenDDR, was man bei ScientiaMobile letztlich einsehen musste, und auch GitHub stellte ab Q1/2012 das OpenDDR Ressource Repository erneut zur Verfügung und es wird seither in regelmäßigen Abständen weiter gepflegt.

Im Herbst desselben Jahres fällte ein UK-Gericht eine Entscheidung – im „Football DataCo“-Prozess [2] den Lizenz-Makler im Auftrag der Britischen Premier League gegen diverse Medien von Yahoo bis zu kleinsten Fanclubs oder Fußfallmagazinen geführt hatten. Das Urteil befand das Einheben einer Lizenzgebühr auf „Allgemeinwissen“ – wie sie die Ergebnisse von Fußballergebnissen letzten Endes darstellen – für unzulässig. Die Kläger mussten jegliche Gerichtskosten bezahlen und wo gegebenenfalls Gebühren zu Unrecht bezahlt wurden, diese wohl auch rückerstatten. Sobald ein neues Mobiles Endgerät auf dem Markt ist, oder manchmal auch schon durch fundierte Vorab-Tests, sind Daten wie etwa die „User Agent“-Signatur und andere Kennzahlen zu diesem Gerät nicht anders als Fußball- oder andere Sportergebnisse ebensolches „Allgemeinwissen“. Es ist somit unzulässig, exklusive Gebühren dafür zu erheben. Niemand wird WURFL oder anderen kommerziellen Portalen verbieten, teilweise 5- oder 6-stellige Beträge von Leuten zu verlangen, die es nicht besser wissen oder für geringfügige Mehrinformation einen vergleichsweise sehr hohen Preis bezahlen. Man verbietet ja auch Glücksspiel um teils horrende Summen fast nirgends auf der Welt, schon gar nicht im Internet. Aber diese Anbieter haben kein Recht, anderen Portalen oder Medien die Veröffentlichung der allgemein gültigen Informationen zu verbieten, erst recht, wenn die Geräte bereits im Handel sind.

Abb.1: JVM Heap Speicher von WURFL. © Werner Keil

Neben dem Kostenaspekt ist WURFL (die jeweils letzte verfügbare Version von DB und Client 2011) selbst verglichen mit dem nicht reduzierten OpenDDR-Vokabular deutlich speicherhungriger, wie Abb. 1 und 2 zeigen.

Abb.2: JVM Heap Speicher von OpenDDR „unreduziert“. © Werner Keil

Während nach anfänglicher Initialisierung und Einlesen der Daten der OpenDDR „W3C Simple“ Client auf einem gleichmäßigen Speicherniveau bleibt, weist der Java WURFL-Client ständige hohe Spitzen auf, die mehr oder weniger der Max Heap Size entsprechen. Das kann insbesondere im Cloud-Umfeld bedeuten, dass entweder ständig Swap Memory konsumiert werden muss, was die Performance empfindlich beeinträchtigt, oder man muss für gleiche Leistung deutlich mehr in echten Speicher investieren. Das mag heute nicht mehr so tragisch wirken, aber gerade in hoch-skalierbaren Servern und Portalen muss man das mit Faktoren wie Hundert oder Tausend multiplizieren. Ganz zu schweigen vom bereits erwähnten finanziellen „Appetit“ von WURFL und ScientiaMobile bei solchen Enterprise-Anwendungsfällen.

Apache DeviceMap

Fast zeitgleich mit der Entstehung des OpenDDR-Projekts machte man sich in der Apache Foundation ähnliche Gedanken und evaluierte verfügbare Open Source-Lösungen. Diese Evaluierung befand OpenDDR als das vielversprechendste Projekt und im ersten Halbjahr 2012 wurden neben dem W3C konformen Device Repository Java- und .NET-Clients von OpenDDR als Initial Contribution zur Verfügung gestellt [3].

Anwender wollen bzw. müssen manchmal die Betriebssysteme ihrer Geräten aktualisieren (auch eigene benutzerspezifische Builds) und/oder einen neuen Web-Browser installieren können. Die Identifizierung eines Gerätes durch den ursprünglichen User Agent, der von Herstellern bereitgestellt wird, ist dann oft nicht mehr ausreichend. Deshalb betrachtet Apache DeviceMap das Gerät als eine Kombination dreier wichtiger Aspekte:

Physical Device
Operating System
Web Browser

DeviceMap kann spezielle Versionen des Betriebssystems und Webbrowser von Drittherstellern erkennen. Falls die Version eines bestimmten Browsers oder ein Betriebssystem nicht genau bekannt ist, liefert DeviceMap die Information der nächst gelegenen Version statt gar keiner. DeviceMap erkennt ein Gerät, einen Browser oder ein Betriebssystem mit einem gewissen Vertrauensgrad. Sie können dessen gewünschte Präzision beim Erkennungsprozess selbst bestimmen. Größerer Vertrauensgrad kann längere Erkennungszeiten bewirken, während geringerer Vertrauensgrad die Erkennung beschleunigt, dabei aber das Risiko weniger präziser Erkennung birgt. DeviceMap erlaubt auch das Patchen der Datenquelle. DeviceMap implementiert die W3C Simple API-Schnittstelle. Es unterstützt das Basisvokabular, das im Dokument zur DDR W3C-Empfehlung festgelegt wurde.

Um DeviceMap Simple API zu nutzen, müssen Sie lediglich Werte einer
derartigen Property-Datei anpassen:

oddr.ua.device.builder.path =   
   PATH_TO_FILE/BuidlerDataSource.xml
oddr.ua.device.datasource.path =
   PATH_TO_FILE/DeviceDataSource.xml
oddr.ua.device.builder.patch.paths =
   PATH_TO_FILE/BuilderDataSourcePatch.xml
oddr.ua.device.datasource.patch.paths =
   PATH_TO_FILE/DeviceDataSourcePatch.xml
oddr.ua.browser.datasource.path =
   PATH_TO_FILE/BrowserDataSource.xml
ddr.vocabulary.core.path = PATH_TO_FILE/coreVocabulary.xml
oddr.vocabulary.path = PATH_TO_FILE/oddrVocabulary.xml
oddr.limited.vocabulary.path =   
   PATH_TO_FILE/oddrLimitedVocabulary.xml
oddr.vocabulary.device = 
   www.DeviceMap.org/oddr-vocabulary
oddr.threshold = 70

Die oddr.threshold-Eigenschaft erlaubt dem Entwickler, den gewünschten Vertrauensgrad festzulegen. In diesem Fall wählten wir einen Vertrauensgrad von zumindest 70%. Zur Erstellung eines Identification-Services nutzen wir die ServiceFactory der W3C DDR-Simple-API.jar

Service identificationService = ServiceFactory.newService
("org.apache.devicemap.simpleapi.ODDRService", 
ODDR_VOCABULARY_IRI, initializationProperties);

Das erste Argument ist die implementierende Klasse des DDRService, das zweite Argument ist das Standardvokabular zur Identifikation, falls kein Vokabular explizit angegeben wurde und das dritte Argument ist die DeviceMap Properties-Datei. Hier ein kurzes Beispiel um “displayWidth-”, “model-” und “vendor-”Eigenschaften aus dem Standardvokabular zu ermitteln:

PropertyRef displayWidthRef;
PropertyRef vendorRef;
PropertyRef modelRef;

try {
       displayWidthRef = identificationService.newPropertyRef("displayWidth");
       vendorRef = identificationService.newPropertyRef("vendor");
       modelRef = identificationService.newPropertyRef("model");
     } catch (NameException ex) {
       throw new RuntimeException(ex);
     } 
[…]

Seit der Graduation des DeviceMap-Projekts aus dem Apache Incubator November 2014 hat sich insbesondere auf Java-Seite einiges bewegt. Aktuell nicht kompatibel nach dem W3C-Standard DDR-Simple aber als sinnvolle Weiterentwicklung entstand ein neuer Java-Client. Dieser lässt unter anderem die Nutzung unterschiedlicher Datenquellen zu, neben Dateien in einem Ordner auch direkt aus einer JAR-Datei oder von einer URL bzw. vergleichbarem Service. Weitere denkbare Varianten sind auch NoSQL-Dateien, u. dgl. Hier ein kurzes Beispiel wie das neue DeviceMap-Client-API aufrufbar ist:

    //create a client object, store this somewhere permanent
    DeviceMapClient client = new DeviceMapClient();

    //load the device data, do this only once!!!
    client.initDeviceData(LoaderOption.JAR);

    //classify a User-Agent string
    String test = "Mozilla/5.0 (Linux; U; Android 2.2; en; HTC Aria A6380 Build/ERE27) AppleWebKit/540.13+ (KHTML, like Gecko) Version/3.1 Mobile Safari/524.15.0";
    Map<String, String> m = client.classify(test);

    //iterate thru the attributes
    for (String attr : m.keySet()) {
        System.out.println(attr + ": " + m.get(attr));
    }

Ausblick

Als nächster Schritt ist vor allem eine neue Datenstruktur angedacht. Mit Abbildung der Gerätesignaturen möglichst in JSON, was auch die Speicherung etwa in NoSQL-Datenbanken erleichtert, und Nutzung durch gängige APIs, die zumeist auf RESTful Web-Services und JSON-Strukturen basieren. Solche Services können in der Folge zur vereinfachten Datenpflege durch Anwender selbst per „Crowdsourcing“ genutzt werden, wo die technische Apache Infrastruktur und Nachvollziehbarkeit eingereichter Updates dies erlauben.
Die Erfassung eines neuen User Agent etwa direkt vom eigenen Gerät ist zulässig, Copy-and-Paste aus anderen speziell proprietären Closed Source-Repositories dagegen nicht. Heute ist dies bereits über den JIRA Issue Tracker von DeviceMap möglich [4].