Blog

Grafik: Book vs Internet 1800 - 2000 im Books Ngram Viewer: Gab es um 1900 schon mal ein Internet? :-)

Hintergrund der Artikel in der NZZ bildet ein Paper in Science, in welchem gezeigt wird, wie die gewaltige Datenmenge der von Google digitalisierten Bücher mit quantitativen Methoden für die Forschung nutzbar gemacht werden kann.

Vor gut zwei Wochen berichtete bereits der Economist über das Paper. So konnte man lesen, mit welchen Problemen sich die Wissenschaftler bei der statistischen Analyse von Texten herumzuschlagen haben (Schreibfehler, Daten, Akronymen). Auch ein paar interessante Erkenntnisse bezüglich des Umfangs des Wortschatzes und dessen Abdeckung in Wörterbüchern wurden erwähnt.

In der NZZ findet sich im Teil "Forschung und Technik" ein Artikel, welcher auf die interessanten Aspekte des wissenschaftlichen Aufsatzes eingeht, in "Meinung & Debatten" und dem Feuilleton finden sich erstaunlich kulturpessimistische und ablehnende Artikel. Im Grundtenor wird kritisiert, dass Texte so nicht mehr gelesen sondern nur noch benutzt würden (suchen statt lesen).

"Das genaue und emphatische Lesen (man kann es auch zweckfreies Lesen nennen) dürfte in den letzten Jahren etwas aus der Mode gekommen sein. Auf dem Vormarsch dagegen befinden sich die Benutzer der Texte."

Wer so argumentiert, der nimmt die wichtigste Motivation ein Buch zu lesen nicht ernst: das Lesevergnügen. Natürlich ist die Volltextsuche nichts anderes als ein Werkzeug um Inhalte zu kategorisieren. Solche Kategorisierungen gab es in Bibliotheken schon immer; keiner wäre jedoch auf die Idee gekommen, das Suchen im Register dem Lesen eines Buches vorzuziehen. Wo bliebe da der Lesespass!

Ganz unabhängig davon ob die von den Autoren des Science-Papers postulierte neue Forschungsrichtung names "Culturomics" jemals Früchte tragen wird, die Digitalisierung, Indexierung und quantitative Erschliessung von Texten ist auf jeden Fall sehr positiv zu bewerten.

Werden Texte und Daten online verfügbar gemacht, so kann man von einer Demokratisierung des Wissens sprechen. Ich als Laie kann nun - auch ohne das Gesamtwerk eines Autors zu kennen - dessen Werk thematisch durchforsten. Natürlich bin ich so noch weit von einem tieferen Verständnis entfernt, die Eintrittshürde aber sinkt. Auch für diese Demokratisierungsthese spricht die ablehnende Haltung der Feuilleton-Leute: sie verhalten sich als würde ungebetene Gäste in den Garten, welchen sie bisher sorgsam gehegt und gepflegt haben, eindringen. Culturomics bringt neue Forscher und damit neue Konkurrenz in die Geisteswissenschaften.

Mit den neuen Methoden der Culturomics lassen ganz andere Fragestellungen untersuchen als mit der klassischen Hermeneutik. Für die nach Erkenntnis strebe Wissenschaft ist dies per se ein Gewinn.

Schliesslich singt der NZZ-Author das altbekannte Lied der Probleme der Haltbarkeit von digitalen Texten. Im Falle von Google Books ist es technisch gesehen aber Unsinn von der beschränkten Haltbarkeit von Datenträgern zu schreiben. Die Daten sind nicht auf einem einzelnen, vom Verfall bedrohten, Datenträger (CD) gespeichert, sondern in der Cloud. Natürlich liegen auch der Cloud physische Datenträger zu Grunde, Speicherkapazitäten werden da aber viel dezentraler und nach Bedarf bezogen. 
Beim Brand der klassischen Bibliothek von Alexandria ging sehr viel Wissen verloren. Dank dem Digitalisierungsprojekt von Google sind heute viele bereits vergriffene Bücher wieder verfügbar und können auch durch eine Feuersbrunst nicht zerstört werden.

Die Digitalisierung von Texten ist ein Projekt der Fortschritts!

Grafik: NZZ vs FAZ 1800 - 2000 im Books Ngram Viewer

http://ngrams.googlelabs.com/
http://www.culturomics.org/

http://www.economist.com/node/17730198
http://www.nzz.ch/nachrichten/startseite/suchen_statt_lesen_1.8925645.html

repoze.bfg + Pylons = Pyramid

repoze.bfg ist ein mächtiges zugleich aber einfaches Framework und wir freuen uns daher sehr auf Pyramid.
Ganz in der repoze.bfg-Tradition bietet Pyramid eine umfassende, stets aktuelle Dokumentation: http://docs.pylonshq.com/pyramid/dev

Die nächsten Projekte werden wir bereits auf Pyramid starten und unsere bisherigen repoze.bfg Applikationen nach dem Erscheinen von Pyramid 1.0 auf die neue code base umstellen.

Die Ankündigung von Pyramid: http://lists.repoze.org/pipermail/repoze-dev/2010-November/003619.html

P.S. Offenbar wurden auch unwahre Gerüchte verbreitet, welchen das Pyramid-Team mit aller Entschiedenheit entgegen tritt :-): http://docs.pylonsproject.org/denials/pyramid.html

Jeffrey Pfeffer und Robert I. Sutton beschreiben in "The Knowing-Doing-Gap" ein Phänomen, das wir alle nur zu gut kennen. Oft ist es schwierig, etwas wirklich in die Tat umzusetzen und es entsteht eine Kluft zwischen dem Wissen was zu tun ist und der Umsetzung.

Pfeffer und Sutton beschreiben die Ursachen für endemische Umsetzungsdefizite:

1. Talk and Action

One of the main barriers to turning knowledge into action is the tendency to equate talking about something with actually doing something about it. In many organizations, there is an unspoken but powerful belief that once a decision is made to do something, no additional work is needed to make sure it is implemented!

Tut doch mal richtig gut, das in dieser Deutlichkeit zu lesen! Dass Worte gegenüber Taten im Vorteil sind, scheint mit sozialer Interaktion zu tun zu haben. Auch wenn wir eine Person an ihren Taten messen sollten, tun wir es meistens  an ihren Worten.

We should form our impressions of others based on how well they perform, how well they get things accomplished, and what they contribute to the organization through their actions. But often we form our impressions of others based on how smart they seem. Appearing smart is mostly accomplished by sounding smart; being confident, articulate, eloquent, and filled with interesting information and ideas; and having a good vocabulary.

Auch das sitzt! Es kommt aber noch schlimmer, denn das Streben danach von den andern als intelligent wahrgenommen zu werden, wird sogar destruktiv und verhindert gute neue Ideen:

Interestingly enough, for getting anything done in organizations, one of the best ways of sounding smart is to be critical of the ideas of other people. It is always possible to find a reason to say no to some idea or proposal. People in many organizations are remarkably skilled at making excuses about why something cannot be done, why something will not work, and why the present condition is better than trying something new.

Akzentuiert wird diese Tendenz zusätzlich durch die Tatsache, dass Worte sofort bewertbar sind, die Umsetzung jedoch Zeit braucht. Wenn also der Zeithorizont kurz ist, sind die "Taten" gegenüber Worten immer im Nachteil, denn etwas auch zu tun und nicht nur davon zu sprechen braucht Zeit.
Zudem versuchen Leute auf andere dadurch einen guten Eindruck zu machen, indem sich sich einer komplexen Sprache bedienen. Einfache Ideen hätten aber eine grösse Chance verwirklicht zu werden, weil sie einfacher zu erklären und transparenter sind daher weniger einfach durch Bremser bekämpft werden können.

2. Memory and Thinking

Memory often serves as a substitute for thinking. People often do what has always been done without reflecting.

Der Punkt scheint mir weniger neu. Interessanter wird es wenn die Autoren konkreter werden und feststellen, dass Menschen - besonders unter Zeitdruck - dazu neigen Evidenz, welche ihrer eigenen Einschätzung entgegensteht zu verdrängen.

3. Fear and Knowlege

It is easier to encourage people to question conventional wisdom and to create dramatic breaks with the past, in an atmosphere of trust and safety.

Wer Neues wagt macht Fehler. Am sichersten ist es immer gar nichts zu tun und auf Tauchstation zu gehen. Das Umfeld muss also so sein, dass jeder Fehler machen darf.

4. Measurement and Judgment

Measures focus attention on what is measured. Measures affect what people do, as well as what they notice and ignore. What is measured is presumed to be important. What gets measured gets done. What is not measured tends to be ignored.

Auch das Problem ist hinreichend bekannt. In der Leistungsbeurteilung wird Quantifizierbares bevorteilt. Dies kann zu falschen Anreizen und sogar dazu führen, dass  Angestellte viel Zeit darauf verwenden Indikatoren zu manipulieren. Nicht explizit erwähnen Peffer und Sutton die Verdränung der intrinsischen Motivation, die auch durch ein falsches Leistungsmessungssystem verursacht werden kann.

5. Internal Competition

Competition inhibits learning and creativity. Instead of focusing on the task at hand, people focus too heavily on what competitors are doing, on how well they are performing in comparison, and on the reactions of third parties such as leaders and peers who are the audience for the contest. Moreover, when a task is difficult or complex and requires help and sharing ideas with others, internal competition is especially destructive.

Fazit: Small is beautiful!

Alle diese hemmenden Faktoren dürften mit der Organisationsgrösse zunehmen. Peffer und Sutton weisen denn auch explizit auf die Notwendigkeit der Dezentralisierung hin, gehen aber nicht soweit eine radikale Verkleinerung grosser Organisationen zu fordern. Kleine Firmen können sich den Overhead, der ausschliesslich Worte ohne Taten produziert, schlichtweg nicht leisten.

Unsere Kritik an der Art und Weise wie Service-Provider die suisseID in ihre Internet-Applikationen integrieren kann man hier nachlesen.

Die eigentlichen Stärken der suisseID liessen sich nützen, wenn man sich konsequent an der Kernidee einer Authentifizierung mittels einer Trusted Third Party orientiert.

Trusted Third Party

1. Als Endbenutzer vertraue ich nur meinem Identity Provider (IdP): Natürlich weiss ich wer das ist (im Moment QuoVadis und SwissSign).
2. Als Service Provider vertraue ich nur den Identity Providern.

Daraus leitet sich Folgendes ab:

1. Als Endbenutzer gebe ich Daten nur über meinen IdP frei. Dies geschiet immer über die Website des IdP und lasse nur diesen mein Zertifikat auslesen.
2. Als Service Provider lese ich nie ein Zertikat direkt aus, sondern leite den Benutzer lediglich auf den IdP weiter und bekomme die angefragten Informationen - nach der Zustimmung des Endbenutzers - vom IdP.

Nun ist aber auch die rein zertifikats-basierte Authentifizierung nach den Einsatzszenarien der suisseID zulässig.
Für Internet-Applikationen scheint uns dies nicht der richtige Weg, weil:

1. Der Endbenutzer sein Zertifikat nicht einfach jeder Internetseite zeigen sollte (vgl. unseren Beitrag dazu).
2. Der Service Provider gar nicht zu wissen braucht, auf welche Art sich der Benutzer beim IdP identifiziert.

Identitätsprovider können für mehr Sicherheit sorgen

Und jetzt kommt der Clou: Es liegt eigentlich beim Identitätsprovider die Sicherheit der Authentifizierung zu erhöhen: er kann zum Beispiel zusätzlich ein One Time Token per SMS an den Benutzer schicken (wie das Banken schon machen).
Und es kommt noch besser: Damit lösen wir auch das unten stehende Problem.

Offenbar arbeitet SwissSign bereits an suisseID in der Cloud, wo mein Zertifikat also beim IdP liegen würde und nicht mehr physisch bei mir. Dazu müsste dann wohl in jedem Fall ein Verfahren wie ein One Time Token über SMS oder etwas Ähnliches dazu kommen.

Service Provider, die eine echte Authentifizierung über den IdP machen, müssen dabei an ihrer Implementation gar nichts ändern.

Keine rein zertifikats-basierten Anmeldungen mehr!

Die Service-Provider sollen aufhören direkt Zertifikate auszulesen. Das verbaut uns allen den oben beschriebenen Weg. Das SECO hätte es einfach in der Hand (gehabt), Subventionen für Webapplikationen nur für die Authentifizierung via einen IdP zu sprechen. Wir sehen wirklich nicht ein was man bei einer Webapplikationen durch die rein zertifikatsbasierte Anmeldung gewinnt; man muss für jede Anfrage so oder so einen Abgleich mit Certificate Revocation List (CRL) machen. Bleibt einzig der Punkt, dass die Email-Adresse leider nicht zu den Core Attributes gehört und nur auf dem Zertifikat gespeichert ist. Da viele Service Provider genau an dieser interessiert sind, wäre es wohl besser die Spezifikation in diesem Punkt zu ändern.

On mac you want to install git svn:

"sudo port install git-core +svn"

Next you create an authors file (authors.txt) to convert the svn contributors and keep the full history:

buck = Buck Mulligan <buck@seantis.ch>
hans = Hans Castrop <hans@seantis.ch>

The simplest command if only want to convert your trunk:

git svn clone --no-metadata -A authors.txt https://svn.example.com/code/trunk   

To convert branches/tags see: http://pauldowman.com/2008/07/26/how-to-convert-from-subversion-to-git/

HB-ZKT der BOHAG AG

Gesetzliche Grundlagen

Helipiloten zeichnen in ihrem Flugbuch die Rotor Turning Time auf. Die entsprechende Weisung gilt seit Januar 2007 und wurde vom BAZL im Zusammenhang mit der Einführung von JAR-FCL 2 erlassen.

Flight time ist nach JAR-FCL 2.001 definiert als:

The total time from the moment a helicopter’s rotor blades start turning until the moment the helicopter finally comes to rest at the end of the flight, and the rotor blades are stopped.

Block time ist gemäss der Verordnung des UVEK über die Betriebsregeln im gewerbsmässigen Luftverkehr (748.127.1 PDF) definiert als:

Gesamtzeit zwischen dem erstmaligen Abrollen eines Luftfahrzeugs aus seiner Parkposition zum Zweck des Startens bis zum Stillstand an der zugewiesenen Parkposition und bis alle Triebwerke abgestellt sind.
Bei Hubschraubern gilt als Blockzeit die Gesamtzeit zwischen der erstmaligen Fortbewegung eines Hubschraubers zum Zwecke des Abfluges und dem Stillstand nach Beendigung des Fluges.

Rotor Turning Time / Block Time

Aus den zwei Definitionen ergeben sich folgende Implikationen:

• Die Block Time ist kürzer als Rotor Turning Time (Motor läuft schon und Pilot geht z.B. noch die Checkliste durch.)
• Bei einem Flug mit mehrmaligem Absetzen „läuft“ die Rotor Turning Time weiter, die Blockzeit kann aber unterbrochen werden, wenn der Heli auf den Kufen steht.
• Für Currency Limitation ist einzig die Block Time relevant.

Umsetzung in myControl

MyControl testen: https://www.mycontrol.aero

In myControl hat der Helipilot zusätzlich zur Rotor Turning Time für jeden Flug die Möglichkeit die Block Time zu loggen. Auf dem PDF-Ausdruck seines Flugbuches wird die Rotor Turning Time ausgewiesen, die Block Time wird ausschliesslich für die Berechung der Currency Limitation verwendet.

Nachtrag (12.10.2010) Es geht uns in dieser Darstellung einzig um die Art und Weise wie Service-Provider die Authentifizierung implementieren. Es geht nicht um eine generelle Kritik an der SuisseID. Wir sind auch bemüht unsere Darstellung nach Kommentaren entsprechend zu ergänzen und zu präzisieren. Vielen Dank für die gute Diskussion!

Vorbemerkung: Es geht uns hier nicht um eine grundlegende Kritik an zertifikatbasierter Authentifizierung oder SAML2, sondern darum wie SuisseID-Authentifizierungen implementiert sind.

Ergänzung (14.10.2010): Die SuisseID sieht folgende Einsatzszenarien vor:

1. Authentifizierung rein Zertifikats-basiert
2. Authentifizierung via einen IdP (Identity Provider)
3. Abfrage von Attributen der SuisseID via einen IdP

Auch Kombinationen sind zulässig. Die direkte Authentifizierung mittels des SuisseID-Zertifikates scheint uns für Internetanwendungen, aus den unten genannten Gründen, nach wie vor problematisch.

Vielen Dank für den entsprechenden Kommentar!

Ablauf 1: Wie es sein sollte!

Hier mal der Prozess der Authentifizierung mit SuisseID für unsere Plone-Site. Ich sehe  in der rechten Spalte eine Login-Box, in der ich mich mit meiner SuisseID anmelden kann.

Im Dropdown muss ich den SuisseID-Provider wählen. Zur Zeit vergeben SwissSign und QuoVadis SuisseIDs. Wie wir später sehen werden ist es wichtig, dass ich als Benutzer diese Auswahl selbst treffe und diese nicht irgendwie automatisch passiert.

Nachdem ich meinen Provider gewählt habe, werde ich auf die Site von SwissSign weitergeleitet. Da ich mich nun bei SwissSign authentifizieren muss, fragt mich mein Browser nach dem Passwort meiner SuisseID.

Ich gebe dieses ein und sehe nun ein weiteres Fenster, das mir mitteilt, an wen mein Zertifikat und damit auch einige persönliche Daten übermittelt werden. Ich sehe, dass es sich beim Empfänger um SwissSign handelt und da ich meinem Identitätsprovider vertraue, bin ich mit der Übermittlung einverstanden.

Als Benutzer werde ich nun in der Adressbar des Browsers schauen, ob ich wirklich auf der Site von SwissSign bin. Die grüne Adresszeile zeigt mir an, dass dies der Fall ist und dass die Site per SSL verschlüsselt ist. Es ist zentral, dass diese Seite bei SwissSign läuft. Man kann diesen Schritt nicht überspringen, da ich nur meinem eigenen Identitätsprovider vetraue und damit nur dieser mich authentifizieren kann und darf.

Ich kann nun auch wählen welche Infos (Vorname, Nachname) ich zurück an unsere Plone Site übertragen will. Ich klicke also auf "Freigeben" und komme zurück auf die Plone Site wo ich nun angemeldet bin. Wenn ich hier "Abbrechen" klicke, dann werden überhaupt keine Daten an den anfragenden Dienst übermittelt.

"Bin ich schon drin?" Ja, ich bin nun bei der Plone Site angemeldet. Alles bestens also! So bin ich auf der absolut sicheren Seite, weil ich nur meinem Provider Zugriff auf meine Daten gegeben habe.

Ablauf 2: Wie es besser nicht sein sollte!

Nun schauen wir uns ein Beispiel an, welches gegen die Idee dieser Authentifizierung - seine Daten übermittelt man ausschliesslich an seinen Provider  - verstösst. Als zweites Beispiel schauen wir uns eine Applikation an, wo die Authentifizierung anders abläuft. (Korrektur 14.10.2010 vgl. Kommentar)

Ich kicke auf den SuisseID-Button und HOPPLA werde nach dem Passwort meines Zertifikates gefragt!

Der Weinladen verlangt also nach meinem Zertifikat. Das finde ich nicht so toll, denn eigentlich wollte ich meine email-Adresse und meinen vollen Namen nicht an den Weinshop (bzw. das SECO) übermitteln, da sich diese Informationen jedoch im Zertifikat befinden, werden sie ans SECO übermittelt!

Eigentlich sollte der Weinshop jedoch nur mein Alter überprüfen. Dazu werde ich korrekterweise auf die Seite meines Identitätsproviders (in diesem Fall SwissSign) weitergeleitet:

Falls ich der Datenübermittlung zustimme, sendet SwissSign nur gerade diese Information (Nachweis dass ich älter als 18 bin) an den Weinshop. Was in diesem Ablauf nicht optimal läuft, ist dass der Wineshop selbst auf mein Zertifikat zugreift, um mir die manuelle Auswahl des Providers zu ersparen. Indem er das jedoch tut, wird gleichzeitig auch meine Email Adresse (und mein Arbeitgeber, der auf meinem persönlichen Zertifikat gespeichert ist) ausgelesen. Die Idee hinter einem Verfahren wie der SuisseID ist, dass ich nur meinem Indentitätsprovider voll vetrauen muss, und dieser vor jeder Datenübermittlung meine Zustimmung einholt. Somit sollte ich auch nur meinem Identitätsprovider Zugriff auf mein Authentifizierungszertifikat gewähren.

Verlangt jedoch bereits der Weinshop Zugriff auf mein Zertifikat und ich die darin enthaltenen persönlichen Daten nicht an ihn übermitteln will, so bleibt nur die Möglichkeit die Authentifizierung mittels SuisseID  abzubrechen!

Ich muss zudem die Sicherheitseinstellungen in meinem Browser so setzen, dass ich jedes mal explizit ein Zertifikat auswählen möchte, falls eine Website ein solches verlangt. Ansonsten kann jede Website mittels SSL auf alle Daten meines Zertifikats zugreifen ohne dass ich überhaupt etwas davon bemerke. Man könnte jetzt natürlich argumentieren, dass auf meinem Zertifikat keine wirklich heiklen Daten liegen, sondern dass diese bei meinem Indentitätsprovider hinterlegt sind. Das stimmt aber nur teilweise: Mein amtlich beglaubigter Name, meine Email Adresse und meine Organisation sagen doch schon einiges über mich aus. Ich will diese Infos nicht irgendeine beliebige Website schicken!

(Ergänzung 14.10.2010 vgl. Kommentar) Es handelt sich hier um eine Kombination der rein zertifikatsbasierten Authentifizierung mit der Abfrage von personenbezogenen Attributen beim IdP. Dies ist zwar zulässig, die Authentifizierung wäre jedoch wie in Ablauf 1 besser auch über den Identity Provider gelaufen, so hätte ich mein Zertifikat nur diesem zeigen müssen.

Ablauf 3: Wie es definitiv nicht sein sollte

Drittes Beispiel ist der Authentifizierungsprozess bei www.amazee.com.

Ich klicke als wiederum auf den SuisseID Button und werde - wie schon beim Weinshop - nach dem Passwort meines Zertifikates gefragt. Bemerkenswert ist hier, dass ich auf der Site von amazee bin und ich meine Daten an Clavid übermitteln werden sollen! Mit Clavid habe ich aber gar nichts am Hut, es handelt sich weder um die Seite bei der ich mich anmelden möchte (amazee) noch meinen Identitätsprovider (SwissSign). Trotzdem will Clavid auf mein Zertifikat und damit meine Daten zugreifen.

Man könnte, wie bereits beim zweiten Prozess, wiederum argumentieren, dass diese Daten nicht wirklich heikel sind.

Das wirklich bemerkenswerte passiert jedoch im nächsten Schritt. Ich komme nun auf eine Site die zwar derjenigen von SwissSign ähnlich sieht, hinter der sich aber Clavid versteckt!

An diesem Punkt ist für mich als sicherheitsbewusster Benutzer definitiv Feierabend! Ich sollte hier auf der Site meines Providers (SwissSign) sein. Clavid kenne ich nicht und vertraue der Seite daher auch nicht. Clavid übernimmt hier also die Rolle meines Identitätsproviders, obwohl ich für die Authentifizerung nur meinem wirklichen Identitätsprovider (SwissSign) vertrauen sollte. Clavid liest als Drittpartei also nicht nur mein Zerifikat aus sondern gibt sich auch noch als Identitätsprovider aus.

Die grundlegende Idee hinter dem der SuisseID zu Grunde liegenden Authentifizierungsverfahren besteht darin, dass ich mich nur auf der Seite meines Identitätsproviders (mit einem Zertifikat oder Passwort) anmelde und mich deshalb auch wirklich auf dieser Seite befinden muss (was ich an Hand der URL und des Zertifikat überprüfen kann). Dadurch ist der Prozess für den Benutzer transparent. Im Fall von amazee/Clavid ist jedoch völlig unklar ob und wie ich bei meinem Identitätsprovider authentifiziert werden. Bei Clavid handelt es sich nicht um einem authorisierten SuisseID Identitätsprovider und trotzdem übernimmt der Dienst meine Authentifizierung. Zusätzlich kann Clavid auch meine persönlichen Daten einsehen, obwohl ich nur der Übermittlung an amazee zugestimmt habe.

Entgegen aller meiner Grundsätze klicke ich mal auf OK und tatsächlich habe ich nun einen Account bei amazee.

(Ergänzung 14.10.2010 vgl. Kommentar) Es handelt sich hier (amazee möge mich korrigieren) um eine rein zertifikatsbasierte Authentifizierung, auch wenn die Seite für die "Freigabe" der Daten den entsprechenden Seiten der Identity Provider zum verwechseln ähnlich sieht.

Fazit - Bei der Implementierung die Idee des SuisseID-Prinzip (SAML2 oder auch OpenID) ernst nehmen

Die unser Prozess für die Anmeldung mit der SuisseID zeigt, dass man das Zertifikat des Benutzers auf Seiten des anfragenden Services weder auslesen muss noch soll. Das Zertifikat wird erst auf der SSL-Seite von SwissSign ausgelesen. Unsere Plone Seite muss gar nicht wissen wie sich der Benutzer bei SwissSign oder QuoVadis authentifiziert. Das kann über ein Passwort, ein One Time Token oder eben ein Zertifikat geschehen. Wie das geschieht liegt aber in der Verantwortung des Identitätsproviders. Dem Serviceprovider (unsere Plone Seite) ist die Art der Authentifizierung egal er muss nur dem Identitätsprovider vetrauen (dass dieser eine sichere Authentifizierung durchführt). Das ist die grundlegende Idee hiner SAML2 oder auch OpenID.

Was der Idee widerspricht:

• Wenn jeder Serviceprovider rasch das Zertifikat des Benutzers ausliest (sei es auch nur um auf den passenden Provider weiterzuleiten). Der Endbenutzer muss so "erzogen" werden, dass er mit seinem Zertifikat sehr sorgfältig umgeht. Wenn nun inflationär im Browser die Frage nach dem Zugriff kommt, so legt er genau diese Vorsicht ab. Immer wenn er Zugriff auf sein Zertifikat gibt, so kann der Service-Provider persönliche Angaben wie die email-Adresse auslesen. Der Benutzer hat nicht wirklich eine Möglichkeit zu sagen, dass er diese Angabe nicht machen will (mehr zum Thema SuisseID und email-Adresse ein anderes Mal).
• Es dürfte keine "Pseudo"-Identitätsprovider wie Clavid geben, denn ich darf nur meinem Provider vertrauen.
• Was macht Clavid wirklich? Der Ablauf ist für uns unklar und intransparent und entspricht schon daher nicht der grundlegenden Idee des Protokolls

myControl Flyer

Dank dem Feedback unserer Benutzer können wir myControl stetig weiterentwickeln und um neue Funktionalitäten erweitern. Zur Zeit arbeiten wir an einem Duty Time Tracking Tool.

https://www.mycontrol.ch

Download Flyer

SuisseID USB Stick

Nachdem die Weltwoche vor ein paar Wochen, mit einem Gastbeitrag des Bloggers Andreas Von Gunten, vorgelegt hat, bringt die NZZ die ihr eigene gelassene Sachlichkeit zurück in die Debatte.

Natürlich haben die Kritiker nicht unrecht, wenn sie bemängeln, dass Klasse-2-Leser (d.h. ohne gesichertes Display), gegen Trojanerangriffe nicht schützen. Dies bedingt aber, dass sich auf dem Computer des Benutzers bereits ein Trojaner eingenistet hat. Jeder Benutzer hat ein grosses Interesse daran, dies durch Antiviren-Programme zu verhindern.

Die NZZ bringt es im Kommentar auf den Punkt: "Niemand käme auf die Idee, dem Hersteller eines Türschlosses Vorwürfe zu machen, weil Dinge gestohlen wurden in einem Haus, bei dem alle Fenster sperrangelweit offen stehen. Wo es um Türen und Fenster geht, wird niemand perfekte Sicherheit verlangen, sondern nur, dass der Aufwand für die Überwindung dieser Barrieren höher ist als der Ertrag, den sich ein Einbrecher erhoffen darf."

http://www.nzz.ch/nachrichten/digital/identitaetskrise_1.7572142.html

http://www.weltwoche.ch/onlineexklusiv/aktuell/2010-05-04-suisseid-teure-loesung-fuer-nicht-existierende-probleme.html

Auch ein Heer von Businessanalysten, Software-Architekten und der Trend zu Outsourcing in Niedriglohnländer (Indien, China) ändern nichts daran, dass Software von Programmieren geschrieben wird. Wenn wir nach Gründen für die bessere Qualität von Open Source Code suchen, müssen wir uns auf die Programmierer konzentrieren:

• Freude, Leidenschaft
  Open Source Programmierer arbeiten aus Freude und Leidenschaft an einem Projekt, sie werden nicht von ihrem Chef dazu verknurrt.
• Handwerk
  Programmierer in der Open Source Welt verstehen sich als Handwerker und wollen eine Sache ihrer selbst willen gut machen. In einem Open Source Projekt haben sie die nötige Muse (sprich Zeit) dafür. Die Arbeitsweise des Software-Handwerkers ist durch das zeitgleiche Lösen und Finden von neuen Problemen gekennzeichnet. Er ist kein Akkord-Maurer, der - ohne grosse gedankliche Eigenleistung - die vom Architekten geplante Mauer in möglichst kurzer Zeit hochzieht.
• Peer Review
  Das Argument ist hinlänglich diskutiert: Da der Quellcode offen liegt werden Fehler viel schneller erkannt.
• Erfahrung: "Programmieren als Jugendsünde"
  Leider scheint es so, dass Programmieren der Jugend vorbehalten ist. Programmierer mit grauen Schläfen sind teurer als ihre jüngeren Kollegen. Da Arbeitgeber offenbar nicht bereit sind, Erfahrung im Programmieren mit einem höheren Lohn zu würdigen,  wechseln Programmierer nach ein paar Jahren in einen Management-Job. Die NZZ schreibt dazu: "Dass ein Programmierer bei der Lösung von grösseren Problemen in der Regel keine zweite Chance erhält, vermag vielleicht zu erklären, warum sich aus der Sicht des Anwenders Software oftmals unfertig, unausgereift, unstabil anfühlt, pubertär."
  Seinem Open Source Projekt bleibt man jahrelang verbunden.
• Code steht im Zentrum
  Bei Open Source steht der Code im Zentrum, man konzentriert sich auf guten Code. Elegante Lösungen eines Problems werden in der Community entsprechend gewürdigt.
• Kein Outsourcing
  Würde ein Open Source Projekt je auf die Idee kommen seine Kern-Aktivität, also das Programmieren, auszulagern?

Dies führt dazu, dass der Einsatz von Open Source in Unternehmen nicht mehr in erster Linie aus Kostengründen sondern aufgrund besserer Qualität geschieht.

http://www.silicon.de/cio/strategie/0,39038989,41536153,00/qualitaet_hauptargument_fuer_open_source.htm