Offline-first App-Architektur & Privacy by Design

Viele Apps folgen heute einem vertrauten Muster: installieren, Account anlegen, anmelden – anschließend tauschen Smartphone, Backend, Cloud-Dienste und verschiedene Schnittstellen Daten miteinander aus.

Technisch kann das vollkommen sinnvoll sein. Cloud-Synchronisation ermöglicht geräteübergreifendes Arbeiten, Backups oder Dienste, die ohne Server kaum realisierbar wären. Trotzdem lohnt sich bereits ganz am Anfang eines Projekts eine ziemlich einfache Frage:

Müssen diese Daten das Gerät überhaupt verlassen?

Bei AuraHarmony haben wir uns diese Frage früh gestellt. Die zentralen Funktionen der App benötigen weder ein eigenes Benutzerkonto noch eine AuraHarmony-Cloud. Playlists, selbst angelegte Frequenzen und die eigentliche Nutzung werden lokal verarbeitet. AuraHarmony überträgt diese Nutzungsinformationen nicht an eigene Server. Warum wir uns grundsätzlich für diesen Weg entschieden haben, beschreibt unsere Produktperspektive in Warum wir AuraHarmony ohne Accounts, Tracking oder Cloud gebaut haben – dieser Artikel hier betrachtet die technische Seite dahinter.

Das ist zunächst einmal eine Architekturentscheidung. Gleichzeitig beeinflusst sie ganz unmittelbar, welche Datenschutzfragen überhaupt entstehen.

Datenschutz beginnt bei der Architektur

Bei Datenschutz denken viele zuerst an Datenschutzerklärungen, Einwilligungen oder Cookie-Banner. Für Entwickler beginnt das Thema allerdings deutlich früher: beim Datenmodell und bei der Systemarchitektur.

Schon während der Konzeption fallen Entscheidungen wie:

• Welche Daten braucht eine Funktion tatsächlich?
• Wo werden diese Informationen gespeichert?
• Muss dafür eine Internetverbindung bestehen?
• Ist ein Benutzerkonto notwendig?
• Werden Nutzungsdaten ausgewertet?
• Welche Daten verlassen das Endgerät?
• Welche externen Dienste benötigt die Anwendung?

Je weniger unnötige Datenflüsse eine Anwendung erzeugt, desto weniger müssen später geschützt, verwaltet, übertragen oder gelöscht werden.

Genau hier treffen Softwarearchitektur und Datenschutz aufeinander.

Datenminimierung nach Art. 5 DSGVO

Artikel 5 Absatz 1 Buchstabe c der Datenschutz-Grundverordnung definiert den Grundsatz der Datenminimierung.

Personenbezogene Daten müssen dem Zweck angemessen und erheblich sowie auf das für die Zwecke der Verarbeitung notwendige Maß beschränkt sein.

Aus Entwicklersicht folgt daraus eine interessante Reihenfolge. Bevor man fragt:

„Wie schützen wir diese Daten?"

lohnt sich zunächst die Frage:

„Brauchen wir diese Daten für die Funktion überhaupt?"

Kann eine Funktion ohne bestimmte personenbezogene Daten realisiert werden, entfällt für diese Daten auch ein ganzer Block späterer Verarbeitung.

Privacy by Design und Privacy by Default nach Art. 25 DSGVO

Artikel 25 DSGVO greift diesen Gedanken technisch auf. Datenschutz soll bereits bei der Gestaltung von Systemen berücksichtigt werden – häufig unter dem Begriff Privacy by Design zusammengefasst. Absatz 2 ergänzt den Gedanken um datenschutzfreundliche Voreinstellungen, also Privacy by Default.

Wichtig ist dabei eine saubere Abgrenzung:

Die DSGVO schreibt keine Offline-first-Architektur vor.

Auch eine cloudbasierte Anwendung kann datenschutzkonform konstruiert und betrieben werden. Offline-first ist lediglich eine mögliche technische Strategie, mit der sich bestimmte Datenschutzprinzipien besonders konsequent unterstützen lassen.

Bei AuraHarmony funktioniert die datensparsame Variante allerdings nicht erst nach einer komplizierten Konfiguration. Die Kernfunktionen arbeiten von Haus aus ohne AuraHarmony-Account, Tracking oder eigene Cloud-Synchronisation. In diesem Sinne steckt ein Teil des Datenschutzes bereits in den Voreinstellungen des Produkts.

Was bedeutet Offline-first?

Offline-first beschreibt grundsätzlich eine Architektur, bei der eine Anwendung ihre wesentlichen Funktionen auch ohne permanente Netzwerkverbindung bereitstellen kann.

Die Android-Architekturdokumentation beschreibt beispielsweise Ansätze, bei denen eine lokale Datenquelle als maßgebliche beziehungsweise kanonische Datenquelle der Anwendung dient.

Ein cloudzentrierter Datenfluss könnte stark vereinfacht so aussehen:

App
 ↓
API – authentifiziert über Benutzerkonto
 ↓
Backend
 ├── Datenbank
 ├── Analysesysteme
 └── weitere Dienste

Eine lokale Architektur kann wesentlich kürzer ausfallen:

App
 ↓
lokale Datenhaltung
 ↓
lokale Verarbeitung

Offline-first bedeutet dabei nicht automatisch „niemals Internet". Eine App kann durchaus einzelne Online-Funktionen besitzen.

Entscheidend ist vielmehr, welche Rolle die lokale Verarbeitung spielt und ob die eigentlichen Kernfunktionen dauerhaft von einem Backend abhängen.

Offline-first und Local-first sind nicht dasselbe

Eng verwandt ist das von Martin Kleppmann und seinen Mitautoren beschriebene Konzept der Local-first Software. Dort steht die Kontrolle der Nutzer über ihre Daten stark im Mittelpunkt. Lokale Kopien sollen eine zentrale Rolle spielen; die Cloud darf unterstützen, soll aber nicht zwangsläufig die alleinige Instanz darstellen.

Das Konzept geht an einer Stelle allerdings weiter als AuraHarmony: Local-first im Sinne dieses Papers berücksichtigt ausdrücklich auch geräteübergreifende Synchronisation und Zusammenarbeit.

AuraHarmony verfolgt hier einen einfacheren Ansatz. Wir übernehmen den Grundgedanken der lokalen Datenhoheit, verzichten für persönliche App-Daten aber zusätzlich auf eine eigene Cloud-Synchronisation.

Damit entstehen weniger Abhängigkeiten – allerdings auch weniger Komfort bei bestimmten Funktionen.

Wie AuraHarmony diesen Ansatz nutzt

Die entscheidende Produktfrage lautete während der Entwicklung:

Welche Informationen müssen wir als Anbieter tatsächlich besitzen, damit AuraHarmony funktioniert?

Für die Kernfunktionen lautet die Antwort: ausgesprochen wenige.

AuraHarmony benötigt keinen eigenen Benutzeraccount. Eigene Frequenzen, Playlists und Nutzungsinformationen werden nicht an AuraHarmony-Server übertragen. Es existiert außerdem kein Tracking des individuellen Nutzungsverhaltens durch AuraHarmony.

Vereinfacht sieht der relevante Datenfluss deshalb so aus:

AuraHarmony
│
├── Benutzeroberfläche
├── Audio- und Frequenzfunktionen
├── Playlists
├── eigene Frequenzen
└── lokale Speicherung
       │
       └── keine Übertragung an AuraHarmony-Server

Dass diese lokale Klangerzeugung auch technisch präzise funktioniert, haben wir übrigens messbar gemacht: Im Beitrag Smartphone-Frequenzen im Oszilloskop-Test prüfen wir die erzeugten Frequenzen direkt am Messgerät.

Das ist ein wichtiger Unterschied.

Die Aussage lautet ausdrücklich nicht, dass lokale Daten niemals irgendeine Cloud berühren können. Betriebssysteme wie Android und iOS können je nach Gerätekonfiguration eigene Backup-Mechanismen verwenden. Diese Prozesse gehören zur Infrastruktur des jeweiligen Plattformanbieters und nicht zu einer AuraHarmony-Cloud.

Was wir kontrollieren können, ist unser eigener Datenfluss: AuraHarmony überträgt diese persönlichen Nutzungsdaten nicht an eigene Server.

Welche externen Verbindungen gibt es trotzdem?

Offline-first bedeutet nicht, dass ein Smartphone beim Einsatz von AuraHarmony grundsätzlich keinerlei Netzwerkverbindungen aufbauen kann.

Zwei Bereiche müssen wir deshalb transparent unterscheiden.

AGB und Datenschutzerklärung

Die rechtlichen Dokumente – insbesondere AGB und Datenschutzerklärung – werden über iubenda bereitgestellt. Beim Abruf dieser extern bereitgestellten Inhalte entsteht entsprechend eine Verbindung zu diesem Dienst.

Die eigentlichen Audiofunktionen, eigenen Frequenzen und Playlists benötigen diese Verbindung jedoch nicht.

Apple App Store und Google Play

Installation, Kauf und Aktualisierung der App laufen über die jeweiligen Plattformen von Apple beziehungsweise Google.

Welche Daten Apple und Google im Rahmen ihrer App-Stores verarbeiten, liegt außerhalb der AuraHarmony-App-Architektur und richtet sich nach den Bedingungen der jeweiligen Plattform.

AuraHarmony erhält daraus keine individuellen Nutzungsprofile. Als Anbieter erhalten wir im Wesentlichen Informationen über die Anzahl der verkauften Apps.

Das ist eine wichtige Unterscheidung: Datenverarbeitung durch den Plattformbetreiber ist nicht dasselbe wie Datenerhebung durch AuraHarmony.

Offline bedeutet nicht automatisch sicher

Ein weiterer Punkt verdient eine klare Grenze.

Es wäre technisch falsch zu behaupten:

„Offline-first bedeutet absolute Sicherheit."

Lokale Daten können ebenfalls gefährdet sein. Ein kompromittiertes Smartphone, Schadsoftware, unzureichend geschützte Geräte oder andere Sicherheitsprobleme verschwinden durch Offline-first nicht.

Was wir deutlich enger und belastbarer formulieren können:

Daten, die AuraHarmony nicht an eigene Server überträgt, können dort auch nicht von einem serverseitigen Datenleck betroffen sein.

Außerdem müssen wir diese Daten nicht:

• einem AuraHarmony-Benutzerkonto zuordnen,
• zentral speichern,
• zwischen unseren Systemen synchronisieren,
• für individuelle Nutzungsanalysen aufbewahren,
• oder später aus einer eigenen Cloud-Infrastruktur löschen.

Damit unterstützt die Architektur Datenminimierung bereits technisch.

Warum das bei persönlichen Anwendungen interessant wird

Apps rund um Entspannung, Schlaf, Audio oder persönliche Routinen bewegen sich in einem Bereich, den viele Nutzer als privat empfinden.

Das bedeutet keineswegs automatisch, dass jede Wellness-App sensible Gesundheitsdaten verarbeitet. Trotzdem lohnt sich ein kritischer Blick darauf, wie Apps dieser Kategorie mit Nutzungsinformationen umgehen.

Eine 2022 online veröffentlichte Untersuchung analysierte beispielsweise 27 populäre Mental-Health-Apps aus dem Google Play Store und dokumentierte erhebliche Unterschiede und Probleme beim Umgang mit Datenschutz und Transparenz.

Diese Ergebnisse lassen sich nicht pauschal auf sämtliche Wellness- oder Audio-Apps übertragen. Sie verdeutlichen jedoch eine grundsätzliche Entwicklungsfrage:

Sollten wir Informationen sammeln, nur weil wir sie technisch sammeln könnten?

Bei AuraHarmony haben wir diese Frage für die Kernfunktionen bewusst verneint.

Weniger Daten bedeuten auch weniger Analyse

Als Entwickler könnte ich zahlreiche Nutzungsinformationen interessant finden:

• Welche Frequenzen werden besonders häufig verwendet?
• Wie lang laufen Sitzungen durchschnittlich?
• Welche Playlists werden angelegt?
• Welche Funktionen bleiben ungenutzt?
• Zu welchen Tageszeiten wird die App besonders häufig gestartet?

Solche Informationen könnten bei der Produktentwicklung helfen.

Doch „interessant" und „für die Funktion notwendig" sind zwei unterschiedliche Dinge.

Wer diese Daten nicht zentral erhebt, verliert damit selbstverständlich auch einen Teil der Möglichkeiten für datengetriebene Produktoptimierung. Genau das gehört zur ehrlichen Bewertung einer datensparsamen Architektur.

Die Nachteile einer konsequent lokalen Architektur

Architekturentscheidungen haben fast immer ihren Preis. Offline-first bildet da keine Ausnahme.

Kein eigener automatischer Sync zwischen Geräten

Eine persönliche Konfiguration wird nicht über eine AuraHarmony-Cloud automatisch auf andere Geräte übertragen.

Für Nutzer mit mehreren Geräten wäre eine zentrale Synchronisation bequemer.

Keine serverseitigen Nutzungsprofile

AuraHarmony erstellt aus dem individuellen App-Verhalten keine serverseitigen Profile. Damit können wir daraus auch keine serverseitig personalisierten Empfehlungen ableiten.

Lokale Personalisierung wäre technisch grundsätzlich möglich; sie ist lediglich etwas völlig anderes als zentrale Profilerstellung.

Weniger Telemetrie für die Produktentwicklung

Wir erhalten weniger Informationen darüber, wie einzelne Funktionen tatsächlich genutzt werden.

Was aus Datenschutzsicht attraktiv ist, kann aus Entwickler- und Produktperspektive also durchaus einen Nachteil darstellen.

Diese Abwägung war bewusst.

Cloud ist nicht der Gegner

Bei Diskussionen über Datenschutz entsteht schnell ein zu einfacher Gegensatz:

Offline gut, Cloud schlecht.

So funktioniert Softwarearchitektur nicht.

Cloud-Systeme können sicher, leistungsfähig und datenschutzkonform aufgebaut werden. Für zahlreiche Anwendungen sind sie sogar unverzichtbar.

Umgekehrt kann eine vollständig lokale App schlecht programmiert oder unsicher sein.

Die bessere Architekturfrage lautet deshalb:

Welche Infrastruktur benötigt die konkrete Aufgabe – und welche Daten müssen dafür tatsächlich verarbeitet werden?

AuraHarmony benötigt für seine Kernfunktionen weder eine zentrale Benutzerverwaltung noch eine eigene Cloud-Speicherung persönlicher Frequenzen und Playlists.

Deshalb haben wir darauf verzichtet.

Privacy by Design ist Softwaredesign

Für mich als Softwareentwickler steckt genau darin der spannendste Aspekt.

Datenschutz erscheint in vielen Projekten irgendwann als juristische Zusatzanforderung kurz vor der Veröffentlichung. Technisch betrachtet beeinflusst er jedoch sehr viel früher grundlegende Entscheidungen.

Die Architektur bestimmt unter anderem:

• welche Daten entstehen,
• wo sie verarbeitet werden,
• welche Systeme Zugriff erhalten,
• welche Schnittstellen existieren,
• und welche zusätzlichen Angriffsflächen daraus entstehen.

Offline-first ist dabei kein Allheilmittel und keine Forderung der DSGVO.

Es ist ein Architekturwerkzeug – und für eine App wie AuraHarmony passt dieses Werkzeug ausgesprochen gut.

Fazit: Die datenschutzfreundlichste Datenbank kann manchmal die sein, die man gar nicht erst betreibt

Softwareentwicklung besteht aus Abwägungen.

Cloud-Synchronisation bietet Komfort. Benutzerkonten ermöglichen geräteübergreifende Dienste. Telemetrie kann wertvolle Erkenntnisse für die Weiterentwicklung liefern.

All das lässt sich technisch sauber und datenschutzkonform realisieren.

Vor der Umsetzung lohnt sich trotzdem eine einfache Frage:

Brauchen wir es für dieses Produkt überhaupt?

Bei AuraHarmony haben wir uns für die Kernfunktionen bewusst für lokale Verarbeitung entschieden. Persönliche Playlists, eigene Frequenzen und individuelles Nutzungsverhalten müssen dafür nicht auf einer AuraHarmony-Serverinfrastruktur landen.

Damit beginnt Datenschutz nicht erst bei der Datenschutzerklärung.

Ein Teil davon steckt bereits im Softwaredesign.

Du möchtest AuraHarmony ausprobieren? AuraHarmony erzeugt Frequenzen und binaurale Beats direkt auf deinem Gerät. Eigene Frequenzen und Playlists bleiben Teil der lokalen App-Nutzung – ohne AuraHarmony-Account, ohne Tracking und ohne eigene Cloud-Synchronisation. AuraHarmony für iOS und Android entdecken – oder teste die Demo direkt im Browser.

Quellen und weiterführende Literatur

• Europäische Union – Datenschutz-Grundverordnung, Art. 5: Grundsätze für die Verarbeitung personenbezogener Daten; insbesondere Datenminimierung nach Art. 5 Abs. 1 lit. c.
• Europäische Union – Datenschutz-Grundverordnung, Art. 25: Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen.
• Google / Android Developers: Build an offline-first app – offizielle Android-Dokumentation zur Architektur von Offline-first-Anwendungen.
• Kleppmann, M., Wiggins, A., van Hardenberg, P. & McGranaghan, M. (2019): Local-first software: you own your data, in spite of the cloud. Proceedings of Onward! 2019, 154–178.
• Iwaya, L. H., Babar, M. A., Rashid, A. & Wijayarathna, C.: On the privacy of mental health apps. Empirical Software Engineering, 28(1), Article 2.