neunetz.com

Zur Zeit geht wieder ein Dienst durch die Webgeekszene, bei dem ich nur mit dem Kopf schütteln kann. Socialthing! ist ein Lifestream-Dienst ähnlich Friendfeed (und dutzende andere). Man kann also seine fragmentierte Onlinepersönlichkeit hier zusammenführen.

Der Twist: Im Gegensatz zu Friendfeed das ausschließlich auf APIs und RSS-Feeds setzt, muss man bei Socialthing! seine Logindaten der aggregierten Dienste eingeben.

!

Hallo? Noch ganz knusper?

Ich finde die Unart, mit Passwörter abzufragen ziemlich, na, bedenklich. Es ist erstaunlich, dass dieser Vorgang mittlerweile als “üblich” angesehen wird.

Zum Glück wurde mit diesen Passwörtern, die man an dritte Webdienste weitergibt wenigstens noch nie Missbrauch getrieben. Oh, Moment. Da war doch eben erst am Wochenende etwas:

Your Email Password: A True Horror Story About Why We Need Authentication Standards - ReadWriteWeb

Dustin Brooks is a reader of Atwood’s excellent blog Coding Horror and sent Atwood the story of his sleuthing around the app, called G-Archiver.

“It didn’t really have the functionality I was looking for,” Brooks wrote, “but being a programmer myself I used Reflector to take a peek at the source code. What I came across was quite shocking. John Terry, the apparent creator, hard coded his username and password to his gmail account in source code. All right, not the smartest thing in the world to do, but then I noticed that every time a user adds their account to the program to back up their data, it sends and email with their username and password to his personal email box! Having just entered my own information I became concerned.

“I opened up a browser and logged in to gmail using his account information. It still worked.

“Upon getting to the inbox I was greeted with 1,777 emails with account information for everyone who had ever used the software and right at the top was mine. I decided to go ahead and blast every email to the deleted folder and then empty it. I may have accidentally changed the password and security question to something I don’t remember as well, whoops, my bad. I also contacted google to erase this account as I didn’t see a way to delete it myself.”

Die Ironie, dass der Launch von Socialthing und diese Horrorgeschichte quasi fast zusammenfielen, ist auch einem Kommentator auf TC, das die obige Story auch vorher behandelt hatte, nicht entgangen:

I love that this story comes immediately after this:

“These users should have known better than to type their email credentials into a third party service, so sympathy levels are at a minimum.”

I’ll just hop on over to SocialThing! now and enter my credentials (I wouldn’t anyway, but it was just funny).

Besonders bei GMail, an dem ja noch der ganze Rest an Google-Webdiensten hängt, sollte man besonders vorsichtig sein.

Das dürfte auch einer der Hauptgründe gewesen sein, warum Google als erste eine Oauth-ähnliche API veröffentlicht haben.

Dienste, die umfassenden Zugriff auf meine Accounts auf anderen Seiten benötigen, werde ich auch erst nutzen oder ausprobieren, wenn Oauth oder etwas Vergleichbares die Verzahnung zwischen den Seiten auf ein vernünftige Basis stellen. Alles andere ist einfach nur leichtsinnig.

Denn weder vertraue ich jedem dahergelaufenen Webdienst mit pastellfarbenen abgerundeten Ecken, noch will ich den anscheinend sich mittlerweile einbürgernden leichtfertigen Umgang mit Zugangsdaten unterstützen.

also known as die proprietäre Googlealternative, bis OAuth endlich nutzbar wird

Namentlich geht es darum, dass beispielsweise ein Kontaktabgleich zwischen Mail (hier Gmail) und einem Socialirgendwas-Dienst bezüglich sozialer Kontakte nicht über die Herausgabe von Loginname und Passwort läuft sondern über eine Authentifikation über die API.

Was man als Entwickler mit der Contacts Data API machen kann:

# Import a user’s Google contacts into their web or desktop application
# Export their application’s contact list to Google
# Write sync applications for mobile devices or popular, desktop-based contact management applications

Wie das funktioniert:

Instead of the 3rd party application itself asking for the username and password, it asks Google to retrieve that data. Google then uses the AuthSub mechanism to ask the user themselves to login if they aren’t already logged in and asks afterwards if it’s ok for that 3rd party application to access this data.

Das ist soweit schon mal toll und auf jeden Fall wesentlich besser, als die Unart, Logindaten zu fordern und auch einzugeben. Aber eine langfristige Lösung ist das auch nicht, denn:

Wenn OAuth nicht bald aus den Puschen kommt und jeder Dienst (beispielsweise etwa Yahoo und Windows Live Hotmail, beide wesentlich größere Emailanbieter und damit Kontaktdatensilos) folglich anfängt, Google folgend sein eigenes API-Süppchen zu kochen, kann man sich als Entwickler auch gleich einbuddeln.

Mehr zur Contacts Data API:

• auf Programmable Web
• und auf ReadWriteWeb

OpenID scheint dieses Jahr langsam im (Web-)Mainstream anzukommen. Die Meldungen dieses Jahr über große Unternehmen die (zugegeben oft erst einmal halbherzig) OpenID anfangen zu unterstützen, brechen nicht ab. Wenn auch die meisten großen Seiten OpenID nur als Provider nicht als Consumer zunächst unterstützen (heißt man kann sich mit ihren Accountdaten anderenorts einloggen nur bei ihnen anmelden mit einer OpenID geht nicht, siehe hier zur näheren Erklärung).

Markus hat nun vor ein paar Tagen einen interessanten Text über OpenID geschrieben und ist dort besonders auf Probleme eingegangen:

Leider ist openID aber wie eine Kreditkarte bei der man dann auch nicht mehr mit Bargeld bezahlen kann, wenn man in einem Geschäft einmal mit ihr bezahlt hat, und leider kann man den Kreditkartenbetreiber dann auch nicht mehr wechseln.

Er erwähnt dann Delegation als Lösung dieses Problems (Zu Delegation siehe diesen Artikel von Carsten hier auf neunetz.com, außerdem wird im Agenturblog die Bedeutung von Delegation nochmal unterstrichen).

Ein weiterer Punkt, der sich durchsetzen wird mMn, ist, dass sowohl auf Consumer als auch auf Providerbasis unabhängige Emailadressen hinterlegt werden können. Mit diesen lässt sich dann im Notfall der Account sperren, wiederherstellen, whatever.

Markus:

Das Problem mit openID ist nicht, dass es zu Problemen kommen kann, sondern dass die Konsequenzen der Probleme unangenehmer sind als man sie sonst so antrifft.

Das Problem gibt es auch heute schon. Wenn man nämlich zum Beispiel einen Googleaccount hat und alles von Email über Feeds, Bookmarks, Fotos, SocialNetwork (Orkut) und Onlineoffice über Googledienste abwickelt. Deshalb gibt es seit geraumer Zeit die Möglichkeit in den Settings des Googleaccounts weitere Emailadressen neben der Gmail-Adresse zu hinterlegen. Im Falle des Passwortklaus kann man dieses ja nicht zurücksetzen und an Gmail senden lassen..

Außerdem wird es sich beim Großteil der Webdienste einbürgern, dass neben OpenID (oder welches webglobale Loginsystem sich auch durchsetzen mag) immer auch ein seitenexklusives Login angeboten wird, das sich wahlweise nachträglich zum Account hinzufügen lässt. Heißt, man wird die Wahl haben, ob man auf die Seite immer nur via OpenID zugreift oder aus Sicherheitsgründen oder warum auch immer einen separaten Zugang einrichtet. Das würde dann zB auf die sich aus jahrelangem Gebrauch herauskristallisierenden Lieblingsseiten zutreffen. (Ja, die Ironie ist mir durchaus bewusst.)

Oder aber es kommt ganz anders und eine Seite wie Facebook -oder Facebook selbst *gasp*- wird sich zum Rückgrat für das soziale Web entwickeln und mit der Öffnung in alle Richtungen in ein globales Loginsystem mutieren (evolutionieren?). [Das mag noch leicht lächerlich klingen, die Wahrscheinlichkeit dafür ist aber gar nicht so gering.]

Denn ehrlich gesagt: Vor ziemlich genau einem Jahr war ich sehr optimistisch, was OpenID anging. Der große Durchbruch, den ich für 2007 phantasierte, scheint nun dieses Jahr zu kommen. Aber ich sehe keine Lösungen für immer noch bestehende schwerwiegende Probleme:

Nachwievor ist die Usability nicht sonderlich gut -freundlich ausgedrückt. Alles ist viel zu kompliziert und schwer zu durchschauen für Normalnutzer. Datenschutz bleibt ein Problemfeld. Und auch die Securityprobleme sind nicht zu unterschätzen:

The problem(s) with OpenID « The Identity Corner

Dieser Artikel ist mit Vorsicht zu geniessen, da der Verfasser an einem konkurrierenden System zu OpenID arbeitet. Nichtsdestotrotz ist die Fülle an Problemen nicht gerade gering. Inwiefern einige der angesprochenen Probleme mit dem neuen OpenID2.0 behoben sind, kann ich nicht beurteilen. Zumindest kommt OpenID2.0 mit Verschlüsselung. (siehe zu OpenID2.0 auch diesen Artikel auf centernetworks vom November ‘07)

Wie auch immer OpenID sich entwickelt, an einem seitenübergreifenden Identifikationsmechanismus für die Nutzer geht kein Weg vorbei. Die Anzahl nützlicher und damit regelmäßig genutzter Webdienste wird eher noch zu- denn abnehmen. Von nur temporär genutzten bzw. ausgetesteten Seiten ganz zu schweigen. Auch deswegen wird die Webevolution an einem weit verbreiteten Single-SignOn nicht vorbeikommen: Neue Dienste können leichter User akquirieren, wenn sie ihnen den Login so einfach wie möglich machen. Diese Mikrointeressen führen zwangsläufig zu einem Makrozustand der weitgehenden Flächenabdeckung.

Ich hoffe nur, wir implementieren hier nicht einen Standard, der uns in der Zukunft irgendwann aufgrund unzureichend beachteter Probleme in die Knie zwingt; und dann zum Bücken. Das reicht schon in Sachen in Email.

Wer sich für OpenID interessiert, dem sei nochmal die neunetz.com-Artikelserie von Carsten Pötter über OpenID vom letzten Jahr ans Herz gelegt. Carsten betreibt mit Thomas Huhn zusammen die Infoseite Spread OpenID. Thomas Huhn ist unter Anderem bekannt vom deutschen OpenID-Blog OpenID Blog Germany, vom OpenIDDirectory und dem OpenID-Provider meinguter.name.

(Link out like your life depends on it - that’s my motto :))

Tja, der Monat Juli neigt sich unerbittlich seinem regnerischen Ende und ich habe es nicht fertig gebracht hier etwas über OpenID zu schreiben; ist mir etwas peinlich. Also dann mal direkt rein ins Geschehen und wenigstens die letzten zwei Wochen Revue passieren lassen, was sich so in der OpenID Community getan hat.

OpenID Bounty

Mit der I Want My OpenID Bounty wurde vor einem Jahr von Sponsoren wie Sxip, VeriSign, JanRain, NetMesh, Six Apart,… eine Aktion gestartet, die Open Source Projekte prämieren möchte, die OpenID entweder als Relying Party (RP) oder als Identity Provider (IdP) integrieren. Insgesamt können zehn Projekte eine Prämie in Höhe von je $5000 bekommen. Auf der diesjährigen O’Reilly Open Source Konferenz wurden die ersten drei Projekte prämiert: Drupal, Plone und DotNetNuke.

Wo ich gerade bei dieser Konferenz bin: David Recordon, Mitarbeiter bei VeriSign und Vize der OpenID Foundation wurde als Best Strategist für seine Arbeit an OpenID ausgezeichnet. Glückwunsch, nicht schlecht für einen Zwanzigjährigen.

Stromausfall in San Francisco

Teile San Franciscos waren am 24. Juli von einem Stromausfall betroffen; darunter befand sich auch ein großes Datacenter, wo u.a. Sites wie Six Apart, Craigslist und Technorati ihre Server haben. Mal davon abgesehen, dass dort so etwas wie Notstromaggregate eigentlich ihren Dienst verrichten sollten, hat dieser Stromausfall auch eine kleine Schwachstelle von OpenID aufgezeigt. Ein IdP wie LiveJournal (gehört bekanntlich zu Six Apart) war plötzlich nicht mehr erreichbar und Benutzer konnten somit keine Webseiten mit OpenID mehr benutzen. Dumm gelaufen.

RP’s haben allerdings die Möglichkeit mehrere OpenID’s für einen Account zuzulassen; leider machen davon die wenigsten Gebrauch. Vielleicht wachen jetzt ein paar von denen auf und ermöglichen ihren Nutzern das.

OpenID Non-Assertion Covenants

Bislang haben drei der führenden Unternehmen der OpenID Community sogenannte Non-Assertion Covenants veröffentlicht: JanRain, Sun und VeriSign. Damit versprechen diese Unternehmen, dass sie keine Forderungen irgendwelcher Art (Lizenzen, Gebühren,…) gegenüber Entwicklern geltend machen, die OpenID einsetzen möchten und dabei Patente dieser Unternehmen nutzen. Nicht ganz unwichtige Entscheidungen, wenn sich OpenID weiter verbreiten und entwickeln soll. Sxip hingegen haben eine solche Erklärung bislang noch nicht abgegeben, beteuern aber ihre Patente nur defensiv einzusetzen. Dafür müssen sie allerdings auch Kritik einstecken; sie halten sich hoffentlich an die Aussage.

OpenID Directory listet mehr als 300 Seiten

Das OpenID Directory führt mittlerweile mehr als 300 RP’s auf. Das sind selbstverständlich nicht alle Seiten mit OpenID Unterstützung, aber trotzdem nicht schlecht; 300 Seiten schön übersichtlich geordnet.

Ein paar neue Vertreter: Online Adressbuch Plaxo, Wikihoster Wikispaces und Taskmanager Toodledo. Meiner Meinung nach drei richtig gute Seiten.

Es gibt so Tage, da denke ich mir, dass OpenID nicht so richtig vom Fleck kommt. Diese Vorstellung prägt sich größtenteils durch das Lesen der OpenID Mailingliste. Versteht mich nicht falsch: die Diskussionen dort sind wichtig, aber hin und wieder kommt der Gedanke auf, dass man das doch schon alles mal vor Wochen geklärt haben konnte. Naja, wird wohl bei vielen anderen Projekten ähnlich sein.

Anderen Leuten widerum schreitet die Entwicklung viel zu schnell voran, und sie sehen schon überall im Netz das OpenID Logo blinken; gezwungen OpenID zu nutzen, sofern sie sich überhaupt noch im Netz bewegen möchten. Soweit sind wir aber noch lange nicht. Da fehlen einfach noch ein paar tausend wichtige Seiten, die dann stolz OpenID enabled auf der Registrierungseite verkünden können.

Aber was tun, wenn es doch geschieht? Was sollen dann die Trolle der Netzwelt, die Spammer dieser Erde, die Anonymen Kommentierer und weiteres Gesindel tun, um den Rest der Welt zu belästigen? Ist eine OpenID nicht so etwas wie ein Ausweis? Lässt sich dann nicht jeder Kommentar einer bestimmten Person zuordnen? Aus und vorbei mit dem Trollen? Wird das Netz sauber und gut? Leute, keine Panik! Alles bleibt wie es ist.

Wir bleiben anonym

Erst einmal ist eine OpenID natürlich kein Ausweis. OpenID verifiziert von Hause aus nicht, ob mein Name nun Carsten Pötter oder doch eher Marcel Weiß ist. Grundsätzlich kann man nur davon ausgehen, dass hinter einer OpenID - einer URI, also eindeutig - immer die gleiche Person steht. Sieht man also auf Blog ABC einen Kommentar von def.openidprovider.com und bei dem Social Netwerk Tolle Freunde einen Nutzer mit eben jener OpenID, sollte dahinter jeweils die gleiche Person stehen.
Möchte ich jetzt nun weiterhin durch das Netz trollen, kann ich mir natürlich einfach OpenID’s bei unterschiedlichen Providern besorgen; bei Provider A bin ich der seriöse Carsten Pötter (OK, kleiner Scherz am Rande) und die OpenID von Provider B nutze ich zum Trollen. Ist das jetzt anonym? Vielleicht noch nicht so richtig.

Gehen wir also einen Schritt weiter. Weiter oben habe ich die Wörter grundsätzlich und sollte benutzt, was durchaus seinen Grund hat. Es gibt nämlich einen komplett anonymen OpenID Server: www.jkg.in/openid.
Bereits beim Aufruf der Seite wird einem eine automatisch generierte OpenID angeboten; gefällt die einem nicht, kann man auch seine Wunsch OpenID nehmen, jkg.in/openid/tollerhecht oder so etwas. Loggt man sich damit bei einer Seite mit OpenID Unterstützung ein, erfolgt keine Weiterleitung zurück an den Server, um dort ein Passwort einzugeben, ein Browserzertifikat abzufragen oder sonstige Authentifizierungsmaßnahmen, die bekannte OpenID Provider nutzen. Man ist eingeloggt, einfach so. Und weil mich niemand authentifiziert, kann diese OpenID auch jeder andere nutzen. Hinter jkg.in/openid/tollerhecht verbirgt sich vielleicht einmal Marcel und einmal ich. Ich hoffe mal, dass das anonym genug ist. Wie gesagt, alles bleibt wie es ist und grundsätzlich sollte man mal von gar nichts ausgehen.

Fazit

Wie man an dem Beispiel sieht, kann man einer OpenID ohne weitere Verifizierung nicht trauen. Es stellt sich natürlich auch die Frage, ob ein solcher OpenID Server überhaupt lange genug bestehen bleiben wird bzw. ob alle OpenID Consumer ein Login von diesem Server akzeptieren werden. Die Möglichkeiten des Missbrauchs sind doch als weitaus größer einzuschätzen als evtl. Nutzen, denke ich mal. Aber Ihr seht, dass OpenID auch völlig anonym funktionieren kann. Gut? Schlecht? Egal?