eOrbit

Seit einem halben Jahr testet die (vielleicht bald von Edeka übernommene) Supermarktkette Kaiser’s Tengelmann in 30 Berliner Märkten, wie Kunden einkaufen, wenn sie glauben, dafür belohnt zu werden. Dafür bekommen sie gelbe “Extrakarten”, die bei jedem Einkauf gescannt werden müssen, damit dem Kartenkonto Punkte gutgeschrieben werden (jeweils 5 Punkte pro 1 Euro Einkaufswert).

Das System funktioniert anders als z.B. Payback bei Rewe und Real, weil Extrakarten-Besitzer keinen Namen, kein Geburtsdatum und keine Adresse zu hinterlegen brauchen. Dafür sollen sie vor jedem Einkauf an einem Terminal im Markt eine Liste mit dem aktuellen Punktestand und fünf bis acht “persönlichen Angeboten” ausdrucken. Beim Vorzeigen des “Extra Sparscheins” an der Kasse kosten die jeweiligen Produkte dann 10, 20 oder 30 Prozent weniger als am Regal dransteht.

Das Besondere ist, dass die “persönlichen Angeboten” tatsächlich persönlich sein sollen – weil sie angeblich auf das individuelle Kaufverhalten des jeweiligen Kunden abgestimmt werden.

“Die Extrakarte ist eigentlich wie ein physischer Cookie”,

erklärte Raimund Bau, Mitgründer der Software-Firma SO1, mit der Kaiser’s kooperiert, im vergangenen Herbst Zeit Online. Jedes Produkt sei “ein statistischer Hinweis auf andere Produktvorlieben, wo wie Weleda-Shampoo auf Bio-Obst hinweist”.

Vermutlich bräuchte es keine aufwändigen Computerberechnungen, um darauf zu kommen, dass Kunden mit einer Vorliebe für Naturkosmetik auch ökologisch erzeugte Äpfel und Bananen bevorzugen. Aber vielleicht überrascht die künstliche Kaiser’s-Intelligenz nach einiger Zeit ja damit, dass sie Begehrlichkeiten aus dem Unterbewusstsein auf Thermopapier zaubert. Mit ungewöhnlichen Produkten, die man schon immer mal kaufen wollte, sich bislang aber nie getraut hat! Lebensmitteln, von denen man gar nicht wusste, dass man sie mochte, und erst durch Kaiser’s davon erfährt! Also zum Beispiel …

… Chips, Kaugummi, Margarine, Nudeln und Müsli?

Seit drei Monaten zieh ich jetzt “Extra Sparscheine” aus dem roten Terminal im Kaiser’s-Markt, der nicht direkt auf meinem Heimweg liegt. (Der, der auf meinem Heimweg liegt, gehört nicht zu den Testmärkten.) Und vielleicht kommt es daher, dass ich dort nach der Arbeit immer nur Minimaleinkäufe erledige, weil die Schlangen zu Stoßzeiten bis weit in die Flure hineinreichen. Jedenfalls sehen meine “persönlichen Angebote” jedes Mal so aus, als hätte die künstliche Intelligenz grad keinen Bock gehabt zu rechnen und sie stattdessen ausgewürfelt.

Freilich könnte das auch daher kommen, dass es Kaiser’s nur sehr am Rande darum geht, treue Kunden zu belohnen, sondern vielmehr: sich selbst und die Markenindustrie.

Dass auf den “Sparscheinen” fast ausschließlich Markenartikel stehen, ist natürlich kein Zufall. Die kooperierenden Hersteller hoffen, dass ihre Produkte eher in den Einkaufswägen landen, wenn die Kunden sie als Angebot aus dem Terminal gezogen haben. SO1 verspricht wiederum, einen individuellen Rabatt für jeden Kunden zu errechnen. Je nach vermuteter Preisempfindlichkeit kriegt der eine auf ein Produkt dann vielleicht 20 Prozent Rabatt, jemand anderes aber nur 10 oder 15. Im Grunde genommen sind die “persönlichen Angebote” also nix anderes als die unpersönlichen Angebote im wöchentlichen Werbeprospekt. Bloß für manche Kunden, von denen die Kaiser’s-Technologie vermutet, dass sie den Geldbeutel etwas lockerer sitzen haben, zu schlechteren Konditionen.

Was für eine tolle, ähm – Belohnung.

Die Supermarktkette selbst hat auch was davon: Sie hofft, dass Extrakarten-Kunden die herabgesetzten Markenartikel kaufen und dann nicht nochmal woanders einkaufen gehen (zum Discounter), also dank der Lockmittel insgesamt mehr Geld in der Kaiser’s-Kasse lassen. Und das wäre ja auch völlig legitim, würde Kaiser’s gegenüber seinen Kunden für die Werbung im Belohnungspelz nicht mit dem Satz werben:

“Einfach. Günstig. Extra für Sie!”

Ist halt nur mittelrichtig. Passt aber zum restlichen Schlamassel.

Das Risiko, dass Kunden sich auf den Arm genommen fühlen, wenn ihr Supermarkt sie dazu auffordert, bei jedem Einkauf einen ellenlangen “Sparschein” auszudrucken, aber an der Kasse dann bitteschön der Umwelt zuliebe auf den Ausdruck des halb so großen Bons zu verzichten, nimmt Kaiser’s bei seinem Test in Kauf.

Die kleinen Belohnungen, die Kunden dafür kriegen, dass sie sich derart für Promotion- und Umsatzerhöhungszwecke einspannen lassen, gibt es – wie bei Waitrose in Großbritannien – immerhin sofort. Unten auf jedem “Sparschein” ist jedes Mal ein neues Produkt gedruckt, das sich bei diesem Einkauf gratis mitnehmen lässt. So weiß man gleich, was man als treuer Kunde wert ist: ein Duplo (-150 Punkte), ein Schälchen Milchreis (-350 Punkte) oder eine Tüte Gummibärchen (-500 Punkte).

Mehr zum Thema:

• Selbstquälerische Zeithaber, geht öfter donnerstags einkaufen!

Fotos: Supermarktblog

In den Kommentaren zu meiner Krautreporterkritik vom Sonntag schreibt Krautreporter Rico Grimm auch etwas zum KR-Honorarsystem:

Rico Grimm: Ich habe bisher 4500 Euro bekommen, also 500 Euro pro Artikel. Wenn Leute nur 1-3 Texte geschrieben haben, haben sie auch nur entsprechendes Honorar bekommen.

Spiegel Online oder Zeit Online würden 180 Euro beziehungsweise 150 Euro zahlen, führt er weiter aus (zum Vergleich). Über die Honorarsätze gibt es nichts zu meckern (und wer das hier in den Kommentaren auch nur andeutungsweise macht, wird gelöscht – dafür kann der oder die gerne andere Kanäle nutzen), schreibt man PR kann man das pro Tag abrechnen. (Und wer die Kommentare gelesen hat, kann hier aufhören, ich habe einiges davon schon dort geschrieben.)

Allerdings ist Honorierung pro Artikel nicht das, was in der Fundingphase angekündigt war.

Social Secrets-Interview mit Alexander von Streit: Die Autorinnen und Autoren in unserem Kernteam bekommen eine monatliche Pauschale von 2000 bis 2500 Euro. Dafür liefern sie in der Regel einen Text pro Woche, übernehmen auch regelmäßig redaktionelle Arbeiten.

Das wurde geändert, aber am Honorar ändert sich wenig, da ein Text pro Woche à 500 Euro auch 2000 Euro bedeutet.

Aber man ist mit der Honorierung pro Artikel wieder an einer Stelle, von der man meiner Auffassung nach doch eigentlich weg wollte. Nämlich von dem kurzfristigen Denken und Handeln. Auch wenn es vermutlich gute und zwingende Gründe gab, von der Monatspauschale abzurücken.

Social Secrets-Interview mit Alexander von Streit: Die Orientierung auf Reichweite, also vermarktbare Klicks auf den meisten Nachrichten-Websites, führt in der Masse zu einem Journalismus, der sich in erster Linie an dem Reichweitenpotenzial eines Themas orientiert. Das verändert die Themenauswahl, (…) In der Masse fehlt es aber aufgrund der oben beschriebenen Mechanismen meist an Zeit und Budget, um tiefer in Themen einzusteigen, die abseits der aktuellen Agenda liegen.

Jetzt setzt KR als Website zwar nicht auf die schnelldrehenden Geschichten, aber ich als Reporter bin doch schwer in der Versuchung, bei Bezahlung pro Artikel, schnelldrehende Themen zu suchen. Bei Bezahlung nach Masse ;-) überlege ich mir doppelt, wo ich mich dransetze und mache im Zweifelsfall die Geschichte mit dem geringeren Aufwand und/oder die bei der ich sicherer mein Honorar bekomme.

Ich will damit nichts unterstellen, aber ich bin hier als freier Journalist im Lokalen auch immer vor solchen Entscheidungen. Und habe auch schon mal Artikel abgelehnt und abgegeben, wenn ich befürchtete, dass ich im Verhältnis zu dem was rauskommen kann, da zuviel Zeit reinstecken muss. Im Endeffekt muss bei jedem Termin und Gespräch was bei rumkommen, zuviel Hintergrundgespräche rechnen sich nicht.

Wenn ich für einen Zeitungsartikel über eine (ich nenne jetzt mal den Klassiker des Lokalteils als pars pro toto) “Kaninchenausstellung” genau so viel bekomme, wie über einen tiefen Blick in einen kommunalen Haushalt plus Nachfragen in der Kämmerei und bei der Kommunalaufsicht, dann ist doch klar was schneller geht. Vor allem wenn ich auch noch was für eine Kaninchenfotogalerie bekomme. Haushaltssseiten voller Zahlen sind leider weder fotogen noch niedlich. ;-)

Honorierungssysteme sind nämlich immer auch Wetten. Zahle ich als Verlag eine Pauschale (oder stelle die Redakteure fest an), hoffe ich, dass die mehr Zeilen abliefern, als wenn ich sie nach Zeilen bezahle. Bezahle ich nach Zeilen, setze ich Anreize, dass der freie Mitarbeiter ordentlich viel Text abliefert. Und als Pauschalist hoffe ich, dass ich mit weniger Arbeit rumkomme. Davor schützt nur, dass man Mitarbeiter hat mit Arbeitsethos und einem Verständnis, dass der Beruf Berufung ist.

Denn ein Blick in meine Arbeit sagt mir, dass eine “Rechnerei mit Bodenrichtwerten” beim Stadiongelände des SV Darmstadt 98 oder ein Kurzüberblick über “Haushaltsgenehmigung und Kommunalaufsicht” eigentlich in einem schlechten Aufwand/Ertrag-Verhältnis steht. Aber ich wollte nunmal nicht nur die Sportausschussitzung oder die Stadtparlamentssitzung eins zu eins wiedergeben. Etwas Mehrwert sollte auch für den dabei sein, der auch da war.

Michael Feathers - Detecting Refactoring Diligence:

Detecting Refactoring Diligence

Weil niemand mit sowohl das Erscheinen einer starken islamistischen Gruppe in Syrien und im Irak als auch mit den Bemühungen des russischen Tzar um einen kleinen kalten Krieg gerechnet hatte, steht heute die Bundeswehr zum Teil außer Gefecht.

Ähnliches könnte in Bildung und Forschung passieren. Seit Jahrzehnten erodiert in Deutschland nicht nur die materielle, sondern auch die personelle Substanz. Überall in Hochschulen sind marode, notdürftige in Stand gehaltene,  Gebäude zu sehen. Überall fehlt es an Lehrpersonal. Neulich erzählte mir lachend ein junger Informatik-Professor, dass seine Bewerbung bei einem dynamischen IT-Unternehmen mit der Begründung abgelehnt wurde, man könnte ihm leider derzeit ein Jahresgehalt von nur 120.000 € anbieten. Dabei verdient ein Professor auf der höchsten Gehaltsstufe deutlich weniger.

In der Informatik ist eine Hochschulkarriere für die begabtesten jungen Absolventen keine anziehende Perspektive mehr. Die Arbeitsbedingungen sind zu schlecht, die Lehre ist viel zu hart geworden. Ein ehemaliger Doktorand, der nach der Promotion mehrere Jahre in einem Forschungszentrum im Universitätsumfeld ohne Lehraufgaben tätig war, teilte mir neulich sein Wechsel zu einem IT-Konzern wie folgt mit: “Es ist angenehm, einen Arbeitgeber zu haben, der sich um sein Personal kümmert.” Hochschulkarriere sind auch deswegen wenig attraktiv geworden, weil in den letzten Jahrzehnten die Fürsorge für das wissenschaftliche Personal sehr zurückgegangen ist.

Begabte und kreative Informatik-Professoren wird es sicherlich trotz allem immer noch geben. Es wird aber viel mehr Professoren geben, die vor allem die Bequemlichkeit einer sicheren Stelle suchen, und die sich in ein System gerne einfügen, welches Bequemlichkeit und Anpassung mehr als selbständiges Denken und Kreativität fördert.

Irgendwann wird man aber kreative Informatiker für Forschung oder Lehre benötigen, und ausreichend qualifizierte und begabte werden schwer zu finden sein. Der Wiederaufbau wird dann mühsam und langsam sein. Das Land wird Jahrzehnte lang an Wettbewerbsfähigkeit einbüßen.

FB

During a long plane flight to San Francsico I could see a number of people editing their presentations while stuck in the air for more than 10 hours.

Many of them were editing the exact sequence of what they were going to say to the audience. Changing a sentence, switching the order of some bullet points: they were editing speaker notes, not editing slides.

This type of editing should be done in the notes field of the slide, not on the slide itself. It is a good check for yourself: if you find yourself editing speaker notes in the slide itself, you are probably doing something wrong.

Goto Fail, Heartbleed, and Unit Testing Culture by Mike Bland:

Two computer security flaws were discovered in early 2014: Apple’s “goto fail” bug and OpenSSL’s “Heartbleed” bug. Both had the potential for widespread and severe security failures, the full extent of which we may never know. Given their severity, it is important for the software development profession to reflect on how they could have been detected so we can improve our ability to prevent these kinds of defects in the future. This article considers the role unit testing could play, showing how unit tests, and more importantly a unit testing culture, could have identified these particular bugs. It goes on to look at the costs and benefits of such a culture and describes how such a culture was instilled at Google.

I regularly take the the top voted question from readers and answer it in a post. With 85 votes, today’s winner was:

How do you create a reliable character in your story?  how do you create a deep, reliable personality? So they would seem real?  (Submitted by Elchanan Paley)

I am going to do something I haven’t done before and deliberately not answer this question, at least not directly.

This question seems, at first, like a reasonable, if basic, thing a writer should ask. But there are several issues lurking inside this question that made it a great example for how to ask better questions. It’s not a bad question, despite the title of this post, but it certainly could be a better one. And the way you ask better questions is to question the question.

Why does a character need to be reliable?

I know many unreliable people in real life. Part of what makes a person a person is their contradictions and flaws. Even narrators can be unreliable in good books. It’s by carefully capturing the important details of a person in words that makes them seem real or not. And don’t forget depending on the kind of writing you are doing, unreality is an asset. Consider Frankenstein, Darth Vader or even Harry Potter. Unreliability, or superficiality, might be the most important trait a character, or a person has.

Which writers have you read that have written good characters?

One powerful thing about books is there are no wires or strings. There are no special effects. Every book is just a series of words. This means anything one writer achieves can be studied by other writers. Go read how Dickens describes the characters in Great Expectations, or Tolstoy in Anna Karanenna. It’s all there. Of course you can’t see how many drafts it took them to arrive at these finished works, you can see every verb, noun and adjective in every sentence.

You might read these books and decide that the way these writers wrote those characters isn’t all that good, and as a writer you are entitled to your opinion (A great exercise is to take a page you don’t like from a classic book and rewrite it in your own style). But the way you develop your sensibilities isn’t to just read books about how to write, but to read whatever kinds of books you’re trying to write, study them and then write something yourself based on what you learned.

Pick any two novels, read ten pages of each, and then compare the different ways the author was effective, or ineffective, in achieving whatever thing you want to achieve in your own works.  To be a serious writer demands developing your own opinions and you can only do that by changing how, why and what you read.

Why do you think there is an objective answer?

I think The Catcher in The Rye is a good book, but many people don’t agree, as it has 400+ one star amazon reviews. There is no one answer for what is a good book, much less for what is a well written character. The writing styles of, for example, Hemingway and Updike, are very different, but neither is necessarily better than the other.

This is part of the challenging of making things: you have to accept we are an opinionated species. Some people will like what you write and some people won’t no matter how good a writer you are. Some people will prefer characters written one way, others another. John Gardner, author of the classic The Art of Fiction, wrote that “Nothing in the world is inherently interesting… to all human beings.” If you want to write you have to accept the subjectivity of writing. 

Why do you think I would know the answer?

I’ve written five books, but they’re all non-fiction. I have an unpublished novel, but that, in the grand scheme of writing fiction, isn’t much of an achievement. This means I’m not the best person to ask this particular question. Given how many writers make a living purely by writing about writing, rather than writing books on other subjects, there are many good places to start. Gardner’s The Art of Fiction is the first book I think of for new writers of fiction, but it’s easy to find others.

Der Ärger mit den mächtigen IT-Konzerne aus den USA ist eine Konstante des europäischen Empfindens. Diesen Ärger habe ich erst gegenüber IBM wahrgenommen. In den 70er Jahren des 20. Jahrhunderts, als ich Gymnasiast und dann Student war, war IBM für viele sowohl der Traumarbeitgeber wie eine gefährliche Krake, die die Welt zu beherrschen droht.

Dann kam der Personal Computer, der PC, und jemand, der im Gegenteil zu IBM der Auffassung war, dass der PC zukunftsweisend war. Er entwickelte dafür ein Betriebssystem und leitete den Erfolg von Microsoft in. Microsoft wurde zum für viele sowohl der Traumarbeitgeber wie eine gefährliche Krake, die die Welt zu beherrschen droht.

Es kam Web und zwei Studenten, die ihr Verständnis von Netzwerkanalyse, Betriebssysteme und Parallelalgorithmen bündelten, um die erste Suchmaschine zu gründen. Nun ist Google für viele sowohl der Traumarbeitgeber wie eine gefährliche Krake, die die Welt zu beherrschen droht.

Dank Web und Suchmaschinen-Technologie konnten sich die soziale Medien verbreiten. Facebook kam … und so weiter.

Gewiss Konzerne mit Monopolstellungen gefährden die Marktwirtschaft. Geht es aber mit IBM, Microsoft, Google und Facebook Monopole. IBM sicherlich nicht länger. Microsoft hat auch viel Macht verloren und viele Wirtschaftsbereiche nicht erfasst. Google beherrscht immer noch das Suchmaschinengeschäft. Facebook ist längst nicht länger das modische soziales Medium für die jüngeren Generationen … sowie für andere.

Viel ärgerlicher als der große Erfolg von einigen US-Unternehmen ist für mich die Unfähigkeit Europas in der IT erfolgreiche Unternehmen zu gründen. Eine Graphik von Wired , “The Schools Where Apple, Google, and Facebook Get Their Recruits” lässt fürchten, dass keine Verbesserung in Sicht ist. Fünf indische Hochschule sind unter der “Arbeitskraftslieferanten” der führenden IT-Unternehmen … aber keine aus Europa. Darüber sollte man sich in Europa ärgern. Dagegen sollte man in Europa etwas unternehmen. Gymnasiasten ohne Scheu vor Mathematik und die gerne Probleme lösen, Informatik-Studierende, die viel Zeit mit der Programmierung verbringen und die Lust am Experimentieren haben. Das ist, was Europa braucht, um in der Liga der weltweit führenden IT-Unternehmen einen Platz zu ergattern.

FB

Heartbleed has encouraged people to look at the OpenSSL source code. Many have called it "spaghetti code" -- tangled, fragile, and hard to maintain. While this characterization is accurate, it's unfair. OpenSSL is written according to standard programming practices. It's those practices which are at fault. If you get new engineers to rewrite the code, they'll follow the same practices, and end up with equally tangled code.

Coding practices are out of date, laughably so. If you learn how to program in C in a university today, your textbook and your professor will teach you how to write code as if it were 1984 and not 2014. They will teach you to use "strcpy()", a function prone to buffer-overflows that is widely banned in modern projects. There are fifty other issues with C that are just as important.

In this post, I'm going to focus on one of those out-of-date practices called "pointer-arithmetic". It's a feature unique to C. No other language allows it -- for good reason. Pointer-arithmetic leads to unstable, hard-to-maintain code.

In normal languages, if you want to enumerate all the elements in an array, you'd do so with with an expression like the following:

     p[i++]

The above code works in a wide variety of programming languages. It works in C, too, and indeed, most languages got it by copying C syntax. However, in C, you may optionally use a different expression:

    *p++

This is pointer-arithmetic. Instead of a fixed pointer and a variable index, the pointer is variable, moving through the array.

To demonstrate how this gets you into trouble, I present the following bit of code from "openssl/ssl/s3_srvr.c":

   {
s2n(strlen(s->ctx->psk_identity_hint), p);
strncpy((char *)p, s->ctx->psk_identity_hint, strlen(s->ctx->psk_identity_hint));
p+=strlen(s->ctx->psk_identity_hint);
}

The first thing to notice is the line I've highlighted. This line contains the old programming joke:

    strncpy(dst,src,strlen(src));

The purpose of strncpy() is to guard against buffer-overflows by double-checking the size of the destination. The joke version double-checks the size of the source -- defeating the purpose, causing the same buffer-overflow as if the programmer had just used the original strcpy() in the first place.

This is a funny bit of code, but it turns out it's not stupid. In C, text strings are nul terminated, meaning that a byte with the value of 0 is added to the end of every string. The intent of the code above is to prevent the nul termination, not to prevent buffer-overflows. In other words, the true intent of the programmer can be expressed changing the above function from "strncpy()" to "memcpy()".

The reason the programmer wants to avoid nul termination is because they are building a protocol buffer where the string will be prefixed by a length. That's the effect of the macro "s2n()" in the first line of code, which inserts a 2 byte length field and invisibly moves the pointer 'p' forward two bytes. (By the way, macros that invisible alter variables are likewise bad programming practice).

The correct fix for the above code is to change from a pointer-arithmetic paradigm to an integer-indexed paradigm. The code would look like the following:

append_short(p, &offset, max, strlen(s->ctx->psk_identity_hint));
append_string(p, &offset, max, s->ctx->psk_identity_hint);
Last year, college professor John Regehr had a little contest to write a simple function to parse integers. Most solutions to the contest used the pointer-arithmetic approach, only a few (like my solution) used the integer-index paradigm. I urge you to click on those links and compare other solutions to mine.

My solution, using integer indexes

Typical other solution, using pointer-arithmetic

Many justify pointer-arithmetic claiming it's faster. This isn't really true. In the above contest, my solution was one of the fastest solutions. Indeed, I'm famous for the fact that my code is usually an order of magnitude faster than other people's code. Sure, you can show with some micro-benchmarks that pointer-arithmetic is faster in some cases, but that difference rarely matters. The simplest rule is to never use it -- and if you ever do, write a big comment block explaining why you are doing something so ugly, and include the benchmarks proving it's faster.

Others justify pointer-arithmetic out of language bigotry. We are taught to look down at people who try to program in one language as if it were another language. If you program in C the way you'd program in Java, then (according to this theory) you should just stick with Java. That my snippet of code above works equally well in Java and C is considered a bad thing.

This bigotry is wrong. Yes, when a language gives you desirable constructs, you should use them. But pointer-arithmetic isn't desirable. We use C not because it's a good language, but because it's low-level and the lingua franca of libraries. We can write a library in C for use with Java, but not the reverse. We use C because we have to. We shouldn't be programming in the C paradigm -- we should be adopting the paradigms of other languages. For example, C should be "object oriented", where complex structures have clear constructors, destructors, and accessor member functions. C is hostile to that paradigm of programming -- but it's still the right way to program.


Pointer-arithmetic is just one of many issues effecting the OpenSSL source-base. I point it out here because of the lulz of the strncpy() function. Perhaps in later posts I'll describe some of it's other flaws.

---

Update: Another good style is "functional" programming, where functions avoid "side effects". Again, C is hostile to the idea, but when coder's can avoid side-effects, they should.

Zwei Jahre nach Datenkrake Google ist aus den damals noch unscharfen Gedanken mit Unterstützung meiner Kolleginnen Annika Selzer, Andreas Poller und Mark Bedner ein Artikel geworden: Denkverbote für Star-Trek-Computer?, Datenschutz und Datensicherheit – DuD 38(1), Januar 2014, DOI: 10.1007/s11623-014-0008-x. Abgeschlossen ist das Thema damit nicht, die Diskussion geht gerade erst richtig los.

Vor 30 Jahren definierte das Bundesverfassungsgericht im Volkszählungsurteil das Recht auf informationelle Selbstbestimmung und erklärte es zu einer Voraussetzung für Freiheit und Gemeinwohl. Die elektronische Datenverarbeitung (EDV), so nannte man die Informationstechnik damals, steckte noch tief im Manufakturzeitalter. Datenbanken ersetzten gerade die Karteischränke, das beschriebene und sortierte Papier. Wissenschaftler begannen, über künstliche Intelligenz nachzudenken, aber das war eine Zukunftsvision; der Spielfilm Computer Chess fängt die Stimmung jener Zeit ein.

Einerseits zeugt das Volkszählungsurteil von Weitsicht. Aus der Datenmanufaktur ist eine Datenindustrie geworden. Computer spielen heute nicht nur Schach auf Weltmeisterniveau, sie gewinnen auch im Fernsehquiz Jeopardy! Amazon, Netflix, Last.fm und viele andere Dienste empfehlen uns, was unserem Geschmack entspricht, und liegen damit häufig genug richtig um uns erfolgreich etwas zu verkaufen. Google ermittelt aus Suchanfragen die Ausbreitung von Grippewellen, wenn auch nicht ganz genau. Das Thema Datensammlung und Datenverarbeitung grundsätzlich anzugehen erweist sich im Nachhinein als richtig.

Andererseits war die technische Entwicklung damals in ihren Einzelheiten kaum vorherzusehen. Als die Grundzüge unserer Datenschutzgesetze entstanden, dürfte niemand an ein Internet mit bald drei Milliarden Nutzern gedacht haben. Karteischränke und Datenbanken »wissen«, was man vorher darin abgelegt hat und über einen Index wiederfindet. Was man ihnen vorenthält, wissen sie nicht. Auf diese Vorstellung stützen sich weite Teile unseres Datenschutzrechts.

Heute aber sehen wir uns mit lernenden, zu einem gewissen Grad intelligenten Systemen konfrontiert und mit statistischen Verfahren, die aus Daten Modelle gewinnen und diese auf Einzelfälle anwenden. Geheimdienste sagen anhand von Facebook Proteste voraus; Surveillance by Algorithm nennt Bruce Schneier das. Online-Partnerbörsen setzen ähnliche Verfahren ein wie Online-Shops für Produktempfehlungen. Nicht nur Internet-Nutzer liefern Daten, sondern zum Beispiel auch Autos oder die vernetzte Haustechnik.

Betrachten wir diese Technik und ihre Anwendungen im alten Paradigma der elektronischen Karteischränke, führt dies zu überschießenden Warnungen, aber nicht zu einer effektiven Risikobehandlung. Einen Vorgeschmack gibt die Debatte um das Verbraucher-Scoring, die schließlich zu spezifischen Regelungen im Bundesdatenschutzgesetz führte, ohne dass damit alle Probleme befriedigend gelöst wären. Als sich die Schufa vor einiger Zeit anschickte, gemeinsam mit dem Hasso-Plattner-Institut die Auswertungsmöglichkeiten von Facebook-Daten zu untersuchen, war dies technisch folgerichtig, für den organisierten Datenschutz jedoch eine ungeheure Provokation. Das Vorhaben wurde nach öffentlichem Aufschrei zunächst abgebrochen.

Dass sich der Big-Data-Zug noch stoppen ließe, bleibt eine Illustion. Ebenso wie vor dreißig Jahren der PC und vor zanzig Jahren das Internet ist moderne Datenverarbeitung im Internet-Maßstab auf dem Wege der Demokratisierung. Uns bleibt nichts anderes übrig als diese Entwicklung hinzunehmen und sie konstruktiv zu begleiten. Dazu müssen wir uns zum einen von der einst formulierten Vorstellung lösen, Daten seien per se gefährlich und nur äußerst sparsam zu verarbeiten, und unsere Bemühungen um den Datenschutz auf die tatsächlichen Risiken konzentrieren. Zum anderen müssen wir diese Risiken effektiv behandeln.

Diskussionen um Datenschutzerklärungen und IP-Adressen sind dabei nur Scheingefechte; formale Lösungen gemäß überholten Paradigmen machen in der Praxis keinen Unterschied. Stattdessen stehen wir vor der Frage, wie wir statistische Inferenz und künstliche Intelligenz im Sinne der informationellen Selbstbestimmung handhabbar machen. Die Ziele des Datenschutzes bleiben richtig, aber seine Methoden sind – teilweise – überholt. Ein Beispiel mag dies verdeutlichen: Das Bundesdatenschutzgesetz enthält Regelungen zum Umgang mit besonderen Arten personenbezogener Daten: »Angaben über die rassische und ethnische Herkunft, politische Meinungen, religiöse oder philosophische Überzeugungen, Gewerkschaftszugehörigkeit, Gesundheit oder Sexualleben.« Sie gelten als besonders sensibel und sollen daher besonders geschützt werden. Das ist eine gute Idee. Wenn Maschinen jedoch selbständig schlussfolgern, dann können sie solche Daten implizit verarbeiten, ohne dass sie jemals irgendwo explizit genannt werden. Formale Erklärungen und Erlaubnistatbestände ändern daran nichts.

Lösungen für solche Probleme finden wir nicht, indem wir Google, Facebook oder die Schufa verdammen. Sie zeigen uns nur, was heute technisch möglich ist. Wollen wir der Technik einen Rechtsrahmen geben, müssen wir tatsächlich über Denkverbote für Star-Trek-Computer nachdenken: darüber, ob wir sie wollen, und gegebenenfalls darüber, wie wir sie umsetzen.

Filed under: Datenkrake, Datenschutz, Forschung, Spackeria, Wahrnehmung Tagged: Big Data, Datenanalyse, Dateninterpretation, machinelles Lernen, Modelle, Paradigmenwechsel, statistische Inferenz

Unser CAST-Seminar »Sichere Software entwickeln – Erfahrungen, Methoden, Werkzeuge« geht in die zweite Runde. Am 15. Mai 2014 laden wir zum Erfahrungsaustausch ins Darmstadtium ein. Vorträge von Praktikern und aus der angewandten Forschung beleuchten das Thema von allen Seiten. Unsere Themen in diesem Jahr:

• Organisation der sicheren Softwareentwicklung in Großunternehmen
• Security in schlanken und agilen Processen
• Denial-of-Service-Schwachstellen in Anwendungen
• Sicherheitsaspekte der Schnittstellenentwicklung
• Bedrohungsmodellierung und Sicherheitsanforderungen in der Praxis
• Skalierung von Methoden am Beispiel der Risikoanalyse

Anmeldung und Programm unter http://www.cast-forum.de/workshops/infos/190.

Filed under: Events, Forschung, How to, Security Tagged: CAST e.V., Secure Software Engineering, Sicherheit, Softwareentwicklung, Veranstaltung

Unsplash is a frequently updated blog of creative commons images. Mostly background and nature shots. Via Orli. Image by Dyaa Eldin Moustafa. 

Nach Google+ und Facebook kann man nun auch bei Twitter Personen auf Fotos taggen – also an den Tweet dranhängen, welche @twitterer auf dem Bild zu sehen sind.

Im Gegensatz zu G+ und Facebook kann man aber nicht direkt klicken welches Gesicht zu welchem Mensch gehört. Und natürlich kann man auch die Person Gumbo Fröhn taggen, obwohl da eigentlich Limbo Uffnick zu sehen ist, denn im Grunde ist die Funktion nur eine neue Art, jemanden zu mentionen.

Es findet nämlich keine Gesichtserkennung statt und so spart das eigentlich nur Zeichen, weil man die Abgebildeten nicht mehr separat erwähnen muss – die Tags gehen nicht mehr von den 140 Zeichen ab. Eigentlich muss Twitter nur aufpassen, dass es dabei Blocklisten usw. berücksichtigt, damit man nicht über eine Hintertür belästigt wird.

Ich finde sowas ja toll. Wenn man mich auf Fotos taggen kann und – wichtig! – ich darüber informiert werde, dann weiß ich, wo Bilder mit mir in der Öffentlichkeit rumschwirren. Ich kann mich dann drüber freuen. Oder, wenn jemand damit Mist baut, habe ich dadurch die Möglichkeit, den Rechtsstaat draufzuwerfen.

Das man mich auf Fotos in sozialen Netzwerken taggen und markieren kann gibt mir also ein Stück Kontrolle über meine Daten zurück. Das ist doch super. Noch superer wäre aber, wenn die Anbieter eine solche Funktion automatisieren und mich per Gesichtserkennung über die Veröffentlichung von Bildern mit mir drauf informieren müssten.

Ich hätte gern einen wöchentlichen Digest von G+, Facebook, Twitter und Co. mit „Es wurde hier, dort und da ein Bild veröffentlicht, auf dem vermutlich Du zu sehen bist. Bitte klicke hier, um das Bild zu sehen. Du möchtest auf dem Bild nicht veröffentlicht sein? Bitte klick hier, um das Bild zu melden und Dein Gesicht zu verpixeln“. Naja, oder so in der Art.

Wenn es diese Technik der Gesichtserkennung nun mal gibt müssen wir irgendwie lernen, damit umzugehen und dann wäre es doch besser, mir Möglichkeiten zu geben, dem vermeintlichen Kontrollverlust gegenzusteuern und meine informationelle Selbstbestimmung tatsächlich wahrnehmen zu können.

Earlier this week I attended the excellent Stevenson Science lecture at Royal Holloway University on "The Birth of Machine Cryptanalysis at Bletchley Park" given by Dr Joel Greenberg of the Bletchley Park Trust. When listening to any account of wartime code breaking one cannot fail to be impressed by the astounding level of innovation demonstrated by the early cryptographers. Such creativity is rarely encountered in today's commercial environment which stamps out mavericks and encourages tick-box conformance, short-term action and widespread copying of other people's practices.

The lecture was followed by a private dinner at which the Dean announced the University's plans for a new Innovation Centre. There's been a slight hitch in accommodation. (I'm told the earmarked site was sold to house builders.) But the concept must be applauded. Innovation is essential to help us escape from the damaging culture of conformance and compliance that has poisoned our cyber security efforts. And funding of fresh thinking is the key to finding the silver bullets to kill advanced persistent threats.  

Unfortunately it's more likely to be more of same rather than anything new: one step forward and another back. The step forward is the creation of a bigger research effort and an incubator for new developments. That is certainly welcome though it might not necessarily create any new funding. The step back is that the research will still be under the direction of the usual suspects, i.e. the government and industry sponsors, supported by an advisory board of establishment figures. So don't expect to see anything that is left-field, long term or high risk.

The problem is that government research bodies don't like to fund anything that looks remotely like a product: the closer you get to anything practical the quicker the funding tails off. In contrast vendors and venture capitalists tend not to fund anything that takes more than 18 months to develop. They are only interested in money or new features for their products. That's why we have so few innovative security technologies. New approaches tend to disappear down the gap between blue sky research and product development.

Fifteen years ago I sponsored the development of a model of the human immune system for fraud detection. It worked but needed further development. The concept died when the funding ran out. A similar fate killed another promising research project to detect human behaviour of security interest in digital networks. No less than a decade of funding is required to take a new technology from the drawing board to the market place. In the case of cryptography it can be even longer, as new approaches take many years to be accepted and implemented.   

Groundbreaking ideas rarely result from themed research. Creativity requires a high level of freedom coupled with a clear focus on a challenging problem - the more impossible-sounding the better. NASA research works because it focuses relentlessly on solving problems. MIT Media Lab works because it recruits students with creative ideas and gives them freedom to choose and direct their own work. MIT Media Lab researchers can develop a magic trick, design a new musical instrument or tackle a seemingly-unsolvable problem. Sponsors can visit and discuss their business requirements with researchers but they have to "charm" the researchers into cooperating. Promising projects will run for many years. That's how to encourage and enable real innovation. Anything less is merely jobs for the research boys.  

It seems counterintuitive: how can it be that making software “stronger” (as in reducing vulnerabilities) can increase risk on the Internet (as in creating more incidents)? But it happens frequently. The trick to understanding this conundrum lay in thinking like an economist and not like an engineer.

Engineers are focused on quality, so when they hear about vulnerabilities in software, their immediate reaction is to want to fix them… all of them. Regardless of whose software it is. Regardless of where it’s deployed. In fact, some of them care so much that they go out seeking vulnerabilities simply to fix them. They are the type of people who are great at solving problems, but not at understanding the downstream implications of their actions.

Economists, on the other hand (get it?), look at cause and effect, actions and reactions, and, most importantly, outcomes. The root of the economic problem lay in the ultimate unwanted outcome – the breach.Economics-oriented security pros understand that everything we do is intended to thwart the breach. It is easy to lose track of unwanted outcomes in the face of compliance needs and operational activities, but even those activities are all intended to minimize damages from attacks and exploits.

The engineer correctly believes that fixing vulnerabilities creates high quality (“stronger”) software. If the program starts with 300 vulnerabilities and you fix one, that obviously leaves 299 – one less than when it started. More importantly, if an enterprise has 1,000 systems that all have that same vulnerability and they apply a patch to 500 of them, they have decreased their attack surface by 500 vulnerabilities. From both perspectives, the level of vulnerability is, in fact, reduced.

But the economist knows that fewer vulnerabilities is not the ultimate objective. The ultimate objective is to reduce the likelihood of an incident.

The economist understands that there is a key missing ingredient to the engineer’s scenario – the intelligent adversary, aka the threat. And in pursuit of higher quality software the vulnerability details usually get published, leading to lower attack costs for the adversary. Given the scalability of technology, this typically leads to more attackers connecting to more targets, albeit in a (somewhat) smaller population of targets.

That is the key observation for this discussion – a breach requires both an attacker (threat) and a target (vuln), which manifests itself in the form of a connection between source and destination. Even though the population of targets may be reduced (perhaps even significantly so), if the threat is sufficiently motivated, more connections can be made with the vulnerable targets. The only way to guarantee reduced risk is to bring one of the populations (most likely the vulnerable targets) to zero. History shows us this is not likely with commercial software in enterprises. Interestingly, the increasingly common scenario for cloud-based software (e.g. Software-as-a-Service) may be able to do just that.

And there you have it – given the need for both threats and vulnerabilities, the reduction in one doesn’t force a reduction overall. And if the other element is increased in the process, the marginal difference in each population must be evaluated to truly understand the impact. Historically, this has led to scenarios where the vulnerability is reduced while the risk is simultaneously increased.

For reference:

More Sex is Safer Sex…

So, there was this big story in cosmology the other day– Tom Levenson’s write-up is very nice– which has been hailed as one of the greatest discoveries since the last greatest discovery, blah, blah, blah. And now that a few days have passed, we’re starting to see the inevitable backlash, ranging from detailed technical analyses of possible other explanations to more general musings about the nature of peer review. I’m not qualified to evaluate the former, so I’m going to talk a bit about the latter.

The title of that Atlantic post is “‘One of the Greatest Discoveries in the History of Science’ Hasn’t Been Peer-Reviewed—Does It Matter?,” which is probably a good candidate for applying the rule-of-thumb that a question in a headline is always answered “No.” Or at least “Not really.” It wanders around a bit, eventually hitting the most important point, namely that for all it is sometimes fetishized in coverage of science, the modern version of “peer review” is a very recent invention. Einstein famously encountered the modern refereeing system only once, and when he got some criticisms from a referee, he huffily withdrew the paper (and then made changes addressing the criticism before submitting to a different journal).

There’s also a decent case to be made that, in high-energy physics in particular, the peer review system has largely been superseded. What really matters these days is the posting of a result on the arxiv, which occurs before the anonymous-referee formal peer review process (in most cases). In that community especially, you really have lots of “peer review” happening in parallel– there may be a couple of people looking it over for a journal, but there are dozens of others looking it over as a basis for response papers and the like, which is vastly more important in the end.

What ultimately matters, after all is not review but replication– that is, when somebody else tries to do the same experiment, do they get the same results? This is where issues with statistical flukes usually sort themselves out, and that’s not a problem that can be fixed by any amount of refereeing. A journal referee can look for obvious gaps in the analysis, but will never get to the level of detail of a repeat experiment or a follow-up measurement.

Which means that the Atlantic article is sort of in the vicinity of an interesting philosophical question, without actually hitting the right point. That is, the interesting question isn’t “What does it mean that this result wasn’t reviewed?” but “What does it mean when you have results that can’t easily be replicated?” The BICEP2 results don’t really trigger that, because while from all reports it’s a technical tour de force, there are other experiments doing the same basic thing, and thus within a few years there will be independent confirmation or refutation of the result.

The Higgs boson, cited repeatedly in the Atlantic article because anyone writing about physics in 2014 is contractually obligated to mention that goddamn particle, comes closer, because the LHC is really the only game in town for high-energy physics. There’s no other accelerator in the world with comparable energy that can check the results produced at the LHC, which dances up to the line of being a problem. This is part of why the LHC includes multiple detectors, though– while ATLAS and CMS use the same high-energy proton beams, they are independent detectors, run by separate teams of physicists, and so can provide a cross-check on each other’s results. I suspect that, in the spirit of people who invoke Byzantine loopholes in Bell inequality experiments, somebody could come up with a reason to doubt the Higgs detection based on both detectors being located at the LHC, but it would be kind of strained.

More potentially troubling are the things that are very difficult to do, but not quite sexy enough to produce many parallel efforts. Weirdly, the best example of this that comes to mind is on the theory side, with the high-order calculations of the electron g-factor. This is a technically brilliant and highly demanding task, and there seems to be only a small number of people the world working on it, mostly associated with Toichiro Kinoshita at Cornell. The last time I saw a talk on this stuff, a couple of DAMOP meetings ago, the speaker ended with a plea for somebody else to take up the same question, and provide an independent check. There didn’t seem to be any takers, though, because it’s a fantastically complex task, and not all that intrinsically exciting. They do a lot of internal consistency checks, and apply multiple calculation methods, but pretty much all of the results in this area seem to come from one group. That situation is probably a more legitimate philosophical problem than BICEP2.

In the end, as I said, these recent results will all shake out in the normal manner of such things. Other groups will look at other areas of the sky with other telescopes, and either see the same pattern of gravity-wave-induced polarization, or something different. It’ll take a little while, but nothing in this fundamentally challenges the nature of science.

Team ist unter Spöttern ja eine Abkürzung für “Toll, ein anderer macht’s”. Den Eindruck hatte ich vor einigen Jahren auch in einem Projekt. Die Kooperationpartner (praktischerweise nicht am Schreibtisch gegenüber, sondern im Ausland) lieferten eher spärlich für eine gemeinsam betreute Website.

Und nun gibt ein Berater in einem SpOn-Artikel einen Hinweis darauf, dass im Team jeder mit weniger Einsatz rangeht: So sank die Leistung bei Testpersonen, wenn sie nur glaubten, es ginge um Teamwork. Aha.

Bei den damaligen ausländischen Partnern war es so, dass mit dem Geld zwei Uni-Stellen kofinanziert wurden. Und dem Prof war natürlich wichtiger, dass seine Mitarbeiter bei ihm fein forschen und nicht fürs ferne Frankfurt Fachartikel formulieren. Weil man sich auf die dortigen hauptberuflich Schreiber verlassen konnte.

Es gibt natürlich auch Gründe für Teamarbeit, steht bei SpOn:

In manchen Situationen kann sich die entspannende Wirkung des Teams positiv auswirken: Dort, wo uns zu viel Anspannung im Weg steht, also bei besonders schwierigen Aufgaben. Hier werden die Ergebnisse im Team besser. Und nur hier ist es wirklich sinnvoll, nach einer Arbeitsgruppe zu rufen.

Und dann sollten auch die Rollen in einem Team (z.B. Erfinder, Macher oder Koordinator) richtig besetzt sein. Ein Detail, das übrigens in Stellenausschreibungen selten bis gar nicht erwähnt wird. Teamfähig muss man sein – nur welche Rolle zu besetzen ist, das sagen die nicht. Und manche haben im Gespräch dann auch keine Antwort darauf.

I read a blog post by Greg Knauss, the creator of an iPhone app called Romantimatic, an app “to remind the distracted or forgetful to text nice things to their significant other”. Sounds like a cool app, right?

The blog post is only partially about the app itself, instead focusing more on the “medium-level Internet pile-on” that happened after its release.

Here is a paragraph from the article:

Derision from Cult of Mac. Disapproval from Esquire. The accusation that my goofy project has killed romance as we know it from Elle. Fifteen hundred words of high-minded arm-chair psychology and moral indignation from the Atlantic, including the comparison of the app’s users to — reductio ad absurdum — those who need reminding not to harm animals. And thousands and thousands of excoriating tweets.

Such a harmless app, but such a harsh reaction! It made me think about why people view it as indicating something broken in the person who uses such an app.

I figure it has something to do with people’s perception of being included in a technological solution to a social or interpersonal problem without their consent.

A hypothetical analogy would be a dating website… but one that didn’t connect the user with other users, but showed them automatically created profile pages of non-users using external sources like Facebook, Instagram, Goodreads, and Twitter accounts. All those disparate, but publicly viewable, data streams are out there, and it would only take one startup to use it to automatically create dating site profiles.

The users of the dating site could then pay to get the phone number or email or other contact information of their top picks, and end messages asking for dates.

But that sounds creepy! Right? The Romantimatic app is nowhere near as extreme as this example, but I think the visceral reaction against it comes about because it feels like it lands somewhere along a path that leads to such a world. We want to have social connections that have equal amounts of effort, time, emotion, and even money, flowing both ways.

The smartphone technology element is only one factor in this equation. The technology can be far more simple, like a stranger approaching you for the purposes of romantic engagement in a bar is acceptable and not creepy, but the same stranger approaching you in your kitchen is utterly unthinkable.

The level of social engagement is variable too. It doesn’t just have to be about romantic relationships. The creepiness still arises when there is unequal access to the technological solution; being signed up for email news letters or being added to FaceBook groups without permission gets at the same source of discomfort. Taken to the extreme: email spam.

While it would be a completely different app, one that functions like Romantimatic but was accessible by both parties in a relationship would bypass the creepiness factor and the resulting reactions. I can imagine a game where the user’s partner one would put in some simple keywords or phrases that they’d like to hear from their significant other, but that remained hidden in the app. The user would then compose a new romantic text message whenever they are reminded too, and if they guess the keyword or phrase they get… well, probably nothing but a gold star. The point of the game isn’t the game itself. The game is simply a way to make sure that the partner knows the romantic text messages is part of a technological solution, and their entering some keywords is consent of inclusion.

At some point in the last year there was too much email.

I’ve considered myself a competent manager of email and to-dos for much of my career, but the quantity of email that needed my attention exceeded a heretofore unknown ceiling and I began to understand how the smallest parts of my inbox policy could have a large affect on my reputation.

In this piece, I’ll explain the flawed system that worked nicely me for decades, how I detected its failure, and the new system that I’ve built that is currently keeping me sane.

A PRE-EMPTIVE ASIDE TO THE GTD NERDS OUT THERE. Yes, I know David Allen wrote this phenomenal book 12 years ago that would have saved me a lot of pain, but as an engineer I am afflicted with a wonderful disease called “Not Invented Here.” This disease forces me to ignore the helpful advice of others. It requires me to often build my own tool when there are plenty of pre-existing tools already built. You may think this disease is inefficient, but I find it educational. If GTD is your life blood, you will likely find little value in the piece, so go read this amazing Nobel Prize acceptance speech.

Decades of Email

My email system has been simple by design. What I discovered over the years is that whenever I added unnecessary complexity to my process, I also tended to create more work than productivity. Years of following this simple design resulted in the following setup:

All mail is contained within my inbox folder. This should set off all sorts of alarms for you. Of course, you have too much email, Rands – it’s all in your inbox. Calm down. I’m a professional. The “every mail in my inbox” policy is accompanied by the following rules and assumptions:

Aggressive pruning of noise via mail rules. To increase the signal of my inbox, I’ve developed a set of mail rules that pull non-essential emails into sub-folders. Noisy mailing lists are a primary culprit. By pruning out the noise, the probability of an email in the inbox being useful is higher. This includes rules like:

Automated highlighting of important emails. With a good chunk of the noise removed from my inbox, important mails tend to have a small handful of similar characteristics, and these characteristics are captured in additional mail rules:

• Mails from humans I care about.
• Mails with me and only me in the To: line.
• Mails with me in the To: or CC: line.

Within whatever email program I’m using, these types of mails are highlighted in some fashion so I can know at-a-glance that they are likely higher in priority.

The last two rules aren’t rules, but assumptions. My traditional inbox strategy made two large assumptions:

Search in mail works. With everything sitting in my inbox, search must work effortlessly. I must be able to remember, “Who said that thing about the thing?” and run a search and reliably find the appropriate email.  

To-dos can be equally tracked in email and a productivity app. In hindsight, it seems like an obvious flaw, but I’ve always worked under the assumption that I can track a follow-up equally well within email (via flags or other tagging mechanism) as well as within my productivity system, which for years was Things until I recently moved to Asana. In general, smaller tasks that lacked subtasks would remain in email, whereas large tasks would land in the productivity system. More on this flawed assumption shortly.

For years this system has worked. You can look at those simple rules and assumptions and easily find structural and systematic flaws. But even with those flaws I’ve had a modicum of success in my career, and this flawed system kept track of important projects, kept me in touch with my teams, and kept me in the know for many years. Your system is likely better, fancier, and more efficient, but I had proof my system worked. Until last year.

The Little Things

First, an important word about priority. I use the following system to prioritize work in my head:

• P0: Heinous. Must be handled immediately. Top of the list. Major repercussions if not resolved promptly.
• P1: Important. Needs to be handled soon. Major repercussions if not resolved, but not heinously on fire.
• P2: Somewhat important. Likely sans deadline. No one foaming at the mouth. Still needs to be finished in a reasonable amount of time. This is the majority of the work in the world.
• P3: Nice to have. Someone somewhere needs this to be done, but if doesn’t happen, we’re likely ok.

With my rules and assumptions in place, my inbox routine was:

• When I had time for email,
• I would read everything that was unread, and,
• If I could act on it immediately I would (mostly), but,
• If the next step was too big for the moment, I would either move it to the productivity system or leave it in the inbox for future consideration.

There are three kinds of email:

1. Useless crap
2. Information for later use
3. Actionable in some fashion.

At my historical usual arrival rate of actionable mails per hour, this process works. Checking email every so often, I would use the unread flag as a means of understanding both whether I’d read the mail and where I needed to act on them. Actionable (read: easy) P0s and P1s were crushed. Larger high priority issues were often pushed to the productivity system for longer term tracking. Lower priority issues remained in the inbox for short-term handling. Rinse. Repeat. Mostly everything handled… for years.

At a substantively higher arrival rate of actionable mails, the system fails in both obvious and devious ways:

• At a high rate of actionable email arrival, this system is unacceptably lossy because the inbox is growing at fast rate. P0 issues and P1 issues were mostly being handled (keyword: mostly – keep reading), but those P2 and P3 issues were dropping at an unacceptable rate. Does this mean I was prioritizing incorrectly? No. It was ok for a few of those P3s to drop and even some P2s, but when the majority of these fell through, the message I sent to the world was: lossy.

• Search in mail is fine, it’s my brain that sucks. On top of the exploding inbox was the fact that I believed I could keep all of the state and context of my inbox in my head, and if I couldn’t, I’d search. Again, that works at a certain arrival rate, but when the inbox explosion occurred I was no longer really reading all the mails. Which meant I didn’t have context, and more and more often searched my inbox for things I didn’t know. Inefficient.

• Unread doesn’t mean shit. In a time of inbox explosion, the unread flag doesn’t mean a thing. It’s the smallest piece of useless data. All it says is, You were here at some point and maybe you did something. I really don’t know. I would furiously get through my unread mail, chasing the fake goal of getting to zero unread messages… like it meant something. It doesn’t. Again, inefficiency.

It is the combination of all these unscalable flaws that is the most damning and obvious failure. As it became clear that my tried and true system was no longer working, I worked harder… using the same system. This meant that as the email continued to increase, I searched more – poorly. I started to try different tagging mechanisms. New folder and inbox strategies were adopted, then dropped, and all this thrash did was exacerbate the core problem: lossiness. What was a steady loss of P2s and P3s transformed into the loss of P0 and P1 issues, which leads us to the final rule:

Everyone knows when you drop a P0.

Inbox Close-to-Zero

As a leader, you define your reputation all the time. You’d like to think that you could choose the moments that define your reputation, but you don’t. They are always watching and learning. They are always updating their model regarding who you are and how you lead with each observable action, no matter how large or small.

Your inbox policy is full of observable action. How quickly does he respond? Did she read the whole mail? Who did they CC:? Why does he sign some mails, but not others?

Each micro-transaction I performed in my inbox had the ability to collectively affect my reputation as a leader. Worse was the realization that if P0s could fall through the cracks, how many P1, P2, and P3s did I drop? The answer is a painful “a lot.”

With these two punches to the stomach in mind, I rebooted my inbox during the holidays with these fixes. Some are essential and some are personal, but I believe all are valuable.

1. Anything more than ten or so emails in your inbox might as well be a bajillion. I now practice inbox Close-to-Zero. As each email arrives, I act if I need to and then I archive and if I can’t act immediately, I determine if I am likely to act today. If the answer is yes, I leave it in my inbox. If the answer is no, it moves to Asana and is then archived.
2. Stop hoarding. Start archiving For mails where I don’t need to act, I read the whole mail and move it to my archive folder. If I can’t read the whole mail, but need to, it stays in the inbox. Otherwise, the mail is sent to the archive. The goal with both this and the previous rule is to decrease cognitive load. I should be able to look at my inbox and have a good understanding of what is important today. Not yesterday, not a week ago, but today.
3. Use conversation/threaded view. I’ve turned this feature on and off in my various email clients over the years, mostly because of a perceived performance hit when it’s enabled, but it is now remains permanently on. With my aggressive archiving policy and piles’o’email, the conversation view gracefully brings back all the context I need when I invariable dig into my archive to refresh my memory.
4. A strict to-do transfer policy. As I alluded to above, the protocol by which a mail becomes a to-do is well defined. Just about everything that can’t be acted on immediately is placed in the to-do system, except for a short list of mail that I’ve planned to handle that day. If those mails exist at the end of the day, they are moved to Asana. No exceptions.

Small Heroic Acts of Efficiency

Your day as a leader is full of very small decisions. Speak up in that meeting? Embrace serendipity and talk to the random person in the hallway? Answer that email? These very small decisions collectively send signal to the company regarding who you are and what you believe. Your team is watching you – always – because you are their leader.

An efficient inbox policy doesn’t make you a good leader. In fact, it’s expected. Whether you like it or not, progress often stalls while they’re waiting for your response. You, as a leader, have the ability to create a huge amount of organizational consternation simply by not getting completely through your inbox efficiently on a daily basis.

As a nerd afflicted with “Not Invented Here” I like to architect and build systems from the ground up because I tell myself that I like to learn, but I’m often simply stubborn. Uh, I could build that. This stubbornness unfortunately often makes me beholden to the things I build because, well, I built them. As a leader, I need to be willing to throw away cherished things that aren’t capable of evolving with me and I need to listen to the helpful advice others so I can better focus on getting shit done.

[Warning: rant ahead. Slow to impulse power, Mr. Sulu.]

Ever since I've been responsible for user-facing applications -- which is probably since the early Jurassic period -- and ever since I've been using pentesters on those apps, which was probably two seconds after the Jurassic was over -- I've run into the same problem, over and over again.

It's the ridiculous security trope that "username and password feedback is bad."

It's one of the first things that a pentester points out: you can find out valid email addresses or usernames by putting in a bad one and looking at the response. Yes, I know this to be the case.

IT'S ON PURPOSE.

Anyone who has had to provide user support on an application knows how much of that burden is due to users forgetting their usernames, or forgetting which email address they used. Remember: you have one application. The user may have dozens or hundreds of accounts in applications across the Internet, some of which they may use only once in a few years. It's unrealistic to expect them to have been writing down which usernames, email addresses and passwords they've been using since the '90s (especially if they were assigned those usernames - remember when that was a fad?). Unless you think it's okay for them to have saved everything in their browser ... no? I didn't think so.

It's bad enough when they get a clear message saying "We've never heard of you," and they're sure that they do have an account on that system.

Can you imagine how much worse the support load gets, and how much more frustrating it is for the user, if the application refuses to tell them what's wrong?

We may or may not have sent a password reset email to the address you typed in. Even if we sent one, you may not be registered on our system, so the password won't do you any good. Ha ha ha. Take THAT, HaXX0rz!!!1

If you want to prevent user enumeration attacks, you had better have a good alternative in mind. You CANNOT forget the real reason the system is there, and what that user understands and needs in order to use it. If you can't suggest anything that helps, then you are myopic in the extreme, and you're probably just playing reindeer games with other hackers, not contributing usefully to the business that hired you.

Treating username feedback as evil is just playing into the "security by obscurity" mindset. If your system can't withstand attacks by someone who knows a valid username or email address, then you have MUCH bigger problems to solve. Throwing your users under the bus because it's easier for YOU is not the way to solve them.

Thank you for listening.

»Ich will jedenfalls auf dieses Problem aufmerksam machen: Sicherheitsbedürfnisse sind strukturell unstillbar. Es ist gegen das Argument ‘Morgen kann vielleicht etwas passieren’ kein Kraut gewachsen.«

— Winfried Hassemer im Streitgespräch mit Wolfgang Schäuble (via Telepolis)

Zu kurz gedacht wäre allerdings, dies – und die Schlussfolgerung, dass man Grenzen setzen müsse – nur auf staatliche Sicherheitsgesetze, -behörden und -projekte zu beziehen. Der Satz gilt in alle Richtungen und für alle Sicherheitsbedürfnisse, also auch zum Beispiel für den Ruf nach mehr Datenschutz, mehr Verschlüsselung, weniger NSA und so weiter.

Morgen kann vielleicht etwas passieren. Das ist kein ausreichender Grund, auf Segnungen des Internet-Zeitalters zu verzichten, auch wenn sie Google, Facebook oder Cloud Computing heißen. Es ist nicht mal ein ausreichender Grund, sich anders zu verhalten und etwa amerikanische Dienstleister zu meiden, öfter zu verschlüsseln oder Datenpakete anders zu routen.

Morgen kann vielleicht etwas passieren. Etwas dagegen zu tun lohnt sich nur, wenn man sein individuelles Risiko nennenswert reduziert und der Aufwand im Verhältnis zur Risikoreduktion steht. Deswegen erlaube ich mir, die Snowden-Enthüllungen mit Interesse zur Kenntnis zu nehmen, in meinem alltäglichen Verhalten aber nicht weiter darauf zu reagieren. Ich habe keinerlei Anhaltspunkte dafür, dass die NSA mein Leben beeinflusst, folglich lohnt es sich auch nicht, individuelle Maßnahmen zu ergreifen.

Filed under: Bedrohung, Begriffe, Datenschutz, Property Degrees, Risiko, Security, Spackeria