Skip to main content

Das Smartphone als Übergangsphänomen

3 min read

Virtuelle Realität beginnt im Bildschirm eines Mobiltelefons. Das war im Jahr 2000 eine steile These von mir. Es hat etwas gedauert, aber inzwischen sieht man in jeder U-Bahn, wie sich der Cyberspace über unsere physische Wirklichkeit stülpt: Die Körper parken in den Sitzen, ein Teil des Lebens der Pendler spielt sich gerade anderswo ab. An einem Ort, den jeder über das Smartphone-Display erreicht. Dieses Smartphone-Konzept, ist nicht einmal zehn Jahre alt. Vielleicht sind diese kleinen Bildschirme nur ein interessantes Übergangsphänomen, das uns 2027 so bedeutend wie Wap und iMode vorkommen wird.

Steile These: Mixed Reality verdrängt die Displays

Dass das so kommen kann, ist die steile These dieser Wired-Titelgeschichte über virtuelle Realität. Wenn Wired recht hat, sieht die Schnittstelle zur virtuellen Realität in zehn Jahren so aus, wie man sie sich in den Achtziger vorgestellt hat: Datenbrillen!

Wired beschreibt sehr interessante Mixed-Reality-Ansätze. Ausprobiert haben die bislang ein paar tausend Menschen, wenn es hochkommt. Wenn es wirklich funktioniert, sieht das im Büroalltag so aus: Man sieht die physische Umwelt -  Wände, Schreibtisch, die Kollegen vor Ort. Und wo immer man einen Bildschirm braucht in dieser Welt, legt die Software eine Fläche über die physische Wirklichkeit. Kein 40-Zoll-Fernseher im Konferenzraum mehr, kein Bildschirm am Schreibtisch, kein Telefondisplay mit der Anrufliste. All das kann man virtualisieren, physische Bildschirme sind nicht wichtig. Das ist keine Vision für das Jahr 2027 - so sollen im nächsten Jahr die Menschen bei Magic Leap und Meta 2 arbeiten. Wired:

„I found virtual screens and virtual media within a virtual reality surprisingly natural and practical. At Magic Leap, the development team will soon abandon desktop screens altogether in favor of virtual displays. Meron Gribetz, founder of Meta, says that its new Meta 2 mixed-reality glasses will replace monitors in his company of 100 employees within a year. It’s no great leap to imagine such glasses also replacing the small screens we all keep in our pockets. In other words, this is a technology that can simultaneously upend desktop PCs, laptops, and phones.“

Aber auch wenn sich das Smartphone tatsächlich als kurzfristiges Übergangsphänomen erweisen sollte: Die drei grundlegenden Veränderungen, die es gebracht hat, werden sich wohl noch beschleunigen:

1. Die physische Realität wird maschinenlesbar

Dem Smartphone als Sensor verdanken wir zum Beispiel, dass Verkehrsprognosen präziser und schneller verfügbar sind. Wie wird man Daten über die Nutzung von Mixed-Reality-Anwendungen analysieren? Vielleicht misst jemand, wer in teilweise virtualisierten Besprechungen welche Teammitglieder wie oft anschaut. Kann man daraus Rückschlüsse über das soziale Gefüge in einem Team ziehen? Darüber, wie es wirkt, was da gerade jemand sagt?

2. Neue Schnittstellen stülpen der Welt neue Geschäftsmodelle über

Uber oder Mytaxi wären ohne Smartphones nicht möglich. Wie Mixed Reality wohl das Geschäft der Außenwerber verändert?

3. Neue Schnittstellen verteilen Aufmerksamkeit anders

Medien liefern heute Videos und Texte großen Medienplattformen wie Facebook, Snapchat und Youtube zu, die den direkten Kontakt zu den Menschen haben. Das wäre ohne Smartphones nicht so schnell und in diesem Ausmaß geschehen. Eine Schnittstelle, die das leisten kann, was der Fernseher, der Smartphonebildschirm und der Monitor auf dem Schreibtisch tun, wird die Aufmerksamkeit der Menschen komplett neu verteilen.

Es genügt nicht, nur die Algorithmen zu analysieren

5 min read

Zum nächsten TÜV-Termin nehme ich ein Blatt Papier mit einem Rezept für die Entwicklung meines Autos mit. Der Inhalt des Rezepts: Meine Scouts analysieren alle zugelassenen Autos in Deutschland und suchen dann jene Bauteile heraus, die am besten funktionieren und am wenigsten kosten. Daraus baue ich mein Auto. Und dieses Auto soll mir der TÜV dann schon mal vorab auf Basis des Rezeptes zulassen. Klingt absurd? Ich glaube auch nicht, dass der TÜV da mitmacht. Was bei Autos merkwürdig klingt, soll bei Software so funktionieren. Einen „Algorithmen-TÜV“ fordern immer wieder kluge Menschen in der deutschen Debatte über Software (zum Beispiel Bundesjustizminister Heiko Maas).

Trainingsdaten machen Software klug.

Wer beurteilen will, ob eine Software gut oder schlecht handelt, muss mehr tun als alle paar Monate oder Jahre Algorithmen zu prüfen. Denn es ist nicht Algorithmen allein zu verdanken, dass Software heute recht gut übersetzt, Sprache verschriftlicht, Risiken abschätzt, Nachrichtenrelevanz beurteilt, Go und Schach spielt. Die Verfügbarkeit großer Trainingsdatensätze dürfte dafür mindestens ebenso wichtig sein. Einige Hinweise darauf führt der Mathematiker Alexander Wissner-Gross an:

  • 2005 feierte Google große Fortschritte seiner Übersetzungssoftware beim Übertragen aus Mandarin in Englische. Der zugrunde liegende Algorithmus war 1988 veröffentlicht worden. Doch den 1,8 Billionen Elemente umfassende Trainingsdatensatz hatte Google erst im selben Jahr zusammengetragen.
  • 2011 schlug die IBM-Software Watson menschliche Gegenspieler in der Spielshow „Jeopardy“. Die Watson zugrunde liegenden Algorithmen waren seit 1991 öffentlich, die aus Wikipedia und anderen Quellen gefüllte Wissensdatenbank hatte IBM 2010 fertiggestellt.

Es ist also kompliziert.

Um das Handeln von Software zu analysieren, muss man ihr Lernmaterial kennen.

Das Bild „Algorithmen-TÜV“ erscheint sehr sinnvoll, wenn man sich Entscheider-Software wie ein Auto oder wie ein Kuchenrezept vorstellt. Also als etwas, das einmal fertig gestellt ist und dann nur noch in Intervallen weiterentwickelt wird - wenn überhaupt. Ans Auto kommt ein neuer Spoiler? Ab zum TüV. Beim Kuchenrezept verdoppeln wir die Zuckermenge? Besser prüfen. Um dieses Bild von Software aus dem Kopf zu kriegen, muss man andere Analogien lesen. Denn lernende Software funktioniert anders.

Der estnische Informatik-Doktorand Tambet Matiisen beschreibt lernende Software in diesem Essay über einen Vergleich mit menschlichem Lernen: Positive Erfahrungen verstärken trainierte Muster:

„Reinforcement learning is an important model of how we (and all animals in general) learn. Praise from our parents, grades in school, salary at work – these are all examples of rewards. Credit assignment problems and exploration-exploitation dilemmas come up every day both in business and in relationships. (…) But deep Q-networks still continue to amaze me. Watching them figure out a new game is like observing an animal in the wild – a rewarding experience by itself.“

Diese Analogie veranschaulicht zwei Dinge: Lernende Software entwickelt sich ständig fort. Und: Wie sie sich entwickelt, hängt davon ab, mit welchem Lehrmaterial sie konfrontiert ist und welche Anreize ihre Entwickler vorgeben.

Wir brauchen neue Analogien für Entscheider-Software

Eine andere großartige Analogie für die Entwicklung lernender Software hat Suresh Venkatasubramanian erdacht. Der Mann lehrt Informatik an der University of Utah. Er vergleicht lernende Software mit einem Rezept für die indische Linsensuppe Sambar. Die heute wohl weit verbreitete Vorstellung ist, dass ein Algorithmus einem Rezept nach diesem Muster entspricht: Man nehme 500 Gramm Linsen, einen Teelöffel Curry und noch etwas hiervon und etwas davon, dann koche man es so und so lange. So arbeitet lernende Software aber nicht.

Programme, die heute übersetzten, Menschen auf Fotos erkennen, Nachrichten einordnen und so weiter gleichen eher einem Verfahren, um überhaupt erst zu einem Linsensuppenrezept zu kommen. Venkatasubramanian beschreibt es so: Lernenende Software gleicht jemandem, der nur eine vage Ahnung davon hat, welche Zutaten in eine Sambar-Linsensuppe gehören. Der Koch lädt Freunde ein und lässt sie wieder und wieder nach immer neuen Konfigurationen gekochte Sambar-Varianten probieren. Er fragt die Gäste nach ihren Rezepten. Er probiert auch diese aus. Aus den Reaktionen der Gäste leitet er ab, welche Zutaten in welcher Dosis gut ankommen. Nach vielen Durchgängen wird der Koch ein Rezept für Sambar-Linsensuppe haben.

Nun stellen Sie sich vor, derselbe Koch hätte dieses Experiment in Tokio, Aarhus und Rio gemacht. Wie sehr sich die Rezepte wohl unterscheiden würden? Das ist die Stärke dieser Analogie: Sie zeigt, wie sehr es auf den Input ankommt.

Venkatasubramanians kommt zum Fazit: Algorithmen analysieren allein bringt nichts. Auf dieser Basis wird man nicht beurteilen können, was eine Entscheider-Software tut. Der Informatiker schreibt:

"Yes, we could just “look at the code”, but what we see is a mysterious alchemy in which each individual step might be comprehensible, but any “explanation” of why the code does what it does requires understanding how it evolved and what “experiences” it had along the way. And even then, you’d be hard-pressed to explain why the algorithm did what it did. If you don’t believe me, try looking at a neural network sometime."

Eine vierte Gewalt muss Input, Output und Verarbeitung analysieren

Das sollte eine unabhängige Aufsicht lernender Software leisten:

  • Überprüfen, ob die Software den Maßgaben folgt, die der Betreiber offenlegt.
  • Unerwünschte Verhaltensweisen und Folgen erkennen, die trotz Einhaltung der Maßgaben entstehen.

  • Beabsichtigte Manipulationen durch Dritte erkennen.

Um das zu leisten, genügt es sicher nicht, bloß Algorithmen zu analysieren. Man muss zudem auch die Trainingsdaten und alle von der Software getroffenen Entscheidungen einbeziehen. Es gibt einige Kontrollansätze, die mit den Input und den Output lernender Software analysieren. Beide Ansätze liefern Hinweise auf die Diskriminierung von Minderheiten - Amerikaner asiatischer Abstammung zahlen mehr für Nachhilfe, Menschen in mehrheitlich von Schwarzen bewohnten Vierteln waren länger auf Dienstleistungen und so weiter. Was mir bei beiden Ansätzen auffällt: Sie können nur funktionieren, wenn genügend Daten offen zugänglich sind. Um lernende Software zu prüfen und alternative Entscheidungen zu kennen, müssen Trainingsdaten offen zugänglich sein.

Warum Thomas Hobbes begeistert von Cloudflare wäre

5 min read

Wenn ein Text das Internet mit Autobahnen vergleicht, geht das oft schief. Deshalb versuche ich es mit Milchbauern, Kühen und Wiesen. Milchbauern sind alle, die im Netz veröffentlichten. Kühe sind Datenpakete und die Wiese ist die verfügbare Bandbreite. Das wird ein phantastischer Vergleich! Am Ende schaut noch Hobbes' Leviathan vorbei. Vorher aber einige wirklich wichtige Absätze mit einem konkreten Fall. Er zeigt, wie sich das Internet gerade verändert. Also los:

Erpresser nutzen Dienste für Erpresser-Abwehr

Spiegel Online berichtet, dass Erpresser deutschen Mittelständler drohen, ihre Webangebote mit Überlastungsangriffen lahmzulegen. Laut SPON nutzen einige Anbieter, bei denen man solche - illegalen - Überlastungsangriffe buchen kann, ausgerechnet die Dienste des Internet-Infrastrukturbetreibers Cloudflare. Darin liegt eine gewisse Ironie, denn Cloudlfare bietet Schutz gegen Überlastungsangriffe.

Spiegel Online schreibt:

„Auch die meisten der in Untergrundforen als Top 10 der kostenpflichtigen DDoS-Dienstleister geführten Angebote lassen ihre Webseiten von Cloudflare schützen. Anbieter von Netz-Attacken nehmen selbst kostenpflichtigen Schutz vor solchen Attacken in Anspruch.“

Ich erkläre mir das so: Die Anbieter solcher Überlassungsattacken greifen sich gegenseitig an, um Konkurrenz klein zu halten. Wer offline ist, verliert Aufmerksamkeit, Kunden und letztlich Geld. Die Anbieter von Überlastungsattacken wollen diese Schäden minimieren. Sie kaufen sich Schutz davor, dass ihre Internetpräsenz bei Überlastungsattacken unerreichbar ist. Cloudflare verteilt und liefert die Daten so zuverlässig aus, dass auch Angreifer auf diese Dienste vertrauen.

Soll eine Infrastukturfirma über zulässige Daten urteilen?

Die Situation von Cloudflare ist heikel: Wenn das Unternehmen von sich aus Inhalte vorab prüft und basierend auf einem eigenen Urteil bestimmte Angebote nicht ausliefert, tritt es als Torwächter auf. Soll Cloudflare alleine entscheiden, welche Daten weltweit ausgeliefert werden? Lieber nicht, urteilt Cloudflare-Gründer Matthew Prince:

„While we will respect the laws of the jurisdictions in which we operate, we do not believe it is our decision to determine what content may and may not be published. That is a slippery slope down which we will not tread.“

Das ist ein gutes Argument. Solche Entscheidungen sollten nicht privatisiert werden. Andererseits: Wenn die Entwicklung so weitergeht, werden sich noch mehr Anbieter aus Angst vor Überlastungsangriffen für einen Auslieferer wie Cloudflare entscheiden. Wenn man die eigenen Daten im Internet nicht zuverlässig ausliefern kann, bucht man die Dienste eines Infrastrukturanbieters.

Die Auslieferer verändern die Struktur des Internets: Daten von einem Server laufen auf ihrem Weg nicht mehr frei durch unterschiedliche Netze, die zum Internet zusammengeschlossen sind. Stattdessen transportiert ein Dienstleister die Daten vom Server durch seine Infrastruktur bis in die Zielnetze der großen Endkundenversorger.

Dienstleister wie Cloudflare bauen das Internet um - und zentralisieren

Cloudflare beschreibt die Entwicklung als einen Umbau des Internet:

„We are rebuilding the Internet, and we don’t believe that we or anyone else should have the right to tell people what content they can and cannot publish online.“

Diese neue Organisation ist umso attraktiver, je unzuverlässiger die bisherige Form der Auslieferung wird. Überlastungsangriffe schaden der Zuverlässigkeit der bisherigen Organisation des Internets in vielen miteinander verbundenen Teilnetzen unterschiedlicher Betreiber.

Mit dem dezentralen Internet verhält es sich wie mit der gemeinsamen Weidefläche in der klassischen Denkfigur von der „Tragödie der Allmende “. Die Gemeinschaftsweide nutzen alle Milchbauern eines Dorfes. Wenn nun ein Bauer die geteilte Infrastruktur über Gebühr in Anspruch nimmt, haben die Kühe dieses einen Überweiders kurzfristig mehr zu essen. Übertragen auf Überlastungsangriffe müsste das Bild so aussehen: Ein Bauer lässt seine Kühe mehr essen als sie brauchen, nur damit seine Konkurrenten weniger Ertrag haben. Kurzfristig profitiert einer, langfristig leiden alle, weil das gemeinschaftliche Gut leidet und die Gemeinschaft schwindet.

Wir ermächtigen Leviathane wie Cloudflare, wo das dezentrale Netz Macken hat

Nun haben wir im Internet mit Auslieferungsdiensten wie Cloudflare eine Option, die den Milchbauern nicht offen steht: Eine ganz neue Weidefläche mit einem magischen Schutz vor jener Art von Überweidung, die nur anderen Bauern schaden soll. Einen Nachteil hat diese neue Weide allerdings: Sie steht nicht mehr allen offen, sondern nur Bauern, die einen Vertrag mit dem Eigentümer abschließen. So gut dieser Vertrag auch kurzfristig ist, er ist strukturell anders: Hier schließen sich nicht Gleiche zusammen, um gemeinsam eine Ressource zu nutzen.

Hier geben die vormals Gleichen die gemeinsame Ressource auf, damit ein Verwalter Standards durchsetzt. Das läuft genauso wie bei Hobbes Gesellschaftsvertrag: Weil die Menschen als gleichberechtigte Partner ein Zusammenleben nicht hinkriegen, unterwerfen sie sich einem Herrscher, mit dem sie einen Vertrag schließen. Ihm übertragen sie ihre vormals gleichberechtigt geteilte Macht. Der Herrscher soll basierend auf dem so geschlossenen Gesellschaftsvertrag mit der neuen Macht durchsetzen, was die Menschen gleichberechtigt gemeinsam nicht geschafft haben.

Es kann sein, dass es anders nicht funktioniert als mit einem solchen Gesellschaftsvertrag und der Übertragung der Macht. Vielleicht ist Zentralisierung von Infrastrukturen im Internet bei wenigen Unternehmen tatsächlich der einzige gangbare Weg, damit es erträglich funktioniert. Ich weiß es nicht. Aber um das zu diskutierten, sollte man die Verhältnisse klar benennen. Natürlich hat ein Infrastrukturbetreiber wie Cloudflare Macht. Wer Infrastruktur betreibt, steuert. Auch die Entscheidung, vorab Dienste nicht zu kontrollieren, prägt Infrastruktur. Auch Untätigkeit hat eine Wirkung auf das Verhalten vieler Internetnutzer und letztlich, wie wir im Netz zusammenleben.

In diesem Fall setzt der Herrscher seine Macht nicht ein, um bestimmte Angebote zu unterbinden. Er hat einen Weg gefunden, dass Überlastungsangriffe die eigenen Nutzer der eigenen Infrastruktur nicht schädigen. Das hat aber eine Wirkung auf alle, die ihre Angebote nicht über einen Auslieferer gegen Überlastungsangriffe absichern. Es steigt ihr Risiko, Opfer zu werden. Und je größer diese Gefahr ist, desto attraktiver wird das „neu gebaute“ Internet, weil auch der Staat Überlastungsangriffe nicht unterbindet.

Das Wikipedia-Dilemma: Pflege ist so wichtig wie Innovation, motiviert aber nicht so sehr

3 min read

In einer fast 60 Jahre alten Kurzgeschichte steht eine phantastische Parabel für die größten Herausforderungen der Wikipedia, der Open Street Map und jeder Software, die mehrere Versionen und Jahre im Einsatz ist. Der argentinische Autor Jorge Luis Borges erzählt in »Von der Strenge der Wissenschaft« von der perfekten Landkarte. Der Herrscher eines längst untergegangenen Reiches wollte eine vollkommene Karte seines Imperiums schaffen. In einer seiner Karten war das Abbild einer Provinz des Reichs so groß wie eine Stadt. Aber selbst diese Karte war dem Herrscher nicht detailliert genug, also ließ er die Arbeit an einer Karte im Maßstab 1:1 beginnen. Irgendwann wurden die Karten nicht mehr gepflegt, weil die Ressourcen des Reichs nicht genügten. Die 1:1-Karte wurde nicht fertig, das Imperium zerfielt und es blieben nur verfallene Überreste der Modelle übrig.

An eine solche zu groß geratene und sich irgendwann selbst überlassenen Karte erinnern mich manche Unterseiten von Artikeln in der Wikipedia oder Friendica-Profile. Jedem Mitmach-Projekt im Netz und jeder gemeinschaftsgetriebenen Software droht das Schicksal der 1:1-Karte: Je größer und detaillierter eine Karte wird, umso mehr Pflege ist nötig, um sie nützlich zu halten. Nur ist leider bei vielen Projekten die größte Motivation für Mitwirkende, die Möglichkeit, etwas gänzlich Neues zu schaffen. Auf diesen Zielkonflikt zwischen dem Erschaffen und der Pflege des Erschaffenen kann man einige Probleme der Wikipedia oder dezentraler sozialer Netzwerke zurückführen. Wenn zu viel Kraft für das Erschaffen neuer Projekte, Artikel und Programme aufgewendet wird, verfällt das Bestehende irgendwann. Bei der Open Street Map kommen seit 2010 für jede Überarbeitung eines Details drei völlig neue Ergänzungen. Bisher ist die Mitmach-Karte noch gut nutzbar und aktuell. Doch wie lange hält das noch? Alan McConchie beschreibt die Entwicklung in diesem Essay.

Was tun? Die Technikhistoriker Lee Vinsel und Andrew Russell formulieren die provozierende These: »Innovation is overvalued« - Pflege sei viel wichtiger. Mir erscheint dieser Gegensatz allerdings künstlich. Tatsächlich kann ja auch die Pflege eines bestehenden Projekts durchaus kreativ sein und etwas auch etwas gänzlich Neues hervorbringen. Ein Beispiel für die Wikipedia: Viele Artikel leiden inzwischen meiner Ansicht nach daran, dass sie für viele Leser zu ausufernd und detailreich sind. Wer Details zu einem Aspekt eines Themas sucht, wird fündig. Wer einen Überblick der wichtigsten Aspekte eines Themas für Laien haben will, ist oft überfordert. Die Pflege dieses Fundus könnte auch das Schreiben von Zusammenfassungen sein.

Man muss nicht immer bei Null beginnen.

Warum Google Boston Dynamics verkauft? Vielleicht wegen Rüstung.

2 min read

Die Google-Mutterfirma Alphabet sucht also einen Käufer für das Roboterunternehmen Boston Dynamics. Bei den Spekulationen über die Gründe dafür dominiert gerade eine Lesart, die dieser Bloomberg-Artikel zusammenfasst:
- Die Roboter sind gar nicht so toll, weil sie nicht autonom handeln (»a human steered the robot via radio during its outside strolls«)
- Es wird mit Blick auf kommerzielle Produkte zu lange dauern, bis autonomes Handeln möglich sein könnte. (»it would take a decade to develop Boston Dynamics’s technology into a commercial product«)

Mir erscheint dieser Gedankengang nicht schlüssig. Es gibt heute eine Menge von Robotern, die durch Menschen gesteuert werden und viel Geld kosten. Zum Beispiel fliegende Drohnen. Es gibt durchaus einen Markt für solche Technologie in der Luft. Vielleicht auch am Boden. Dass Menschen die Drohnen steuern müssen, ist kein Ausschlusskriterium. Nur sind Rüstungsaufträge vielleicht nicht das Geschäftsmodell, das Alphabet verfolgen und in der Öffentlichkeit verteidigen will. Auch das ist reine Spekulation, aber ich finde diesen Gedanken so plausibel wie die dominierende Erklärung, die Bloomberg rekapituliert.

Es kann sein, dass die Technik für Rüstungsprojekte weit genug ist, für alle andere aber nicht und Alphabet dieses Geschäft nicht selbst verfolgen will.

Kopiert ein Mensch kreativer als Software?

5 min read

Tübinger Forscher haben hier einen interessanten Quiz ins Netz gestellt: Man sieht 10 Bilderpaare. Von jedem der Paare hat eines ein Mensch gemalt, das andere die Software der Tübinger errechnet. Menschen können bei diesem Quiz nicht besonders gut die Werke der Software von denen der Menschen unterscheiden. Die bislang knapp 44.000 Teilnehmer haben (Stand 22.2.2016) im Schnitt nur 6 von 10 Paaren richtig Mensch und Maschine zugeordnet.

unnamed-chunk-2-1
Ich habe den Quiz mit einem provozierenden Kommentar weiterempfohlen: „Was Software heute alles tut: Bilder malen.“ Daraus entspann sich eine interessante Diskussion darüber, ob Software wirklich malt und nicht doch etwas ganz anderes tut als Menschen, die Bilder machen.

Das Argument gegen die Formulierung „Software malt“ ist auf den ersten Blick einleuchtend: Ein Kopist ist kein Maler. Software ahmt nur nach, wendet die Techniken der analysierten Gemälde nach. Und in der Tat, so funktioniert die Software: Sie analysiert Kunstwerke. Sie nimmt dann ein Foto als Input entgegen und wendet die aus Kunstwerken gelernten Muster an.

Mein Argument ist: Meister nachahmen und deren Techniken anwenden - das beschreibt auch die Vorgehensweise vieler menschlicher Maler ziemlich gut. Oder sollte ich sagen: die Vorgehensweise bilderproduzierender Menschen? Malen kopierende Menschen etwa nicht?

Kopie als künstlerische Praxis

Ob Nachahmung Malerei ist, debattierte man lange, bevor Software Malstile erkannte und kopierte. In diesem Aufsatz über Kopie als künstlerische Praxis und ihre Bedeutung für die Erforschung der flämischen Buchmalerei aus dem 16. Jahrhundert sieht man das an einigen ganz konkreten Beispielen: Die Illustrationen französischer und flämischer Handschriften lassen sich kaum zweifelsfrei namentlich bekannten Künstlern zuordnen. Die Maler haben massig Motive kopiert und über die Verbreitung dieser Kopien kann man rückblickend die Werke einzelnen Werkstätten oder Malern zuordnen.

Höllenbruegel kopiert Papas Werke

Ein anderes Beispiel aus der niederländischen Renaissance: Pieter Bruegel dem Älteren werden nur gut 40 Gemälde eindeutig zugeschrieben. Es gibt viele andere, bei denen die Urheberschaft kaum zu klären ist. Einer seiner Söhne, Pieter Bruegel der Jüngere (aka „Höllenbruegel“), kopierte Werke des Vaters. Oder er ließ kopieren in seiner Werkstatt. Hat der andere Sohn Jan (aka „Samtbruegel“) aber auch gemacht.

Das Fazit dieser Beobachtungen hat schon der Kunsthistoriker Max Jakob Friedländer gezogen, 1946 in „Von Kunst und Kennerschaft“ (zitiert nach): Es gibt keine absolut originale Produktion, bilanziert er. Denn:

"Selbst der große und selbstständige Maler hat nicht nur die Natur, sondern auch Kunstwerke gesehen, Gemälde anderer Meister und seine eigenen. Er fußt auf einer Kunsttradition. In irgendeinem Grad ist jeder Maler Nachahmer und Kopist, so schon, indem er nach eigenen Naturstudien, Zeichnungen, Entwürfen ein Gemälde ausführt."

Wie würde Software in Rembrandts Werkstatt arbeiten?

Zurück zur Software. Wenn wir schon bei den unzweifelhaft großen Meistern anerkennen, dass Kopieren zu Ihrer Kunst gehört, kann das wohl kaum das einzige Kriterium sein, um das Schaffen einer Software von dem eines Menschen zu unterscheiden.
Die Rolle des künstlichen neuronalen Netzes der Tübinger Forscher kann man vielleicht mit einem Gedankenspiel präziser fassen. Stellen wir uns vor, die Software hätte für Rembrandt gearbeitet. Von den damals nicht vorhandenen Computern abgesehen, ist das gar nicht so abwegig. Rembrandt hatte Mitarbeiter, in seine Malerwerkstatt. Er malte nicht alles in allen ihm zugeschriebenen Gemälden selbst. Bekannt sind zum Beispiel die Hände des Pfarrers Johannes Wtenbogaert: Die hat ein Mitarbeiter gemalt. Der Mitarbeiter hat sie in Rembrandt Stil gemalt. Er hat unter Anleitung des Meisters zu dem Werk beigetragen - einen Künstler würden wir ihn vielleicht nicht nennen. Aber dass er malte, sehe ich als unstrittig an. Wenn ein künstliches neuronales Netz wie das der Tübinger diesen Job erledigen würden, würde sich an der Bewertung dieses Beitrags nichts ändern: Rembrandt ist der Maler, auch wenn die Hände eine Software aus seiner Werkstatt in kollaborative Fortentwicklung gemalt hat. Wenn wir eine Software haben, die wie der Höllenbruegel kopiert und die eigene Könnerschaft dadurch entwickelt, wird eine andere Stufe erreicht sein.

Mein Fazit daraus: Es bringt wenig Erkenntnisgewinn, Tätigkeiten und Werke danach zu kategorisieren, ob Software oder ein Mensch sie ausübt oder geschaffen hat. Man muss sich anschauen, was genau getan wird.

So formuliert klingt das banal. Versuchen wir es einmal anders: Der Chefredakteur des britischen Nachrichtenportals The Register Andrew Orlowski hat in einer lesenswerten Polemik diese These formuliert: „When the professional classes hollow themselves out, […], then they can’t really blame automation. They’ve automated themselves.“ Eines seiner Beispiele:

„Editors look at what hashtags are trending. They instruct that material is generated to feed that demand. The material is published in such a way to lure for Google News or Facebook algorithms. Behind the scenes, robots place the ads that accompany the material. More robots then click the ads ... around half of the ads served are never seen. It’s not really a »writer-reader« relationship any more. It’s a robot-robot relationship. At which point the utilitarian logic dictates that it makes sense to remove the middleman – the human.“

Artikelbild: "Brain surgery" (1893), keine bekannten Urheberrechtseinschränkungen

Fünf Faustregeln für nachhaltige digitale Dienste - und ein großartiges Beispiel namens Known

3 min read

Ich bin begeistert von der schlanken Blogging-Software Known. Man kann damit kurze und lange Texte, Fotos und Zitate im Web veröffentlichen. Das Besondere an Known ist, dass die Software als Basis gedacht ist, um die Datensilos sozialer Netzwerke wie Twitter oder Facebook zu befüllen (so sieht meine Known-Instanz aus).

Man veröffentlicht also einen kurzen Text im eigenen Known-Blog und kann den von dort automatisch auch in den eigenen Profilen bei Twitter, Facebook und so weiter veröffentlichen. Das Prinzip heißt POSSE - Publish (on your) Own Site, Syndicate Elsewhere.

Known importiert zudem die Reaktionen und Diskussionen aus diesen Netzwerken. Der Sinn der Sache: Die Datensilos bekommen eine Kopie, man behält jedoch den Ursprung der eigenen öffentlichen Rede in einer eigenen Datenbank, auf eigener Infrastruktur - außerhalb der Datensilos. Das hat einige Vorteile:

  • Menschen, die nicht geschlossene Netzwerke nutzen wollen (oder nicht dasselbe, das man selbst bevorzugt), können dennoch im offenen Web dem eigenen Gedankenstrom verfolgen.
  • Known unterstützt Standards wie RSS - die grundlegende Infrastruktur des dezentralen, offenen Netzes.
  • Man erreicht Menschen, die unterschiedliche Datensilos nutzen und bindet Reaktionen ein.

Nebenbei stärkt jeder Known-Nutzer das dezentrale, offene Netz und digitale Nachhaltigkeit.

Known - der Dienst ist in der Beta-Phase - erfüllt meine Faustregeln für digitale Nachhaltigkeit. Die ersten vier habe ich von Rafael Laguna aus dieser großartigen Rede.

https://youtu.be/sQAs91VWgos?t=1m43s

1. Der Dienst ist bei mehreren Anbietern erhältlich.

Man kann Known gegen Bezahlungen von den Entwicklern hosten lassen, aber auch bei einem Anbieter seiner Wahl installieren.

2. Beim Wechsel von einem Anbieter zum anderen müssen Daten transportierbar sein.

Die Exportfunktion von Known packt alle Posts, alle Uploads, alle Nutzerdetails ein und lässt sich dann in einer anderen Known-Installationen bei einem anderen Anbieter wieder einspielen.

3. Die Software muss zum Selberhosten verfügbar sein, damit man den Dienst auf eigener Infrastruktur betreiben kann.

Wer will, kann Known selbst hosten. Ist schnell gemacht und funktioniert auch bei Shared Hosting Anbietern wie Uberspace. Hier meine Installation.

4. Die Software, die den Dienst implementiert, sollte open source sein.

Na klar.

5. Der Dienst muss einen nachvollziehbaren Plan verfolgen, um die Fortentwicklung zu sichern.

Known ist Open Source - das ist eine Absicherung für den schlimmsten Fall, sollte das Geschäftsmodell scheitern. Die Entwickler haben ein Geschäftsmodell: Bezahltes Hosting der Pro-Version, eine bezahlte Eigenrntwicklung namens Convoy, die bei selbstgehosteten Installationen die API-Fummelei an den Datensilos abnimmt, Auftragsarbeiten im Bildungssektor.

Fazit

Nachhaltige digitale Dienste sind der Nährboden eines dezentralen, vielfältigen Webs. s gibt sie, trotz der neuen Blüte der walled gardens im Web. Known zeigt: Plausible Geschäftsmodelle sind denkbar und wenn mehr Menschen mitmachen auch möglich. Man muss die Vorteile und die Nutzer von Plattformen wie Twitter oder Medium nicht aufgeben, um ein freies, dezentrales Netz zu stützen — Publish (on your) Own Site, Syndicate Elsewhere, zum Beispiel mit Known.

Illustration: Telephones and Telegraphs, 1902, Public Domain

Lesetipp: Wo Wikipedia als Enzyklopädie versagt

1 min read

Meine EmpfehlungJohn Timmer, Wikipedia fails as an encyclopedia, to science’s detriment, Arstechnica.com

Darum: Die These des Autors ist diese: Selbst wenn alle Fakten eines Wikipedia-Artikels stimmen und selbst wenn alle Debatten in der Forschung über ein naturwissenschaftliches Thema dargestellt sind, kann der Artikel dennoch völlig ungeeignet für ein breites Publikum sein. Timmer argumentiert, dass viele Artikel, gerade zu naturwissenschaftlichen Themen, zu detailliert seien und zu viel Vorwissen voraussetzen. Es fehlt seiner Ansicht nach eine kurze, allgemeinverständliche Einführung für jeden. Artikel, denen das fehlt, sind letztlich wertlos fürs breite Publikum. Das mindere langfristig das Interesse der breiten Öffentlichkeit an Naturwissenschaft. Denn wer etwas verstehen will und das mit Hilfe eines Wikipedia-Artikels zum Thema als ersten Anlaufpunkt nicht schafft, gibt auf. So Timmer.

Wie die KI-Debatte falsch läuft und wo Software heute teilautonom entscheidet

3 min read

Anfang 2015 hat Elon Musk dem Future of Life Institute 10 Millionen Dollar gespendet, damit künstliche Intelligenz zum Wohle der Menschheit arbeitet. Das Paper, das dieses Grundlagen-Forschungsvorhaben umreißt, hat mich überzeugt, dass es heute Zeit ist, sich darüber Gedanken zu machen. Es gibt heute keine generelle Künstliche Intelligenz, ganz zu schweigen von einer Superintelligenz.

Aber seit einigen Jahren macht für spezielle Aufgaben (Gesichtserkennung, Spracherkennung, Übersetzung) entwickelte Software enorme Fortschritte. Programme erledigen einige früher Menschen vorbehaltene Aufgaben nunmehr gut genug für den produktiven Einsatz.

Und hier sehe ich ein Problem: Das gut genug in dieser Formulierung wird selten präzisiert, unabhängig untersucht und quantifiziert. Wir denken bei KI an Shodan, das Master Control Program, Terminator und derlei und unterschätzen dabei die aktuelle Wirkung von Software. Es ist nicht so, das Software in einer entfernten Zukunft autonom entscheidet. Software tut das heute in speziellen aber sensiblen Aufgabengebieten.

Ein Beispiel: Vor zwei Jahren fand ein Systemingenieur zufällig heraus, dass Software in Profi-Kopierern unter bestimmten Umständen Zahlen in Scans vertauscht. Aus einer 6 im Original wird eine 8 in der digitalen Kopie. Banal, denkt man. Dann denkt man weiter: Mit den Geräten arbeiten Architekten, Buchhalter, Rechnungsprüfer usw..

Es wäre gut, wenn es eine Debatte gäbe. Voraussetzung: Es geht nicht um Science Fiction, sondern um die Gegenwart. Eine Kernfrage ist heute wie übermorgen: Wie prüfen wir unabhängig, ob Software die abstrakt formulierten Ziele für ihren Einsatz erfüllt? Dabei wäre dann aber auch über die konkreten Ziele zu reden, die ein Unternehmen mit solcher Software verfolgt. Das kann sich von abstrakt und öffentlich formulierten Zielen unterscheiden.

Einige Beispiele dafür, was Software heute tut. Software…

Auf all diesen Gebieten sind schon heute die vier Forschungsfragen relevant, die das Future of Life Institute für Robuste KI formuliert hat:

  1. Verifizierung: Wie beweise ich, dass  das System die formellen Kriterien erfüllt? Oder: Habe ich das System richtig gebaut?
  2. Validität: Wie sichere ich, dass das System beim Erfüllen der formalen Kriterien nicht unerwünschte Verhaltensweisen und Folgen produziert? Oder: habe ich das richtige System gebaut?
  3. Sicherheit: Wie verhindere ich beabsichtigte Manipulation durch nicht autorisierte Dritte?
  4. Kontrolle: Wie ermögliche ich sinnvolle menschliche Kontrolle des Systems? Oder: Ich habe das System falsch gebaut, kann ich es reparieren?

Wäre doch gut zu wissen, oder? Ich würde eine fünfte Frage anhängen: Das es Software oft auf gesellschaftlich relevanten Feldern autonom handelnd, sollten die Antworten auf die Fragen 1 bis 4 öffentlich sein und eine Debatte anregen. Wie kriegt man das hin? Das finde ich wichtiger und spannender als Diskussion über Shodan & Co..

(Foto: NASA / Public Domain)

Das Netz als Rohstoff für Künstliche Intelligenz

3 min read

Jetzt gibt es noch eine Sache, die Software zuverlässiger erledigen kann als Menschen: Eine Million Fotos fehlerarm in 1000 vordefinierte Kategorien sortieren. Das erledigt ein bei Baidu entwickeltes Programm mit einer Fehlerquote von 4,58 Prozent. Menschen lagen bei den Imagenet-Fotos nach Training bei 5 Prozent Fehlerquote.

Das klingt ganz beachtlich, aber hey: Hier geht es darum, verschiedene Terrier-Arten, Gurken und Dreiräder korrekt auf Fotos zu erkennen. Nicht trivial, aber doch etwas weltfremd als Beleg für die enormen Fortschritte künstlicher Intelligenz. Oder?

Ich denke nicht. Was Baidu bei da bei der Bilderkennung schafft, erledigt Software heute bereits für Millionen Menschen: Programme sortieren für uns die unüberschaubare Wirklichkeit in erfassbare, für uns nützliche Ausschnitte. Beispiele, die so alltäglich sind, dass sie banal klingen:

  • Software entscheidet, wie viel Aufmerksamkeit wir welchen Freunde und Bekannten schenken (auf Facebook).
  • Software wählt die fünf oder sechs Aspekte aus, auf die wir uns bei der Recherche zu einem Buch, einem Menschen oder einer Firma fokussieren, weil sie in den Suchtreffern weit oben stehen.
  • Software beurteilt, wie vertrauenswürdig Käufer sind (und entscheidet, wer wie zahlen und wohin was geliefert werden darf).

Abstrahiert man von diesen Beispielen, ist diese Entwicklungsrichtung zu erkennen: Software erfüllt mehr und mehr eine Aufgabe, die lange menschengemachten Medien vorbehalten war: Software strukturiert die Welt. Sie ist eine Schnittstelle zur Welt. Dabei hilft es, dass heute der überwiegende Teil des aktuellen Weltwissens, der menschlichen Reaktionen und digital und online vorliegt. Das Internet ist der Rohstoff für Software, die daraus etwas Neues, für Menschen Brauchbares zieht und zusammenstellt. So wie Googles Knowledge Graph in diesem Beispiel:

https://twitter.com/fst/status/598041441055703040/

Was folgt daraus?

  1. Es wird Ärger und Verteilungskämpfe zwischen Rohstofflieferanten und den Erschaffern der Software geben, die Rohstoffe veredelt und vermarktet. (Hier einige Gedanken dazu)
  2. Wir werden viel mehr Medienwirkung-Experimente sehen. Baidus Bilderkenner hat sich selbst (nach Vorgaben seiner Entwickler) optimiert. Im Netz ist mit einem Millionenpublikum der Reaktion bestimmter Nutzer auf bestimmte Veränderungen des Angebot experimentell messbar. Und die Ziele dieser Optimierung? Nutzungintensität steigern? Verkaufswirkung von Content Marketing erhöhen? Nutzer glücklich machen? Führt uns zu Punkt 3.
  3. Wir brauchen Kriterien und Methoden, um unabhängig zu prüfen, ob Software diese Aufgaben gut und richtig macht. Eine Berufsethik für die Erschaffer dieser Programme wäre auch nicht schlecht. Wenn es seit Jahren Testfahrten für Software-gesteuerte Autos gibt, warum nicht auch für Welt.

Ich habe  obenoft Software tut dies und jenes geschrieben. Mir ist völlig klar, das Menschen sie schaffen. Doch wie die Autoren des Papers zum Baidu-Bilderkenner schreiben:

„It is possible that other approaches will yield the same results with less demand on the computational side. The authors of this paper argue that with more human effort being applied, it is indeed possible to see such results. However human effort is precisely what we want to avoid.“

Foto: Scrappo, mechanical scrap metal creation made by the Marion County salvage committee, Salem, Oregon, 1942, gemeinfrei

So holt man leicht Gebietsgrenzen für Infografiken aus Openstreetmap

3 min read

Das Ziel

Staaten, Bundesländer, Kreise, kreisfreie Städte, Stadtviertel - es gibt eine Menge Gebiete, für die man Daten auf Karten visualisieren kann. Die Umrisse solcher Gebiete lassen sich manuell aus Openstreetmap ziehen (hier eine Anleitung). Bei großen Karten ist das allerdings langwierig - etwa bei den 59 Kreisen und kreisfreien Städten in Nordrhein-Westfalen. Zum Glück gibt es da das großartige, kostenlose Hilfsmittel OSM Boundaries (Danke für den Tipp, Joost!) von Walter Nordmann. Hier eine Bedienungsanleitung.

Die Grenzen wählen

Die Bedienung von OSM Boundaries ist denkbar einfach. Entweder im Suchschlitz oben den Namen der Stadt oder des Bundeslandes oder Kreises eintippen. Dann klappt OSM Boundaries im Verzeichnisbaum links den richtigen Eintrag auf. Wichtig: Der Baum ist hierarchisch aufgebaut und man muss alle Ebenen (auch die darunter liegenden) bewusst auswählen.

screen-26-22-2015_01.22.36

Ein Beispiel: Ich habe einen Datensatz aus dem Mikrozensus Daten zu den Nettoeinkommen nach Städten und Kreisen im Bundesland Nordrhein-Westfalen. Also wähle ich im Baum links NRW aus, dann ein Rechtsklick und ich wähle „Select children“ aus. Nun sind die Regierungsbezirke aufgeklappt und deren Grenzen ausgewählt. Ich brauche aber noch die darunter liegende Ebene. Also wiederum bei jedem Regierungsbezirk Rechtsklick und „Select children“. Noch tiefer (das wären dann Stadtteile) muss ich nicht auswählen, so fein aufgeschlüsselt sind die Daten nicht.

Die Polygone exportieren

screen-26-24-2015_01.24.25
Ist die Auswahl komplett, wählt man ganz unten links das Exportformat aus. Hier kommt es darauf an, mit welchen Werkzeug man die Daten kombinieren und visualisieren will. Da ich zum Beispiel mit dem kostenfreien Google Fusion Tables arbeite, benötige ich die Grenzen der Kreise und kreisfreien Städte im KML-Format. Das bietet OSM Boundaries nicht als Exportformat an, aber das verfügbare json-Format ist eine gute Basis für die Konvertierung.

Konvertieren

Für die Konvertierung in das KML-Format bietet sich der Geoconverter der Hochschule für Technik Rapperswil an. Die von OSM Boundaries exportierte json-Datei hochladen, KML auswählen und herunterladen. Klappt bei mir für die Nutzung mit Fusions Tables zum Kombinieren und CartoDB zum Visualisieren problemlos. Eine Alternative ist z.B. Geojson.io.

Gebiete und Daten kombinieren

Nun muss ich die KML-Datei mit den Gebietsgrenzen und die CSV-Datei mit den visualisierenden Daten in einer Datei zusammenführen. Dazu eignet sich das kostenfreie Google-Werkzeug Fusion Tables gut.

Dort lade ich die KML Datei direkt hoch. Den Datensatz musste ich noch etwas aufbereiten vorher: Leerzeichen raus, Daten so sortieren, dass nur noch ein Wert je Zeile drinsteht (hier eine Anleitung, wie das mit Datawrangler geht)

Bevor man die beiden Dateien vereint, sollte man unbedingt noch prüfen, ob sich beides richtig zuordnen lässt. Man braucht in beiden Dateien ein Merkmal zum Identifizieren der richtigen Paare. Sprich: Die Werte zu den Nettoeinkommen für die Stadt Essen sollen mit den Stadtgrenzen Essens kombiniert werden. Damit das klappt, muss aber in beiden Dateien das Merkmal identisch benannt sein. Bei meinem Datensatz gab es eine Abweichung: Im Datensatz heißt Mettmann Mettmann, in der KML-Datei Kreis Mettmann.

screen-26-16-2015_03.16.08

 

Also habe ich das vorangestellte „Kreis“ gelöscht und dann die Daten über den Merge-Befehl zusammengeführt (anhand des Merkmals Localname).

screen-26-11-2015_03.11.57

Visualisieren

Die zusammengeführten Daten kann man als CSV-Datei aus Fusion Tables exportieren und bei CartoDB einlesen. Damit habe ich diese einfache Visualisierung gemacht (Anleitung):

https://klischka.cartodb.com/viz/7dfcaf0c-ec1a-11e4-9d63-0e018d66dc29/public_map