Java APIs in Android: Der Rechtsstreit ist entschieden

Die Auseinandersetzungen zwischen Oracle und Google um Google’s Nutzung von Java APIs in Android sind offenbar vorbei: Das Oberste Gericht der USA hat entschieden, dass diese Nutzung unter den Fair Use fällt. Neben IT und Tech Seiten wie Heise und The Verge haben auch SPIEGEL und FAZ direkt darüber berichtet. Das Urteil ist spannend zu lesen:

Fast 11 Jahre vor Gericht

Zusammenfassungen der verschiedenen Etappen dieser Auseinandersetzung zwischen den beiden IT Giganten lassen sich an verschiedenen Stellen im Netz finden, für mich verbindet sich die Anfangsphase noch mit intensiven Diskussionen darüber beim schon lange eingestellten Google+. Dort haben sich naturgemäß die eher Google-freundlichen Diskutanten eingefunden, aber die Frage ob Google sich unrechtmäßig der kreativen Leistung anderer bedient hat, oder ob Oracle mit seinem Versuch Programmierschnittstellen nachträglich als urheberrechtlich geschützte Werke zu interpretieren die Softwarewelt aus ihren gewohnten Angeln hebt, war heiß umstritten. Ich war da eher auf der Seite, die Oracles Klagen strikt ablehnte. Die folgende Karikatur aus dieser Zeit zu den Organisationsstrukturen verschiedener IT Unternehmen ist mir daher direkt wieder eingefallen:

Humoristische Organisationscharts verschiedenen US IT Unternehmen: Apple, Google, Microsoft, Oracle, Facebook, Amazon
Comic von Manu Cornet

Interessante Auszüge aus dem Urteil

Das Urteil kann man hier als PDF vom Heise Verlag abrufen. Es ist durchaus lesenswert und auch ohne umfangreiche juristische Kenntnis durchaus verständlich. Ein paar Abschnitte habe ich mir rauskopiert:

‚To decide no more than is necessary to resolve this case, the Court assumes for argument’s sake that the copied lines can be copyrighted, and focuses on whether Google’s use of those lines was a “fair use.”

Das oberste Gericht hat also die für die IT Welt – insbesondere auch die Open Source Community – wesentliche Frage ob eine API überhaupt ganz grundsätzlich ein Urheberrecht haben kann, nicht entschieden. Und da hatte Oracle in früheren Instanzen einen Etappensieg errungen. Auch wenn die Oracles Niederlage nun vielleicht einen abschreckenden Effekt hat, grundsätzlich ist damit zumindest in den USA wohl mit weiteren Verfahren zu rechnen, in denen API-Nutzungen Anlass zu Gerichtsverfahren geben. Und nicht jede Beklagte ist so mächtig und wohlhabend wie Google.

‚Computer programs differ to some extent from many other copyrightable works because computer programs always serve a functional purpose.‘

Das Gericht hat sich aber Gedanken dazu gemacht, in wie weit das Urheberrecht eigentlich auf Software angewendet werden kann.

‚As a result, this code is different from many other types of code, such as the code that actually instructs the computer to execute a task. As part of an interface, the copied lines are inherently bound together with uncopyrightable ideas (the overall organization of the API) and the creation of new creative expression (the code independently written by Google). Unlike many other computer programs, the value of the copied lines is in significant part derived from the investment of users (here computer programmers) who have learned the API’s system.

Hier macht das Gericht zum ersten, aber nicht zum letzten Mal, einen interessanten Punkt: Eine API – zumindest die, um die es hier konkret geht – gewinnt dadurch an Wert, dass Programmierer*innen sie erlernen und dafür Zeit investieren. Damit wird die Wertgenerierung nicht mehr allein den Erschaffer*innen zugebilligt, sondern jede Java Entwickler*in, die diese APIs gelernt hat, vergrößert durch ihr Investment den Wert der Sprache.

‚Google copied only what was needed to allow programmers to work in a different computing environment without discarding a portion of a familiar programming language.‘

Auch hier wird wieder der Verweis auf das existierende Knowhow von Entwickler*innen gemacht und das es Googles Vorgehensweise diesen ermöglicht habe ihr Wissen nun in einem weiteren Umfeld zu nutzen. Dieses Wissen also wertvoller wurde.

‚Google copied approximately 11,500 lines of declaring code from the API, which amounts to virtually all the declaring code needed to call up hundreds of different tasks. Those 11,500 lines, however, are only 0.4 percent of the entire API at issue, which consists of 2.86 million total lines. In considering “the amount and substantiality of the portion used” in this case, the 11,500 lines of code should be viewed as one small part of the considerably greater whole. As part of an interface, the copied lines of code are inextricably bound to other lines of code that are accessed by programmers. Google copied these lines not because of their creativity or beauty but because they would allow programmers to bring their skills to a new smartphone computing environment.‘

Und noch einmal der Verweis auf die Möglichkeit für Entwickler*innen ihr Knowhow in einer neuen Umgebung zu nutzen. Verbunden mit der Entlastung von Google, die eine vergleichsbare API oder gleich eine ganze Programmiersprache auch leicht hätten selbst entwickeln können (was sie in späteren Jahre mit Dart und Go taten).

‚The fourth statutory factor focuses upon the “effect” of the copying in the “market for or value of the copyrighted work.” §107(4). Here the record showed that Google’s new smartphone platform is not a market substitute for Java SE. The record also showed that Java SE’s copyright holder would benefit from the reimplementation of its interface into a different market

Mir persönlich gefällt, dass das Gericht den positiven Einfluss von Android auf das ganze Java Ökosystem hier honoriert. Schon bei den ersten Diskussionen gab es diesen Punkt, wenn es Oracle wirklich darum gegangen wäre Java zu pushen, dann hätten sie direkt mit Google zusammenarbeiten können. Und offenbar ist im Laufe der Jahre das Argument von Oracle verloren gegangen, wonach Google mit Android das ‚florierende‘ Ökosystem von Java ME Handys vernichtet habe.

Die Entwickler*innen als eigene Partei

Abgesehen von der eigentlichen Urheberrechtsfrage, die vermutlich in anderen Gerichtsverfahren – vielleicht nicht nur in den USA – entschieden wird, finde ich den Aspekt, das wir als Entwickler*innen eine wesentliche Rolle in solchen Erwägungen spielen, sehr spannend:

Wenn wir uns auf eine Sprache / API / Technologie einlassen kostet uns dies Zeit und vielleicht auch Geld und eine Technologie kann sich kaum durchsetzen ohne eine entsprechende Menge von Menschen, die sich damit gut auskennen. Und unsere Interessen sind dabei durchaus anders als die der potentiellen Urheberrechtsinhaber*innen: Für uns ist es attraktiv die Wahl zu haben, zwischen Werkzeugen und zwischen Implementierungen einer API, und jedes neue Feld, in dem wir unsere Kompetenz einsetzen können, ist zunächst einmal gut für uns und den Wert unseres Wissens.

Man wird sehen, ob dieser Aspekt auch in zukünftigen Gerichtsverfahren eine Rolle spielen wird.

Update | Mit der Spiegelreflexkamera in die Cloud: Mein Fotoworkflow mit Eyefi Karte, Smartphone und Photos

Vor fast vier Jahren habe ich in dem Blogpost ‚Mit der Spiegelreflexkamera in die Cloud: Mein Fotoworkflow mit Eye-Fi Karte, Smartphone und Google+‚ meinen damaligen Workflow zum Umgang mit den Fotos beschrieben, die ich mit der Spiegelreflexkamera mache. Der Originaltext ist unten noch einmal angehängt, hier gibt es dazu ein kleines Update, was sich in der Zwischenzeit geändert hat – und was nicht:

Google+ ist heute Google Fotos

Weiterhin landen meine Fotos bei Google, nur das die Fotofunktion schon 2015 aus Google+ ausgegliedert und seit dem im spezialisierten Produkt Google Photos gelandet ist. Google Photos hat den Umgang mit den 100.000+ Fotos, die ich dort abgelegt habe, auf ein Level gehoben, welches noch vor wenigen Jahren kaum vorstellbar war:

Auf jedem Gerät, welches eine halbwegs brauchbare Internetverbindung hat, stehen mir meine Bilder der letzten ca. 20 Jahre in Sekunden zur Verfügung. Und selbst Suchen, die ich nie durch entsprechende Alben oder Fotobeschriftungen antizipiert habe, lassen sich meist schnell über die immer leistungsfähigere Bilderkennung durchführen.

Es ist schon Jahre her, seit ich das letzte Mal Fotos direkt vom Smartphone auf einen PC übertragen haben, heute läuft alles über Google Photos. Tatsächlich habe ich in diesem Moment wohl kein vollständiges Backup meiner Fotos zu Hause.

Weniger Bilder mit der Systemkamera, mehr mit dem Smartphone

Der Umgang mit Fotos, die nicht bereits auf dem Smartphone entstanden sind, ist in den letzten Jahren – zumindest wenn man die Anzahl der gemachten Fotos vergleicht – weniger wichtig geworden: Seit ich mir das Nexus 6P Ende 2015 zugelegt habe waren die Bilder, die vom Smartphone kamen, in vielen Fällen besser bzw. gefälliger als das, was die Systemkamera produzierte:

In diesem Album wird eine Reihe von Dämmerungsbildern des Nexus 6P mit Fotos der Sony Kamera verglichen. Man kann hier über die Farbtreue diskutieren, aber die meisten BetrachterInnen würde vermutlich die Bilder des Smartphones bevorzugen. Seit ich auf das Pixel 2 umgestiegen bin ist die Leistungsfähigkeit der Smartphonekamera noch weiter gestiegen.

 

Eyefi ist heute Keenai

Meine alte Eyefi Karte wird inzwischen nicht mehr richtig auf der Softwareseite unterstützt, und sie war auch nur 4 GB groß. Beim Neukauf einer Karte war ich zunächst verblüfft über die Stolpersteine, die einem bei der Inbetriebnahme dieses über Amazon als neu vertriebenen Produkts begegnen:

Alle – wirklich alle – Links, die man auf der Packung findet, landen auf nicht mehr funktionierenden Seiten. Es scheint, also sei die http://www.eyefi.com/ heute wenig mehr als ein Platzhalter für einige Werbebotschaften, aber ansonsten komplett von jeder Funktion entkleidet.

Sucht man dann im Play Store nach ‚eyefi‘ findet man keine einzige App, die auf den ersten Blick so aussieht, als sei sie eine offizielle App zu der Karte. Allerdings stellt sich dann der erste Treffer – die Keenai App –  tatsächlich als die richtige heraus. Und etwas googlen bringt einen dann zu dieser Meldung, die den Übergang von Eyefi auf Keenai erläutert.

Ist man so weit gekommen geht die Inbetriebnahme der neuen Karte über das Smartphone nichts mehr im Weg, im Gegensatz zum früheren Modell ist kein PC mehr notwendig. Die Registrierung in der Keenai Cloud habe ich dann direkt abgeschaltet, da mir die Funktionen keinen Nutzen bietet. Gefühlt geht die Übertragung der Fotos mit dem neuen Karte schneller, allerdings fällt das bei mir mit dem Wechsel auf das Pixel 2 zusammen.

Der Blogpost von Anfang 2014

Mit dem Start von Google+ und der genialen Möglichkeit quasi unbegrenzt viele Bilder in der Google Cloud abzulegen hat sich mein Umgang mit den selbst geschossenen Bildern komplett umgestellt: Das wichtigste Ziel ist es jetzt alle Bilder möglichst schnell zu Google+ zu schicken, denn das ist der Ort, an dem ich heute nahezu ausschließlich auf meine Bilder zugreife.

Bei den Bildern, die ich mit dem Smartphone mache, ist das geschenkt: Einfach die Option für die Automatische Sicherung aktivieren und der Rest geht – wie versprochen – automatisch. Bei den Bildern von meiner Spiegelreflexkamera bzw. neuerdings meiner Systemkamera geht es aber erst einmal nicht ganz so direkt. Den Workflow, den ich dabei für mich gefunden habe, möchte ich hier einmal beschreiben:

Man wird bequem

Der zunächst naheliegendste Weg wäre es die Bilder von der Kamera – wie früher auch – auf den PC zu kopieren und von dort zu Google+. Aber zum einen gibt es die automatische Google+ Foto Synchronisation für Windows PCs erst seit Mitte Dezember letzten Jahres. Zum anderen ist es erstaunlich, wie lästig einem das Hantieren mit Kabeln werden kann, wenn die ganze andere Kommunikation zwischen den Geräten erst einmal über das Netz bzw. die Cloud funktioniert. Auch ist das keine Lösung für den manchmal dringlichen Wunsch ein irgendwo im Wald gemachtes Foto gleich mit dem Rest der Welt auf Instagram oder Google+ teilen zu wollen.

Die Lösung: Eye-Fi

Meine Lösung für alle diese Bedarfe: Die Eye-Fi WiFi-SD-Karte. Diese Karten bauen ein eigenes WLAN auf, sobald sie mit Strom versorgt sind, und das Smartphone kann über eine vom Hersteller mitgelieferte App eine Verbindung aufbauen. Über diese Verbindung werden die Bilder direkt übertragen und liegen dann auf dem Smartphone, (fast) so wie die direkt mit dem Phone gemachten Bilder.

Als zusätzlichen Bonus kann die Smartphone App die Bilder noch mit GPS Tags versehen, sofern man der App gestattet entsprechende Daten zu sammeln und die Uhren von Phone und Kamera synchron sind. Es reicht also auch eine ganz ‘dumme’ Kamera zu verwenden, ohne eigene WiFi- und GPS-Funktion.

Mein Workflow von A-Z

Und so sieht dann mein Workflow ganz konkret aus:

  1. Mit der Kamera werden viele tolle Bilder geschossen.
  2. Entweder schon während des Shootings oder auch erst später, falls das Smartphone gerade nicht in Reichweite sein sollte, werden die Bilder übertragen und von der App mit GPS Tags versehen.
  3. Die Bilder landen dabei in einem Ordner, der nicht von der automatischen Sicherung der G+ App erfasst wird. Das scheint sich nicht ändern zu lassen, gibt mir aber eine Gelegenheit eine Sichtung durchzuführen und die Bilder gleich zu verwerfen, die unbrauchbar sind. Auch könnte ich nun schon die ersten Bilder bearbeiten und online stellen. Meine Bildbearbeitung hat sich heute fast komplett auf das Smartphone verlagert. [UPDATE: Mit der heutigen Version der Google+ App kann man auch andere Ordner auf dem Smartphone automatisch hochladen lassen. Ich habe aber bisher meinen manuellen Workflow beibehalten.]
  4. Danach verschiebe ich die verbliebenden Bilder in den Ordner, in dem die Smartphone Kamera ihre Bilder speichert. Ich nutze dazu Quickpic, die Foto App, die es bisher immer auf meine Android Smartphones geschafft hat.
  5. Die Bilder werden dann zu Google+ hochgeladen, sobald ich wieder ein WLAN erreicht habe.
    Nach dem Hochladen sortiere ich einige Bilder über die Google+ Fotos App – die sich in den letzten Monaten unglaublich gemacht hat – in bestimmte Ordner, so dass auch die Organisation der Bilder gleich über das Smartphone erfolgt.
  6. Alle paar Monate mache ich schließlich ein komplettes Backup der Bilder von meinem Smartphone. Das ist heute das einzige Mal, dass ich einen normalen PC verwende. Auch dabei habe ich es mir angewöhnt kein Kabel mehr zu verwenden, ich hole mir die Bilder per WLAN mit der AirDroid App.

Für mich ist das im Moment ein nahezu optimaler Ablauf.

Die Nutzung der Eye-Fi Karte war für mich auch beim gerade erfolgten Neukauf einer Kamera ein Argument dafür auf teure Zusatzfunktionen wie integriertes WiFi und GPS zu verzichten.

BoringSSL und die FIPS 140-2 Zertifizierung

Vor inzwischen mehr als 3 Jahren verkündete Adam Langley in seinem Blog den Beginn der Arbeiten an BoringSSL, einem Fork von OpenSSL, der speziell auf die Anforderungen von Google zugeschnitten ist. Anlass waren die verschiedenen Probleme in SSL/TLS Implementierungen, insbesondere der Heartbleed Bug in OpenSSL, der damals für viel Aufsehen sorgte. Mit BoringSSL schuf Google sich eine bereinigte SSL/TLS Implementierung, die schon knapp ein Jahr später in die großen Google Produkte Chrome & Android einging und zum Betrieb der Google Services im Netz verwendet wurde. Für Google ist das Projekt offenbar ein Erfolg, da sie damit endlich eine einheitliche Basis für diesen sicherheitsrelevanten Code schaffen konnten, die sie nach eigenem Gutdünken weiterentwickeln können.

Ist BoringSSL eine Alternative?

Wer OpenSSL einsetzt, oder LibreSSL, den anderen damals entstandenen Fork, kann sich die Frage stellen ob ein Library, welches von Google entwickelt wird, vielleicht die bessere Alternative ist? ‘Besser‘ ist dabei ein Adjektiv mit mehreren Aspekten, darunter Rückwärtskompatibilität (mit OpenSSL), Stabilität, Sicherheit, Codereife, Funktionsumfang und Lizenzierung. Google stellt auf der BoringSSL Seite dazu diese Hinweise direkt an den Anfang:

“BoringSSL is a fork of OpenSSL that is designed to meet Google’s needs.

Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don’t recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.

Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.”

Das kann man nicht gerade als aktives Werben um neue NutzerInnen verstehen. In jedem Fall muss man damit rechnen einen gewissen ’Preis’ für die Nutzung eines leistungsfähigen, von einem hochkompetenten Entwicklerteam weiterentwickelten Pakets zu bezahlen, und zwar in Form vorzuhaltender eigener Entwicklerkapazitäten, damit man im Fall von Änderungen an BoringSSL in den eigenen Produkten entsprechend nachsteuern kann. Auf der anderen Seite ist heute das Risiko eines kompletten Refactorings von BoringSSL wohl eher gering, dazu ist selbst Google nicht mehr so ohne weiteres in der Lage angesichts von Millionen – oder gar Milliarden – von Android Geräten, die sich nur schwer aktualisieren lassen.

Seit ein paar Tagen gibt es eine neue Seite im BoringSSL Repository, die das Thema der FIPS Validierung behandelt. Dabei geht es nicht um das komplette Projekt, sondern um einen Teilbereich, genannt BoringCrypto. Dies könnte für Unternehmen, die nur entsprechend zertifizierte Produkte einsetzen dürfen (Finanzbereich, etc.), noch einmal einen Stolperstein bei der Nutzung beseitigen. Aber was ist FIPS 140-2 eigentlich und verbessert es wirklich die Sicherheit von BoringSSL?

Was ist FIPS 140-2 und was macht es ‘sicher’

Der ‘Federal Information Processing Standard (FIPS) Publication 140-2’ ist ein Standard der US Regierung, der – ausgeführt vom NIST – Anforderungen an kryptographische Module sowohl in Hardware wie auch Software definiert. Er legt damit verbindlich fest welche Anforderungen an entsprechende Module gestellt werden (z. B. in Form einer Liste der notwendigen/zulässigen kryptographischen Algorithmen) und auch das Verfahren, über das Anbieter entsprechender Produkte diese Zertifizierung erhalten können. Dabei wird in 4 Level unterschieden, die jeweils immer höhere Anforderungen stellen, z. B. in Bezug auf die Verhinderung bzw. Feststellung von Manipulationsversuchen.

Dieser Standard ist neben den Common Criteria wohl der wichtigste IT Sicherheitsstand weltweit. Eine FIPS Zertifizierung erhöht damit die Sicherheit eines Produkts in jedem Fall. Oder?

Die Snowden Enthüllungen

Eine Anforderung im FIPS Zertifizierungsprozess ist die Garantie, dass eine zertifizierte Software sich selbst auf Konsistenz prüfen kann. Siehe dazu im letzten Abschnitt mehr. Dies kann nur auf eine Weise erreicht werden, die man aus heutiger Sicht nicht mehr unbedingt als letzten Stand der sicherheitsbewussten Programmierung sehen muss. In der BoringSSL Seite zu FIPS findet sich daher an einer Stelle der Satz

‘This might make building ROP chains easier for an attacker, but so it goes.’

Ein weiterer Kritikpunkt – der z. B. in der entsprechenden OpenSSL Seite vorgebracht wird – ist die Langsamkeit des Zertifizierungsprozesses. Nun braucht eine sorgfältige Zertifizierung ihre Zeit, aber auf der anderen Seite ist es heute wichtiger denn je bei gefundenen Fehlern schnell Bugfixes verbreiten zu können. Denn selbst nach einer Zertifizierung ist es unwahrscheinlich, dass jeder einzelne Fehler gefunden wurde. Wenn aber eine Fehlerkorrektur dann eine erneute Zertifizierung erforderlich macht vergehen schnell mal einige Monate. In dieser Zeit haben Angreifer dann ausgerechnet in den Industrien mit besonderen Sicherheitsanforderungen, die zur Nutzung FIPS-zertifizierter Lösungen gezwungen sind, ggf. leichtes Spiel.

Ein letzter, massiver Kritikpunkt entsteht allerdings aus dem mit den Snowden Enthüllungen massiv gewachsenen Misstrauen gegen die US-Geheimdienste und ihre Verquickungen mit den Standardisierungsbehörden. Insbesondere betraf dieses Misstrauen damals einen in den Standard gebrachten Algorithmus zur Generierung von Zufallszahlen, der immer schon von Kryptographen misstrauisch beäugt worden war, sich nun aber als sehr wahrscheinlich mit einer bewusst konstruierten Hintertür versehen erwies. Durch die langsamen Standardisierungsprozesse war es dann ein sehr zeitaufwändiger Prozess diesen Algorithmus aus Produkten zu entfernen, bis dahin schlummerte er als potentielles Einfallstor in den als ‘sicher’ zertifizierten Produkten.

Insgesamt ist die Sache also ein zweischneidiges Schwert, und für EntwicklerInnen eines Libraries wie BoringSSL immer mit der Frage verbunden was ihnen wichtiger ist: Ein Produkt zu entwickeln, welches nach den bekannten Maßstäben der IT Sicherheit ganz vorne ist, oder zusätzlichen, teilweise bürokratischen Aufwand auf sich nehmen um am Ende bei einem möglicherweise in Teilaspekten weniger sicheren Produkt zu landen, welches dafür dann aber in besonders sicherheitsbedürftigen Bereichen eingesetzt werden – und dort vielleicht andere, weniger gut gepflegte Lösungen verdrängen – kann. Oder den Aufwand noch weiter zu erhöhen und parallele Stränge des eigenen Produkts zu pflegen, die beiden Anforderungen gerecht werden.

Wie macht man Software FIPS kompatibel

Aber nun wieder zurück zu der Frage welche Anforderungen eigentlich entstehen, wenn man eine C/C++ Programmierung mit den FIPS Vorgaben in Einklang bringen will?

‘FIPS-140 mandates that a module calculate an HMAC of its own code in a constructor function and compare the result to a known-good value. Typical code produced by a C compiler includes large numbers of relocations’

Wie man diesen Spagat löst, darüber geht der größere Teil der BoringSSL Seite und er erklärt auch recht gut wie ein C/C++ Compiler im Detail vorgeht und welche Dinge man ihm abgewöhnen muss, damit dieses Ziel erreichbar wird. Möglicherweise haben die Google Leute hier nur damit begonnen die Erfahrungen nachzuhalten, die sie entweder selbst gemacht haben oder große Android Nutzer wie Samsung (PDF), die auf BoringSSL basierende Komponenten bereits in den FIPS Prozess eingebracht haben.

Zwei Jahre Android Security Rewards – Was hat sich verändert?

Vor nun zwei Jahren hat Google mit den Android Security Rewards sein spezielles Bug-Bounty-Programm für Android gestartet. Kurz bevor mit den ersten Stagefright Sicherheitslücken die Kritik an der damaligen, desolaten Sicherheitslage Androids ein Allzeithoch erreichte. Im Android Entwicklerblog hat Google nun ein Fazit dazu gezogen, wie sich die Situation seit damals entwickelt hat. Der Post ist recht kurz, aber trotzdem in seinen Details interessant:

Android Update - Rot

Ein steter Strom von Bugreports

Man kann wohl sagen, dass dieses Bug-Bounty-Programm heute funktioniert: Im letzten Jahr sind mehr als 450 Reports eingegangen. Es vergeht damit wohl kaum ein Tag bei Google, an dem nicht eine Fehlermeldung eintrifft. Das ist zunächst einmal ein echter Erfolg, auch wenn daraus natürlich Schlagzeilen entstehen wie z. B. diese hier: „Android Was 2016’s Most Vulnerable Product.

Da Google den Android Quellcode im Android Open Source Project (AOSP) veröffentlicht kann sich hier faktisch jedeR an der Fehlersuche beteiligen und damit Geld und Anerkennung verdienen. Und tatsächlich tut dies eine große Zahl von Leuten.

In gewisser Weise bestätigt Android damit das von Open Source Verfechtern gern ins Feld geführte Argument, wonach die Offenheit auch gleichzeitig für eine bessere Sicherheit sorge, weil eben viele Menschen ohne große Hürden nach Fehlern suchen können. Auf der anderen Seite zeigt aber der Erfolg des Bug-Bounty-Programms auch was für ein wichtiger Faktor der finanzielle Anreiz sein kann. Dieser Anreiz fehlt bei vielen Open Source Projekten.

Mehr Geld, mehr Bugreports?

1,1 Millionen Dollar hat Google laut dem Bericht in den letzten 12 Monaten ausgeschüttet, was einer durchschnittlichen Summe von mehr als 10.000$ pro Sicherheitsforscher entspräche. Natürlich gibt es Personen / Gruppen, die durch besonders viele Meldungen herausstechen, Google selbst hebt hier das C0RE Team hervor, welches allein 118 Reports eingereicht und dafür 300.000$ erhalten hat.

Die höchsten Belohungsstufen wurden dabei aber bisher nicht erreicht, Google hebt diese Belohnungen nun auf das 4- bzw. 5-fache der bisherigen Werte. Damit könnte man nun 6-stellige Summen allein für einen einzigen Bugreport erhalten.

Google steht hier – wie heute alle großen IT Unternehmen – in starker Konkurrenz zu staatlichen Stellen aus aller Welt, die für ihre Geheimdienste nach ‚Cyberwaffen‘ Ausschau halten und sich dazu privater Dienstleister bedienen, für die die Suche nach Einbruchsmöglichkeiten in populäre Software zu einem profitablem Geschäft geworden ist. Hier kann man mit einem funktionierenden Exploit in das weltweit meistgenutzte Betriebssystem vermutlich noch weitaus höhere Gewinne erzielen.

Das ein hoher Belohnungspreis ein Bug-Bounty-Programm nicht automatisch erfolgreich machen muss hat der gescheiterte Versuch von Googles Project Zero gezeigt: Dieses wollte mit dem Project Zero Price ein eigenes Programm auf die Beine zu stellen, welches ebenfalls 6-stellige Summen für hochwertige Angriffe auf Android in Aussicht stellte. Es erhielt aber keine einzige relevante Einreichung und wurde wieder eingestellt.

Ein breiter aufgestelltes Programm wie die Android Security Rewards kann da durchaus erfolgreicher sein, auch wenn bzw. gerade weil seine Belohnungsstaffelung bei deutlich kleineren Summen beginnt: Dadurch erhöht sich die Zahl der beitragenden ForscherInnen und der Versuch einzelne Fehler zu horten, bis sie sich zu einem leistungsfähigeren Exploit kombinieren lassen, ist dann mit dem großen Risiko verbunden, dass jemand anderes einen der Fehler findet, die Belohnung erhält und Google die Lücke schließt.

Welche Geräte sind für sicherheitsbewusste Android NutzerInnen kaufbar?

Im Oktober 2015 – gezwungen durch das Stagefright Debakel – entschied sich Google einen lange überfälligen Schritt zu machen: Damals begann das Programm der monatlichen Android Sicherheitsupdates. Bis dahin gab es den absurden Zustand, in dem Google Meldungen über Sicherheitslücken zwar einsammelte, aber faktisch niemand zeitnah davon profitieren konnte. Durch die neuen Updates waren zuerst nur die direkt von Google kontrollierten Android Geräte wieder auf einem akzeptablen Sicherheitslevel, aber allmählich auch die Produkte einiger anderer Hersteller.

Android Upate

Und auch darüber gibt der aktuelle Blogpost Auskunft: Bei welchen Herstellern von Android Geräten ist meine Chance groß, dass diese zeitnah Sicherheitsupdates bekommen? Google sagt dabei zum einen dies:

Over 100 device models have a majority of their deployed devices running a security update from the last 90 days

Die dann gezeigte Tabelle mit konkreten Geräten lässt trotz ihrer etwas anderen Semantik (‚This table shows the models with a majority of deployed devices running a security update from the last two months‘) eigentlich nur einen Schluss zu: Wer keines der wenigen direkt von Google kommenden Gerät kaufen kann oder will, der sollte zu einem Samsung Gerät greifen. Samsung hat mit Abstand die größte Zahl von Geräten in dieser Liste und kann damit wohl als Vorbild bei der Updatepolitik gelten (wobei es hier wohlgemerkt nicht um Updates der Android Version geht, dass ist noch mal ein ganz anderes Thema).

Fazit: Auf dem richtigen Weg (aber der Weg ist noch weit)

Google ist es augenscheinlich gelungen ein lebendiges Umfeld von Sicherheitsforschern zu schaffen, die zur Android Sicherheit beitragen. Die ausgeschütteten Summen – auch wenn es sich dabei inzwischen um einen Millionenbetrag handelt – sind dabei vermutlich immer noch ‚günstig‘. Muss man das Fazit ziehen, dass Android angesichts der weiterhin hohen Zahl von monatlichen Fehlerkorrekturen besonders unsicher ist?

Das finde ich schwer zu beurteilen, auch andere (Betriebs-)Systeme haben durchaus ansehnliche Zahlen an korrigierten Fehlern vorzuweisen und faktisch ist jeder korrigierte Fehler einer weniger, den jemand anderes schon im Geheimen gefunden und ausgenutzt haben könnte. Nur falls auch in den kommenden Jahren die Zahl der in Android gefundenen Fehler so hoch bleibt wäre das ein sicheres Zeichen, dass mit der Codebasis bzw. der Weiterentwicklung etwas grundsätzlich nicht in Ordnung ist.

Weiterhin das größte Problem des Android Ökosystems ist aber das Fehlen von Updates für die Masse der inzwischen mehr als 2 Milliarden Geräte. Auch wenn Google die ‚mehr als 100 Modelle‘ nicht genau benennt, bei denen die Mehrheit der NutzerInnen wenigstens ein maximal 3 Monate altes Sicherheitslevel erreicht hat, kann man auf Grund der Vielzahl von Android Geräten – siehe die immer wieder gern zitierte Auswertung von OpenSignal aus dem Jahr 2015 – davon ausgehen, das dies nur ein Bruchteil der in aktiver Nutzung befindlichen Geräte ist.

Auch hier muss es die Zeit erst zeigen, ob die Seamless Updates, die mit Android N eingeführt wurden, und die in Android O mit dem Project Treble geplante stärkere Separierung von Betriebssystemteilen in der Lage sein werden eine signifikante Verbesserung zu bringen. Angesichts der gewohnt langsamen Ausbreitung neuer Android Versionen kann man von diesen Verbesserungen aber bestenfalls in einigen Jahren einen sichtbaren Effekt erwarten.

Bis dahin wird es wohl insbesondere den im Hintergrund von Google durchgeführten Prüfungen im Play Store und auf den Endgeräten überlassen bleiben Angriffe zu verhindert.

Google baut eine eigene Root-CA auf

Vor ein paar Tagen hat Google in seinem Security Blog bekannt gegeben selbst zu einer Zertifizierungsstelle (Certificate Authority / CA) zu werden. Diese kann man unter der Adresse https://pki.goog/ erreichen. CAs sind heute entscheidende Stellen in der Public Key Infrastructure (PKI) des Webs, die erst die sichere Kommunikation z. B. zwischen Webbrowser und Webserver ermöglichen.

Welches Problem will Google damit für sich lösen?

Google ist zum einen ein Unternehmen, welches einen enormen Bedarf an Zertifikaten hat, der durch zwei Faktoren bedingt wird:

  1. Die schiere Anzahl der zu sichernden Onlinedienste
  2. Googles schnelle Zertifikatsrotation, die Zertifikate heute nach 3 Monaten auslaufen lässt

Dann hat Google das Thema der IT Sicherheit wie kaum ein zweites Unternehmen im Blick und treibt es an allen Ecken voran, auch im Bereich der Zertifizierungsstellen. Gleichzeitig sind Google Zertifikate oft das Ziel bei Kompromittierungen von Zertifizierungsstellen, da Googles Dienste nun mal von vielen Nutzern besucht und damit für Angreifer besonders wichtig sind.

Google hat hier  in den letzten Jahren über seine Marktmacht mit Chrome als dominierendem Webbrowser und Android als dominierendem Mobilbetriebssystem immer mal wieder kräftig an den Zügeln gezogen, wenn eine CA Mist gebaut hat.

Was stimmt nicht mit mit dem heutigen System der Zertifizierungsstellen?

Das heute existierende System der Zertifizierungsstellen ist in der Lage unsere Webbrowser-Webserver-Kommunikation gegen massenhaftes Abhören zu sichern, wenigstens seit es Initiativen wie Let’s encrypt gibt, die Serverbetreibern die dazu notwendigen Zertifikate kostenfrei und mit geringem Aufwand automatisiert zur Verfügung stellen können. Die Verschlüsselung ist aber nur der eine Aspekt bei einer PKI: Der andere ist die Sicherstellung der Authentizität meines Kommunikationspartners. Damit ist gemeint, dass ich – wenn ich z. B. auf ‘https://www.google.com’ gehe – auch tatsächlich direkt auf einer zu Google gehörenden Webseite lande, und nicht auf einer gefälschten Seite bzw. über einen mithörenden Mittelsmann kommuniziere.

Hier kommen die CAs ins Spiel, die mir garantieren sollen, dass das Zertifikat, welches mir beim Besuch von google.com präsentiert wird, auch tatsächlich Google gehört. Eine CA kann dabei ihre Aufgabe nur erfüllen, wenn sie es schafft mit ihren Wurzelzertifikaten in die gängigen Webbrowser und Betriebssysteme aufgenommen zu werden. Damit ihr das gelingt muss sie ihre Sorgfalt bei der Vergabe von Zertifikaten beweisen.

So weit, so gut. Ein grundlegendes Problem ist dabei allerdings, dass mein Webbrowser danach zunächst jeder der mitgelieferten CAs uneingeschränkt vertraut. Dies sind im Firefox heute mehr als 150 Zertifikate von mehr als 50 Herausgebern und jedes Zertifikat – und sogar davon abgeleitete Unterzertifizierungsstellen – ist in der Lage ein ‘gültiges’ Zertifikat für google.com zu unterzeichnen. Natürlich muss so etwas immer mal wieder schief gehen, Beispiele siehe oben.

Google hat hier in den letzten Jahren in mehreren Schritten versucht diese Probleme zumindest teilweise in den Griff zu bekommen:

  • Certificate Pinning in Chrome: In Chrome ist ein kleines Set von CAs fest einkodiert, die prinzipiell für Google Zertifikate ausstellen könn(t)en. Dadurch hat sich Chrome in den vergangenen Jahren immer wieder als Melder von Verstößen gegen die Sicherheit oder die Regelungen von CAs erwiesen.
  • Dieser Ansatz ließ sich natürlich nicht auf das komplette Web skalieren, von Google kommt daher das inzwischen in einem RFC definierte HPKP, welcher aber noch nicht alle Browser unterstützen. Auch schützt es Benutzer nicht beim ersten Besuch einer Webseite.
  • Abkehr von SHA-1: Die Ablösung von SHA-1 als Signaturalgorithmus für Zertifikate wurde von Google besonders aggressiv vorangetrieben.
  • Certificate Transparency (CT): Dieses Projekt beschreibt wie ein endloses Logbuch aller jemals von CAs ausgegebenen Zertifikate effizient geführt und online zugreifbar gemacht werden kann. Es gibt eine Implementierung von Google, aber inzwischen auch von CAs. Certificate Transparency ermöglicht es Webseitenbetreibern gezielt zu prüfen ob für ihre Webseiten illegitime Zertifikate ausgestellt wurden.
  • Chrome und CT: Google hat für den Herbst 2017 angekündigt, dass Chrome beginnen wird bestimmte Zertifikate nur noch dann zu honorieren, wenn die Certificate Transparency verfügbar ist.

Google hat die CAs hier in den letzten Jahren teilweise vor sich hergetrieben und sich damit durchaus einiges an Kritik eingefangen. Für Google selbst ist der Aufbau einer eigenen CA vermutlich nur ein letzter Baustein in einem System, dass sie bereits mit einem Browser (Chrome), Betriebssystemen (Android, ChromeOS), Protokollen (SPDY und QUIC) und einigen der wichtigsten Internetdienste der Welt nahezu vollständig im Griff haben und weiterentwickeln möchten. Google schafft sich damit nun auch an dieser Stelle ein eigenes Experimentierfeld, in dem sie beweisen können, dass sich ihre Ideen für die Zukunft des Netzes in großem Maßstab umsetzen lassen.

Wird Google Zertifikate frei anbieten bzw. verkaufen?

Abgesehen vom Vorantreiben der Internetsicherheit wird Google seine PKI sicher in Zukunft mit anderen Diensten wie der Domänenregistrierung verknüpfen. Unklar ist allerdings ob sie tatsächlich zu einer CA werden wollen, die jedem Zertifikate anbietet.

Aus dem Policy Dokument der Google PKI kann man nach meinem Verständnis entnehmen, dass Google zumindest zur Zeit nicht mit kostenfreien Angeboten wie Let’s encrypt konkurrieren will. Ich lese das aus der Beschreibung des Verfahrens zur Überprüfung der Identität von Antragsstellern bei der Zertifikatsbeantragung. Hier gibt es u. a. einen Aspekt, der eine Überprüfung der postalischen Adresse fordert. Das ist ein über die Domänenvalidierung der Gratisdienste hinausgehender Schritt, der sich nicht voll automatisieren lässt.

Meine Vermutung ist daher, dass Google zumindest mittelfristig nicht mit den existierenden CAs in direkte Konkurrenz treten, sondern seine CA nur für die eigenen Dienste nutzen wird. Auch damit wird diese CA allerdings schnell zu einer der CAs werden, deren Zertifikate den größten Teil des Internetverkehrs sichern.

Wann werden die Google Root Zertifikate in Webbrowsern auftauchen?

Google selbst weist in seinem Blogpost darauf hin, dass es einige Zeit dauert die Wurzelzertifikate für eine neue CA zu verbreiten. Hier müssen zunächst die großen Browseranbieter überzeugt werden die Zertifikate aufzunehmen. Gleiches gilt für die Betriebssystemhersteller (praktischerweise in einigen Fällen die gleichen Unternehmen). Und es müssen noch viele andere Dinge wie die Updategeschwindigkeiten der jeweiligen Produkte bedacht werden. Vermutlich wird man die Zertifikate zuerst in den Google-eigenen Produkten wie Chrome, ChromeOS und Android finden können, auch wenn Google bei Mozilla den entsprechenden Prozess schon im letzten Dezember angestoßen hat.

Google ist allerdings nicht dafür bekannt Dinge, die sie unbedingt wollen, von den Zeitplänen anderer abhängig zu machen. Daher hat man zwei bereits in Browsern und Betriebssystemen vorhandene Wurzelzertifikate gekauft und kann mit diesen schon jetzt nach eigenem Gutdünken verfahren. Faktisch ist damit Google bereits zur Root CA geworden. Der vorherige Screenshot zeigt eines dieser Zertifikate in Chrome.

Was soll man von der ganzen Sache halten?

“You can now have a website secured by a certificate issued by a Google CA, hosted on Google web infrastructure, with a domain registered using Google Domains, resolved using Google Public DNS, going over Google Fiber, in Google Chrome on a Google Chromebook. Google has officially vertically integrated the Internet.” – aduffy, 27.01.2017 auf ycombinator

Auf ycombinator findet man eine sehr ausführliche und meist gute Diskussion zu der Frage welche Auswirkungen dieser Schritt hat. Natürlich gibt es viele, die das zitierte Szenario eines über alle Ebenen des Internets integrierten Konzerns für bedrohlich / monopolistisch halten. Andere stellen die Frage warum man Google eigentlich so viel Vertrauen entgegen bringen sollte um nun auch noch ihrer CA zu trauen?

Die zweite Frage ist dabei für mich die einfachere: Wenn ich von meinem Android Smartphone über eine Google Suche eine Seite im Chrome Browser öffne vertraue ich Google sowieso schon sehr, sehr weitgehend. Wenn Google dann auch noch die Zertifikate verantwortet, die wenigstens die Google Dienste schützen, fällt für mich eine Stelle weg, der ich bisher auch noch vertrauen musste (die zuvor verwendete CA). Das ist eine Verbesserung.

Die Frage der Machtkonzentration bzw. des Monopols ist da wohl eher eine Gefühlsfrage: Aus meiner Sicht hat Google das Thema der Internetsicherheit in den letzten Jahren sehr vorangebracht und ist dabei in schwierigen Fragen wie z. B. der Bestrafung von versagenden CAs mehr oder weniger auf der richtigen Seite geblieben. Mit einer eigenen CA kann Google im besten Fall demonstrieren wie eine leistungsfähige und sichere PKI aussehen kann. Ich sehe das Ganze also positiv.

Eine andere Frage ist vielleicht die, ob dadurch CAs verschwinden werden? Heute sehen sich die existierenden Zertifizierungsstellen am unteren Ende durch Let’s encrypt bedrängt, welches für viele Webdienste Zertifikate in vollkommen ausreichender Qualität bereitstellt. Am oberen Ende mag es in Zukunft eine Konkurrenz durch die Google CA geben, aber nicht ohne Grund haben viele Länder eigene CAs gegründet und werden die ganz unabhängig von einem Google Angebot betreiben. Wenn dafür einige der kleineren CAs, die möglicherweise Probleme damit haben einen seriösen Betrieb zu leisten, am Ende verschwinden, so ist das für die Sicherheit des Internets dann eher gut.

Die Stagefright Bugs: Das Beste, was der Android Sicherheit passieren konnte

Vor wenigen Tagen wurde ‘Stagefright 2.0’ bekannt, also die nächste Iteration der gefährlichen Fehler in Stagefright, der zentralen Mediaplayer Komponente des Android Betriebssystems. Warum soll das gut sein für die Sicherheit des weltweit meistgenutzten Betriebssystems?

Eine kurze Geschichte der Stagefright Bugs

Wir erinnern uns kurz: In den Wochen vor der Blackhat Konferenz Ende Juli begannen Gerüchte über einen schweren Fehler in Android zu kursieren. Der besondere mediale Reiz dieses Bugs war die Möglichkeit ihn über eine zugeschickte MMS auslösen zu können. Kombiniert mit dem damaligen Verhalten der Standard MMS Apps solche Inhalte ohne Zutun des Benutzers auszuführen hatte man ein mögliches Horrorszenario und Schlagzeilen wie ‘Eine Milliarde Android Geräte per MMS hackbar!’ waren die unvermeidliche Folge. Und der Name ‘Stagefright’ der betroffene Komponente lieferte auch gleich einen eingängigen Namen für das Problem.

Android Security

Unter dem hohen öffentlichen Druck zeigte sich—wieder einmal—das größte Problem des gigantisch gewordenen Android Ökosystems: Nur ein Teil der mehr als eine Milliarde aktiver Android Geräte bekommt Updates. In diesem Fall standen selbst die Besitzer der direkt von Google mit Updates versorgten Nexus Geräte genauso dumm da, denn obwohl Google den Fehler seit Monaten kannte war noch kein Patch offiziell verfügbar.

Wie konnte es so weit kommen?

Wie konnte ausgerechnet Google in diese Misere geraten? Hat Google mit dem Chrome Browser die automatischen, ohne Benutzerintervention stattfindenden Updates doch erst zum heutigen Standard gemacht und auch in fast allen späteren Produkten durchgesetzt: ChromeBooks, Android Wear Uhren, Chromecasts, OnHub Router, Android TVs, sie alle bekommen ihre Updates unmodifiziert direkt von Google und sind trotz Nutzerzahlen, die ebenfalls im Millionenbereich liegen, immer auf dem aktuellsten Stand. Selbst auf Android Geräten hat Google mit den Play Services einen Systemteil, der regelmäßig Updates erhält, sich selbst ohne Benutzerinteraktion aktuell hält und heute ein wesentliches Element von Googles Android Sicherheitsmanagement ist.

Das Problem beim Android Betriebssystem ist durch das komplizierte Verhältnis zwischen Google, dem Herrscher über die Android Weiterentwicklung, seinen Partnern wie Samsung, die die eigentlichen Geräte bauen und Android dafür modifizieren, und den Telekomanbietern, die noch einmal eigene Anpassungen von den Geräteherstellern verlangen, entstanden. Vermutlich hatte Google bisher die — berechtigte — Sorge, dass Veröffentlichungen von Fehlerkorrekturen im Android Open Source Projekt (AOSP) schnell von Angreifern untersucht und zum Bau von Angriffscode genutzt werden. Schneller, als die Gerätehersteller in der Lage oder Willens sind ihren Kunden Updates zu liefern.

In der Konsequenz konnten nicht einmal die Nexus Geräte Updates erhalten, da auch hier ein Reverse Engineering möglich wäre. Und so ist die Situation entstanden, die am Ende die ganze Android Welt ohne ein einziges Gerät mit einer wirklich nach aktuellem Wissenstand fehlerfreien Version dastehen lies.

Der Befreiungsschlag

Der durch die ersten Stagefright Fehler aufgebaute Druck hat Google schließlich dazu gebracht seine Strategie komplett zu ändern: Der auf der Blackhat Konferenz vortragende Google Sicherheitsmann Adrian Ludwig kündigte in seinem lesenswerten Vortrag an, dass es ab sofort monatliche Sicherheitsupdates für die Nexus Geräte geben werde, gefolgt von einer raschen Veröffentlichung der Fehlerkorrekturen im AOSP.

Ob Google dabei nun vom Druck getrieben wurde, oder ob man den Druck nutzte um auch bei Android eine Entwicklungsgeschwindigkeit zu erreichen, wie man sie in allen anderen Google Produkten kennt, wird man von außen vermutlich nie abschließend beurteilen können. In jedem Fall gibt Google den Druck damit an seine Partner weiter: Der Angriffsdruck auf alle Android Geräte, die keine aktuellen Patches erhalten, wird durch diese neue Linie mit Sicherheit steigen.

Mindestes den großen Herstellern, die auf Markenbildung, nachhaltige Kundenbeziehungen und den Einsatz ihrer Produkte in Unternehmen und Behörden setzen, kann so ein permanenter Kritikpunkt nicht gefallen.

Den Druck noch weiter erhöhen

Interessanterweise hat Google den Druck in den letzten Wochen noch einmal erhöht. Google selbst hatte mit seinem Project Zero angefangen andere Softwarehersteller mit einer 90 Tage Frist bis zur Veröffentlichung von Fehlern unter Druck zu setzen. Und musste sich prompt in Bezug auf Stagefright den Vorwurf gefallen lassen, bei seinen eigenen Produkten offensichtlich mit zweierlei Maß zu messen.

Nach der Strategieänderung hat das Project Zero nun auch Android Lücken öffentlich aufs Korn genommen und in einem Blogpost demonstriert, wie die zunächst dank Schutzmechanismen wie ASLR eher theoretisch erscheinende Ausnutzbarkeit eines bestimmten Stagefright Fehlers in einer Weise aufgerüstet werden kann, die sie in unmittelbare Nähe eines verlässlichen Exploits bringt.

Die Updates von Google kommen

Inzwischen ist das dritte Sicherheitsupdate an die Nexus Geräte ausgerollt werden, kurz bevor Android 6.0 ausgeliefert wird. Google hat hier also sein Versprechen gehalten. Wenn man sich die Liste der behobenen Fehler samt ihrer Kritikalität ansieht und weis, dass sie bald allgemein bekannt sein werden, kann man sich schon die Frage stellen ob man — trotz der zusätzlichen Schutzmaßnahmen, die Google im Play Store und den Play Services implementiert — jemandem ernsthaft dazu raten kann sich ein Nicht-Nexus-Gerät zuzulegen.

Den ersten Gewinn für die Android Sicherheit aus dem Stagefright Desaster haben wir damit: Es gibt nun mit den Nexus Geräten — die bald zwei schöne Hardwareupdates erhalten — eine Android Linie, bei der man von Google garantiert häufige Updates für alle bekanntgewordenen Sicherheitsprobleme bekommt.

Aber auch Custom ROM Anbieter wie Cyanogen haben nun die Chance über die schnelle Integration der AOSP Korrekturen ihre eigenen Versionen von Android aktuell zu halten. Damit haben wir den zweiten Gewinn: Wer kein Nexus Gerät hat oder haben will, aber ein Gerät, für das ein Custom ROM verfügbar ist, kann nun ebenfalls auf ein schnelles Schließen von Sicherheitslücken hoffen.

Wann kommen die Updates von den Geräteherstellern?

Trotzdem hatte die Masse der Android Nutzer bisher noch keinen unmittelbaren Vorteil von diesen Entwicklungen, auch wenn einige Gerätehersteller nach den ersten Stagefright Lücken schon Updates ausgerollt hatten. Hier kann man aber hoffen, dass das nun durch die Nexus Updates monatlich aufflackernde Sicherheitsthema dafür sorgt, dass der Druck auf die Hersteller und Telekomunternehmen nicht nachlässt. Am Ende kann hier eigentlich nur die Einsicht stehen, dass die Möglichkeit schnell und häufig Updates an die Geräte der Kunden zu geben ein eigenes Qualitätsmerkmal ist, mit dem sich werben lässt.

Wenn dieser Status — wenigstens für die Flaggschiffgeräte der großen Hersteller — erreicht worden ist, dann haben wir den dritten und entscheidenden Gewinn aus den Stagefright Lücken gezogen. Ein Gewinn, der sich im verwickelten Android Ökosystem offenbar erst mit dem enormen Druck, den die Stagefright Probleme ausgelöst haben, realisieren liess.

Und falls dies auch dazu führt, dass die im Zeitalter des Material Design oft klobig und unelegant wirkenden ‘Verbesserungen’ der Gerätehersteller am Android System zurückgefahren werden, so kann man dies nur begrüßen.

Notizen zur Google I/O 2015

Gestern begann die Entwicklerkonferenz von Google und wie in jedem Jahr ist die Keynote der Auftakt und in gewisser Weise auch der Höhepunkt der Veranstaltung, jedenfalls von außen gesehen. Hier präsentiert eines der wichtigsten Technologieunternehmen der Welt seinen Stand, seine Produkte und seine Visionen für die nahe und ferne Zukunft. Das sind meine Notizen, ohne Anspruch jedes Detail abzudecken:

Google I/O 2015

Google als KI Unternehmen

Am Anfang der Keynote sprach Sundar Pichai eine kurze Zeit von den Fortschritten beim maschinellen Lernen, die Google im vergangenen Jahr gemacht hat. Ein Schlüsselkonzept sind dabei tiefgestaffelte, neuronale Netze, bei denen die verschiedenen Ebenen unterschiedliche Aspekte der gestellten Aufgabe lernen. Auch wenn das Thema nur vergleichsweise kurz und zeitlich deutlich getrennt von der heute am besten sichtbaren Anwendung (Google Photos) präsentiert wurde: Das ist das Thema, welches heute — oder immer schon — im Kern von Google steckt und mit dem offenbar schnelle und überraschende Fortschritte möglich sind. Beispiel die Spracheingabe bei der Google Suche, deren Fehlerrate innerhalb des letzten Jahres auf diese Weise deutlich verringert werden konnte.

Android M

Das Rechtemodell geht mehr in Richtung iOS: Rechte werden in größeren Gruppen gebündelt; Rechte werden (zumindest teilweise) erst bei der ersten Verwendung abgefragt; Können später wieder entzogen werden und lassen sich sowohl per App wie auch per Recht betrachten und bearbeiten. Sicher die größte Änderung am Rechtemodell, die es in Android jemals gab. Die Entwickler wurde damit geködert, dass Nutzer Apps dann schneller installieren (da keine vorherige Rechteabfrage mehr erfolgt) und auch bei Updates, in denen mehr Rechte verlangt werden, nicht mehr zögern.

Viel Herumreiten darauf, dass man sich in M auf Qualitätsverbesserung konzentriert habe. Vermutlich ein Eingeständnis, dass Lillipop ziemlicher Müll war, was die Softwarequalität angeht.

Google Now wird immer schlauer (und übergreifender)

Google baut seine bisher ziemlich einzigartige Now Funktion noch stärker aus und zwar nicht nur in der schon bekannten Weise, in der einem Informationen proaktiv angeboten werden. Mit Now on Tap kann man die Funktion in Android M dazu veranlassen, die von der gerade offenen App gezeigten Inhalte zu interpretieren und einem geeignete Funktionen und Informationen anzubieten. Hier legt Google also ein eigenes Layer über potentiell alle Apps. Ob die App Anbieter etwas dazu tun müssen ist nicht ganz klar geworden (vermutlich nicht), dagegen wehren können sich aber bestimmt nicht. Wenn das so funktioniert, wie sich Google das vorstellt, bekommt die Google Suche über Now wieder eine ganz neue Funktion und Wichtigkeit und kann das händische Hin- und Herspringen zwischen Apps weitgehend beenden.

Chrome custom tabs

Google arbeitet weiter an der möglichst nahtlosen Verschmelzung von Apps und Webinhalten. Ein neuer Weg sind die custom tabs, die Apps in Chrome öffnen können. Dabei wird ein Webinhalt zwar außerhalb der aufrufenden App in Chrome geöffnet, aber die App ist in der Lage einen Teil ihres Brandings und auch ihrer Funktionen an Chrome zu übermitteln. Damit entsteht für Entwickler ein dritter Weg neben der einfachen Verlinkung und dem Aufbau eines eigenen, internen Browsers über eine Webview. Frage ist für mich aber, in wie weit das andere Browser wie Firefox ausschließt?

Android Pay

Das Google Wallet wird zu Android Pay und wird sich dann auch in den eigenen Apps verwenden lassen. Zusammen mit der neuen Fingerabdrucksensor API, die Android M bringt, macht dies den Eindruck, dass Google hier stark Apple Pay nacheifert. Aber hier in Europa wird davon wohl auf absehbare Zeit nicht viel ankommen.

Brillo und Weave: Googles Lösung für das Internet der Dinge

IoT ist gerade wieder aktuell und tatsächlich kommen ja auch jede Menge Produkte auf den Markt, die irgendwie ‘intelligent’ sind, die sich aber in jedem Fall vernetzen wollen. Und deren komplexe Funktionen von außen gesteuert werden wollen.

Google bietet mit Brillo nun ein abgespecktes Betriebssystem, welches von Android abgeleitet ist und daher bestimmte Funktionen wie Netzwerkstacks erben kann. Interessanter ist aber vielleicht aus Nutzersicht Weave, welches ein Protokoll ist, über das sich IoT Devices und die sie steuernden Geräte wie Smartphones austauschen können. So soll man offenbar mit einer einzigen Weave App auf seinem Smartphone alle entsprechenden Geräte steuern können, die dort ihre Fähigkeiten darstellen.

Wird Google hier etwas schaffen, was quasi schon jeder große Softwarehersteller in den letzten Jahren irgendwie mal versucht hat, aber bisher noch nie so richtig geklappt hat?

Google Photos

Für mich der interessanteste Punkt dieser Keynote: Die Kernideen, die ich an einem Fotodienst in der Cloud am meisten benötige, werden umgesetzt. Google bietet sich als verlässlicher Speicherdienst für ‘lebenslange’ Fotoarchivierungen an. Nun weis niemand, ob es Google in 20 oder 30 Jahren noch gibt und wenn ja, welche Ziele das Unternehmen dann verfolgt. Trotzdem ist das die Zusage, die man von seinem Cloud Anbieter hören will und sie muss sich glaubwürdig anhören. Ich fand sie glaubwürdig, vor allem, da sie von einer weitgehenden Aufhebung der bisherigen Beschränkungen / Grenzen beim gratis zur Verfügung gestellten Speichervolumen begleitet wurde.

Natürlich will man die Bilder immer auf allen Geräten verfügbar haben. Hier gibt es sowohl in der neuen App wie auch in der Webdarstellung einige coole Interfaceideen und neue Gesten, die einem den Umgang mit seinen Bildmassen deutlich zu vereinfachen scheinen. Und schließlich die Suche und Gruppierung: Hier treten die Verbesserungen in der Bilderkennung durch das maschinelle Lernen klar zutage, Google kann inzwischen ein weites Feld von Begriffen / Dingen in Bildern erkennen und kategorisieren.

Das klappt nicht zu 100%, aber das ist auch nicht entscheidend: Zum einen wird sich dies weiter verbessern, zum anderen reicht es mir wenn die Suche nach ‘Pferd’ mir Bilder von Pferden zeigt, ein paar falsch klassifizierte Hundebilder sind da egal. Auf diese Weise kann man in den Datenhalden, die man in den vergangenen Jahren angehäuft hat, endlich wieder schnell die Bilder finden, die man gerade sucht, und das ohne aufwändige Verschlagwortung oder manuelle Einsortierung in irgendwelche Ordner.

Die neue App kam unmittelbar nach der Keynote an, so dass man gleich damit herumspielen konnte.

Cardboard und Jump

Die Papp-3D-Brille von der letzten Google I/O nahm einen überraschend großen Teil der I/O in Anspruch: Google nimmt die Sache, die zuerst wie ein Gimmick erschien, offenbar weiterhin sehr ernst. So gibt es nun eine Neuauflage, die auch große Smartphones aufnehmen kann und mit dem iPhone zusammenarbeitet, und ein merkwürdiges, ergänzendes Produkt: Jump.

Jump ist ein Weg um mit Hilfe von Google 360 Grad Videos erstellen, verarbeiten und veröffentlichen zu können und damit ein Lieferant für Inhalte, die Cardboard oder andere VR Lösungen erst interessant machen. Jump hat drei Bestandteile: Das erste ist im Grunde nur ein Bauplan, den Google zur Verfügung stellt, und der beschreibt wie man 16 Kameras anzuordnen hat, damit deren gleichzeitige Aufnahmen ein 360 Grad Bild ergeben und die spätere Verarbeitung möglich wird. GoPro wird schon ein fertiges Gerät anbieten, aber offenbar könnte sich im Prinzip jeder so etwas zusammenbauen. Google wird z. B. Steuerungsdateien für 3D Drucker veröffentlichen, die den Halter für die Kameras erzeugen.

Danach kommt die Verarbeitung: Aus den 16 Kamerafeeds muss eine 360 Grad Aufnahme samt Tiefeninformation und allen möglichen Blickpunkten synthetisiert werden. Hier bringt Google seine riesigen Rechenzentren ein, die diese Arbeit übernehmen sollen, und die Algorithmen, die all die komplizierten Transformationen durchführen. Schließlich muss das Endprodukt irgendwo abrufbar werden. Dazu dient natürlich YouTube und die entsprechenden Apps, die man dann in Cardboard nutzen kann.

In der Keynote wurde als denkbares Einsatzszenario der Schulbereich genannt, so könnte eine Klasse auf diese Weise tatsächlich zwischen den Gletschern in Grönland umherwandern, an statt sich nur eine flache Projektion anzusehen (aber wer bezahlt die teuren Smartphones?).

Zahlen, Zahlen, Zahlen

Viele Produkte wurde nur gestreift, dafür dann aber mit Zahlen um sich geworfen: 17 Millionen Chromecasts verkauft, für die 1,5 Milliarden Mal der Cast Button angeworfen wurde; eine Milliarde täglicher Android Nutzer; 1 Million Cardboards; so und so viele Android Wear Watches und Watchfaces; so und so viele Autohersteller, die bei Android Auto mitmachen; 50 Milliarden App Downloads im vergangenen Jahr (aber keine Zahl zu den generierten Umsätzen im Play Store).

Die nächste Milliarde Internetbenutzer

Ein wiederkehrendes Thema war die Frage, wie die Reichweite des Internets erhöht wird. Sei es durch Loom, die Ballone, die nicht verkabelten Regionen ein Funknetz bringen sollen; seien es günstige Android Smartphones, die für viele Menschen der erste (und vielleicht einzige) Computer sein werden, mit dem sie ins Netz gehen.

Hardware

Abgesehen von der neuen Cardboard Version und dem skurilen Kameraarray gab es da nichts. Weder ein Chromecast II noch neue Chromebooks und erst recht keine Nexus Geräte.

Programmierung

Konkrete Themen für die anwesenden EntwicklerInnen wurden hier nur gestreift, die Vertiefung kommt dann später in den Sessions. Da gab es Dinge wie die nächste Version von Android Studio, die nun auch sehr umfangreiche Unterstützung für C/C++ Entwicklung mitbringt; Polymer 1.0 ist da; Android M natürlich.

Fazit

Keine ganz so atemlose, überladene Veranstaltungen wie in früheren Jahren, aber trotzdem schön und anregend.

Wiederholt Google mit Chrome die Geschichte von Microsoft und dem Internet Explorer?

“Cynics surely look at this [the web version of Inbox is Chrome-only] as the second coming of Microsoft’s IE-only web technologies from the late ’90s, but my guess is that support for additional browsers iscoming .. and they shipped Chrome-first only because it was the fastest way they could ship.” — John Gruber | Montag, 3. XI 2014

Eine alte Darstellung des Pflügens (Quelle: Internet Archive): So wie der Bauer das Land bestellt, bereitet Google mit Chrome den Acker für zukünftige Webtechnologien.
Eine alte Darstellung des Pflügens (Quelle: Internet Archive): So wie der Bauer das Land bestellt, bereitet Google mit Chrome den Acker für zukünftige Webtechnologien.

Ist das eine merkwürdige Frage? Dieser Vergleich von Googles bisher unendlichem Fortschrittsdrang bei der Weiterentwicklung der Webtechnologien in seinem Chrome Browser, und der bleischweren Zeit eines Internet Explorers 6, der Microsoft nach dem Sieg über Netscape und dem Erringen der uneingeschränkten Hegemonie über das Web dazu diente, dieses technologisch quasi einzufrieren? Ich glaube schon. Aber warum eigentlich?

John Gruber kommt auf dieses Thema am Rande einer interessanten Betrachtung zu Google’s neuem ‘Material Design’, der Gestaltungssprache, die sich gerade über alle Google Dienste, Betriebssysteme und Apps ausbreitet. Er kann dabei nicht umhin auf zwei Punkte hinzuweisen:

Google, das Unternehmen, welches am längsten für den Triumph des Websals übergreifender Entwicklungsplattform über die nativen Apps gekämpft hat, setzt zum einen inzwischen intensiver als je zuvor auf solche Apps, jedenfalls für Android und iOS. Zum anderen zeigt er am Beispiel der brandneuen INBOX auf, dass die hier verfügbare Webversion zur Zeit einzig und allein unter Chrome funktioniert.

Ist das nicht genauso schlimm wie die proprietären Funktionen, die Microsoft damals in seinen Internet Explorer einbaute, und die anderen Browserherstellern das Leben schwer machten?

Es gibt dabei einen entscheidenden Unterschied: Google unterstützt andere Browser (in einigen Fällen) nicht, weil diese noch nicht die Funktionen bieten, die Chrome bereits enthält. Mit Chrome hat sich Google ein Mittel geschaffen das Web insgesamt im 6-Wochen-Takt voran zu bringen und hat hier als einzigen ‘Konkurrenten’, der dieses hohe Tempo mitmacht, die Mozilla Foundation. Alle anderen relevanten Hersteller — also Apple und Microsoft — nehmen ggf. die von den beiden Vorreitern entwickelten, getesteten, und schon im Einsatz befindlichen Standards dann später auf, wenn sie in ihren viel langsameren Releasezyklen mal wieder eine neue Version von Safari oder dem Internet Explorer veröffentlichen.

Im Gegensatz zur Versteinerung des Zeitalters der Microsoft Hegemonie befinden wir uns nun also in einem rasanten Zeitalter der unterschiedlichen Entwicklungsgeschwindigkeiten, bei dem es immer Beispiele wie INBOX geben wird, die so nahe an der ‘bleeding edge’ der Webtechnologie sind, dass sie schon aus Prinzip nicht von allen Browsern unterstützt werden können.

Es gibt daher keinen Grund eine erneute Versteinerung des Webs zu befürchten, solange Google von Mozilla, Microsoft und Apple ein Mindestmaß an Konkurrenz erfährt.