Archiv der Kategorie: Freundlich zum Nutzer

Usability, Benutzerfreundlichkeit

Scheinalternative Anwendungszoo

Digitalisierung, Digitalveganismus, Freundlich zum Nutzer, Propaganda, So geht das, , ,

In Baden-Württemberg laufen einige Vereine und Verbände weiter Sturm gegen den Einsatz von Microsoft-Produkten in Schulen als handle es sich dabei um von Bill Gates persönlich verimpfte atomgetriebene Tunnelbahnhöfe der fünften Generation. Neben ätherischen Ideen wie WeltSchulfrieden, Datenschutz und digitaler Souveränität sowie abstrusen Prägungstheorien führen die Vereine als Argument auch angebliche Alternativen an (PDF):

„Mit Moodle (Lernplattform), BigBlueButton (Videokonferenzsystem), LibreOffice (Bürosoftware), Thunderbird (Mailprogramm) und Nextcloud (Dateiablage und Kooperation) stehen allen Schulen Anwendungen zur Verfügung, die den Funktionsumfang von MS 365 abdecken oder übertreffen.“

Eine Sprecherin des Kultusministeriums zitiert dagegen positive Erfahrungen und findet es „verwunderlich, dass die Verbände in ihrer gemeinsamen Stellungnahme die Bedürfnisse der Schulen und Praktiker vor Ort offenbar nicht zur Kenntnis nehmen und die Realitäten des Alltags verkennen.“ Ich teile ihre Verwunderung nicht, denn die Ansichten der Aktivisten lassen sich zwanglos mit einem engen Erfahrungshorizont erklären. Anscheinend hat keiner von ihnen in den letzten zehn Jahren eine moderne Office-Installation aus der Nähe gesehen.

Wer Microsoft Office hört, denkt zuerst an Word, Excel und PowerPoint. Kein Wunder, denn aus diesen Produkten schnürte Microsoft vor gut drei Jahrzehnten sein erstes Office-Paket. Bis heute sind sie in jeder Version enthalten, doch die Hauptrolle spielen sie nicht mehr. Microsoft Office heißt heute: Outlook und Skype for Business und OneNote und Teams sowie im Hintergrund in einer herkömmlichen On-Premise-Installation Exchange, SharePoint und Active Directory. Und das ist zusammen kein Zoo aus einzelnen Anwendungsgehegen, sondern eine integrierte Lösung, ein digitales Gondwanaland.

Eine Besprechung mit Microsoft Office geht ungefähr so: Zuerst sagst du Outlook, dass du gerne Leute einladen würdest, und suchst dir die Teilnehmer aus dem Adressbuch aus. Dein Adressbuch weiß, wo das Active Directory steht, deshalb findest du da jeden aus deiner Organisation. Outlook schaut dann selbständig in die einzelnen Kalender und schlägt dir Zeiten vor, die allen passen. Du schreibst deinen Einladungstext und klickst auf den Skype-Button, der einen Block mit den Zugangsdaten fürs Meeting in deine Nachricht einfügt. Das ist alles. Kein Wechsel zwischen Programmen, keine mentale Checkliste erforderlicher Fleißarbeiten – du schreibst einfach eine Einladung, der Rest geht mehr oder weniger von selbst. Wenn nicht gerade Pandemie ist und alle zu Hause bleiben, kannst du im Vorbeigehen auch einen freien Besprechungsraum suchen und reservieren.

Genauso unkompliziert legst du aus deinem Kalender einen Notizzettel in OneNote an, entweder für dich alleine oder auf dem Sharepoint-Server für alle. Auf diesem Notizzettel erscheinen von selbst die Metadaten zur Besprechung – Betreff, Datum, Uhrzeit, Teilnehmerliste und so etwas — und dann kannst du oder könnt ihr loslegen und zum Beispiel die Agenda entwerfen. Dir fällt dabei ein, dass du zur Vorbereitung unbedingt noch etwas erledigen musst? Kein Problem, aus OneNote heraus kannst du deine Outlook-Aufgabenliste befüllen und aus der Aufgabenliste kommst du selbstverständlich auch zurück zum Ursprung und ob du deine Aufgabe in Outlook oder in OneNote als erledigt abhakst, bleibt dir überlassen.

Kurz bevor die Besprechung losgeht, meldet sich Outlook mit einer Erinnerung. Daraufhin beginnst du nicht etwa hektisch im Kalender und deiner E-Mail nach den Einwahldaten zu suchen, sondern du klickst einfach den Beitreten-Button im Erinnerungsfensterchen an und setzt dein Headset auf, während Skype for Business die Verbindung aufbaut. Während der Besprechung kommt dann vielleicht mal PowerPoint zum Einsatz oder Excel oder was auch immer man gerade zum Arbeiten braucht. Das Protokoll schreibst du in OneNote, das dir die im Skype-Meeting erschienenen Teilnehmer in der Liste selbständig ankreuzt, damit du dich auf Wichtigeres konzentrieren kannst. Du berichtest im Meeting von einem Telefonat letzte Woche und kannst dich nicht mehr erinnern, wer dich da angeskypet hat? Guckst du Outlook, das merkt sich deine Chats und Anrufe aus Skype for Business.

Du bist oft unterwegs und willst lieber mit dem Smartphone? Dann nimmst du halt Outlook und OneNote und Skype for Business für Smartphones. So wird nicht nur die Cloud als Backend auf einen Schlag plausibel, sondern du bekommst auch noch gratis Office Lens dazu, das dir  Whiteboards und Flipcharts und Visitenkarten und Dokumente nach OneNote fotografiert und sie dabei entzerrt und zuschneidet. Und ja, wenn es sich um Drucksachen handelt, macht OneNote unaufgefordert OCR und du kannst später nach dem Inhalt suchen.

Das, und nicht Word/Excel/PowerPoint, ist ein zeitgemäßes Officepaket: eine integrierte Lösung für die Organisation, Kommunikation und Zusammenarbeit im Arbeitsalltag. Wer ganz oder teilweise im Manager Schedule arbeitet, viele verschiedene Vorgänge im Blick behalten muss oder aufgrund seiner Rolle mit vielen verschiedenen Menschen zu tun hat, erleichtert sich seine Arbeit damit ungemein. Gelungene Integration kommt unauffällig daher, hat jedoch einen großen Nutzen, denn sie beseitigt Reibungsverluste und Hürden. Fürs Wesentliche bleibt mehr Zeit, die Kommunikation und Zusammenarbeit läuft rund.  Dabei habe ich Microsoft Teams mangels eigener Erfahrung damit noch nicht einmal berücksichtigt.

In vielen Unternehmen funktioniert das so. Richtig klar wird einem das vielleicht erst, wenn man es mal selbst erlebt hat – und dann südwestdeutschen Querdünkel von Dateiablagen und LibreOffice schwärmen hört. Solche Alternativen spielen nicht in derselben Liga und auch nicht in der nächstniedrigeren. Google Workspace spielt in derselben Liga, aber das würde ihnen ja genauso wenig gefallen.

Selbstverständlich könnte man sich vornehmen, Ähnliches auf der Grundlage von Open-Source-Software selbst zu entwickeln. Vorher möge man jedoch kurz überschlagen, wie viele Jahre Vorsprung Microsoft und Google haben, wie viele Milliarden an Investitionen in ihren Produkten stecken und wie viele voraussichtlich noch hinzukämen, bevor man sie eingeholt hätte. Fünf Milliarden aus einem Digitalpakt würden dort kein ganzes und auch kein halbes Jahr reichen.

Gewiss, in die Hände von Grundschülern gehört ein digitaler Büroarbeitsplatz nicht. In die ihrer Lehrerinnen und Lehrer dagegen schon und dann bitte ordentlich, nicht als Modell 601S. Lehrerinnen und Lehrer haben nämlich allerlei zu planen, zu kommunizieren und zu organisieren. Gibt man ihnen vernünftige Werkzeuge dafür, können sie sich genau wie Büroarbeiter besser aufs Wesentliche konzentrieren. Ein paar jugendfreie Funktionen wie einfach zu nutzende Konferenzschaltungen für improvisierten Fernunterricht fallen dabei fast von alleine mit ab und vielleicht kann auch die Redaktion der Schülerzeitung etwas mit zeitgemäßen Werkzeugen anfangen. Von mir aus kann die gerne jemand anderes als Microsoft oder Google liefern, wenn es denn jemand anderes kann. Solche Diskussionen müssen aber auf dem Stand der Technik geführt werden und nicht auf der Basis von Fake News. Stand der Technik sind integrierte Lösungen, die Arbeit erleichtern, und nicht zusammengewürfelte Sammlungen halbgarer Me-too-Produkte. Mal schnell für ein paar Euro Open-Source-Software aufzusetzen, die gerade auf der Anwendungsebene oft hinterherhinkt, rettet uns nicht.

P.S. (2021-01-17) Im Golem.de-Diskussionsforum findet User Oktavian diese schöne Metapher:
„Als Bauherr möchte ich ein Haus. Der Bauträger bietet mir ein Haus gebaut nach meinen Wünschen an. Du möchtest mir einen Bagger liefern, Steine, einen Kran und Dachziegel. Daraus kann ich mir bestimmt ein Haus bauen, aber dann brauche ich noch Bauarbeiter, einen Plan, Genehmigungen, ein Grundstück, einen Architekten, einen Statiker und habe das Risiko, dass alles nicht funktioniert. Was glaubst Du wohl, wessen Angebot ich reizvoller finde?“
Und auch sonst dreht sich die Diskussion dort um die hier angesprochenen Punkte.

Digitale Scharlatane

Anforderungen – Requirements, By Design, Digitalisierung, eBürokratie, Freundlich zum Nutzer, Regierungsviertel, , ,

Chatbots gelten den EDV-Experten in deutschen Amtsstuben heute als so modern und zukunftsweisend wie einst die Blockchain-Technologie. Wieder einmal überschätzen sie banale Technik grandios, ohne sich um den Anwendungsnutzen und die Benutzerinteraktion zu scheren. Oder wissen sie, was sie tun und setzen Chatbots aus denselben Gründen auf, aus denen sich Kleinstadtbürgermeister bei feierlichen Eröffnungen neuer Spielplätze oder Radwege fotografieren lassen, nämlich um dabei gesehen zu werden? Immerhin gelten Chatbots in Deutschland als zukunftsträchtige KI, damit zeigt man sich gerne.

Die Bundesverwaltung zeigt sich aus aktuellem Anlass mit dem Chatbot C-19 zum Thema Coronavirus. Nach eigener Aussage hat man weder Kosten noch Mühen gescheut, um dieses zukunftsweisende Technologieprojekt umzusetzen:

„Hinter C-19 steht ein interdisziplinäres Team in den beteiligten Ministerien und Ämtern, beim Beauftragten der Bundesregierung für Informationstechnik und beim IT-Dienstleister des Bundes. Das Team besteht aus Programmiererinnen und Programmierern, Trainerinnen und Trainern, Redakteurinnen und Redakteuren, Softwarearchitektinnen und -architekten, Administratorinnen und Administratoren und weiteren Wegbegleiterinnen und Wegbegleitern sowie Fürsprecherinnen und Fürsprechern, die ihn mit Informationen versorgen, beim Lernen unterstützen und sich um das Wohlergehen von C-19 kümmern.“

Müsste ich raten, wo das Budget herkommt, würde ich auf die KI-Strategie der Bundesregierung tippen, denn die Bundesregierung möchte, dass wir KI-Weltmeister werden, und wenn die Regierung etwas möchte, dann ist das in den Amtsstuben Gesetz. Unter diesen Umständen kann man nicht nicht KI machen und so verspricht man das Blaue vom Himmel:

„In Form eines Chats kann C-19 mit Ihnen ein Gespräch führen und soll Ihnen als Bürgerinnen und Bürgern so den Zugang zu fachlichen Inhalten der Ministerien, Ämter und Institutionen des Bundes erleichtern. Er ist um Antworten nicht verlegen und ist sogar bereit, aus Ihren Fragen mehr zu lernen und seine Wissensbasis zu Corona stetig zu erweitern. Mit C-19 wird ein Prototyp für den Aufbau einer bürgernahen Kommunikation mit Hilfe einer lernenden Technologie entwickelt.“

Nicht nur diesem Anspruch wird C-19 nicht gerecht, sondern auch keinem anderen vernünftigen. Gespräche führen kann der „Chatbot“ schon mal nicht, das überfordert ihn:

screenshot-2020-10-13-at-22.01.21

Am besten füttert man C-19 einfach mit Stichworten wie eine Suchmaschine. Dann verhält er sich auch wie eine Suchmaschine und liefert Ergebnisse:

Screenshot 2020-10-14 at 00.30.30

Eine unmittelbare Antwort auf seine Frage bekommt man selten, auch wenn man eine formuliert, sondern in aller Regel einen Link und dazu einen Sermon unterschiedlicher Länge in schönstem Bürokratendeutsch:

Screenshot 2020-10-14 at 00.03.43

Manchmal bekommt man auch nur den Sermon und keinen Link dazu. Ob es sich auch um eine Antwort auf die gestellte Frage handelt, bleibt dabei Glückssache:

Screenshot 2020-10-13 at 12.20.27

Irgendwann muss auch dem interdisziplinären KI-Projektteam klargeworden sein, dass es sich bei seinem Chatbot in Wirklichkeit um eine banale Websuche handelt. Bietet C-19 weitere Informationen an, kann man direkt aus einem Menü wählen, welches dann – auf dem Umweg über ein inszeniertes Selbstgespräch des Bots – das Ergebnis liefert:

Screenshot 2020-10-13 at 22.03.53

C-19 ist also in Wirklichkeit eine Suchmaschine, die sich hinter einem chatartigen Interface verbirgt, dadurch umständlich zu nutzen ist und ihre Tarnung nur kurz durchhält. Das ist keine Kinderkrankheit, die sich irgendwann gibt, sondern Resultat eines Vorgehens, in dem Benutzerinteraktion und Anwendungsnutzen keine Rolle spielen. Das Entwicklungsziel lautete anscheinend nicht, eine sinnvoll und leicht verwendbare Anwendung, Funktion oder Informationsdarstellung anzubieten, sondern um jeden Preis mit einem Chatbot gesehen zu werden.

Wer sich nur ein wenig mit Interaktionsdesign beschäftigt, kommt schnell darauf, dass der Austausch wohlformulierte Sätze in natürlicher Sprache selten der geeignetste, einfachste  Modus der Mensch-Maschine-Interaktion ist. Eingaben werden nicht einfacher, wenn man ganze Sätze tippt, sondern anstrengender; diese Anstrengung bleibt vergebens, wenn der Computer am Ende doch nur auf Stichworte reagiert oder schlechte Antworten gibt.

Ausgaben müssen knapp und prägnant sein und dürfen wesentliche Informationen nicht in nutzlosem Rauschen verstecken. Styleguides für Benutzerschnittstellen sind deshalb voll von Empfehlungen, wie man Rauschen entfernt. Schon die Frage: „Möchten Sie mehr erfahren?” ist als Beschriftung eines Buttons zu lang, „Mehr erfahren“ oder auch nur „Mehr“ spart allen Zeit. Selbst bei kürzeren Texten sorgt die Chatdarstellung für eine geringe Informationsdichte auf dem Bildschirm und bietet keine Möglichkeit, alle relevanten Informationen oder eine übersichtliche Aufstellung derselben auf einen Schlag auf den Schirm zu bekommen.

Mit Vorteilen hat man sich diese Defizite nicht erkauft. C-19 lässt selbst offensichtlichste Gelegenheiten zur Interaktion ungenutzt. Erklärt etwa jemand der Suchmaschine, einige Symptome einer Infektion zu verspüren, böten sich Rückfragen nach weiteren Symptomen sowie umfassende, klare Verhaltensmaßregeln an. Doch so weit wollte niemand denken:

Screenshot 2020-10-13 at 22.37.00

Was stattdessen herauskommt, wenn man tatsächlich nützliche Informationen sinnvoll verfügbar machen möchte, die Benutzerinteraktion ausgehend von diesem Ziel gestaltet und über die erforderliche Designkompetenz verfügt, demonstriert Google. Dort muss man nicht einmal seine Anfrage selbst zu Ende tippen, sondern bekommt nach wenigen Wörtern den passenden Fortsetzungsvorschlag:

Screenshot 2020-10-13 at 12.30.17

Dessen Auswahl liefert ein sorgfältig aufbereitetes Ergebnis: Verhaltensmaßregeln in wenigen einfachen Hauptsätzen ohne ein überflüssiges Wort oder in Stichpunkte, Verweise auf weitere Informationen sowie leichter Zugang zu Antworten auf ähnliche Fragen, alles übersichtlich aufbereitet mit einer hohen Informationsdichte und schnell zu erfassen.

Screenshot 2020-10-13 at 12.31.35

Wer etwas allgemeinere Stichwörter als Suchbegriffe eingibt, bekommt so viel Information, wie sich auf einer Bildschirmseite unterbringen lässt:

Screenshot 2020-10-13 at 22.52.54

Auch auf die unspezifische Symptomschilderung liefert Google zwar keine Rückfrage, aber eine passende Antwort:

Screenshot 2020-10-13 at 22.56.15

Hinzu kommt, dass Google jeder kennt und dass das bis auf einige zwanghafte Nonkonformisten auch jeder dort sucht, während man vom Chatbot C-19 der Bundesverwaltung nur zufällig erfährt. Mich hat das Randgruppenmedium Twitter auf C-19 aufmerksam gemacht.

C-19 ist nutzlos. Der Chatbot ist keiner, seine Gestaltung lässt keine kompetenten Bemühungen um Nutzen und Usability erkennen und mit der Suchmaschine Google sind wir besser bedient. Das wird sich auch nicht ändern, wenn man weiter am Bot herumbastelt, denn der gewählte Ansatz ist nicht fortschrittlich, sondern unsinnig und kein Stück nutzerorientiert. Zu befürchten ist jedoch, dass man noch lange daran herumbasteln wird, aus denselben Gründen, aus denen man damit begonnen und sein Scheitern nicht bemerkt hat.

Kein Wunder, dass es mit der Digitalisierung der Verwaltung so schleppend vorangeht, wenn maßgeblichen Akteuren das Immunsystem gegen Scharlatanerie fehlt. Wir sind nicht mehr nur digital rückständig, wir verlieren langsam den Kontakt zur Realität. Zwischen dem „Chatbot“ der Bundesverwaltung und einem sinnvoll gestalteten User Interface nach dem Stand der Kunst liegen Welten und sie liegen nicht hinter, sondern vor dem Bot. So wird das nichts mit der digitalen Souveränität.

PS (2020-10-21): Wenigstens die Erfahrungen mit Karl Klammer alias Clippy sollte man kennen, wenn man was mit Chatbots machen möchte.

Plattform, mit Betonung auf platt

Anforderungen – Requirements, Digitalisierung, Freundlich zum Nutzer, Unterwegs, , ,

Digitale Plattformwirtschaft gilt der Bundesregierung als großes Ding, seit sie bemerkt hat, dass wir keine eigene haben. Um diese Lücke zu schließen, fördert Berlin Plattformprojekte. Zum Universalleuchtturm Gaia-X, dessen Anwendungen von Chatbots für das eGovernment bis zur Krebsheilung reichen sollen, kommen die Themen der einzelnen Ressorts. Das Verkehrsministerium fördert, naheliegend, die Mobilitätsplattform Stadtnavi, die nicht weniger verspricht als Mobilität gemeinsam neu zu denken. Das Ergebnis ist Asche, nämlich ein notdürftig als Plattform verkleideter Karten- und Routenplanungsdienst, der seine Claims statt auf die Hauptsache direkt auf Nebengebiete wie Open Data, Open Source und Datenschutz legt. Zu kurz kommt wie so oft die Nutzerorientierung und damit das, was andere Plattformen erfolgreich macht.

Der Fairness halber sei gesagt, dass Stadtnavi nach eigener Aussage noch nicht fertig ist und das Projektbudget mit 370.000 Euro überschaubar bleibt. Gleichwohl lässt sich bereits eine Richtung erkennen. Stadtnavi bietet im Wesentlichen einen Karten- und Navigationsdienst, der verschiedene Verkehrsträger berücksichtigt und der mit Echtzeitdaten zum Beispiel über freie Parkplätze, Ladestationen, Mitfahrgelegenheiten, Busverspätungen und so weiter angereichert wird. Richtig verpackt sind solche Dienste unbestritten nützlich, das zeigen die Navigationssysteme in vielen Autos, Karten- und Navigationsapps für Smartphones sowie der DB Navigator. Anders als der DB Navigator, der auch Fahrkarten verkauft und Bahnreisende unterwegs unterstützt, bleibt Stadtnavi jedoch auf der Metaebene: Man kann sich dort über Mobilität informieren, sonst nichts.

Gemessen am eigenen Anspruch, für saubere Luft zu sorgen, wie auch an den Erfolgsvoraussetzungen für ein Plattformgeschäft drückt man sich vor der eigentlichen Herausforderung: Mobilität nutzerorientiert anders zu organisieren. Dazu müsste man nicht nur irgendwas mit Internet machen, sondern echte und konkurrenzfähige Mobilitätslösungen bieten. Messen lassen müssen sich solche Angebote am Auto, das bei vielen Menschen vor der Tür steht und darauf wartet, gefahren zu werden. Das Auto vor der Tür befriedigt bequem und flexibel eine breite Palette an Mobilitätsbedürfnissen. Wer sich einmal daran gewöhnt hat, einfach einzusteigen und loszufahren, findet kaum einen Anlass, sich überhaupt über Alternativen zu informieren. Wer es dennoch tut, wird häufig in seiner Entscheidung für das Auto bestärkt. Mit Ausnahme der Schnellbahnsysteme in Großstädten und Ballungsräumen bleibt der öffentliche Nahverkehr der individuellen Fortbewegung – einschließlich Fahrrad und Taxi – oft unterlegen.

So verwundert nicht, dass eine kommerzielle Plattform wie Uber, in deren Motivation saubere Luft so wenig eine Rolle spielt wie die Arbeitsbedingungen ihrer scheinselbständigen Fahrer, einen Taxidienst anbietet. Ein Ubertaxi ist so bequem wie das eigene Auto vor der Tür, erspart einem jedoch den Ärger damit und steht im Gegensatz zum eigenen Auto auch am Zielflughafen auf Wunsch vor der Tür. Ob man Uber deswegen auch gestatten sollte, an die Stelle der bisherigen Taxiwirtschaft mit ihrem vergleichbaren Angebot zu treten, sei dahingestellt. Jedenfalls bieten alte wie neue Taxis heute echte Mobilitätsplattformen mit einem Smartphone-Interface, die digital eine Schar mehr oder minder unabhängig arbeitender Dienstleister koordiniert.

Erfolgreiche Plattformen vernetzen Anbieter und Kunden so, dass für alle ein Mehrwert entsteht. Von Amazon zum Beispiel bekomme ich einen Online-Shop für fast alles, was man überhaupt kaufen kann. Manches liefert Amazon selbst, anderes kommt von unabhängigen Händlern, die (auch) über Amazon verkaufen. Mir erleichtert Amazon das Leben, weil ich einmal bestelle und dann in den nächsten Tagen Klemmstifte für die Heizung aus der Oberlausitz, Ersatzteile für meine Fahrradtaschen aus dem Schwarzwald und eine Fahrradbremse aus dem Amazon-Lager geliefert bekomme. Den Händlern nimmt es einen Teil des Shop-Betriebs ab und führt ihnen Kunden zu. Amazon sorgt dafür, dass das alles reibungslos funktioniert. Analog bekomme ich von Apple, Google oder Microsoft nicht einfach ein Gerät oder ein Betriebssystem, sondern Appstores, aus denen ich mir über viele Anbieter hinweg meine Anwendungslandschaft zuammenklicke und Updates bekomme.

Eine echte und nützliche Mobilitätsplattform müsste dasselbe tun und die Verkehrsbedürfnisse ihrer Nutzerinnen und Nutzer besser und einfacher befriedigen als ohne sie. Ein Ansatz dazu ist die echte Vernetzung verschiedender Verkehrsträger nicht nur in Form integrierter Navigation und Fahrplanauskunft, sondern zu einem nützlichen Mehrwertdienst. Möchte ich zum Beispiel nach Frankfurt oder über Frankfurt irgendwohin fahren, muss ich erst einmal zum Bahnhof kommen. Ich wohne zwischen zwei etwa gleich weit entfernten Strecken, auf denen jeweils S-Bahnen und Nahverkehrszüge und auf einer auch nutzbarer Fernverkehr fahren. Die ÖPNV-Anbindung ist in einer Richtung besser als in der anderen, und unabhängig davon etwa einen Kilometer Fußweg entfernt. Mit einem eigenen Fahrzeug, das ich am Bahnhof parke – egal ob Fahrrad oder Auto – beschränke ich mich für die Rückfahrt auf eine der beiden Strecken. Mit einem Rollkoffer im Schlepp fällt das Fahrrad aus und ein eigenes Auto habe ich gar nicht.

Möglicherweise könnte ich mich für eine Plattform begeistern, die mir in dieser Situation das Denken und Organisieren abnimmt. So einer Plattform würde ich einfach sagen, dass ich jetzt nach Frankfurt möchte. Daraufhin bekäme ich die Antwort: „Kein Problem, kostet 25 Goldstücke, Sie werde in zehn Minuten abgeholt. Dürfen wir Sie am Zielort noch irgendwo hinbringen?“, oder auch: „Um die Ecke steht ein freies Mietfahrrad. Wenn Sie darauf spätestens halb drei gen Westen reiten, bekommen Sie die nächste Regionalbahn oder notfalls ein paar Minuten später die nachfolgende S-Bahn. Möchten Sie das Rad bis dahin reservieren?“ Für die zweite Variante fehlt es meiner Kleinstadt an Mieträdern, die gibt es nur in der größeren Nachbarstadt. In der ersten wüsste der Fahrer, der mich abholt, dass ich mit der Bahn weiter möchte und zu welchem Bahnhof er mich bei der aktuellen Verkehrslage fahren soll. In beiden Fällen hätte sich jemand Gedanken gemacht, was mein Mobilitätsbedarf ist, wie er sich befriedigen lässt und wie das für mich möglichst einfach wird. Dafür jedoch etwas mehr nötig als nur Auskünfte.

Nützlich machen könnte sich eine Mobilitätsplattform auch in Ausnahmesituationen. Unsere alltägliche Mobilität ist stark von Gewohnheiten geprägt. Wir fahren so oft zur Arbeit, zum Einkaufen, zu Verwandten und Freunden oder zu regelmäßigen Freizeitbeschäftigungen, dass wir darüber nicht mehr nachdenken, sondern alles wie immer tun. So mancher ist schon versehentlich Samstags zur Arbeit gefahren, weil er irgendwohin wollte, der Anfang des Weges derselbe war und dann der innere Autopilot übernahm. Manchmal haben wir jedoch ungewöhnliche Bedürfnisse, müssen mehr transportieren als das Fahrrad schafft, organisieren eine Familienfeier mit dezentralen Übernachtungen und mehreren Ortswechseln oder müssen eine Zeit überbrücken, in der das eigene Fahrzeug nicht verfügbar ist oder aus sonst einem Grund alles nicht wie gewohnt funktioniert.

Mit intelligenten Angeboten für solche Situationen bekäme eine Mobilitätsplattform vielleicht auch bei jenen einen Fuß in die Tür, die sich sonst gewohnheitsmäßig ins eigene Auto setzen und das auch noch täten, wenn der Benzinpreis bei fünf Euro und die Höchstgeschwindigkeit auf Autobahnen bei 80 km/h läge. Denken wir noch einmal an Amazon: In seiner Jugend konnte der Konzern bei vielen Kunden damit punkten, dass er englischsprachige Bücher ohne Umstände lieferte. Heute sind dort noch viel mehr Dinge zu bekommen, die man in Geschäften und Kaufhäusern vor Ort vergebens sucht. Fotopapier, Feuerpoi, Fahrradständer – alles kein Problem. So etwas kommt heraus, wenn man mit einer Plattform Geld verdienen möchte, so dass man gezwungen ist, sich mit Nutzerbedürfnissen auseinanderzusetzen und echte Vorteile zu verkaufen. Aus ehrgeizarmen Förderprojekten kommt dagegen so etwas wie Stadtnavi, immer und immer wieder.

Bonpflicht als Chance

By Design, Digitalisierung, eBürokratie, Freundlich zum Nutzer,

Die Bäcker jammern: Ab Januar 2020 müssen sie zu jedem Einkauf einen Kassenbon erstellen (und zugleich ihre Kassen mit einer manipulationssicheren Protokollierung ausstatten). Das Bundesfinanzministerium antwortet mit dem Hinweis, dieser Pflicht können auch mit der Ausgabe elektronischer Belegen Genüge tun, woraufhin Medien von Lösungen per E-Mail oder Smartphone phantasieren. Dabei könnte alles sehr einfach sein.

Selbst das traditionelle Bäckerhandwerk entdeckt ganz, ganz langsam das elektrische Bezahlen. Das funktioniert heute kontaktlos und bei kleinen Beträgen ohne PIN-Eingabe. Kunden bekommen den zu zahlenden Betrag angezeigt, halten ihre Karte ans Terminal und finden später einen Nachweis auf ihrem Kontoauszug oder ihrer Kreditkartenabrechnung beziehungsweise in den entsprechenden Funktionen ihrer Online-Bank.

In dieses Verfahren ließen sich elektrische Kassenzettel gut integrieren. Aus Nutzersicht handelt es sich um eine detailliertere Version des Verwendungszwecks, der ohnehin übermittelt und angezeigt wird. Eines Tages könnten die für den Zahlungsverkehr eingesetzten Protokolle solch eine Funktion direkt unterstützen. Gegenwärtig tun sie dies vermutlich nicht und Standardisierungsbemühungen in der Finanzwirtschaft dürften etwas länger dauern.

Bis dahin könnte man sich mit einem Verfahren behelfen, das sich aktuelle Versionen des elektronischen Rezepts zum Vorbild nimmt. Bei allen Kartenzahlungen kämen die digitalen Kassenzettel dann in einen Cloudservice, der sie für eine gewisse Zeit, etwa sechs Monate, zum Abruf vorhielte. Käufer erhielten via Abrechnung zu jedem digitalen Kassenbon eine eindeutige, praktisch nicht erratbare Referenznummer, mit der sie ihn aus der Cloud abrufen könnten. Optional könnte man die Kassenbondaten sogar verschlüsseln (dann dürfte man jedoch zum Abruf nicht denselben Schlüssel verwenden wie zum Entschlüsseln).

Als MVP bekämen man also bei Kartenzahlung in der Abrechnung eine Zahlenkolonne zu sehen, mit der wir den Kassenbon abrufen könnten. Mit etwas gutem Willen und nach einigen Jahren Beratung in  verschiedenen Gremien könnte daraus eine Funktion im Online-Banking werden, mit der sich zu jeder Zahlung der zugehörige Kassenzettel abrufen ließe, wahlweise direkt aus der Cloud während der vorgesehenen Speicherdauer dort oder auf Wunsch aus einem automatisch geführten persönlichen Archiv mit selbst gewählter Speicherdauer und nützlichen Verwaltungsfunktionen zum Beispiel zur Erstellung von Steuererklärungen.

So ungefähr dächten wir über dieses Thema nach, wären wir digital auf der Höhe der Zeit. Wir sind es nicht und zahlen bei vielen Bäckern noch bar. Dazu passt der Bon auf Papier.

PS: Einen Monat später sehen das andere ähnlich. (2019-12-17)

PPS: Weitere anderthalb Monate später diskutiert Deutschland weiter über Kassenbons und zunehmend über digitale Lösungen. (2020-01-29)

PPPS: Das Handelsblatt hat herausgefunden, dass die Bonpflicht zu einem Innovationsschub im Handel führt. (2020-01-30)

CfP: 3rd Workshop on Security Information Workers (WSIW 2017)

English, Events, Forschung, Freundlich zum Nutzer, Psycho, Security, ,

There will be another edition of WSIW this year and it will be part of SOUPS again, which is in turn co-located with the Usenix Annual Technical Conference. WSIW is concerned with  all kinds of security information work and the people doing such work, like developers, administrators, analysist, consultants, and so on. We were there last year with early results of our penetration testing in software development study. If the subject of your reseach is security work, please consider submitting to WSIW.

CfP: https://www.usenix.org/conference/soups2017/call-for-papers-wsiw2017

Workshop website: https://usec.cispa.uni-saarland.de/wsiw17/

Submissions due: 2017-05-25

Eat Less Bread?

English, Freundlich zum Nutzer, Security,

“Eat less bread” requests a British poster from WWI. We all know it makes sense, don’t we? Resources become scarce at wartime, so wasting them weakens one’s own position. Yet this kind of advice can be utterly useless: tell a hungry person to eat less bread and you will earn, at best, a blank stare. However reasonable your advice may seem to you and everyone else, a hungry person will be physically and mentally unable to comply.

“Do not call system()” or “Do not read uninitialized memory” request secure coding guides. Such advice is equally useless if directed at a person who lacks the cognitive ability to comply. Cognitive limitations do not mean a person is stupid. We all are limited in our respective ability to process information, and we are more similar to than dissimilar from each other in this regard.

Secure coding guidelines all too often dictate a large set of arbitrary dos and don’ts, but fail to take human factors into account. Do X! Don’t do Y, do Z instead! Each of these recommendations has a sound technical basis; code becomes more secure if everyone follows this advice. However, only some of these recommendations are realistic for programmers to follow. Their sheer number should raise our doubt and let us expect that only a subset will ever be adopted by a substantial number of programmers.

Some rules are better suited for adoptions than others. Programmers often acquire idioms and conventions they perceive as helpful. Using additional parentheses for clarity, for example, even though not strictly necessary, improves readability; and the const == var convention prevents certain defects that are easy to introduce and sometimes hard to debug.

Other rules seem, from a programmer’s point of view, just ridiculous. Why is there a system() function in the first place if programmers are not supposed to use it? And if developers should not read uninitialized memory, what would warn them about memory being not initialized? Such advice is inexpensive – and likely ineffective. If we want programmers to write secure code, we must offer them platforms that make secure programming easy and straightforward and insecure programming hard and difficult.

Verbraucherschutz für #Neuland

Begriffe, Forschung, Freundlich zum Nutzer, Geschäft, Security

Wieder einmal ist ein Programm damit aufgefallen, dass es dort, wo es installiert wird, die Umgebung vandalisiert. Kristian Köhntopp fasst das Problem anschaulich zusammen und die Kommentare unter seinem Post illustrieren, dass es sich nicht um einen Einzelfall handelt. Technisch kann man das Problem im Prinzip lösen, indem man einen vertrauenswürdigen Anbieter eine geschlossene Plattform betreiben lässt, die solche Programme verhindert beziehungsweise erkennt und ausschließt. Da stecken freilich einige Annahmen drin, die nicht unbedingt erfüllt sind.

Eigentlich handelt es sich jedoch um ein ökonomisches Problem, das nach einer ökonomischen Lösung schreit: “Moral hazard occurs under a type of information asymmetry where the risk-taking party to a transaction knows more about its intentions than the party paying the consequences of the risk. More broadly, moral hazard occurs when the party with more information about its actions or intentions has a tendency or incentive to behave inappropriately from the perspective of the party with less information.” — (Wikipedia: Moral Hazard)

Produkthaftung löst das Problem nicht unbedingt, sondern führt nur zur risikominimierenden Gestaltung von Firmengeflechten. Jedes Produkt bekommt eine eigene Wegwerffirma ohne nennenswertes Vermögen, die man im Krisenfall kostengünstig opfern kann. Dieses Modell ist auch im Security-Geschäft längst erprobt (Fallstudie: DigiNotar). Man müsste die Unternehmen zwingen, Rücklagen zu bilden und in einen Haftungsfond oder so etwas einzuzahlen. Kann man tun, passt aber besser zu Atomkraftwerken.

Zwangsweise hergestellte Transparenz bietet sich als Lösungsweg an. In #Altland haben wir dafür die Stiftung Warentest, aber die hat mit ihren Vergleichstests von Sonnencreme, Fahrradhelmen und Akkuscharubern schon genug zu tun. In #Neuland glaubte man früher, das Problem mit Positivzertifizierungen lösen zu können, die einem einzelnen Produkt definierte Sicherheitseigenschaften bescheinigen. Das funktioniert nur in Nischen gut. In jüngerer Zeit gesellen sich dazu allerlei Bug Bounties und Initiativen wie das Project Zero.

Wenn ich diese Ansätze frankensteine, komme ich auf eine unabhängige und solide finanzierte Europäische Stiftung IT-Sicherheit, die sich relevante Software näher anschaut und die Ergebnisse publiziert. Gegenstand ihrer Tätigkeit wären Consumer- und Massenprodukte, die sie auf Sicherheitsmängel und überraschende Funtionen prüft. Das Verschleiern von Funktionen müsste man vielleicht noch unter Strafe stellen, damit das funktioniert. Außerdem wird man sich überlegen müssen, wie die Tester ungehinderten Zugang zu SaaS bekommen. Das sind freilich Detailprobleme; erst einmal müssen wir grundsätzlich entscheiden, wie digitaler Verbraucherschutz jenseits von Seien Sie vorsichtig mit dem Internet aussehen soll.

(Geringfügig überarbeitete Fassung eines Posts auf Google+)

Zwei Karten, zwei Philosophien

Freundlich zum Nutzer, Philosophie, Risiko, Security, , , , ,

Ich bekomme eine neue Smartcard. Ausgestellt von der Fraunhofer-PKI, kann ich mit der Karte E-Mail und anderes verschlüssel und signieren sowie Urlaub beantragen, Besprechungsräume reservieren und meine Arbeitsstunden auf Projekte buchen. Zur Karte gehört ein Passwort, falls ich sie mal verliere, und aufgedruckt trägt sie ein Jugendfoto meiner selbst.

Ich besitze schon so eine Karte, sie funktioniert auch, doch die PKI möchte mir eine neue ausstellen. Das ist ein komplizierter Vorgang. Ich bekomme einen PIN-Brief, dann muss ich die Karte abholen und dabei einen amtlichen Lichtbildausweis vorzeigen. Vermutlich werde ich auch unterschreiben müssen, dass ich die neue Karte erhalten habe. Alles muss sehr sicher sein, sonst könnte womöglich jemand in meinem Namen Räume reservieren oder Urlaub beantragen.

Von meiner Bank bekam ich vor einigen Tagen ebenfalls eine neue Smartcard. Mit dieser Karte kann ich einkaufen und Geld abheben. Sie kam mit der Post, lag einfach im Briefkasten. Meine bisherige PIN glt auch für die neue Karte.

Die eine Karte steht für ein System, das besonders sicher sein möchte und stattdessen besonders bürokratisch ist. Die rechtsverbindliche elektronische Signatur hat sich deswegen im Alltag nie durchgesetzt, die eID-Funktion des neuen Personalausweises bislang auch nicht. Entworfen hat man Technik und Rechtskonstrukte, keine Anwendungen.Der primäre Zweck besteht darin, in einem formalen Sinn sicher zu sein.

Die andere Karte repräsentiert eine Dienstleistung: Zahlungsverkehr in verschiedenen Ausprägungen. Eine Plastikkarte als Mittel dazu ist praktisch; dass später Magnetstreifen und Chips hinzukommen würden, ahnte man bei der Erfindung des Plastikgeldes noch nicht. Die begleitenden Prozesse bleiben unbürokratisch, sie sind pragmatisch gestaltet. Nicht formale Sicherheit ist das Ziel, sondern akzeptable Risiken.

P.S.: Diese Woche ist Smartcard-Workshop.

Nutzlose Fragen

Freundlich zum Nutzer, Security, Vertrauen,

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.

Datenkrake Google (6/7): Und jetzt Werbung

Datenkrake, Datenschutz, Forschung, Freundlich zum Nutzer, Geschäft, Psycho, Spackeria, Wolkenkuckucksheim, , , ,

[Inhalt – Teil 1 – Teil 2 – Teil 3 – Teil 4 – Teil 5 – Teil 6 (+Nachtrag) – 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.

Screenshot von http://tortoisesvn.net/downloads.html mit Google-Werbung

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:

Screenshot: SEO-Artikel auf t3n mit SEO-Werbung

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

Begriffe, Forschung, Freundlich zum Nutzer, Geschäft, IT, Psycho, So geht das, , , , ,

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.

Cookies, Clients und die Cloud

Datenkrake, Datenschutz, Forschung, Freundlich zum Nutzer, Regierungsviertel, Spackeria, Wolkenkuckucksheim, Zeitmaschine, , , , , , , , ,

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

Freundlich zum Nutzer, Security, , ,

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

Freundlich zum Nutzer, IT, Zahlenspiele, ,

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

Freundlich zum Nutzer, Geschäft, ID, Vulnerability,

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.

Was könnte schiefgehen?

Freundlich zum Nutzer, IT, Phishing, Security, Vertrauen, , ,

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

Freundlich zum Nutzer, Gadget, IT, Nerds, Testlabor, Wahrnehmung, , , ,

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.