The misleading microscopic view

The Guardian lists 10 gross ingredients you didn’t know were in your food, ingredients like arsenic, hair, or silicone breast implant filler. Should we react with nausea and disgust? Of course not. Yummy food is yummy food, neither a just detectable trace of someting (arsenic) nor the source of an ingredient (hair) nor possible other uses of the same ingredient (breast implants) have any noticeble impact. That’s by definition: if a dose of anything has a proven adverse health impact, it will be banned from being used in food. The Guardian‘s list is an example of microscopic properties that don’t matter macroscopically. Yummy food is yummy food.

We commit the same error when, in security, we look just at the software defects and neglect their security impact. All software has defects; we might easily assemble a list of 10, or 100, or 1000 defects you didn’t know were in your programs. This does not mean they’d all matter and need to be removed. A system is secure if it evokes a predictable and controlled incident profile over its lifetime. some software defects in some systems affect this incident profile in such a way that their removal matters. Others are just traces of poison, or issues appearing problematic by analogy. The problem is: we often don’t know which is which.

Das Angstgeschäft – ein Verriss

Für den Tagesspiegel nimmt Kevin P. Hoffmann die allgegenwärtge Sicherheitspropaganda auseinander. Kostprobe:

»Gleichwohl sind Bürger heute bereit, mitunter 60 bis über 100 Euro für ein Fahrradschloss auszugeben, um damit ein Rad zu schützen, das kaum doppelt so teuer war.

Auffällig ist auch, mit welcher souveränen Arroganz Vertreter der Sicherheitsbranchen ihrer potenziellen Kundschaft entgegentreten. Bürger seien zu dumm, Gefahren richtig einzuschätzen, hört und liest man immer wieder.«

(Tagesspiegel: Nach den Anschlägen von Boston: Gute Geschäfte mit der Angst)

Mit Sicherheit ist kein Geschäft zu machen. Investitionen in Sicherheit sind erzwungener Konsum; wer bei Verstand ist, wird die Ausgaben für Sicherheit minimieren und allerlei Risiken einfach hinnehmen. Geschäfte macht man mit Angst, und mit Produkten, die Angst reduzieren. Auf Sicherheit kommt es dabei nicht an.

Number Crunching

HP veröffentlicht den 2012 Cyber Security Risk Report. Neben dem Security Report 2013 von Checkpoint sieht HP natürlich alt aus, aber dafür legen die mit der neuen Forschungsabteilung jetzt ja 14-tägig neue Hot Topics auf den Tisch. Es gab mal Zeiten, da mangelte es an Zahlen, aber mittlerweile gibt es mehr als genug davon. Leider gibt es immer noch zu wenig Maßgebliches oder Interessantes. Gibt es eigentlich eine Statistik über die Anzahl der IT-Sicherheitsstatistiken?

Huch ein Datenleck

Verizons Data Breach Investigation Report 2013 zeigt, was wirklich hilft gegen Datenlecks. Sichere Passwörter bei den Kundendienst-Mitarbeitern!-)

 

 

Mandatory Helmet Laws Reduce … Theft

What happens when a government enacts and enforces a mandatory helmet law for motorcycle riders? According to criminologists, a reduction in motorbike theft follows. The 1989 study Motorcycle Theft, Helmet Legislation and Displacement by Mayhew et al. (paywalled, see Wikpedia summary) demonstrated this effect empirically looking at crime figures from Germany, where not wearing a helmet on a motorcycle is being fined since 1980. This lead to a 60% drop in motorcycle theft – interestingly, with limited compensation by increases in other types of vehicle theft.

The plausible explanation: motorcycle thieves incur higher risk of being caught when riding without a helmet after a spontaneous, opportunistic theft. Adaptation is possible but costly and risky, too: looking for loot with a helmet in one’s hand is more conspicious, and preparing specifically to steal bicycles reduces flexibility and narrows the range of possible targets.

Levels of Crime Opportunity

Just came across a crime science paper that expresses an idea similar to my security property degrees:

»In addition, for any crime, opportunities occur at several levels of aggregation. To take residential burglary as an example, a macro level, societal-level cause might be that many homes are left unguarded in the day because most people now work away from home (cf. Cohen and Felson 1979). A meso-level, neighborhood cause could be that many homes in poor public housing estates once used coin-fed fuel meters which offered tempting targets for burglars (as found in Kirkholt, Pease 1991). A micro-level level cause, determining the choices made by a burglar, could be a poorly secured door.«

(Ronald V Clarke: Opportunity makes the thief. Really? And so what?)

Clarke doesn’t elaborate any further on these macro/meso/micro levels of opportunity for crime. Maybe I’m interpreting too much into this paragraph, but in essence he seems to talk about security properties – he is discussing in his paper the proposition that opportunity is a cause of crime and reviews the literature on this subject. Opportunity means properties of places and targets.

Lobachevsky

(YouTube, via)

In einem Wort

The nonsense math effect (via)

Redefining a Security Problem to Fit Mechanism Capabilities

Bruce Schneier dug out this little gem: Forbidden Spheres. A nuclear weapons lab, so the (apparently unconfirmed) story goes, classified all spherical objects as confidential, rather than just those related to nuclear weapons design. In the security-as-classification paradigm this makes a lot of sense. The desired security policy is to keep everything related to weapons design confidential. This includes objects that might give away information, which one will naturally find in an R&D lab. To enforce this policy, however, requires either comprehensive tracking of all objects, or complicated considerations to decide whether an object is classified as confidential under the policy or not. But a subset of the objects under consideration has a common, easy-to-detect property: they are spherical. The classification required as a prerequisite for policy enforcement becomes much simpler if one considers only this feature. The classification also becomes less perfect, there are classification errors. However, if it’s all about nuclear spheres, than the simplified classifier errs systematically towards the safe side, erroneously classifying innocuous spherical objects as confidential. As long as it doesn’t disturb the intended operations of the lab, this may well be acceptable. This approach would break down if an adversary, or an accident, could easily change relevant shapes without defeating purpose.

An Exercise in Lateral Thinking

A year ago, in a slightly heated debate on secure software engineering, I used a photography analogy to make my point. The precise background of this debate does not matter; it should suffice to say that one party – “us” – opined that security engineering is difficult and complicated, while the the other party – “them” – held the view that average software developers need just a couple of tools and examples to improve the results of their work, security-wise. Both sides had a point, considering their respective backgrounds, but they spoke of requirements while we spoke of the difficulty of fulfilling these requirements. To explain my position on the issue, I tranferred the problem from security engineering into a totally unrelated field, photography. They seemed to expect they could turn average people into reasonably good photographers by handing them a highly automated point-and-shoot camera and a few examples of great photos. We ended the quarrel agreeing to disagree.

The train of thought thus started led to my latest paper Point-and-Shoot Security Design: Can We Build Better Tools for Developers? which I finished a few weeks ago, after having presented and discussed an earlier version at this year’s New Security Paradigms Workshop. In this paper I explore the photography analogy in general, interpreting (some aspects of) photography as visual engineering, and the point-and-shoot analogy of tool support in particular. The final version of the paper does not fully reflect its genesis as I moved the photography part, from which everything originates, into a separate section towards the end.

Describing in abstract terms different classes of properties that we can analyze and discuss in a photo, I develop the notion of property degrees, which I then transfer into security. Properties characterize objects, but they do so in different manners:

• Microscopic properties characterize an object by its parts, and in terms that we can express and evaluate for each part in isolation. Taking a microscopic point of view, we describe a photo by its pixels and the security of a system by its security mechanisms and its defects.
• Macroscopic properties characterize an object by the way it interacts with its surroundings. Macroscopic properties of a photo represent the reactions the photo evokes in the people viewing it, and the macroscopic security properties of a system characterize the reaction of a threat environment to the presence of this system.
• In between, mesoscopic properties characterize the object in its entirety (as opposed to the microscopic view) but not its interaction with an environment (as opposed to macroscopic properties). We speak about microscopic properties if we discuss, for instance, the composition of a photo or the security of a system against a certain class of adversaries, considering motivations and capabilities.

Speaking of property degrees as of three distinct classes is a simplification; one should really think of the property degree as a continuum and of the three classes as tendencies. In a rigorous definition, which my paper doesn’t attempt, we would likely end up calling all properties mesoscopic except for those at the ends of the interval.

The ultimate objective of photography and security engineering alike, I argue, is to shape the macroscopic properties of that which one creates. Any object has properties at all three degrees; to design something means to control these properties consciously and deliberately. To do that, one needs to control lower-degree properties to support what one is trying to achieve. However, there are no simple and universal rules how macroscopic properties depend on mesoscopic and microscopic properties. To figure out these dependencies is a challenge that we leave to the artist. That’s necessary in art, but less desirable in security engineering.

Looking at some of the security engineering tools and techniques that we use today, I argue that security engineers enjoy just as much artistic freedom as photographers, although they shouldn’t. Most of our apporaches to security design have a microscopic focus. The few mesoscopic and macroscopic tools we know, such as attack trees and misuse cases, are mere notations and provide little guidance to the security engineer using them.  To do better, we have to develop ways of supporting macroscopic analysis and mesoscopic design decisions. Right now we are stuck in the microscopic world of security features and security bugs, unable to predict how well a security mechanism will protect us or how likely a bug will be exploited in the wild.

Using photography as a model for security engineering is an intermediate impossible, a term coined by Edward de Bono for one aspect of lateral thinking. An intermediate impossible does not make much sense by itself, but serves as a stepping stone to something that might. In the case of point-and-shoot security design, it’s a double impossible, a) ignoring the boundary between art and engineering and, b) ignoring for a moment the adversarial relationships that we are so focused on and, simultaneously, so ignorant of in security. Out of it we get the universal notion of property degrees, and an application of this notion to the specific problems of security.

In a way, this work is a follow-up on my 2009 NSPW paper What Is the Shape of Your Security Policy? Security as a Classification Problem (mentioned here, here, and here). I based my considerations there on the notion of security policies, and later found it difficult to apply my ideas to examples without something bothering me. Security policies tend to become arbitrary when we understand neither what we are trying to achieve nor what it takes to achieve it. If you meticulously enforce a security policy, you still don’t have the slightest idea how secure you are in practice, facing an adversary that cares about your assumptions only to violate them. Property degrees don’t solve this problem, but maybe they make it a bit more explicit.

Ben Goldacre: Battling Bad Science

(Bad Science)

Theorie und Praxis

Theorie:

»In this work we propose a new security paradigm, that aims at using the network’s flexibility to move data and applications away from potential attackers.« (C.W. Probst; R.R. Hansen: Fluid Information Systems, NSPW’09)

Praxis:

»Willkommen auf der „Silk Road“, dem Portal für Abhängige, dem Amazon für Dealer. Silk Road, zu Deutsch: Seidenstraße, das klingt geschmeidig und weich. Dahinter verbirgt sich ein Onlineshop, der stündlich auf einen anderen Server wechselt, um erreichbar, aber nicht greifbar zu sein.« (Tagesspiegel, Klicken, bezahlen, nach Hause liefern lassen)

Lernung:

Gut und Böse gibt es in der Sicherheit nicht. Es gibt nur Interessen und Bedrohungen sowie Maßnahmen, die Interessen vor Bedrohungen schützen.

Safety Hysteria

(P&T)

Angriff abgewehrt

Im Zuge der durch die Volkspolizei seit dem 17.6.1953 zur Durchführung der Wiederherstellung der öffentlichen Ruhe und Ordnung getroffenen Maßnahmen wurden festgenommen:

Festnahmen insgesamt: 176 Personen
davon Bürger der DDR: 176 Personen
dem Militärkommandanten übergeben: 4 Personen
den Organen des MfS übergeben 142 Personen
den Gerichten übergeben: 2 Personen
bei der Volkspolizei verblieben: 10 Personen
wieder aus der Haft entlassen: 10 Personen

(Bezirksbehörde Deutsche Volkspolizei Erfurt:
Auswertung der Ereignisse seit dem 17.6.1953)

In einem Wort

Cyber Power Index

In einem Wort

Testpad

In einem Wort

Health halo effect

In einem Wort

UC Davis Computer Security Archives Project

Datenschutz: Anforderung oder Spezifikation?

In der Diskussion um die Datenkrake Google fällt mir immer wieder eine begriffliche Ungenauigkeit auf. Datenschutz sei gut und nützlich und bewährt, wie könne man nur dagegen sein, so die Argumentation. Tatsächlich bin ich gar nicht gegen Datenschutz als Anfoderung, sondern ich halte einige Aspekte der gegenwärtigen Spezifikation für ungeignet, die Anforderungen zu erfüllen.

Was ist der Unterschied zwischen Anforderungen und Spezifikationen? Anforderungen beschreiben die Ziele, die man verfolgt. Spezifikationen beschreiben den Weg. Charles B. Haley erklärt den Unterschied so:

»The distinction between requirement and specification is an important one. A requirement does not describe how a system is to be implemented, but instead describes what is desired by the stakeholders in terms of phenomena visible at certain domains in the real world. It is the specification that describes how, in terms of the phenomena of all the domains in the system, the requirement is fulfilled. For example, the requirement “given a temperature input in Fahrenheit, the system shall display that temperature in Celsius” is describing some input phenomena on one domain (probably a keyboard) and some output phenomena of another domain: the display; these are the requirement phenomena. The rest of the phenomena in the system exist to make the system produce its output requirement phenomena, given its input requirement phenomena.«

(Charles B. Haley, Arguing Security: A Framework for Analyzing Security Requirements)

Auf den Datenschutz übertragen finden wir unter einem Begriff, eben Datenschutz, eine bunte Mischung von Anforderungen und Spezifikation. Zu den Anforderungen gehören Ideen wie die der informationellen Selbstbestimmung und des Persönlichkeitsrechts und ihre Konkretisierungen. Alle spezifischen Regelungen hingegen stellen eine Spezifikation dar, eine Umsetzung der Anforderungen.

Dass beides in einem Gesetz vermischt ist, bedeutet nicht, dass die Spezifikation automatisch die Anfoderungen erfüllt. Ich bin der Ansicht, dass sie das im Fall des Datenschutzes heute nur noch teilweise tut. Daraus folgt nicht die Forderung nach einer Abschaffung des Datenschutzes, sondern die Forderung nach einer Anpassung der Spezifikation.

Deutlicher wird das, wenn wir die begriffliche Unterscheidung zwischen Anforderungen und Spezifikation in unsere Diskusionen abbilden. Ich bevorzuge deshalb die Bezeichnung Privatsphärenschutz für die Anforderungen. Ausdrücklich offen bleibt dabei, ob, unter welchen Bedingungen und in welchen Ausprägungen Datenschutz gemäß der aktuellen Spezifikation ein geeignetes und das einzige Mittel dazu ist. Vielleicht fällt uns ja noch was besseres ein.

Datenkrake Google (7/7): Privatsphärenschutz in der Datenwolke

[Seriennavi: Teil 1 – Teil 2 – Teil 3 – Teil 4 – Teil 5 – Teil 6 – Teil 7]

Wir haben uns in den Artikeln dieser Serie ein Modell gebildet, was Google mit Daten macht, welche Prinzipien dahinter stecken und wie daraus optimierte und partiell personalisierte Funktionen werden. Wir haben gesehen, dass naive Vorstellungen von Nutzerprofilen wahrscheinlich falsch sind. In Wirklichkeit betreibt Google automatisierte Verhaltensforschung im Industriemaßstab, bezogen auf spezifische Funktionen wie Eingabekorrektur, Übersetzung oder Werbeoptimierung. Als Ergebnis gewinnt Google populationsstatistische Aussagen, die individuell beziehungsweise nach impliziter Gruppenzugehörigkeit modifiziert werden können; eine klare Grenze zwischen diesen Aggregationsgraden gibt es nicht. Erfasst und gespeichert sind Googles Erkenntnisse in den Konfigurationen aufgabenspezifischer Klassifikatoren, die laufend dem globalen Verhalten der Nutzerpopulation angepasst werden. Die naiven Modelle aus Folge 2 passen nicht so recht dazu, auch wenn Google selbst manchmal anderes suggeriert:

Wer ein Google+-Profil hat und mit Google nach seinem eigenen Namen sucht, bekommt vielleicht diese Aufforderung zu sehen. Gemeint sind die expliziten und freiwilligen Angaben im Profil, nicht der Durchleuchtungsgrad der Person.

Damit es keine Missverständnisse gibt: Google besteht nicht nur aus lernenden Maschinen, viele Funktionen und Dienste nutzen auch herkömmliche Verfahren. Welche Termine in meinem Google-Kalender stehen, wen ich in Google+ in welchen Circles habe und welche Nachrichten in meinem GMail-Account liegen, speichert und verarbeitet Google (auch) ganz normal im Klartext, wie es jeder SaaS-Anbieter in der Cloud tun würde. Darauf mag man alle etablierten Begriffe und Modelle des Datenschutzes anwenden, wenngleich sie sich vielleicht aus anderen Gründen als unpassend erweisen. Ich behandle hier die Angstfunktion Daten sammeln und auswerten. Daten einfach zu sammeln lohnt sich im Google-Maßstab nicht, weil man mit einer Datenhalde wenig anfangen kann. Nach meinem Modell nutzt Google umfangreiche Daten, um damit einen Satz an Betriebsparametern fortlaufend zu optimieren und dem Lauf der Welt anzupassen. Die Optimierung und Anpassung erfolgt interaktiv, Google lernt von seinen Nutzern, was richtig und was falsch ist, was ähnlich und was verschieden. Das ist etwas anderes als das elektronische Profil, das Thilo Weichert sich vorstellt und es hat Folgen, die er sich nicht vorstellt.

Was ist anders?

Ein Klassifikator häuft nicht einfach Daten an. Er besitzt eine Konfiguration und zwei Grundfunktionen, Lernen und Klassifizieren. In der Funktion Klassifizieren erhält er einen Datensatz als Eingabe und gibt eine Entscheidung oder Entscheidungsempfehlung aus. In der Funktion Lernen passt er seine Konfiguration an, um die Rate der Fehlentscheidungen zu reduzieren. Die Konfiguration des Klassifikators gibt nicht die einzelnen Eingabedaten wieder, sondern ein davon abgeleitetes Modell. Darin unterscheidet sich dieser Ansatz von der Karteikarten-IT herkömmlicher Datenbanken, die alle Eingaben wörtlich abspeichern und als Ausgabefunktion im wesentlichen das Herausfiltern der jeweils gesuchten Daten anbieten. Welche Daten ein Klassifikator nutzt und was er über uns weiß, sind zwei Paar Schuhe. Wir können einen Klassifikator nicht danach befragen, welche Eingabedaten er zu einer Person erhalten hat.

Das führt zu interessanten Folgerungen für den Privatsphärenschutz:

1. Verhaltensbeobachtung und -auswertung bedeutet nicht zwingend eine Verletzung der Privatsphäre. Beispiele dafür sind die Korrekturfunktionen in der Google-Suche und in Google Translate, die aus dem Benutzerverhalten lernen. Google beobachtet bestimmte Aspekte des Nutzerverhaltens über eine Folge von Vorgängen hinweg, interessiert sich am Ende aber vor allem für statistische Aussagen.
2. Ein Kontinuum an Personenbezug. Ein Klassifikator kann personenbezogene Entscheidungen treffen, er muss es aber nicht. Er wird Entscheidungen nach den Kriterien treffen, die in der Vergangenheit erfolgreich waren. Da die Konfiguration des Klassifikators variabel ist, kann sich der personenbezogene Entscheidungsanteil laufend ändern. Nützlich ist ein Klassifikator vor allem dort, wo es verallgemeinerbare Zusammenhänge in den Daten gibt – Verallgemeinerung ist das Gegenteil von persönlichen Profilen. Die vielen Einzeldaten braucht man , weil man die Verallgemeinerungsregeln vorher nicht kennt.
3. Einzelne Merkmale – IP-Adresse, Cookies, Geburtsdatum und so weiter – sind wenig relevant. Klassifikatoren arbeiten in vieldimensionalen Merkmalsräumen und bei guter Konstruktion tragen alle Dimensionen zur Klassifikationsleistung bei. Lässt man eine Merkmalsdimension weg, bleiben (n-1) übrig, für ein ziemlich großes n. Die Klassifikationsleistung verringert sich dadurch nur wenig, zumal in den verwendeten Daten Korrelationen zwischen mehreren Dimensionen auftreten können. Das heißt auch: ein Klassifikator kann relativ robust gegen gelöschte Cookies sein.
4. Der Grad der Personalisierung hängt auch vom Nutzerfeedback ab. Wie stark die Entscheidungen eines Klassifikators personalisiert sind, hängt davon ab, welches Feedback der Nutzer zu diesen Entscheidungen gibt. Wer viel Werbung anklickt, personalisiert seine Werbeeinblendungen damit, falls dieses Feedback mit Personen- oder Pseudonymbezug zum Lernen verwendet wird.
5. Klassifikator-Modelle sind inhärent zweckgebunden. Ein Klassifikator wird für eine bestimmte Aufgabe entworfen und trainiert. Zwar kann man die dabei entstehende Konfiguration als Modell der Problemlösung untersuchen und dabei Interessantes herausfinden. Jedoch lässt sich ein Klassifikator nicht einfach für etwas anderes verwenden. Einen universellen Klassifikator, der »alles« kann, gibt es nicht; jedes Optimierungsverfahren benötigt Annahmen über das Problem. Man kann freilich einen Klassifikator mit Personen als Ausgabeklassen bauen, wenn man Feedback über die Richtigkeit der Zuordnung bekommt.
6. Löschen geht nicht – aber Personenbezüge können verblassen. Sind Daten über einen Nutzer in die Konfiguration eines Klassifikators eingeflossen und dort mit anderen Daten verschmolzen, lässt sich dieser Vorgang nicht sinnvoll rückgängig machen. Liefert ein Nutzer keine neuen Daten nach, werden seine Einflüsse jedoch nach und nach von anderen überlagert. Ein fortwährend trainierter Klassifikator in einer veränderlichenUmgebung verliert im Laufe der Zeit seine Fähigkeit, auf diesen Nutzer personalisierte Entscheidungen zu treffen – er vergisst, ohne auf den Innenminister und dessen Ideenwettbewerb zu warten.

Solche Phänomene sind in unseren überlieferten Datenschutz-Konzepten nicht vorgesehen. Wir können auf verschiedene Arten damit umgehen. Wir können auf die Einhaltung formaler Vorschriften aus einer anderen Zeit pochen und Bürokratie als Selbstzweck vollziehen. Dann ist Google verboten, bis jeder Nutzer eine Generalvollmacht erteilt hat und ab und zu gibt es einen Shitstorm. Oder wir erinnern uns daran, dass Datenschutz als Mittel zum Zweck unserer Selbstbestimmung über unsere Privatsphäre dienen soll. Dann müssen wir bei diesem Ziel ansetzen und uns neu überlegen, wie die Technik es bedroht und wie vielleicht auch nicht.

Datenschutzreformen

Juristen diskutieren seit geraumer Zeit über Datenschutzreformen. Thomas Stadler berichtete zum Beispiel in seinem Blog über ein Thesenpapier zur Datenschutzreform (hier gibt’s einen Aufsatz dazu). In der Rechtsanwendung gibt es noch einmal ganz eigene Probleme. Aus Amerikanisch-Kanadischer Sicht beschäftigt sich Tara Whalen mit der Frage, wie man den Personenbezug sinnvoll definieren sollte und fasst im Artikel This Time, It’s Personal. Recent Discussions on Concepts of Personal Information (paywalled) den Stand der Debatte zusammen.

Als Informatiker kann ich dort nicht qualifiziert mitreden. Mir stellen sich andere, aber verwandte Fragen: Wie sieht wirksamer Privatsphärenschutz in heutigen und künftigen soziotechnischen Systemen aus? Von welchen Bedrohungsmodellen muss er ausgehen und wie kann er die Evolution der Technik zulassen und begleiten?

Cookies, IP-Adressen und die Datenübermittlung in andere Länder nützen uns als Diskussionsrahmen wenig. Die Radikallösung, Teile des Netzes ungenutzt zu lassen, ist wegen seines großen Nutzens keine realistische Option. Interessanter ist, wer uns anhand welcher Daten wehtun kann, wie wahrscheinlich das ist, und welche wirksamen Maßnahmen es dagegen gibt.

Die Abstraktion des personenbezogenen Datums und der Entscheidung des Betroffenen, wer dieses Datum haben darf, stammt aus einer anderen Ära der Informationstechnik. Unabhängig davon, in welchem Maße Techniken wie die von Google eingesetzten unsere Privatsphäre bedrohen oder nicht, können wir mit der Freigabe einzelner Datensätze und Datenfelder keinen sinnvollen Einfluss auf eventuelle Risiken nehmen. Vielleicht müssen wir uns gänzlich von der Idee lösen, dass es auf Daten ankäme, und uns damit beschäftigen, was daraus gemacht wird.

Die individuellen und gesellschaftlichen Privatsphären-Interessen müssen wir außerdem abwägen gegen das berechtigte Interesse einer Firma wie Google, technische Details für sich zu behalten. Bessere Klassifikatoren zu bauen als der Rest der Welt gehört zu Googles Kerngeschäft. Andererseits sollte die Technik so transparent sein, dass sie informierte Entscheidungen unterstützt, wobei es auf die Entscheidungen ank0mmt und nicht auf deren formalisierte Niederlegung im Vertragsstil. Mit diesem Spannungsfeld sowie mit realistischen Bedrohungsmodellen muss sich der organisierte Datenschutz beschäftigen, wenn er in Zukunft relevant bleiben möchte. Laut über Daten-Schmu zu schimpfen und dann weiter alte Modelle auf neue Technik anzuwenden, bringt uns keinen Schritt weiter.

Schlusswort

Google ist im wahrsten Sinn des Wortes ein Elektronengehirn, wie es die Science Fiction einst beschrieb. Wer um jeden Preis Angst haben möchte, stellt sich unter Google am besten so etwas wie HAL 9000 vor, hochskaliert auf einen Planeten anstelle eines Raumschiffs. Google verhielte sich ähnlich, zöge man ihm nach und nach die Speichermodule raus – Google würde nach und nach verblöden.

The famous red eye of HAL 9000 by Cryteria, CC-BY 3.0 unported

Unter dieser Prämisse lautet die Grundsatzfrage: Welche Denkverbote müssen wir so einem Computer auferlegen und welche nicht? Wie formulieren wir solche Denkverbote, wenn wir den größtmöglichen Nutzen behalten wollen? Oder brauchen wir in Wirklichkeit gar keine Denkverbote für Elektronengehirne, sondern angemessene Denkweisen und Begriffe für uns selbst als Individuen und als Gesellschaft? Fürs erste tut es auch eine kleinere Frage: Wie machen wir eine Datenverarbeitung transparent für Nutzer, die komplizierter ist als die gute alte Datenbank? Ein Stück Verständnis hat Google mit seiner aufgeräumten Datenschutzerklärung schon mal effektiv vermittelt, nämlich dass seine einzelnen Dienste nur Sichten auf ein System  sind. Das haben jetzt alle verstanden.

Zum Download. Eine Ergänzung zu Teil 6

Eben bin ich noch über diese schöne Illustration zu Teil 6 von Datenkrake Google gestolpert:

Die obere Anzeige betitelt ihren Link einfach mit Zum Download. Genau danach habe ich gesucht, nach einem Download, diese Anzeige wird an dieser Stelle sicher hervorragend funktionieren, gerade weil nicht aus ihr hervorgeht, was sich eigentlich dahinter verbirgt.  Für so eine Optimierung braucht man gewissenloses, nüchtern-rationales Personal, zum Beispiel einen Computer, dessen einzige Mission in der Klickratenoptimierung besteht.

Über mich weiß Google offensichtlich, dass ich Deutsch spreche. Das erzählt mein Browser allerdings jeder Website und ich mache auch sonst kein Geheimnis daraus.

Datenkrake Google (6/7): Und jetzt Werbung

[Seriennavi: Teil 1 – Teil 2 – Teil 3 – Teil 4 – Teil 5 – Teil 6 – Teil 7]

Über die bisherigen Folgen dieser Serie haben wir ein Modell von Google als lernender Maschine etabliert. Vermutlich ist dieses Modell nicht die reine Lehre hinter Googles Werbediensten, da Google vor einigen Jahren Doubleclick und damit fremde Technologie gekauft hat. Gleichwohl lohnt es sich, anhand unseres Modells über optimierte (volkstümlich: personalisierte) Werbung nachzudenken. Weit hergeholt wird es nicht sein; dass Google Techniken wie die skizzierten zur Optimierung von Suchergebnissen und Empfehlungen einsetzt, können wir mit unserem Vorwissen aus den Changelogs herauslesen. Technisch macht es keinen großen Unterschied, ob wir das beste Suchergebnis, die beste Empfehlung zu irgend etwas oder die beste Werbung für einen Anzeigekontext suchen. Aber der Reihe nach.

Personalisierung ist Optimierung

Werbung ist ein Optimierungsproblem. Ziel des Werbers ist, genau dort aufzutreten, wo seine Werbung wirkt, und auch nur dafür zu bezahlen. Klassisch, ob offline oder online, tut man dies, indem man Zielgruppen klassifiziert und seine Werbung bzw. sein Produkt einerseits und die verfügbaren Medien andererseits in dieses Modell abbildet. Erreicht ein Medium möglichst genau die anzusprechende Zielgruppe, schaltet man seine Werbung dort. So kommt die Telefonsexwerbung ins Nachtprogramm von Privatsendern, die Werbung für Pay-TV-Sportsender in die Sportzeitschrift und das ThinkGeek-Banner auf Slashdot. Erscheinen die Streuverluste zu hoch, versucht man die Zielgruppendefinition zu verfeinern. Dieses Vorgehen entspricht dem regelgestützten Ansatz der klassischen KI.

Gemäß der Google-Philosphie würde man hingegen aus allen verfügbaren Daten über die Werbung, den Anzeigekontext und, soweit verfügbar, den Nutzer vor dem Bildschirm alle denkbaren Merkmale extrahieren. In diesem Datenraum würde man einen lernenden Klassifikator auf die Frage ansetzen, welche Cluster die Klickrate als Hilfsmetrik oder besser noch die werbebezogenen Umsätze des Kunden maximieren. Man würde also das tun, was ich in Folge 4 beschrieben habe, nur mit einem Pool von Anzeigen anstelle von Tanksäulen und Abrufereignissen anstelle von Autos mit Fahrern.  Seinen Kunden würde man ein Interface zur Verfügung stellen, mit dem sie neue Zapfsäulen aufstellen und bezahlen können. Selbst müsste man nur noch seine Einnahmen kassieren und verbuchen und alte Zapfsäulen wegräumen. Alles andere liefe komplett automatisch ab.

Die tatsächlichen Regeln, nach denen die Einblendung erfolgt, wären wieder Sache des Klassifikators und von Fall zu Fall verschieden. Zur Entscheidung könnte der Inhalt der Anzeige ebenso beitragen wie der Kontext der Einblendung oder Informationen über den Nutzer. Vielleicht sind Anzeigen mit bestimmten Merkmalen besonders erfolgreich bei europäischen Nutzern des Browsers Firefox ohne Flash Player zwischen 19:23 Uhr und 20:42 Uhr an Samstagen, sofern diese Nutzer nicht in ihren Google-Account eingeloggt sind, die Werbeeinblendung auf einer bestimmten Website erfolgt und der Nutzer diese Anzeige zuvor höchstens zweimal gesehen hat. Eine andere Anzeige könnte bei Nutzern aus einem bestimmten Universitätsnetz gut ankommen, unabhängig vom verwendeten Browser und der Uhrzeit, eine weitere in einem bestimmten Anzeiogekontext gut funktionieren. Dem lernenden Klassifikator ist egal, ob solche Regeln für uns einen Sinn ergeben. Er optimiert stur auf die Daten, die man ihm zeigt.

Textanzeigen enthalten dabei genau jene Art von Merkmalen, mit denen Google ohnehin bereits gut umgehen kann. Für Werbebanner wird man etwas länger nachdenken müssen, welche Merkmale nützlich sind. Wer weiß, vielleicht hat ja die Blinkfrequenz einen Einfluss auf die Klickrate, oder Metadaten aus der klassichen Zielgruppendefinition erweisen sich als nützlich. Grundsätzlich funktioniert das Prinzip auch dann, wenn wir die verschiedenen Anzeigen lediglich unterscheiden können und sonst keine Einzelheiten kennen. Ein Klassifikator hätte dann kein Ähnlichkeitsmaß für Anzeigen zur Verfügung, könnte aber immer noch lernen, unter welchen Begleitumständen Anzeige Nummer 703744 am besten funktioniert.

Was führt zum Klick?

Alltagsbeobachtungen sind mit diesem Erklärungsmodell kompatibel. Nehmen wir zum Beispiel tortoisesvn.net. TortoiseSVN ist ein SVN-Client für den Windows-Explorer; die Website besuchen vermutlich viele Leute, die diesen Client erstmals oder als Update herunterladen möchten. Google blendet dazu Werbung für andere SVN-Clients ein. Was’n Quatsch?! Gar kein Quatsch, sondern folgerichtig.

Wer sich die Seite durch seine Usability-Brille anschaut, wird schnell bemerken, dass ihr Design einige Schwächen hat. Diese Schwächen führen dazu, dass der Nutzer von der Downloadfunktion ab- und auf die Werbung hingelenkt wird. Die echten Download-Buttons sind die grünen Kästen unten. Die wirken in ihrem Format und in ihrer knalligen, vom Rest der Seite abweichenden Farbe optisch wie ein typisches Werbebanner. Das Web hat uns über Jahre darauf trainiert, typische Werbebanner mental auszublenden und zu ignorieren. Hinzu kommt, dass über den Google-AdSense-Anzeigen der Titel Downloads steht und dann außer den Anzeigen kein Inhalt folgt, und die dass Anzeigen farblich der Seitengestaltung angepasst sind. Ist unter den Anzeigen nun noch eine, die einen SVN-Client anbietet, liegt ein versehentlicher Klick auf die Anzeige nahe – alles wirkt auf den Nutzer so, als könne er damit sein Ziel erreichen.

Nach einigen zufälligen Einblendungen, die zu Klicks führen, lernt das auch ein Klassifikator, der Klickraten optimiert. Stehen ihm die nötigen Parameter zur Verfügung, wird er fortan in diesem Kontext bevorzugt Werbung für SVN-Clients anzeigen, falls er welche im Pool hat. Über den einzelnen Nutzer muss er dazu nichts wissen, er lernt nur etwas über eine spezifische Auswirkung allgemeiner Psychologie in einem spezifischen Kontext. Auf ähnliche Weise dürfte SEO-Werbung in einen SEO-Artikel gelangen:

Persönliche Informationen über den Betrachter sind für diese Einblendungen nicht erforderlich – sie können jedoch jederzeit in die Entscheidung einfließen, wenn sie verfügbar und relevant sind. Ob und wo das der Fall ist, erfährt Google nach unserem Modell aber nicht aus den Daten, die wir uns als unser Nutzerprofil vorstellen, sondern aus unseren Werbeklicks. Wer nie Werbung anklickt, schafft keine Möglichkeit zur Personalisierung; Google muss sich dann auf eine optimierte und automatisierte Anwendung der herkömmlichen Targeting-Praktiken beschränken. Zwar werden die Eingabedaten in den Klassifikator genauer, je mehr Google vorher über mich weiß. Google kann aber nicht herausfinden, ob mich diese Details im Hinblick auf das Klassifikationsziel von anderen Teilen der Population unterscheiden. Mit jedem Nichtklick übermittle ich dem Klassifikator nur die Information: »Sorry, das war nicht die richtige Lösung.« Ich bekomme meine Werbung dann gemäß der Populationsstatistik so wie diejenigen die in denselben Clustern landen.

So füttert man Datenkraken

Klicke ich dagegen regelmäßig Werbung an, liefere ich nach und nach ein Modell dafür, wie der Werbeerfolg von meiner Person abhängt. Auch wenn es anders wirkt, erfährt Google dabei immer noch wenig über mich. Google kann dann vorhersagen, wie meine Anwesenheit im Verglich zu anderen Nutzern oder zur Populationsstatistik das Relevanzmodell für Werbeeinblendungen in einem bestimmten Kontext modifiziert. Wenn Google sich anstrengt, gibt der Klassifikator vielleicht auch noch eine – für Googles Zwecke bedeutungslose und in der Begriffswelt des Klassifikators ausgedrückte – Erklärung seiner Entscheidung her. Um systematisch solche Erklärungen über mich zu erheben, müsste Google aber schon wieder zusätzliche Daten neben der Konfiguration des Klassifikators erfassen und speichern.

Zieloptimierte Werbung a la Google funktioniert also wahrscheinlich nicht so, wie es die naiven Modelle aus Folge 2 suggerieren. Wenn mein Verständnis richtig ist, gilt es gleichermaßen auch für andere personalisierte Funktionen und nicht nur für die Werbung. Im letzten Teil der Serie betrachten wir die Auswirkungen solcher Technologien auf den Datenschutz.

Datenkrake Google (5/7): Daten besiegen die Logik

[Seriennavi: Teil 1 – Teil 2 – Teil 3 – Teil 4 – Teil 5 – Teil 6 – Teil 7]

Die vorige Folge dieser Artikelserie behandelte die Frage, wie Maschinen lernen können. Diese Technik ist für Google ein zentrales und dienstübergreifendes Paradigma (freies PDF). Im Vorbeigehen bekommen wir damit eine Erklärung, warum die Metapher von Google+ als Facebook-Konkurrenz  nicht funktioniert (vgl. Teil 1). Facebook (der Dienst) ist für Facebook (die Firma) der Kern des Geschäftsmodells. Für Google dagegen ist maschinelles Lernen aus allen Daten dieser Welt der Kern des Geschäftsmodells – und Google+ vor allem eine weitere Quelle interessanter Daten. Wer interagiert wie mit wem? Welche Inhalte verbreiten sich in welchen Kreisen? Wie reagieren Nutzer auf personalisierte Suchergebnisse? Welche Transformationen durchläuft ein Gerücht? Welche Merkmale unterscheiden ein Mem von einem Shitstorm? Alleine die Liste der Fragen, zu denen man mit Googles Philosophie der Datenverarbeitung in Google+ nach Antworten suchen könnte, scheint endlos. Mit Facebook hat Google+ deshalb nur einige oberflächliche Funktionen gemeinsam, es dient aber – mutmaßlich – einem ganz anderen Zweck.

Künstliche Intelligenz, diesmal richtig

Doch funktioniert das überhaupt? Ist die KI nicht tot? Das ist sie, aber Google macht gerade keine klassische KI. Anfangs versuchte man in der KI, alle wesentlichen Aspekte eines Problems in nachvollziehbare Regeln zu fassen. Man versuchte also, Gehirne sich selbst beschreiben zu lassen. Das war ungefähr so schlau wie der Versuch, eine Turing-Maschine Aussagen über Turing-Maschinen machen zu lassen, aber irgendwo musste man ja anfangen und das Internet als reichhaltige Datenquelle gab es auch noch nicht.

Letztlich geht es auch im Google-Ansatz um Regeln, aber formuliert werden sie nun unter Verwendung aller verfügbaren Daten und ohne die Notwendigkeit, dass ein Mensch diese Regeln nachvollziehen kann. Dass dabei bessere Regeln herauskommen können als aus menschlichen Gehirnen, gerade wenn das Problem kompliziert ist, zeigt ein Beispiel aus der IT-Sicherheit.

Bozorgi et al. beschäftigen sich in ihrem Paper Beyond Heuristics: Learning to Classify Vulnerabilities and Predict Exploits (freies PDF) mit der Vorhersage der Exploit-Wahrscheinlichkeit aus Verweundbarkeitsmeldungen. Gefundene Verwundbarkeiten in Software dokumentiert die Security-Community in Datenbanken, zum Beispiel der CVE oder der OSVDB. Ein Bewertungsschema für Verwundbarkeiten ist der CVSS-Score, ein Wert zwischen 0 und 10, der die Schwere des Problems angibt. 10 ist ganz schlimm, 0 völlig harmlos. Dieser Score wird auf eine nachvollziehbare und sinnvoll erscheinende Weise aus einer Reihe von Parametern gebildet. Für eine gegebene Verwundbarkeit in einer Software oder in einem System kann man sich den Score aus einigen Einschätzungen zusammenklicken und das Ergebnis stimmt meistens mit der Intuition des Fachmanns überein.

Computer schlägt Experten

Man sollte meinen, dass dieser Wert einen Anhaltspunkt liefert, ob ein Security-Bug nach seiner Entdeckung auch für Angriffe ausgenutzt wird – die mit dem Score 10 oft, die mit dem Score 0 nie. Bozorgi et al. zeigen jedoch, dass der CVSS-Score darüber wenig voraussagt, und stellen dem ihm einen angelernte Klassifikatoren gegenüber. Diese Klassifikatoren benutzt die gesamte Verwundbarkeitsdokumentation und liefert weit bessere Vorhersagen darüber, ob und wie schnell eine Verwundbarkeit ausgenutzt wird oder nicht.

Der verwendete Merkmalsraum hat 93.578 Dimensionen, die meisten abgeleitet aus Textfeldern wie den Namen der betroffenen Produkte oder den Freitextbeschreibungen des jeweiligen Sicherheitsproblems. Viele Dimensionen sind binär und geben einfach an, ob bestimmte Worte, zum Beispiel Buffer, in bestimmten Teilen eines Berichts vorkommen. Klassifikator lernt Cluster für ausgenutzte sowie für nicht ausgenutzte Verwundbarkeiten. Nebenbei liefert dieser Klassifikator noch einen Score, der sich daraus ergibt, wie weit eine Verwundbarkeitsmeldung nach der Merkmalsextraktion von der Clustergrenze entfernt liegt. Was tief im Cluster liegt, ist den anderen Punkten dort sehr ähnlich; was nahe der Grenze liegt, könnte nach kleinen Änderungen auch auf der anderen Seite, im anderen Cluster landen.

Das wirkt alles ein wenig wie Zauberei. Im Grunde genommen tut Google aber nichts anderes als unser Gehirn, nur ohne den Filter unserer Sinnesorgane, ohne Abgleich mit Lehrbuchwissen und mit viel mehr Daten und Aspekten dieser Daten als uns normalerweise bewusst werden. Google lernt Sprachen – oder Expertenintuition – wie wir, nur schneller und ohne den Umweg über Übungen und explizite Regeln direkt aus Beispielen und Feedback. Und wir sind die Lehrer.

Im nächsten Artikel werden wir uns damit beschäftigen, wie man mit lernenden Maschinen Werbeeinblendungen optimiert.