Mittwoch, 19. Dezember 2007

Nun kommen die Tage des PiratenVZ...

Ich bin ja wirklich hellauf begeistert. Einer überaus positive Resonanz auf meinen letzten Artikel, gepaart mit spontanem Tatendrang ist es zu verdanken, daß aus der kleinen Randbemerkung, eine solche Sozialnetzwerk-Seite könne nur als OpenSource unter Gewaltenteilung was Code, Datenhaltung und Moderation angeht funktionieren, tatsächlich der Anfang eines ambitionierten Projektes geworden ist.

Ein kleines Team hat sich zusammen gefunden und wir werden ab Januar 2008 mit der Implementierung einer Sozialnetzwerks-Software auf OpenSource Basis unter dem Arbeitstitel 'PiratenVZ' beginnen.
Vorab, hier schon einmal ein grobes Konzept:

Paradigmen



  • Ähnlich den populären Vorbildern soll PiratenVZ eine Platform zur persönlichen Präsentation, Kommunikation und Kontaktpflege werden.

  • Jeder Benutzer besitzt volle und möglichst fein granulare Kontrolle darüber, welche seiner pers. Daten von wem und in welchem Detail angezeigt werden dürfen.

  • Das Hauptaugenmerk der Entwicklung soll dabei auf der Sicherung der Übertragung und der Datenhaltung (z.B. durch die Verwendung passender Kryptoverfahren) liegen.

  • Softwarebereitstellung, technische Administration und inhaltliche Moderation sind soweit wie möglich getrennt zu halten und, wo sinnvoll, in die direkte Hand der Nutzerschaft zu legen, um Machtmonopolen im tatsächlichen Betrieb vorzubeugen.

  • Das Softwaredesign selbst muß solide und erweiterbar genug sein, um für einen langen Zeitraum im Code Bestand zu haben, ohne durch 'Abkürzungen' oder Hacks ad Absurdum geführt zu werden.



Datenstruktur



Hauptziel dieser Datenstruktur ist es, jedes Datenobjekt (auser Konfiguration, die hier bewußt außen vor gelassen wurde) eindeutig auf einen bestimmten Benutzer zurückführen zu können, so daß 'Besitzansprüche' an den einzelnen Datenfragmenten technisch eindeutig abgebildet werden.

Des weiteren ist das Objectdesign so angelegt, daß ein neu hinzukommenter Service (der meist auch neue Datentypen mitbringt) lediglich eine Erweiterung des Datenprofils darstellen, so daß alte Profile zu neuen Versionen der Software kompatibel bleiben.

Das Objektdesign gibt es hier.

Es gibt also pro Benutzer ein User Objekt, welches in der Lage ist, über login und email Adresse einen Benutzer eindeutig zu identifizieren.

Jeder User besitzt einen eigenen LoginContext. Dies ist zuerst einmal ein Interface, welches die Funktionen zum einloggen übernimmt. Jeder Benutzer kann somit später selbst entscheiden, auf welche Art und Weise er autentifiziert werden will.
Geplant ist sowohl eine Implementation als PasswordLoginContext welcher den Benutzer auf eine klasische User/Password hin einlässt, als auch eine Implementation als CypherLoginContext der eine Anmeldung per asynchron verschlüßeltem Handshake ermöglicht.

Des weiteren besitzt jeder User ein UserPreferences object, welches die persönlichen Einstellungen des Benutzers beinhaltet, sowie ein UserProfile Objekt, welches ein beliebig detailiertes Profil des Benutzers darstellt.

Für jeden Service (Social Networking, Blog, Messager, etc.) den der Benutzer verwendet, wird dem User ein ServiceContext Objekt zugeteilt, welches die Daten des Benutzers zu dem jeweiligen Service enthält. Die dargestellten Implementierungen eines ServiceContext Objekts im Bild sind hierbei hauptsächlich als Beispiel gedacht.
Jedes ServiceContext Objekt beinhaltet andere Daten, je nachdem, was durch den verwendeten Service benötigt wird.

Neben diesem Model wird es noch weitere Datentypen geben, welche verschiedene Inhalte (z.B. Bilder oder Texte) verkörpern und hauptsächlich in den einzelnen ServiceContext und UserProfile Objekten Verwendung finden. Welche das sind, wird sich aber erst später im Detail entscheiden.

Software-Komponenten



Das Design der Software-Komponenten ist, wie das Objektdesgin auch, darauf ausgerichtet, eine schmale ubnd solide Grundfunktionalität anzubieten und der Implementation neuer Services nicht im Wege zu stehen.

Zwar ist das Design mit einer typische Java-J2EE Anwendung auf Jboss oder ähnlichem im Hinterkopf geschrieben worden, es wäre aber auch beinahe jede andere gekappselte Serverlogik und Programmiersprache möglich.

Das Designbildchen findet sich hier.

Generel sind die Softwarekomponenten in 3 Teile unterteilt. Einen für die Anzeige, einen für die Logik und einen für die Datenhaltung. Soweit so klasisch.

Der Web Bereich der Anwendung wird über JPS's gestaltet, deren Logik wo es möglich ist in Taglibs und korrospondierende Bean-Klassen ausgelagert ist.
Mit der jeweiligen HTTP-Session können die Beans der einzelnen Tags nach Bedarf auf die Service-Schicht zugreifen.

Jeder Service für sich stellt vordergründig eine möglichst atomare Implementation einer in sich geschloßenen Anwendung dar. Jeder Service soll autark durch eine WebBean ansprechbar sein, Das bedeutet, daß sämtliche Abhängigkeiten der Services untereinander und zur Persistenz für die WebBean transparent sind.

Eine Ausnahme stellt hier der SecurityService dar, welcher in Korellation zum SessionMetadataService einzelne Zugriffe erlaubt oder verbietet und selbst nicht von auserhalb des Servicelayers ansprechbar ist, sondern lediglich von den anderen Services angesprochen wird.

Eine naheliegende Implementationsvariante dieser Services stellen SessionBeans dar. Der Ausnahmeservice SecurityService könnte am besten als singleton Klasse implementiert werden, so daß ein schneller und direkter Zugriff von allen Services aus jederzeit möglich ist.

Zu den einzelnen Services:

  • Der SecurityService besitzt die Möglichkeit über den SessionMetadataService auf die Attribute einzelner Sessions zuzugreifen und vergibt auf Basis dieser Informationen Berechtigungen für verschiedene Aktionen.
    Als einziger Service ist er lediglich durch andere Services ansprechbar und kann daher als singleton implementiert werden.
    Zusammen mit dem SessionMetadata- und UserDataService bildet er das Rückrad der Anwendung

  • Der SessionMetadataService hält sämtliche sessionrelevanten Daten vor. So zum Beispiel den eingeloggten Benutzer, die Berechtigungen dieses Benutzers, die SessionId sowie temporäre Daten anderer Services, die lediglich für diese eine Session Gültigkeit haben.
    Er ist auch die Stelle, an die eine Loginanfrage durch eine WebBean geschickt werden kann.
    Er bildet zusammen mit dem Security- und dem UserDataService das Rückrad der Anwendung.

  • der UserDataService stellt Benutzerprofile und andere benutzerbezogene Daten zur Verfügung. Entsprechen diese Daten denen des Session-Eigentümers, können sie auch geändert werden. So kann ein Benutzer zum Beispiel seine persönlichen Einstellungen ändern.
    Für's Protokoll: Dieser Service bildet zusammen mit dem Security- und dem SessionMetadataService das Rückrad der Anwendung.



Die restlichen Services in dem verlinkten Komponenten-Design stellen pro Service die Funktionalität eines bestimmten, von den Benutzer verwendbaren, Services dar.
So lassen sich zum Beispiel über den SocialNetworkService soziale Netze (analog zu StudiVZ, Wer-Kennt-Wen, etc.) pflegen. Über den BlogService kann ein Benutzer einen eigenen Blog pflegen, oder die Blogs anderer Benutzer anzeigen lassen und kommentieren. Über den PictureGallerieService könnten Bilder der einzelnen Benutzer abgelegt und angezeigt werden.
Diese Liste ist nach Bedarf erweiterbar oder streichbar. Welche Services wir für's Erste tatsächlich anbieten werden wird sic noch entscheiden.

Die Persistenzschicht ist denkbar einfach aufgebaut. Für jeden logisch zusammenhängenden Datenkomplex gibt es eine Implementation eines DataStore Interfaces, welche die relevanten Daten von der Datenbank läd, cached, zur Verfügung stellt und in die Datenbank zurückschreibt.

Freitag, 14. Dezember 2007

Wasser auf meine Mühlen

Manchmal tut es der eigenen Schadenfreude richtig gut, recht zu behalten.
So konnte ich mir zum Beispiel bei der jüngsten Meldung, StudiVZ habe seine AGBs geändert ein fieses Grinsen nicht verkneifen.

Zwar beschwört Dirk Hensen, der Pressesprecher von StudiVZ, daß die Benutzerdaten nicht weiter gegeben werden, sondern lediglich intern ausgewertet werden, aber die Handlungen des Vereins sprechen eine andere Sprache.
In den neuen AGBs, die einige Nutzer schon zugeschickt bekommen haben, heißt es zum Beispiel:


"Ich willige ein, dass StudiVZ Bestandsdaten und/oder Nutzungsdaten von mir an Dritte weitergibt, wenn und soweit die Übermittlung der Daten aufgrund gesetzlicher Vorschriften und/oder infolge von Gerichtsentscheidungen zulässig ist."

Wow, daß klingt gar nicht mehr so freundlich. Dazu kommt die Ankündigung, das Profile von abgemeldeten Benutzern nicht mehr gelöscht werden, sondern lediglich deaktiviert werden, was nur mit dem Wunsch, die Daten weiterzuverhökern erst Sinn ergibt.

Zumal das monolitische Portal bereits in der Vergangenheit negativ aufgefallen ist, was die technische Sicherung und den schlampigen Umgang mit Benutzerdaten angeht.

Die Brisanz gesammelter Informationen gerade über Kontakte und soziale Netzstruckturen, sollte spätestens seit den jüngsten Eskapaden unseres staatlichen Sicherheitsapparates jedem bewusst sein.
Wenn man dann solche Ankündigungen, die mangelhaften Sicherheitssysteme des StudiVZ und die geplante Vorratsdatenspeicherung zusammenzählt, erhält man ein wirklich erschreckendes Bild.

Zum Geleit


Ein Portal wie StudiVZ, wer-kennt-wenn und Konsorten ist grundsätzlich immer unsicher. Das liegt zum einen daran, daß es (sobald eine gewisse Größe erreicht ist) ein lohnendes Ziel für Datensammler darstellt und zum anderen daran, daß der gesammte Code unter den Fittichen derer liegt, die das Portal betreuen und deren Entscheidung es folglich unterliegt, Daten an dritte zu verscheuern. Hier besteht eine immens gefährliche Zusammenlegung von Machtpotenzial.
Daher erscheint für mich das einzig sichere Portal dieser Art eines, welches komplett auf einer OpenSource software aufsetzt und auf einem gemeinnützigen, über Spenden finanzierten Server (ähnlich des Wikipedia-Konzepts) läuft.

So long.