A genuine taxi has … a taxi lamp on its roof

Warsaw tourist information hands out these leaflets to tourists:

Nutzlose Fragen

Sicherheitswarnungen sind dann nützlich, wenn sie den Unterschied zwischen Problem und Nichtproblem möglichst genau modellieren und im Fall eines Problems eine hilfreiche Handlung nahelegen. Klingt einfach, ist es aber nicht. Wie man’s falsch macht, demonstriert Adobe auf dieser Seite, die Hilfe zu Sicherheitswarnungen des Adobe Readers geben soll. Das Problem liegt in diesem Fall nicht bei Adobe, sondern im Stand der Technik. Adobe-Bashing beabsichtige ich deshalb nicht, die liefern mir nur den Aufhänger.

Angenommen ich möchte mein Fahrrad vor Dieben schützen. Diese dynamischen Warnungen wären nützlich:

• »Du hast Dein Fahrrad nicht angeschlossen und die Gegend hier ist gefährlich.«
• »Du hast den Rahmen Deines Rades an einen Poller gekettet. Deine Maßnahme ist wirkungslos.«
• »Unten im Hof macht sich gerade einer an Deinem Fahrrad zu schaffen. Dir bleiben 20 Sekunden; dein Gegner ist unbewaffnet, aber kräftig.«

Weniger nützlich sind solche Hinweise:

• »Überlegen Sie, ob Sie diesen Abstellort für sicher halten.«
• »Der da drüben sieht wie ein Fahrraddieb aus, sei vorsichtig,« bei jedem zweiten oder dritten Abstellen des Rades.
• »Fahrrad wirklich unbeobachtet lassen? [Ja] [Nein]«

Unnütz sind sie, weil sie weder spezifisch auf relevante Risikofaktoren zielen noch eine wirksame Handlung zur Risikoreduktion nahelegen.

Unnütze Warnungen sind das Ergebnis, wenn Entwickler an ihr Produkt schnell noch ein wenig Sicherheit anflanschen. Dann nehmen sie Events und Informationen, die sie in ihrer Software gerade vorfinden, und machen daraus Fragen an die Benutzer. Adobes Erläuterungen illustieren dies:

»This warning does not necessarily mean that the page or website is harmful. (…) They cannot tell you if the page or website actually contains unsafe content.« – Der Reader warnt nicht für gefährlichen Aktionen oder Inhalten, sondern beim Aufruf jeder Website. Websites aufrufen ist Alltag im Internet und führt fast nie in eine Falle. Die Warnung ist fast immer falsch.

»What is the right action to take? 1) If you know and trust the sender … 2) If you don’t know or trust the sender …« –Im Internet weiß ich fast nie, wer der Absender eines Inhalts ist. Und fast immer vertraue ich Unbekanntenz erst einmal, dass sie mich nicht erfolgreich angreifen, denn das ist die Erfahrung, die ich täglich mache. Die Vertrauensfrage ist zudem ohne Interaktionshistorie bedeutungslos, korrekt müste sie lauten: »Vertrauen sie ihrem Gegenüber noch, oder haben sie schon einmal schlechte Erfahrungen gemacht?«

Mit solchen Dialogen kann man als Hersteller das Blame Game spielen und den Nutzern eines Produkts einreden, sie müssten nur besser aufpassen. Das ist aber auch alles, mehr Sicherheit kommt dabei nicht heraus.

Jon Skeet and Tony the Pony

Why software development is hard and the results turn out buggy:

(vimeo)

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.

Social Networks sind Multiplayer-Games

Isotopp schreibt über Gamification und wie sie an Nerds scheitert. Spiele sind so ein Thema, bei dem sich jeder kompetent fühlt, der mal eins gespielt hat. Spiele sind aber nicht einfach zu entwerfen, wie jeder weiß, der mal eins in die Ecke geworfen hat, das zu langweilig oder zu schwer war. Gamification in Anwendungen ist noch komplizierter. Warum Gamification-Ansätze oft hirntot enden, lässt sich erklären. Wer Anwendungen und Spiele verheiratet, muss im Entwurf einen Zielkonflikt zwischen Usability und Verkomplizierung lösen, damit es in der Benutzung nicht zu störenden Konflikten zwischen Anwendungs- und Spielzielen kommt. Beispiele für erfolgreiche Gamifications finden wir in Social Network Sites wie Google und Facebook.

Vor zehn Jahren habe ich mich mal kurz mit diesem Themen beschäftigt und die damals spärliche Literatur für einen Workshop aufbereitet. Damals erhoffte man sich Usability-Wunder davon, dass man Ideen aus Spielen in Anwendungen übernahm. Das Ergebnis naiver Versuche waren Studenten, die sich in ihren Studienarbeiten mit Quake vergnügten – als Teil eines Projekts über digitale Bibliotheken. Manche Leute müssen offenbar erst forschen um zu verstehen, dass eine 3D-Welt aus Bücherregalen als digitaler Bibliothekskatalog etwa so schlau ist wie eine Bildschirmtastatur mit anklickbaren Tasten sowie Papier- und TippEx-Simulation als Texteditor. Dennis Chao hat solche Arbeiten mit seinem Paper Doom as an Interface for Process Management (freies PDF) trefflich ad absurdum geführt. Jetzt also eine neue Runde, Gamification soll diesmal Nutzer anziehen und bei der Stange halten, also eine Persuasive Technology schaffen. Ganz in der Tradition dieses Blogs überlassen wir jedem selbst, ob er das evil finden möchte, und konzentrieren uns auf die Frage, ob und wo es überhaupt funktioniert.

Isotopp beschreibt Beispiele von simpel gestrickten Spielen, die sich schnell beenden lassen, wenn man Ziele außerhalb der Spielregeln verfolgt und die Spielregeln dazu als Werkzeug einsetzt. Er betrachtet diese Spiele als abstrakten Wettbewerbe und abstrakte Herausforderungen und liegt damit richtig. Er führt die Spielkonzepte ad absurdum, indem er durch kreative Regelinterpretation einen schnellen Weg zu einem Endzustand des Spiels geht und damit Ziele außerhalb des Spiels verfolgt. Stützt sich das Spiel auf ein einfaches Regelsystem, ist dieses Vorgehen nur einmal interessant, der Weg danach beliebig wiederholbar, die Herausforderung verloren.

Bessere Spiele stützen sich auf besser entworfene, nachhaltige Herausforderungen. Ego-Shooter im Death-Match-Modus sind ein Beispiel dafür. Sie bieten nachhaltigen Spielspaß, sofern die Maps was taugen und man jede Map nur so lange benutzt, bis die ersten Spieler für jeden Spawn-Point eine Optimierungsstrategie gefunden haben und das Spiel dominieren. Die Fähigkeiten der Mitspieler bestimmen dort das Niveau der Herausforderung, das Spiel selbst bietet eine Plattform dafür.

Andererseits darf das Spiel nicht zu schwer werden, weil dann die Chance auf Gewinne oder Belohnungen zu gering ist und die Motivation verloren geht. Deshalb machen Cheater ebenso wie große Niveauunterschiede der Spieler so ein Spiel kaputt, sie allokieren die Mehrzahl der Belohnungen auf eine Teilmenge der Spieler. Man könnte darauf reagieren, indem man das Belohnungssystem von den Skills der Mitspieler entkoppelt, aber das hätte wieder Auswirkungen auf den Schwierigkeitsgrad insgesamt.

Ein nachhaltig oder zumindest über eine gewisse Zeit funktionierendes Spiel ist also ein kompliziertes System, das sowohl die Motivation des Spielers in einem Zielkorridor halten muss. Ein Spiel darf weder zu leicht noch zu schwer sein. Ein Spiel muss den Spieler regelmäßig belohnen, aber nicht zu oft und nicht beliebig. Schlichteren Gemütern genügt dafür das Gold Farming als Aufgabe, das aber auch nur deshalb, weil sie sich darauf einlassen und sich keine Abkürzung kaufen.

Diese Balance kann man auch in Einweg-Spielen richtig hinbekommen, so dass sie über einen begrenzten, aber längeren Zeitraum funktionieren. Adventures sind ein Beispiel dafür. Hat man sie durchgespielt, sind sie erledigt, aber der Weg dorthin ist so mit Constraints und Aufgaben belegt, dass der Spieler weder frustriert aufgibt noch ohne Schwierigkeiten durchmarschiert.

In die Hose geht Gamification oft, wenn man sie naiv in einer Anwendung versucht, die irgendeinen anderen Zweck als das Spielen hat. In einer Anwendung haben wir andere Ziele, sie sollen irgendwas für ihren Benutzer erledigen und das möglichst einfach. Usability ist nicht nur ein Problem der Benutzeroberfläche, sondern des gesamten Anwendungsentwurfs. Gleichzeitig verlangt Gamification nach Herausforderungen, nach künstlichen Schwierigkeiten. Dieser Zielkonflikt ist selten anders zu lösen als durch eine klare Entscheidung. Antweder bauen wir eine Anwendung oder ein Spiel.

Von dieser Regel gibt es Ausnahmen. Erfolgreiche Gamifizierungen orientieren sich an Egoshootern im Mehrspielermodus. Nicht in den Oberflächenphänomenen allerdings, wie es Second Life mit seiner 3D-Welt relativ erfolglos versucht hat, sondern im Spielkonzept. Erfolgreiche Gamifizierungen lassen Menschen miteinander spielen und stellen mehr oder minder nützliche Funktionen bereit, die man sowohl zum Spielen als auch zum Arbeiten nutzen kann.

Erfolgreiche Gamifications sind beispielsweise Google+ und Facebook, die Ego-Shooter der Gamification mit dem Belohnungssystem eines Swingerclubs. Social Networks bieten Aufgaben und  Herausforderungen (»viele Follower sammeln«, »interessant sein«, »Trollen«, »Meme erfinden«, »in Fotos erkannt werden«) und Belohnungen (Kommentare, Likes, Reshares, neue Follower, Fototags). Parallel dazu stellen sie nützliche Funktionen bereit (interessanten Content und Contentempfehlungen, unkomplizierte Kommunikation, Selbstdarstellung und PR). Welche Spielziele ich mir stecke, überlassen sie mir. Vor allem aber setzen sie mir keine künstlichen Hürden, wie es die Rätsel in einem Adventure tun würden, sondern sie geben mir motivierende Belohnungen als inhärenten Teil meiner Interaktion mit den anderen Spielern. Wir können Facebook und Google+ auch einfach als Anwendungen nutzen, ohne über in diesem Kontext blödsinnige Spielelemente zu stolpern.

Später noch einmal nerven? (Ja/Ja):

Google’s Progress Bar

Cookies, Clients und die Cloud

Politiker und Bürokraten wollen die Verwendung von Cookies gesetzlich regulieren, erst die EU (mit unklarem Regelungsgehalt und schleppender Umsetzung), ein paar Jahre später nun auch die SPD. Warum ist das blöd? Ich hole mal etwas weiter aus:

Persönliche Computer, PCs, waren in den 70er und 80er Jahren des letzten Jahrhunderts eine große Sache. Jedem seinen eigenen Computer, klein genug für den Schreibtisch und mit verschiedenen Anwendungsprogrammen für vielerlei Zwecke einsetzbar, das hatte es vorher höchstens als Vision gegeben. Aus dieser Frühzeit der Jedermann-IT stammen viele Vorstellungen, die wir noch heute hegen, darunter die Wurzeln unseres Datenschutzes.

Auf den ersten Blick hat sich seitdem wenig geändert. Aus dem PC auf Arbeit wurde ein Gerätezoo für alle Lebenslagen aus PCs, Note- und Netbooks, Smartphones, Tablets, Internetradios, Spiekonsolen und so weiter, technisch im Grunde genommen immer noch persönliche Computer, nur schöner und kleiner und schneller. Seit den 90er Jahren folgte dem Jedermann-Computer das Jedermann-Netz und im folgenden Jahrzehnt wurde dieses Netz mobil und sozial. Allen Schichten gemein ist, dass ihre Nutzer in Selbstbedienung nach Bedarf Dienste einkaufen, die nach dem Umfang der Nutzung bzw. den zugesicherten Ressourcen abgerechnet werden. Dienstanbieter stellen aus einem Pool an Ressourcen ohne Zeitverzug die jeweils nachgefragten Dienste bereit.

Die jetzige Dekade wird das Jahrzehnt des Cloud Computing. So wie der PC in den 70ern entstand und in den 80ern seinen Namen bekam und sich verbreitete, ist Cloud Computing keine ganz neue Sache, sondern längst erfunden, einsatzbereit und zum Teil auch schon etabliert. Neu ist nur, dass es jetzt einen Namen dafür gibt und alle ein Geschäft wittern, nachdem die Early Adopters vorgemacht haben, dass es funktioniert.

Cloud Computing bedeutet, dass ein Großteil der IT als Dienst ins Netz wandert. Das kann auf verschiedenen Abstraktionsebenen geschehen. Infrastructure as a Service (IaaS) bietet virtuelle Maschinen und Speicher, Platform as a Service (PaaS) liefert Anwendungsplattformen und Software as a Service (SaaS) schließlich macht Anwendungssoftware zu einem Dienst. Ein Beispiel für SaaS ist wordpress.com, wo dieses Blog gehostet wird. Die Schichten lassen sich stapeln, ein SaaS-Anbieter kann auf PaaS-Dienste zurückgreifen, die sich ihrerseits auf IaaS stützen. Die unteren Schichten IaaS und PaaS sind vor allem für Unternehmen interessant, während SaaS in Form von allerlei Webdiensten längst Teil unseres Alltags ist und die klassische Nutzung von Anwendungssoftware auf einem PC teils ersetzt, teils ergänzt.

Geht es um Sicherheit und Datenschutz im Cloud Computing, starren alle wie gebannt auf die Dienstseite. Daten wandern ins Netz, ob aus dem Rechenzentrum eines Unternehmens oder vom heimischen PC, und man weiß nicht genau, wo sie eigentlich gespeichert und verarbeitet werden. Das macht Angst und wirft technische, organisatorische und rechtliche Fragen auf. Hinzu kommt, dass der Übergang von Software in Kartons zu Diensten im Netz in Verbindung mit agilen Entwicklungsmethoden die Softwareentwicklungs- und -lebenszyklen verändert. Es gibt kein Google 3.0, das ich kaufen und dann ein paar Jahre verwenden könnte, sondern Änderungen am Dienst im Wochen-, Tage-, Stunden- und sogar Minutentakt. Continuous Deployment und DevOps nennen wir diese bewusste Vermischung von agiler Entwicklung und Produktivbetrieb.

Ein SaaS-Dienst ist nicht in sich abgeschlossen und unabhängig vom Rest des Netzes, sondern es handelt sich, für Nutzer manchmal schwer erkennbar, um eine Aggregation mehrerer Anwendungs- und Hilfsdienste, ergänzt um spezifische Funktionen des aggregierenden Hauptdienstes. Like-Buttons, Widgets, Videos, RSS-Feeds, Analytics, Werbebanner, Nutzerkommentare, Payment, Fonts und so weiter stützen sich auf Fremddienste, die, oft clientseitig, in den Hauptdienst integriert werden. Hilfsdienste haben meist ihren eigenen Betreiber und sie werden in viele verschiedene SaaS-Dienste eingebunden.

Weniger Aufmerksamkeit erhält beim Blick auf die Cloud die irdische Hälfte des Systems, die Client-Seite. Cloud-Dienste besitzen praktisch immer ein Webinterface, mindestens fürs Management, oft auch – und bei SaaS sowieso – für den eigentlichen Dienst. Der Nutzer bekommt damit eine universelle Client-Umgebung, bestehend aus einem Browser mit generischen Plugins (Flash, Java, Silverlight) und Unterstützungsanwendungen (PDF-Viewer, Office, iTunes) auf dem klassischen PC oder aus einem Browser und anwendungsspezifischen Apps auf mobilen Gadgets wie Smartphones oder Tablets.

Nach dieser langen Vorrede nun zurück zu den Cookies. Das Konzept des Cookies wird demnächst volljährig, es handelt sich ursprünglich um kleine Datenhäppchen, die eine Website einer Browserinstanz zur Speicherung übermittelt. Der Browser merkt sich diese Daten und schickt sie für einen festgelegten Zeitraum bei jeder weiteren Interaktion mit der Website dorthin zurück. Heute gibt es darüber hinausgehende Persistenzmechanismen auch für größere Datenmengen im Browser selbst sowie in verbreiteten Plugins, zum Beispiel im Flash Player.

Jeder Dienst in einer SaaS-Aggregation kann Cookies setzen und mit Hilfe dieser Cookies Daten über das Nutzerverhalten über alle Dienstnutzungen hinweg erfassen und sammeln. Die aggregierten Hilfsdienste erhalten dabei Daten aus verschiedenen SaaS-Anwendungskontexten verschiedener Anbieter und sind gleichzeitig für den Nutzer schwer zu identifizieren. Datenschützer stellen zu Recht die Frage, wie die Dienstnutzer unter diesen Bedingungen wirksam von ihrem Recht auf informationelle Selbstbestimmung Gebrauch machen können. Sie geben darauf aber die falschen Antworten.

De jure und traditionell wäre das Problem durch Kommunikation und Vereinbarungen des Nutzers mit jedem einzelnen involvierten Dienstanbieter zu lösen. Aggregierte Hilfsdienste als Auftragsdatenverarbeitung unter einer Vereinbarung zwischen dem Nutzer und dem Anbieter des Hauptdienstes zu subsumieren, wie es etwa für Analytics-Dienste diskutiert wurde,  vereinfacht die Sache wegen der Mehrfacheinbettung der Hilfsdienste in verschiedenste SaaS-Anwendungen nur scheinbar. Außerdem ändert sich permanent irgendwo irgendwas, so dass wir als Nutzer am Ende nur noch mit Zustimmen beschäftigt wären, wenn uns keine Generalvollmacht diese Mühe abnimmt. Erforderlich sind Lösungen, die die Architektur von SaaS-Mashups und der Client-Plattform als gegeben hinnehmen und darauf effektive Mechanismen für den technischen Datenschutz bereitstellen.

Cookies sind dabei nur ein wenig kritisches Randphänomen. Da sie clientseitig gespeichert werden, lässt sich ihre Speicherung und Übermittlung auch clientseitig effektiv steuern. Verbesserungsbedarf gibt es dabei vor allem in der Usability. Wünschenswert wäre zum Beispiel ein einheitliches User Interface für Einstellungen über alle Teilsysteme (Browser, Plugins, Apps, etc.) des Clientsystems hinweg anstelle getrennter, inkonsistenter Management-Schnittstellen für Cookies, Persistent DOM Storage und Flash-Cookies. Sinnvoll fände ich auch eine Möglichkeit, meine Datenschutzeinstellungen zwischen meinen fünf regelmäßig genutzten Clientsystemen zu synchronisieren statt fünfmal dasselbe konfigurieren zu müssen. Aber Clientsysteme und ihre Eigenschaften kommen in der Diskussion oft gar nicht vor. Soll ich ernsthaft mit dreiundzwanzig Diensten Vereinbarungen treffen, statt mir einmal eine Policy zusammenzuklicken, die meine eigene Technik für mich durchsetzt? P3P hatte zwar Schwächen und hat sich nicht durchgesetzt, aber damals hat man doch immerhin noch das Gesamtsystem angeschaut und eine Komponente an die richtige Stelle gesetzt, nämlich in den Client.

Mit formalisierten Rechtsritualen aus der Frühzeit der Alltags-IT ist das Problem nicht in den Griff zu bekommen. Gesucht sind effektive und benutzbare Mechanismen. Das ist die technische Sicht, die politische Dimension hat Benjamin Siggel vor einiger Zeit im Spackeria-Blog betrachtet.

Enttäuschte Vorfreude

Liebe Microsoft,

wenn ein Button unter einer Sicherheitswarnung mit Details beschriftet ist,

wäre es schön, wenn ein Klick darauf auch Details anzeigen würde. Und nicht die Hilfe öffnen, die mir SSL erklärt. Mich würde hier zum Beispiel interessieren, welche Inhalte denn gemeint sind, damit ich meine Entscheidung in Kenntnis der Umstände treffen kann. Stattdessen bleibt mir nichts anderes übrig, als immer auf JaNein zu klicken. Dabei brauche ich keine Hilfe, das schaffe ich auch so.

Eine gute Idee schlecht umgesetzt

Das Infor­mations­system der Gesund­heits­bericht­erstat­tung des Bundes ist eine Fundgrube für statistische Gesundheitsdaten, die Joseph Kuhn vom Gesundheits-Check zu Recht empfiehlt. Dort erfahren wir zum Beispiel, dass in der Bundesrepublik des Jahres 1989 aus jeder Milli0n Personenkilometer für Kfz-Insassen 1,31 verlorene Lebensjahre resultierten, aus dem Radfahren hingegen nur 0,02 und damit weniger als aus der Benutzung von Bus (0,11) und Bahn (0,05).

Diese Tabelle hätte ich gerne verlinkt, aber da fängt der Ärger an. Die Inhalte haben keine festen URLs, sondern die Site merkt sich die Navigation ihres Benutzers irgendwo in ihrem Session Management. Wer die Site in mehreren Tabs oder Fenstern öffnet, bekommt beim Reload einer Seite Schwierigkeiten, und verlinken lässt sich anscheinend nur eine Fehlermeldung, aber kein Inhalt.

Stärken zeigt die Site nur in der Erfüllung formaler Anforderungen, vulgo: Compliance. Auf der Startseite prangen CSS- und HTML-Validator-Buttons, und barrierenfrei gibt man sich auch. Das ist nur leider völlig bedeutungslos, solange die Grundfunktionen kaputt sind.

Vielleicht hätten sie die Site nicht in der DDR bei Robotron bauen lassen sollen. Genau danach sieht sie nämlich aus.

Identitätsmanagement für Dummies

Vergesst CardSpace, vergesst OpenID, vergesst den elektronischen Personalausweis. Den Identitäts- und Passwortmanager, auf den wir gewartet haben, gibt es in der Buchhandlung. Er läuft ohne Installation, out of the box, ja sogar ohne Strom, und hört auf den Namen Mein persönlicher Internet- und Passwort-Organizer:

Zuverlässig speichert er alle Benutzeraccounts alphabetisch sortiert für den schnellen Zugriff.

Bankdaten einschließlich des Passworts fürs Online-Banking können in einem eigenen Bereich abgelegt werden.

Eine Bedienungsanleitung erübrigt sich, dennoch ist eine Online-Hilfe mit Sicherheitshinweisen integriert.

Der Preis? Sagenhafte 7,99€. Ich habe mein Exemplar bei Hugendubel entdeckt und gekauft, bei Amazon gibt es ihn auch.

Road Casualties Visualized

ITO has various interesting visualizations of transport data, such as this one representing road casualties in the USA 2001-2009:

It’s interactive, you can zoom into it on their website.

(via de.rec.fahrrad)

Was könnte schiefgehen?

Eine brilliante Idee. Um sich vor Trojanischen Pferden auf ihrem PC zu schützen, gehen Sie auf eine Website, klicken Sie einen Button und installieren Sie damit ein Programm auf ihrem Rechnern. Danach sind Sie sicher:

»Dem im Netz kursierenden Duqu-Trojaner kann man durch einen Klick auf einer Microsoft-Seite den Zugang zum Windows-Rechner verwehren. Anwender müssen folgendes tun: Anwender sollten auf http://dpaq.de/VH2BY unter «Enable» den Button «Fix it» drücken und damit ein kleines Programm installieren, das den Zugriff auf die betroffene Windows-Schwachstelle in einer Programmbibliothek verhindert, erklärt das Bundesamt für Sicherheit in der Informationstechnik.«

(LVZ Online: Duqu-Trojaner einfach aussperren)

Was könnte dabei schiefgehen? Seht selbst, das sind die Buttons:

Toll, nicht wahr?

Homecomputer im Test

Damals wusste man noch nicht so recht, was man mit einem Computer zu Hause anstellen soll, und arbeitete sich an offensichtlichen, aber nicht unbedingt nützlichen Anwendungen ab:

Wer beispielsweise die Bestände seines gut sortierten Weinkellers elektronisch speichern möchte, müßte – sobald ihm der Sinn nach einem edlen Tropfen steht – folgende Prozedur hinter sich bringen: Heimcomputer einschalten, Programmkassette in den Recorder einlegen, Programm laden, Kassette wechseln und »Weinkellerdaten« in den Rechner einlesen, Befehl zur Auswahl eines trockenen ’82er Württembergers eingeben, eintragen in den Daten bestand, dass die Flasche nun bald geleert sein wird. Schreiben der gesamten Daten zurück auf die Kassette. Wegräumen der Kassetten und Ausschalten des Rechners. Während der elektronisch ausgerüstete Weinkenner nun den Weg in den Weinkeller antritt. um die richtige Flasche zu suchen, hebt der technisch rückständige Bacchant gerade das weite Glas und trinkt auf die gute alte Zeit, als man Wein noch mit Kennerblick auswählte.

Danke, Powerpoint

Wie schön, Powerpoint kann neuerdings auch durchstreichen, aber nicht in alten Dateien.

The American Way of Electronic Signatures

An electronic signature is not what security nerds think it is, or think it should be. This is a valid implementation of electronic signatures:

»Instead, you sign a piece of paper and hold it up to your iSight/Facetime camera while Preview snaps a photo. It’ll then detect the signature and allow you to add it to your document. To do this, just open the PDF document you want to sign, click “Annotate” in the toolbar if the annotations bar isn’t already showing, and then click the Signature drop-down menu.«

(Lifehacker via Timyeo’s Blog)

If people are happy with it, as they surely will as Apple made it, what exactly are the problems that we are trying to solve with all our cryptography?

In einem Wort

Dancing pigs

Usable Security: Participatory Design

»If your PERSHING II system needs improvement, let us know. Send us an EIR. You, the user, are the only one who can tell us what you don’t like about your equipment. Let us know why you don’t like the design. Put it on an SF 368 (Quality Deficiency Report). Mail it to Commander, U.S. Army Missile Command, AlTN: AMSMI-QA-QMD, Redstone Arsenal, AL 35898-5290. We’ll send you a reply.«

(TM 9-1425-386-10-1)

R.I.P.: Die rechtsverbindliche digitale Signatur (Teil 4)

Einst galt das Rechtskonstrukt der digitalen Signatur als Schritt in die Zukunft. Inzwischen haben selbst unsere Bürokraten verstanden, dass die einfache Übertragung althergebrachter Konzepte in die digitale Welt der Entwicklung benutzergerechter Lösungen im Wege steht:

»Das Bundesministerium für Wirtschaft und Technologie und das Bundesministerium für Arbeit und Soziales haben sich nach eingehender Überprüfung des ELENA-Verfahrens darauf verständigt, das Verfahren schnellstmöglich einzustellen.

Grund ist die fehlende Verbreitung der qualifizierten elektronischen Signatur. (…)«

(Gemeinsame Pressemitteilung des Bundesministeriums für Wirtschaft und Technologie und des Bundesministeriums für Arbeit und Soziales,
via Netzpolitik)

Das war ein langer, schmerzhafter  Erkenntnisprozess (vgl. Teil 1, Teil 2, Teil 3). Vielleicht versuchen wir in Zukunft mal, Sicherheitstechnik um Anwendungen herum zu konstruieren und nicht Anwendungen um ein Stück Sicherheitstechnik plus Rechtskonstrukt. Es kommt nämlich nicht auf formale Compliance an, sondern darum, dass eine Anwendung funktioniert, nützlich ist und dabei in der Praxis keine Unfälle passieren.

 

Meta-Fail

Da wird sich Oma aber freuen

»Ist ein Verbot für Fahrzeuge aller Art (Zeichen 250) angezeigt, dürfen elektronische Mobilitätshilfen geschoben werden.«

(§ 7 (4) MobHV)

In einem Wort

alarm fatigue

IT-Sicherheit im Jahr 2011

So funktioniert IT-Sicherheit im Jahr 2011:

»Laut der Verfügung, die heise online vorliegt, dürfen die Kartenlesegeräte für die elektronische Gesundheitskarte eGK nur in einer kontrollierten Einsatzumgebung aufgestellt werden, in der sie nicht länger als 30 Minuten unbeaufsichtigt sind. (…) Kann ein “kontrollierter 30 Minuten-Bereich” nicht garantiert werden, müssen die Terminals alle 30 Minuten auf Unversehrtheit kontrolliert werden.«

(Heise online: BSI verärgert Ärzte)

Unsere Systeme sind sicher, solange jemand daneben steht und sie bewacht. Und dieser Jemand soll der Benutzer sein, dem wir die Technik aufdrängen.