Projektübersicht

Wie schon in unserem ersten Blog-Beitrag beschrieben ist die Grundidee von Delete Your Data (DYD), Entwicklern und Betreibern von Online-Plattformen die Einhaltung der Datenschutz-Grundverordnung (DSGVO) zu erleichtern. Für die DSGVO-Konformität ist es essenziell zu wissen, wo Daten über jeden einzelnen Benutzer gespeichert sind, damit darüber Auskunft gegeben werden kann, oder diese auf Wunsch zu entfernen.

Unser Ziel ist es, den Entwicklern die Möglichkeit zu bieten, alle mit einem User verknüpften Datensätze verfolgbar zu machen. DYD soll diese eine Sache gut machen, damit die Plattformbetreiber sicher sein können, keine Lücken in ihren Anstrengungen zur DSGVO-Konformität zu haben.

Erste Schritte der Planung

Zuallererst musste geplant werden, wie die Umsetzung und Funktionsweise von DYD aussehen soll. Da Userdaten auf viele verschiedene Möglichkeiten gespeichert werden können (Mailservices, Datenbanken, diverse externe Systeme, …) müssen hierfür die verschiedenen Module einzeln und spezifisch für ihren Zweck geplant und entwickelt werden. Durch die Unterteilung in verschiedene Module hat der Entwickler dann die Möglichkeit, sich selbst zu entscheiden welche er davon in seiner Seite benötigt und einbauen will.

Eine weitere Grundentscheidung war es, DYD als eigenständigen Service zu entwickeln: mit eigener Datenbank und eigener Web-Schnittstelle zur Administration, gehostet jeweils von den Plattformbetreibern, die DYD nutzen möchten. Durch die Entkopplung von der Plattform wird DYD mit unterschiedlichen Architekturen zusammenspielen können und breiter einsetzbar sein.

Um die weitere Vorgehensweise besser Planen zu können wurden User-Stories erstellt, dazu haben wir mögliche Szenarien zur Verwendung von DYD durchgespielt und schriftlich festgehalten. Eine Erkenntnis daraus war, dass DYD keine eigenes User Interface für die Endbenutzer haben wird: wir erwarten, dass die PlattformentwicklerInnen eigens gestaltete Oberflächen für ihre Benutzer bieten wollen. Wie bereits erwähnt wird es aber ein eigenes Admin-Interface geben, auf dem dann Module hinzugefügt und wieder entfernt werden, Daten anonymisiert und gelöscht werden können.

Planung der technische Strukturen

Von der Architektur her ist DYD also grundlegend eine eigenständige Webanwendung und hat als solche vier wichtige Bereiche: das Backend (die Logik der Website), das Frontend (wie die Seite für den User dargestellt wird), eine API (wie die Informationen zwischen Frontend und Backend übertragen werden) und zu guter Letzt die Datenbank in der die Informationen dann gespeichert werden.

Hier waren entsprechende Technologien zu evaluieren und auszuwählen: was ist für DYD sinnvoll, welche Kombination passt am besten zu uns?

• Backend Hier haben wir zwei Möglichkeiten betrachtet: PHP und Javascript. In unserem Team besteht hier die meißte Erfahrung, manche mehr bei PHP, andere bei Node.js. Das Rennen hat am Ende Node.js mit dem Express Webserver gemacht, vor allem wegen den Inkonsistenzen die bei PHP in der Standardbibliothek zu finden sind. Da beide Alternativen ansonsten gut für Web-Backends geeignet sind, gab das den Ausschlag.
• Frontend Beim Frontend gibt es etliche verschiedene Möglichkeiten - reines JavaScript, JS-Frameworks wie React, Vue und Angular, oder andere Systeme wie Elm -  wir haben uns hierfür für Vue entschieden, da das Entwicklerteam hier bereits Erfahrungen vorweisen kann.
• API Hier gibt es momentan zwei große Camps: das bewährte REST und das moderne GraphQL. Mit ersterem hat unser Team schon viel Erfahrung, und REST passt auch ansonsten gut zu unseren Anforderungen.
• Datenbank Die für DYD benötigten Datensätze haben eine klare Struktur, weshalb NoSQL-Lösungen hier keinen großen Vorteil bieten. Die Frage der Datenbank ist auch für die Betreiber relevant, die ja DYD dann in Betrieb nehmen. Deshalb wollen wir hier sowohl MariaDB/MySQL als auch PostgreSQL unterstützen, und generell vom verwendeten Datenbanksystem so unabhängig wie möglich bleiben.

Los geht's!

Aus dieser ersten Phase gehen wir mit einer gut durchdachten und klar definierten Architektur hinaus. Bei einem Softwareprojekt muss man flexibel für Änderungen bleiben, deswegen evaluieren wir natürlich laufend die Richtigkeit der hier gesteckten Eckpunkte. Ran an die Tastaturen, jetzt geht's los!