Piggyback Hosting

piggyback-hosting

Ein Hosting-Muster für Anwendungen, die von vornherein niemals fremde Daten annehmen.

Blaupause entstanden am 2026-08-02 beim Bau dreier Call-Agenten. Wiederverwendbar für jede Anwendung, die für einen einzelnen lokalen Nutzer entworfen wurde, aber auch für andere hostbar sein soll.

Zum Namen

Im Englischen heißt dieses Muster piggyback — auf fremder Infrastruktur mitreiten ist dort bereits der Fachbegriff dafür. Englischer Fließtext in diesem Skill sagt daher piggyback; "huckepack" ist der deutsche Arbeitstitel, unter dem das Muster gebaut wurde, und zugleich der Name des Repositories, aus dem dieser Skill migriert wurde. Die wörtlichen Modus-Werte bleiben huckepack-gift und huckepack-only-host — sie sind das, was in Code und Konfiguration verschifft wird, genau so geschrieben, unabhängig davon, in welcher Sprache der umgebende Fließtext steht.

Das Problem

Eine Anwendung wird lokal gebaut: eine Datenbank, ein API-Key, State, der im Prozess lebt. Auf der eigenen Maschine ist das schlicht korrekt. Sobald jemand sie für andere hostet, wird jede dieser drei Annahmen zu einem Bug — jeder Besucher teilt sich denselben State, dieselbe Datenbank, denselben Key. Wer die Seite öffnet, sieht die Daten aller anderen.

Die übliche Lösung ist Nutzerverwaltung: Accounts, Login, Zugriffsprüfungen, Löschfristen, eine Datenschutzerklärung, ein Auftragsverarbeitungsvertrag. Oft ein größeres Unterfangen als die Anwendung selbst.

Die Idee

Der Besucher behält alles auf dem eigenen Gerät. Der Host behält nichts.

Das löst die Nutzerverwaltung nicht — es macht sie gegenstandslos. Wo keine fremden Daten auf dem Server liegen, gibt es nichts zwischen Besuchern abzuschotten, nichts nach Zeitplan zu löschen, und die Datenschutzerklärung schrumpft auf das, was der Dienst tatsächlich tut.

Die drei Modi

• huckepack-gift — der Host liefert seinen eigenen Key und verschenkt die Ausführung. Eine reibungslose Einladung, das Tool auszuprobieren.
• huckepack-only-host — der Besucher bringt seinen eigenen Key mit. Der Host zahlt nichts und speichert nichts.
• pay-membership — bewusst als Stub belassen. Hier wird alles wieder nötig, was die anderen beiden vermeiden — Accounts, Abrechnung, serverseitige Speicherung. Ein eigenes Unterfangen, kein Schalter zum Umlegen.

Es gibt immer einen local-Standard: wer nichts konfiguriert, bekommt die Anwendung genau so, wie sie vorher lief, auf der eigenen Maschine.

Die Bausteine

Der eigentliche Engineering-Aufwand liegt darin, die Speicherschicht austauschbar zu machen: die Anwendung schreibt so oder so nach SQLite, aber eine Zwischenschicht entscheidet, ob dieses Schreiben auf dem Server oder im Browser des Besuchers landet (sql.js / der offizielle SQLite-WASM-Build, persistiert über das Origin Private File System). Die Browser-Speicher-Optionen nach Gewicht ordnen, falls WASM zu schwer ist: SQLite-WASM + OPFS (eine echte Datenbank, größte Kapazität) > IndexedDB (strukturiert, eigenes Query-Modell) > localStorage (nur für Kleinigkeiten wie Sprache und Theme geeignet).

Was dieses Muster nicht löst — offen gesagt

• Gelöschte Browser-Daten heißt, alles ist weg. Es gibt keine serverseitige Kopie. Deshalb ist Export eine Bedingung, kein Nice-to-have.
• Kein Gerätewechsel ohne Export und Import.
• Der im Browser lebende Key (only-host) ist weniger geschützt als einer auf einem Server. Er gehört aber dem Besucher, und die Alternative wäre, ihn dem Host zu übergeben — nicht offensichtlich die sicherere Wahl.
• Die Ausführung läuft weiterhin über den Host. Bei Diensten, die einen Dritten erreichen — etwa einen Telefonanruf — verarbeitet der Host die Daten dieses Dritten unabhängig davon, wo die eigenen Aufzeichnungen des Besuchers liegen. Eine Datenschutzerklärung wird dadurch nicht überflüssig, nur kurz.

Was die Rechtsprüfung ergab

Eine rechtliche Ersteinschätzung (references/RECHT.md, deutsch — sie prüft deutsche und EU-Vorschriften, weshalb ein Zitieren in Übersetzung weniger genau, nicht zugänglicher wäre) prüfte das Muster gegen DSGVO, TDDDG und UWG. Ersteinschätzung mit Fundstellen, keine Rechtsberatung. Drei Befunde in je einer Zeile:

• Der Host bleibt Verantwortlicher, auch wenn er nichts speichert. Art. 4(7) DSGVO knüpft die Verantwortlichkeit an das Entscheiden über Zwecke und Mittel, nicht an die Speicherung; der EuGH hat das ausdrücklich so gesagt (C-683/21). Gegenstandslos wird die Nutzerverwaltung, nicht die Verantwortung.
• Für die kontaktierte Person schrumpft nichts. Informationspflichten nach Art. 14, eine dokumentierte Abwägung der Rechtsgrundlage, ein Auftragsverarbeitungsvertrag mit dem Dienst, der den Kontakt ausführt — das sind meist die längsten Abschnitte einer Datenschutzerklärung, und das Muster rührt sie nicht an.
• Die Haushaltsausnahme hilft dem Besucher, nicht dem Host. Sie deckt rein persönliche Nutzung durch eine natürliche Person; ein Dienst, der anderen angeboten wird, ist keine rein persönliche Tätigkeit. Genau dort beginnt Piggyback-Hosting.

Der Gewinn liegt im Umfang der Pflichten und der Größe der Angriffsfläche, nicht in ihrer Art — was zugleich die ehrlichere Aussage über das Muster ist.

Wie dieses Muster angewendet wird

1. references/DATA-FLOW-TEMPLATE.md lesen und für die tatsächliche Anwendung ausfüllen, belegorientiert (jede Zeile braucht ein file:line oder "nicht gefunden"). Das legt genau offen, welche lokalen Annahmen unter Multi-Besucher-Hosting brechen, bevor Code geändert wird.
2. Entscheiden, welche Modi die Anwendung tatsächlich braucht — local ist immer der Standard; huckepack-gift und huckepack-only-host sind die beiden, die Nutzerverwaltung vermeiden; pay-membership bleibt ein Stub, solange kein konkreter Grund für echte Accounts besteht.
3. Die Speicherschicht austauschbar machen (der oben genannte Kern-Schritt), das maskierte Key-Feld für only-host ergänzen und Export/Import verdrahten, bevor irgendetwas ausgeliefert wird — es ist das Sicherheitsnetz für flüchtigen Browser-Speicher.
4. references/PRIVACY-TEMPLATE.md für das konkrete Deployment ausfüllen; nicht zutreffende Blöcke löschen, jede Anbieter-Angabe gegen aktuelle Verträge prüfen und eine fallbezogene Rechtsprüfung einholen, bevor echte Daten verarbeitet werden. Die Vorlage ist ein Ausgangspunkt, keine fertige Erklärung.
5. Bei jeder Installation, die echte Dritte betrifft (Telefonanrufe, Nachrichten an Personen, die sich nicht selbst angemeldet haben) oder Forschungsteilnehmende, die Empfehlungen aus references/RECHT.md als Checkliste behandeln, nicht als Freigabe — vor dem ersten öffentlichen Lauf einen Anwalt einbeziehen.

Referenzen

• references/DATA-FLOW-TEMPLATE.md — Vorlage und Verfahren für einen Data-Flow-Plan: jede Zeile braucht ein file:line, sonst ist es eine Vermutung, kein Befund.
• references/PRIVACY-TEMPLATE.md — Muster-Datenschutzerklärung mit markierten Platzhaltern für eine Piggyback-Installation.
• references/RECHT.md — rechtliche Ersteinschätzung (deutsch) mit DSGVO-, TDDDG- und UWG-Fundstellen.

Beide Vorlagen sind Muster, keine Rechtsberatung. Wer eine Anwendung hostet, passt sie an und ist für das Ergebnis verantwortlich.

Herkunft

Entstanden beim Bau von HungryCall, Ringedingeding und ResearchCall — drei Call-Agenten, bei denen ein Data-Flow-Audit zeigte, dass ein unverändertes Hosting ein Datenschutzvorfall mit angehängtem Namen gewesen wäre. Migriert aus dem eigenständigen huckepack-Repository in diese Skill-Bibliothek.