Banedon’s Cyber-Junk

 

Fall 1: Twitter

Dieser Tweet sieht aus wie von mir geschrieben – ist er aber nicht. Er ist automatisch in meinem Namen geschrieben worden im Auftrage vom Betreiber. Möglich wurde dies, weil ich nicht wirklich gelesen habe, bevor ich mutwillig meinen Twitter Benutzername und Passwort eingegeben habe:

Wer lesen kann ist klar im Vorteil, denn hinter “click here” erfährt man, nachdem man ein schlechtes Gewissen über etliche Zeilen gemacht bekommen hat, wie man dieses System dazu bewegen kann, dass es keinen Tweet sendet.  In diesem Fall bin ich selbst schuld, und gehöre wohl zu einer Minderheit von Nutzern, die zwar gerne Dienste probieren, allerdings den Kommentar dazu in der Timeline gerne selbst verfassen würden.

Unschön bei dieser Anwendung ist auch, dass man Benutzername und Passwort verraten soll. Dabei ist das eigentlich dank OAuth nicht mehr notwendig. Ich habe selbst schon Anwendungen für Twitter entwickelt, und es ist genauso viel Aufwand eine Anwendung auf OAuth Basis zu schreiben wie mittels Benutzername und Passwort Eingabe. Für die Unterstützung von OAuth hatten damals viele Benutzer gekämpft.Für Anwendungen, die nach April 2009 entstanden sind gibt es jedoch eigentlich keine Ausrede mehr dies nicht zu unterstützen.

OAuth Anwendungen
Bei einer Anwendung, die OAuth unterstützt wird der Benutzer auf die Seite von Twitter umgeleitet. Im Browser muss dann zwingend in der Adresszeile eine Adresse stehen, die mit folgendem beginnt:

http://twitter.com/oauth/authorize

Die Seite, die der Nutzer nun angezeigt bekommt enthält immer:

• Welcher Twitter Nutzer gibt den Zugang frei
• Für welche Anwendung wird der Zugang gewährt
• Was darf sie machen (”Daten” und “Status”)

Die OAuth Unterstützung ist zur Zeit noch in Beta. Dennoch wird es wohl in Zukunft möglich sein den Zugriff einer Anwendung auch wieder zu entziehen. Bei Anwendungen die mit Benutzername und Paßwort arbeiten geht dies nur durch Änderung des Paßwortes.

Doch OAuth schützt nicht davor, dass unfreiwillig eine Anwendung Tweets unter dem eigenen Namen versenden kann. Es hilft nur, dass man einen Überblick darüber bekommt, welchen Anwendungen mal welche Rechte gegeben hat. Am Beispiel Twitter ist dies Leserecht (Persönliche Daten, Tweets etc..). und Schreibrecht (Tweets senden, Profilinfos ändern). Eine Anwendung wie die im oben gezeigten Falle braucht eigentlich nur Leserechte, denn was für Tweets sollte sie den zur Erfüllung ihrer Aufgabe senden wollen?

Fall 2: Facebook

Auch hier hatte ich heute ein Erlebnis, bei dem ein Bekannter versehentlich einer Anwendung das Recht gegeben hatte eine Nachricht an alle seine Bekannte zu versenden. Aufgefallen ist mir dieser Verdacht

Bei Facebook ist wie gewohnt alles etwas komplizierter. Aber auch hier haben Anwendungen die Möglichkeit unterschiedliche Rechte anzufordern. Jeder der Facebook verwendet weiss, wie gerne Anwendungsentwickler blaue “Accept” Buttons verwenden, um den Benutzer in die Irre zu führen. Aber über Settings => Application Settings erhält man eine Übersicht über alle Anwendungen, denen man rechte eingeräumt hat. Durch Klick und “Additional Permissions” sieht man, welchen Freigaben zugestimmt wurde. Theoretisch kann der Entwickler sehr feingranular wählen, was die Anwendung können soll – und natürlich dann auch nur diese Rechte anfordern.

Zum Weiterlesen…

• Hashspam – muss nicht sein…
• Facebook wächst mit 700.00 Usern pro Tag
• United Breakes Guitars – Von der Beschwerde 2.0
• Google Wave – Was ist das eigentlich (für mich)?
• Per Yahoo Pipes doppelte Einträge bei Facebook verhindern

Filed under: kommentiert von Thorsten Zoerner