Die Blockchain und das Osterei

ihbrune

Wenn die Ostereier in diesem Jahr ungefärbt waren, dann hat man vielleicht ein neues Logo darauf entdecken können, das Logo von respeggt. Damit werden Eier gekennzeichnet, die ohne das Töten von männlichen Küken bei der Zucht der Legehennen auskommen. Dieser Abschnitt aus der respeggt-Webseite sagt dazu:

Das respeggt-Siegel steht für das Versprechen: „Ohne Kükentöten“. Dank einer lückenlosen Prüfung der Lieferkette wird garantiert, dass nur Produkte das Siegel tragen, die die Forderung „Ohne Kükentöten“ erfüllen.

An dem respeggt-Siegel erkennt der Verbraucher sofort, dass es sich um Eier handelt, in deren gesamter Lieferkette die Grundsätze des respeggt-Versprechens eingehalten werden. Die Nutzung einer Blockchain-Technologie stellt sicher, dass jedes Ei, das das respeggt-Siegel trägt, lückenlos verfolgt und auf das Einhalten des respeggt-Versprechens verifiziert wird.

Das hört sich sowohl in ethischer wie auch in technologischer Hinsicht interessant an. Aber wie funktioniert das?

Ei im Eierbecher

Was ist die Aufgabe

Die respeggt-Group ist selbst kein Eierproduzent, sie hat das Qualitätssiegel entwickelt und betreibt das System zur Sicherung dieser Qualität. Damit das Siegel glaubwürdig ist müssen dabei mindestens diese Dinge beleg- und nachvollziehbar sein und zwar lückenlos:

  1. Von welchem Legehennenbetrieb kommt das mit dem Siegel gekennzeichnete Ei
  2. Von welcher Henne wurde das Ei dort gelegt
  3. In welchem Aufzuchtbetrieb wurde die Henne großgezogen
  4. Woher kam das Ei, aus dem die Henne geschlüpft ist
  5. Wie wurde in der Brüterei mit den männlichen Küken der Eier umgegangen, die zusammen mit dem Ei, aus dem die Henne geschlüpft ist, bebrütet wurden. Diese Frage ist das eigentliche Fundament des Qualitätssiegels

Bis das respeggt-Ei in die Handelsketten und zum Endkunden kommt sind also schon auf mehreren Ebenen Unternehmen mit unterschiedlichen Aufgaben beteiligt, und in jedem dieser Unternehmen und auch bei den Transporten von Hühnern und Eiern zwischen ihnen gibt es Potentiale für Fehler oder gar absichtliche Verstöße gegen die Richtlinien.

Das Supply Chain Monitoring System für so eine Produktions- und Lieferkette ist schon eine komplexe Aufgabe, um das Vertrauen der Verbraucher*innen zu gewinnen muss aber auch plausibel gemacht werden, dass die Dokumentationen dazu vollständig und fälschungssicher sind.

Was kann die Blockchain dazu tun

Für die Blockchain Technologie, die mit dem Aufstieg von Kryptowährungen wie Bitcoin Bekanntheit erlangte, werden schon lange weitere Einsatzfelder diskutiert. Genauer gesagt muss es dabei nicht unbedingt eine Blockchain sein, sondern generell eine Distributed-Ledger-Technologie, was man als verteiltes Kassenbuch übersetzen kann, und Blockchain ist dabei das heute am weitesten verbreitete Verfahren.

Eine Distribute-Ledger-Technologie hat dabei mehrere interessante Eigenschaften, hier sind es wohl diese beiden, die wesentlich sind:

  • Das ‚Kassenbuch‘ ist kryptografisch so abgesichert, das nachträgliche Änderungen nicht möglich sind, zumindest nicht ohne das sie auffallen. Die Blöcke in der Blockkette verweisen dazu aufeinander und bilden so eine Kette, die nicht unterbrochen werden kann
  • Bei einem echten verteilten Kassenbuch gibt keinen zentralen Akteur, der uneingeschränkt über das Kassenbuch bestimmt, es sich mehrere Akteure notwendig, um den nächsten Dokumentationsabschnitt (= Block) zu bestätigen und damit unveränderlich zu machen. Allerdings ist mir beim respeggt-System nicht klar, ob das Sinn macht bzw. so umgesetzt wurde

Diese Eigenschaften sind etwa in der Bildungslandschaft die Grundlage für Überlegungen über eine Blockchain fälschungssichere und allgemein zugängliche Dokumentationen von Abschlüssen bzw. Bildungszertifikaten aufzubauen, die je nach Nutzungsweise auch ohne zentrale Datenhaltung auskommen könnte. Dabei müssen ’nur‘ noch ein paar Hürden überwunden werden, etwa die, das nicht komplette Zeugnisse in die Blockchain aufgenommen werden können: Die personenbezogenen Daten darin würden sich nie mehr daraus entfernen lassen, was sich nicht mit der DSGVO vereinbaren lässt. Hier könnte mit Dokumentenhashes gearbeitet werden, über die sich dann Dokumente, die von Absolvent*innen präsentiert werden, validieren lassen.

Eine andere Idee – und hier kommen wir denke ich dem Einsatzszenario bei den respeggt-Eiern schon näher – ist das hier beschriebene Verfahren für Diamanten Herkunftsnachweise zu realisieren. Und so den Nachweis zu führen, dass es sich nicht um sogenannte Blutdiamanten handelt. Ob dieses Verfahren inzwischen tatsächlich eingeführt und genutzt wird habe ich leider nicht herausgefunden, aber das liegt vielleicht in der Natur der Sache:

Während die Bitcoin Blockchain vom Prinzip her öffentlich sein muss, würden sich die am Diamantenhandel beteiligten Parteien wohl eher nicht völlig frei in die Karten schauen lassen. Hier wird die Blockchain dann zu einem internen Werkzeug für Unternehmen, die sich nicht völlig (oder überhaupt nicht) vertrauen können, aber damit eine gegenseitige Kontrollmöglichkeit erhalten könnten ohne eine zentralisierte Struktur.

Leider habe ich auch zur respeggt-Blockchain keine konkreteren Angaben im Netz finden können, die inhaltlich über den oben zitierten Satz hinausgehen. Es gibt nur von Telefonica dieses Paper (PDF), welches im Kontext des Internet of Things die Anbindung von respeggt-Infrastrukturen beschreibt. Vielleicht speisen verschiedene Gerätschaften wie die Drucker, die das Siegel auf die Eier drucken, ihre Daten so gleich in die Blockchain ein? Leider ist auch nicht klar wer genau wie tief in die Blockchain schauen kann und was genau da alles drin steht. Als Endkunde kann man nur hier seinen Eiercode online prüfen.

Trotzdem ist das für mich eines der bisher noch wenigen Beispiele, in denen die Blockchain Technologie jenseits von Bitcoin ganz direkt nutzbar geworden ist.

Hafnium im Gartenshop

ihbrune

Die wahlweise Hafnium oder ProxyLogon genannte Gruppe von Sicherheitslücken in Microsofts Exchange Servern dominierte in den letzten Wochen die IT Sicherheitsthemen. Und selbst wenn IT Profis wie die Kollegen in der Uni die Lücken schnell geschlossen haben kann einen das Thema betreffen. Daran erinnert diese Mail eines Webshops, bei dem ich vor Jahren mal etwas bestellt habe, und die gestern eintraf:

Screenhot einer Mail mit der Information darüber, dass der Exchange Server eines Webshops gehackt wurde

Nicht alle Admins von Exchange Servern waren schnell genug um den direkt nach Bekanntwerden der Lücke einsetzenden, massenhaften Scans nach verwundbaren Servern zuvor zu kommen. Vermutlich gibt es 10.000e von Systemen, die schon mit Webshells oder anderen Hintertüren ausgestattet wurden (Nachtrag: manche offenbar auch gleich mehrfach). Und ein reines Patchen der Exchange Lücken beseitigt diese Zugänge dann nicht mehr.

Die DSGVO zwingt nun die Betreiber zumindest im europäischen Raum dazu ihre Kund*innen über solche Vorfälle zu informieren. Und ich würde wetten, dass das nicht die letzte entsprechende Mail war, die ich bekommen werde. Natürlich nur, wenn gehackte Betreiber sich gesetzeskonform verhalten bzw. überhaupt entdecken, dass sie gehackt wurden.

Was kann man tun?

Bei der Gelegenheit die Erinnerung an den schönen Have i been pwned? Dienst:

https://haveibeenpwned.com/

Der benachrichtigt einen, wenn mit der eigenen Mailadresse verknüpfte Kontodaten irgendwo im (Dark)Web auftauchen, oft auch verbunden mit der Information von welchem Dienst diese Daten gestohlen wurden. Ich habe in den letzten Jahren schon mehrere entsprechende Meldungen bekommen und zum Glück hatte ich bei den jeweiligen Diensten schon individuelle, nur für den jeweiligen Dienst geltende Passworte verwendet, so dass mit den gestohlenen Zugangsdaten nicht noch weitere Konten von mir missbraucht werden konnten.

Was zum nächsten Tipp führt: Heute ist die Verwendung eines Passwortmanagers unumgänglich um

  • sehr sichere (also lange und komplett zufällige) und
  • für jeden Dienst einzigartige

Logindaten zu verwenden. Wer sich dabei nicht auf die in heutigen Webbrowsern eingebauten Passwortmanager verlassen möchte, der findet hier einen aktuellen Überblick.

Wie lang darf eigentlich ein class-Attribut sein?

ihbrune

Ich arbeite nicht erst seit gestern mit HTML, aber diese Frage habe ich mir nie gestellt. Der aktuelle Security Now Podcast (Folge #810) mit seiner Beschreibung der interessanten ‘Prime+Probe 1, JavaScript 0: Overcoming Browser-based Side-Channel Defenses’ Forschungsarbeit hat mich erst darauf gebracht: Darin geht es um einen Ansatz um Nutzer*innen im Webbrowser ganz ohne Javascript zu tracken und der trickreiche Ansatz um mal wieder Cache Timings als Seitenkanal zu nutzen verwendet – Achtung! – 2 Millionen Zeichen lange Klassennamen. Zitat:

CSS Prime+Probe Implementation. Figure 3 shows a code snippet implementing CSS Prime+Probe, using CSS Attribute Selectors to perform the attack. Specifically, Line 9 defines a div with a very long class name (two million characters).

Kann das sein? Warum sollte die HTML Spezifikation derart lange Namen erlauben? Hätte ich vorher darüber nachgedacht wäre mein Tipp vermutlich bei 1024 oder maximal 32.768 Zeichen gelandet. Das sollte auch für sehr sprechende und exzessive Anwendungen von CSS Klassennamen ausreichen, wie sie z. B. die BEM Vorgehensweise nahelegt.

HTML Code mit sehr langem class-Attribut

Aber die Antwort, warum die Spezifikation solche langen Namen erlaubt, scheint einfach zu sein: Sie macht hier überhaupt keine Vorgabe! Demnach setzen nur die konkreten HTML Implementierungen der Webbrowser Grenzen, schon um zu verhindern, dass solche absurden Inhalte den Speicher zum überlaufen bringen. Aber wenn es solche Grenzen gibt, dann liegen sie offenbar weit jenseits dessen, was sich ‘vernünftig’ anfühlt.

Ob die Browserhersteller angesichts solcher Tricksereien nun anfangen engere Begrenzungen zu definieren? In regulären Webanwendungen sind jedenfalls kaum Anwendungen vorstellbar, die mehr als 1024 Zeichen für Klassennamen verwenden. Oder?

Flutter: Das neue Java

ihbrune

Gerade wurde Flutter 2 veröffentlicht und es gibt einiges zu berichten aus der Flutter Welt. Wenn man sich die Keynote der Flutter Engage anschaut hat mich aber insbesondere der Teil, der die verschiedenen neuen Zielplattformen vorstellt, irgendwie an das Java Marketing vor mehr als 20 Jahren erinnert: 

Write once, run anywhere

So war der Slogan, den SUN 1995 prägte, um das Versprechen auszudrücken mit einem Programm viele Plattformen bedienen zu können. Was sich auf der Serverseite letztlich verwirklicht hat. Aber auf der Clientseite dann doch nicht. Zwar gibt es bis heute Java Desktop Anwendungen, aber so richtig schön und zum jeweiligen Betriebssystemumfeld passend waren die fast nie. Wenn es Android nicht gäbe und die auf Java basierenden für Android Apps, dann würde man sich heute kaum an Java als Frontend Sprache erinnern. Und an Dinge wie Applets möchte man sich auch gar nicht mehr erinnern 😬

Flutter überall 

War Flutter bisher für die Android und iOS Crossplattformentwicklung geeignet kommt nun die Webplattform aus der Beta heraus und weitere Plattformen sind auch bereits bespielbar, wenn auch noch nicht völlig stabil:

Was hier noch fehlt sind eingebettete Systeme wie das von Toyota vorgestellte Infotainmentsystem in ihren Fahrzeugen.

Ob sich Flutter hier wirklich überall durchsetzen wird? Interessant ist auf jeden Fall die Unterstützung von den Ubuntu Linux Machern von Canonical, die sich hier sicher erhoffen die ewige Lücke zu den für Windows und MacOS erhältlichen Programmen schließen zu können.

Perspektiven

Für jemanden, der bisher eher aus der Webentwicklung kommt, wirft Flutter 2 die Frage auf ob hier ein Werkzeug entsteht, mit dem man ähnlich ubiquitär nutzbare Produkte entwickeln kann, wie mit einer responsiven Webseite. 

Dazu aber noch Funktionen erhält, die sich in einer App leichter entwickeln lassen. Und mit dem man in die App Stores kommen kann. Und mit dart eine moderne Programmiersprache als Unterbau bekommt, die nun auch Dinge wie null safety verspricht.

Oder muss man befürchten, dass Google dieses Vorhaben wie so viele andere Dienste und Projekte einstampft? Da sich inzwischen auf andere Firmen – selbst Microsoft – beteiligen und Google selbst wesentliche Apps wie Google Pay damit realisiert scheint diese Gefahr im Moment gering.

Ich bin jedenfalls gespannt welches Bild sich vielleicht in 10 Jahren zeigt und ob Flutter gegenüber den Javascript-basierten Cross Plattform Lösungen die Nase vorne haben wird.

Begeisterung für die Typographie

ihbrune

Gibt bei man Google ‚Typographie‘ ein erhält man heute diese Definition:

  1. Kunst der Gestaltung von Druck-Erzeugnissen nach ästhetischen Gesichtspunkten; Buchdruckerkunst
  2. typografische Gestaltung (eines Druck-Erzeugnisses)

Druck-Erzeugnisse? 🔣

Dabei spielt Typographie für Webseiten und Apps eine wichtige Rolle, selbst wenn man sich für das Thema nicht ganz so begeistern kann wie Oliver Schöndorfer von Zeichenschatz in der 83. Folge des programmier.bar Podcasts.

Schriftartenbeispiele von Google Fonts

Für mich eine unbedingt hörenswerte Folge, die einem als Entwickler*in wesentliche Begriffe und Konzepte von Schriftarten beibringt und das auch noch mit einer ansteckenden Begeisterung (trotz der Wiener Mundart 😏). Und einer seiner Punkte ist für mich besonders überzeugend: In einer App oder responsive Webseite bleibt oft nur noch die Typographie um sich von anderen Angeboten abzusetzen und Wiedererkennungswerte zu schaffen.

Was man im Podcast alles lernt 🔣

  • Was sind Display text, Body text und Functional text? Und nach welchen Kriterien wählt man dafür geeignete Fonts?
  • Wann ist die Frage wie gut unterscheidbar Zeichen wie Il1, ec oder agq in einem bestimmten Font sind wichtig?
  • Warum lohnt es sich auch mal jenseits von Google Fonts nach Schriftarten suchen? Oder wenn doch Google Fonts, dann vielleicht mal die Sortierung umzudrehen und nach den weniger populären Fonts schauen?
  • Was hat es mit Zwiebelfischen und Schusterjungen auf sich?
  • Was sind variable fonts und was macht sie so cool? Diese Frage kann sich auch hier beantworten: v-fonts.com/
  • Und was hat Oliver gegen Open Sans? Und hat dazu sogar ein Video in seinem YouTube Channel (unbedingt bis zum Ende sehen)?
  • Und noch einige mehr…

Für mich war der Podcast gut investierte Zeit 🔣

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

ihbrune

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.

Die ZKI veröffentlichen ihre Prozesslandkarte für Campusmanagement

ihbrune

Von den ZKI – Zentren für Kommunikation und Informationsverarbeitung e. V. – gibt es schon seit einiger Zeit ein interessantes Dokument, welche den Versuch unternimmt eine geschlossene Landkarte für die Prozesse aufzustellen, die beim Thema Campusmanagement bzw. Campus Management Systeme relevant sind. Jetzt kann man die letzte Version hier herunterladen:

https://www.zki.de/zki-nachrichten/einzelbeitrag/1746/

Das ZKI beschreibt die Ziele und den Anwendungsbereich des Dokuments dabei so:

Ein Hauptziel der ZKI-CM-Prozesslandkarte ist es, die Reflektion, Optimierung und Weiterentwicklung der hochschuleigenen Prozesse im Kontext von Campus-Management zu unterstützen. Sie soll dabei helfen, dass komplexe Zusammenspiel von Haupt-, Teil- und Unterprozessen so weit zu reduzieren, dass das Auffinden und Ausführen von Prozessen möglich wird, ohne den Blick auf die gegenseitigen Abhängigkeiten zu verlieren. Das vorliegende Dokument ist dabei so angelegt, dass es von jeder Hochschule an die eigenen Rahmenbedingungen, Anforderungen und Hochschulabläufe angepasst werden kann.

Insgesamt macht der Text einen sehr guten Eindruck, auch wenn sich im Detail idealisierte Prozessvorstellungen finden lassen, die im realen Betrieb einer Hochschule nur schwer durchzuhalten sein werden.

Steht eine Hochschule vor der Auswahl eines Campus Management Systems kann die Prozesslandkarte mit ihrer weit gefassten Definition des Student Life Cycle ebenfalls eine Hilfe sein, auch wenn es bei der Bewertung eines konkreten Produkts weniger darauf ankommt bei möglichst vielen Stationen des Life Cycles ein Häkchen setzen zu können, als darum Aspekte wie die innere Integration, die Offenheit und die Durchgängigkeit des Datenmodells zu bewerten.

Wie man einen Laptop für die Softwareentwicklung auswählt (oder auch nicht)

ihbrune

Angeregt von Ayo Isaiahs Artikel ‘How to choose the right laptop for programming’ schreibe ich hier einmal auf wie es ausgegangen ist, als ich mir zur Jahreswende die gleiche Frage stellte. Und am Ende bei etwas komplett anderem gelandet bin, als ich mir eigentlich vorgestellt hatte. Die Geschichte dazu findet vielleicht der ein oder andere unterhaltend. Oder sieht sie als warnendes Beispiel 😁

Was ich (glaubte) zu wollen

Ich suchte einen Laptop als privates Gerät für kleinere Softwareentwicklungsprojekte. Warum einen Laptop? Weil ich schon seit mehr als 15 Jahren auf solchen Geräten entwickle. Bei den ersten Suchen im Netz waren dabei meine Schlagworte meist so etwas wie ‘Dev Laptop’, ‘16GB’, ‘Linux’, ‘SSD’. Und irgendwie landete ich dabei immer wieder bei Dells XPS Reihe und ihren äußerst positiven Rezensionen wie hier von The Verge.

Vielleicht hat mich dann dieses wunderschöne Gerät allmählich auf die ’schiefe Bahn’ gebracht und nach und nach den ästhetischen Aspekt in den Vordergrund treten lassen: Hat man sich erst einmal in ein so flaches Gerät mit nahezu randlosem, sehr hoch auflösendem Display verliebt wirken Produkte, die eigentlich deutlich pragmatischer sind, plötzlich blass und uncool. Und es gibt sogar Versionen mit Linux drauf. Auch das ich in den Jahren zuvor viel Zeit auf einem MacBook verbracht habe hat sicher dazu geführt, dass ich auf keinen Fall irgendeine ‘Klapperkiste’ erwerben wollte.

Was ich dann tatsächlich erwarb

Leider gab es ein Problem mit der XPS Reihe: Schönheit hat ihren Preis und in der Ausstattungslage, die ich mir vorstellte, gab es nichts unterhalb von eineinhalb tausend Euro. Zu viel für ein Gerät, welches im Haushalt neben Smartphone, Pixel C Tablet samt Tastatur, verschiedenen Chromebooks, dem MacBook und einem alten Windows Laptop würde um seinen Platz kämpfen müssen.

Nachdem ich daher lange in Schnäppchen- und Kleinanzeigenseiten vergeblich darauf gewartet hatte ein günstiges (Gebraucht)Gerät zu finden war klar, dass es kein XPS werden würde. Da inzwischen aber schon so viel Zeit vergangen war wurde es Zeit für einen Spontankauf. Von einem Kollegen auf den in Münster beheimateten Gebrauchtgerätehändler Lapstore gebracht ging es dann ganz schnell: Durch die von der XPS Fixierung erzeugt Fokussierung auf gutes Aussehen und eine dünne Bauform schlug ich dann bei einem Lenovo Yoga 600 Ultrabook zu. Natürlich in der goldenen Variante:

Lenovo Yoga Ultrabook

Und wie gut erfüllt nun das Gerät meine ursprünglich formulierten Ansprüche? Hier halte ich mich grob an die Kategorien, die Isaiah gewählt hat:

Mobilität

Das ist einer der wenigen Punkte, bei denen ich mir treu geblieben bin: Ich wollte ein Gerät, welches eher mobil als extrem leistungsfähig ist. Das habe ich mit diesem Ultrabook erreicht: Der Bildschirm ist ausreichend groß, aber nicht zu groß, es ist sehr, sehr flach und man kann in jeder Tasche Platz dafür schaffen, in dem man die c’t herausnimmt. Die dann später – als die ersten Kratzer aufgetreten waren – beschaffte Filzhülle macht das Gerät ca. doppelt so dick, aber es ist immer noch sehr flach.

Display

Das Display ist kraß. Für mich ist es der erste Laptop mit einer Auflösung, die der schon lange von Smartphone und Tablet gewohnten nahekommt (QHD+). Braucht man das? Vielleicht nicht, und die hohe Pixeldichte macht auch manchmal Probleme, z. B. bei einigen Java Anwendungen, die ohne Anpassungen in winzigen Schriftgrößen daher kommen. Aber wenn es klappt, dann sieht es sehr, sehr gut aus.

Es ist auch mein erster Windows Laptop mit Touchscreen. Ich habe mich früher oft verächtlich über den Sinn eines Touchscreens in Geräten mit fest eingebauter Tastatur geäußert und zwar in dem Sinne, warum man ein Bedürfnis haben sollte den Bildschirm unnötigerweise mit seinen Fingerabdrücken zu besudeln?

Tatsächlich bemerkte ich in den letzten Jahren aber immer häufiger, dass ich unbewusst damit begann auf allen möglichen Bildschirmen herum zu wischen, einfach weil inzwischen die Mehrzahl der benutzten Geräte (Smartphone, Tablet, Chromebook) das bot. Ich könnte auch weiterhin ohne die Touchfunktion leben, aber gelegentlich ist sie – z. B. beim Lesen langer Texte bzw. beim Surfen – einfach praktisch.

Bei der Gelegenheit auch ein Wort zur Möglichkeit das Display komplett herum zu klappen und damit das Gerät in ein klobiges Tablet zu verwandeln: Das habe ich ein einziges Mal gemacht, für mich ist es ein wenig nützliches Gimmick. Allerdings nutze ich tatsächlich recht häufig die damit verbundene Möglichkeit das Display extrem flach anzustellen, z. B. wenn ich auf dem Laptop etwas lese.

Was mich tatsächlich an dem Bildschirm insgesamt nervt sind die sehr starken Spiegelungen. Gerade die Chromebooks, die ich meist zum Schreiben langer Texte verwende, sind alle matt, und bei dem MacBook ist es mir nie so störend aufgefallen. Vielleicht liegt es bei Yoga daran, dass nicht nur der Bildschirm spiegel, sondern auch der schwarze Rand drumherum. Das ist wirklich unnötig.

CPU & Lüfter

Erst als der Lüfter des Yoga zum ersten Mal ansprang und sich lange nicht mehr ausschalten wollte fiel mir ein, dass ich jahrelang Geräte genutzt habe, die entweder:

  • keinen Lüfter hatten,
  • so gut belüftet waren, dass er nie anspringen musste oder
  • deren Lüfter unhörbar leise war.

Keiner dieser Punkte trifft auf das Yoga zu und gerade die manchmal stundenlangen Windows 10 Updates verbringt das Gerät gerne mit einem unangenehmen Dauergepuste aus den schicken Luftauslässen:

Lenovo Yoga Ultrabook

Nervig. Bei der für mich normalen Entwicklungsarbeit (Java, Eclipse) hingegen verhält er sich zum Glück meist ruhig.

Die CPU ist eine i5. Reicht für mich und ein i7 hätte die Lüfter- und Batterieprobleme vermutlich noch weiter verschärft.

RAM

Ich bin dann doch bei nur 8 GB gelandet. Für mich reicht es, da ich im Moment doch nicht so viel mit VMs hantiere, wie zunächst gedacht. Die fehlende Erweiterungsoption könnte mich hier aber vielleicht einmal einholen.

Harddisk

Natürlich eine SSD, aber nicht besonders groß. Was OK für mich ist, meine ganzen Fotos lagern sowieso nicht lokal auf den PCs und ich lade mir bei der bescheidenen Internetverbindung hier auch nicht jeden Tag gewaltige Datenmengen herunter.

Das Gerät hat manchmal sekundenlange Aussetzer, in denen ‘nichts’ passiert, und irgendwie bringe ich das mit der SSD in Verbindung. Allerdings ohne es bisher beweisen zu können.

Tastatur & Trackpad

Die Tastatur ist tatsächlich für mich – neben dem nervigen Lüfter – das größte Problem: Lenovo hatte die blöde Idee an den rechten Rand, also neben Return und Backspace, noch eine Tastenspalte zu quetschen und zwar mit so wichtigen Tasten wie Pos1, Ende, Page up/down. Alle, wirklich alle Geräte, die ich sonst nutze, haben keine derartigen, überflüssigen Tasten an dieser Stelle. Wie sehr sich mein Gehirn angewöhnt hat bei der Suche nach Löschen, Zeilenumbruch und Shift einfach den rechten Geräterand mit den Fingern zu suchen und dann auf die ersten dort vorgefundenen Tasten zu klicken ist mir sehr schnell klar geworden.

Lenovo Yoga Ultrabook

Länger hat es gedauert bis klar war, dass sich mein Gehirn nicht so ohne weiteres umprogrammieren lässt, jedenfalls nicht, solange ich die anderen Geräte weiter nutze. Was ich tue. Und so verfluche ich das Yoga und die Designer seiner Tastatur bis heute, wenn ich meine ersten Zeilen eingebe und beim ersten Versuch ein falsches Zeichen zu löschen am Zeilenanfang lande.

Das Trackpad ist hingegen OK, wobei ich inzwischen einfach größere Pads gewohnt bin und die hier gewählte Aufteilung zwischen einer Seite für ‘linken Mausklick’ und einer für ‘rechten Mausklick’ unsinnig und irritierend finde.

Batterie

Laut Prospekt ‘mehr als 8 Stunden’. Aber das ist gelogen. Für mich ist das Yoga kein Gerät, mit dem man einfach morgens ohne Ladegerät aus dem Haus gehen und sicher sein kann nicht irgendwann in Probleme zu geraten. So wie es beim MacBook der Fall ist.

Gerade am Anfang war das Yoga schockierend schnell leer, z. B. wenn man ein Windows Update machte, weitere Software installierte und nebenher normal damit arbeitete. Gleichzeitig ist das Ladegerät ein echter Klotz, den man nicht mitschleppen möchte.

Betriebssystem

Kein Linux, sondern Windows 10. Auch hier haben sich die Folgen der Ästhetik gezeigt: Für die Laptops mit den extrem schlanken Bauformen und aktuellen Bauteilen ist die Treiberlage einfach schlecht und selbst wenn man es schaffen sollte darauf ein Linux zum Laufen zu bringen kann man nicht damit rechnen die gleiche Performance – z. B. bei der Batterielebensdauer – zu erreichen wie unter Windows.

Und im Grunde gefällt mir Windows 10 wirklich gut: Schicke Oberfläche, weit moderner für meinen Geschmack als das, was Apple heute hat, wenn auch natürlich nicht so aufgeräumt wie das Material Design, welches in ChromeOS nach und nach Einzug hält. Und die Sünden und Fehler aus Windows 8 wurden zum größten Teil rausgeworfen oder minimiert.

Und Linux kann man in ganz unterschiedlichem Umfang für Entwicklungszwecke ja trotzdem bekommen, wenigstens wenn einem die Kommandozeile im wesentlichen ausreicht: Abgesehen von der klassischen VM gibt es seit einiger Zeit von Microsoft das sogn. Linux Subsystem, welches einem die Bash bringt. Und für etwas weniger anspruchsvolle Zwecke reicht vielleicht auch schon die Cmder Shell aus.

Aber, aber….

…wieso ich das Gerät behalten habe, trotz der ganzen nervenden Punkte? Vielleicht hätte ich es wirklich zurückgeben sollen, insbesondere wegen der Tastatur. Allerdings dachte ich damals noch, dass ich mich daran bestimmt gewöhnen würde.

Und auf der anderen Seite ist das Gerät für meinen Geschmack wirklich, wirklich schön. Wer hat nicht gern Werkzeug, welches (auch) gut aussieht? Dadurch zieht das Yoga immer mal wieder interessierte KollegInnen an und sorgt für Diskussionen 😆 Das Gehäuse hat eine hohe Steifigkeit, die bei einem so dünnen Gerät verblüfft, und dem Metallgehäuse des MacBooks nicht nachsteht.

Aber würde ich es noch einmal kaufen? Vermutlich nicht. Denn beim nächsten Kauf hätte ich diese Prioritäten:

  1. Das Gerät sollte weiterhin eine gewisse Eleganz und Schlankheit haben (ja, ich kann da nicht aus meiner Haut)
  2. Die Tastatur muss zu mir passen bzw. meinen Gewohnheiten entsprechen, das Trackpad sollte möglichst groß sein
  3. Der Bildschirm muss nicht matt sein, aber er sollte auch nicht so extrem stark spiegeln. Touch ist OK, aber kein MUSS
  4. Wenn schon Lüfter, dann bitte leise oder selten genutzt
  5. Der Akku sollte einen durch den Tag bringen

Ansonsten natürlich eine gewisse Grundleistungsfähigkeit (SSD, RAM, etc.). Diese Liste führt eigentlich automatisch dazu, dass man das Gerät ein paar Tage nutzen muss, da sich gerade die Frage ob man in der Lage ist sich auf bestimmte Eigenarten einzustellen, oder ob sie ein dauerhafter Stein des Anstoßes sein werden, sonst kaum beurteilen lässt.

BoringSSL und die FIPS 140-2 Zertifizierung

ihbrune

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?

ihbrune

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.