Local-first, verifizierbar — und ehrlich dabei

Die meisten Privacy-Seiten bitten dich, einer Policy zu vertrauen. Diese hier beschreibt Struktur: was der Client per Konstruktion tut, was er verweigert — und wo die ehrlichen Grenzen liegen. Jede Aussage unten ist ein Mechanismus, und einige haben einen offen benannten Preis — derselbe Register, den die Security-Seite hält.

Lokal per Default; Egress ist der Einwilligungsmoment#

Lokale Ausführung ist der Default. Ein Workflow läuft, ein Modell trainiert, ein Commit landet, ohne dass ein Server erreichbar sein muss — die Plattform verbessert Zusammenarbeit und Verteilung, aber Solo-Compute braucht sie nie. Kein Netzwerk-I/O passiert ohne explizite Einwilligung, und jede erteilte Einwilligung wird in die Provenienz des Laufs gestempelt: Was das Gerät verlassen hat, wann und wohin, ist ein Protokoll, keine Erinnerung. Die Einwilligung selbst ist offline-first: lokal erteilt, später synchronisiert, nie auf einen Server wartend.

Die Richtung zählt. Ein Connector, der deine eigenen Daten hereinholt, ist ein konsentierter Fetch, dessen Bytes danach schlicht auf deinem Gerät liegen — weiterhin local-first. Daten, die das Gerät verlassen, sind etwas anderes: Egress ist eine separate, stärkere, mit Ziel benannte Einwilligung und reitet nie auf einer Ingress-Einwilligung mit. Ein Dataset hereinzuholen autorisiert nicht stillschweigend, etwas hinauszusenden — eine Unterscheidung, um die die Connectors herum gebaut sind.

Abb. 1 — Die Einwilligung nennt das Ziel. Bevor ein einziges Byte geht, siehst du, was gesendet wird, wohin es geht und was es kostet — und die einmalige Erlaubnis für genau dieses Ziel steht im Protokoll des Laufs. Daten hereinzuholen erlaubt nie, etwas hinauszusenden.

Keine Analytics, eine Allowlist#

Das Studio liefert null Third-Party-Analytics aus — kein Tag, kein Beacon, kein Session-Replay. Das ist nicht bloß Zurückhaltung; der Browser erzwingt es. Die Content-Security-Policy der Produktion trägt eine einzige connect-src-Allowlist, abgeleitet aus der Konfiguration der Plattform und durch einen Test abgedeckt: die Plattform-API-Origins plus die eingebauten LLM-Provider, die du mit eigenem Key aktivieren kannst. Eine Anfrage an jede andere Origin verweigert der Browser selbst.

text

# Production CSP, connect-src — one derived allowlist (illustrative shape):
connect-src
  'self'                     # the app's own origin
  <platform API origins>     # catalog sync + content objects
  <built-in LLM providers>   # only with your own key, behind a consented effect
# No analytics host. No telemetry host.
# Any other origin: the browser refuses the request before it leaves.

Weil die Allowlist abgeleitet statt handgeschrieben ist, ist ein neues Connect-Ziel eine bewusste Code-Änderung mit einem fehlschlagenden Test auf der anderen Seite — keine stille Bearbeitung.

Credentials verlassen das Gerät nie#

Geheimnisse, die du einem Connector gibst — API-Keys, OAuth-Tokens, SSH-Keys — liegen clientseitig in einem verschlüsselten Speicher: WebCrypto AES-256-GCM, per Default unter einem gerätegebundenen, nicht extrahierbaren Schlüssel. Sie werden nie synchronisiert, nie in die Sync-Warteschlange gelegt und nie in Provenienz gestempelt; die Maschinerie, die deine Arbeit repliziert, kann deine Geheimnisse strukturell nicht mitnehmen. Zwei OAuth-Flows werden absichtlich an entgegengesetzten Orten gespeichert: Ein Drittdienst-Token bleibt auf deinem Gerät, während die Plattform beim Austausch nur zustandsloser Vermittler ist — meldest du dich hingegen bei Scellis selbst an, delegiert die Identität an GitHub OAuth mit einer kurzlebigen serverseitigen Session. Entgegengesetzte Bedrohungsmodelle, entgegengesetzte Speicherorte. Die eine benannte Ausnahme — ein Relay, das sich für Protokolle, die ein Browser nicht spricht, als du authentifizieren muss — wird pro Verbindung konsentiert und hält das Credential nur im Arbeitsspeicher.

Signierte Packs, delegierte Identität#

Ein Pack ist signiert und wird verifiziert. Der Import prüft Hashes — die Bytes müssen zum behaupteten Content-Hash passen — und Signaturen werden gegen ein Register vertrauenswürdiger Signierschlüssel geprüft. Trust-Signale sind Policy-Eingaben: Sie bestimmen mit, was eine Workspace-Policy erlaubt, und verleihen aus sich heraus nie ambiente Fähigkeiten. Dein Signierschlüssel ist ein im Browser erzeugtes Ed25519-Paar, und seine private Hälfte verlässt das Gerät nie. Zusammen mit clientseitigen Credentials hat das eine ehrliche Konsequenz:

Hinweis

Verlierst du das Gerät, überlebt deine Identität — melde dich auf neuer Hardware wieder per GitHub OAuth an. Die gerätelokalen Geheimnisse überleben nicht: Connector-Credentials und der private Signierschlüssel werden neu eingegeben und neu registriert, nicht wiederhergestellt. Serverseitig liegt nichts Geheimes, also lässt sich serverseitig auch nichts Geheimes wiederherstellen. Das ist eine Sicherheitseigenschaft — ausgesprochen, keine Entschuldigung.

Löschen zerstört einen Schlüssel, nicht die Historie#

Sync läuft über append-only Oberflächen — Change-Events, Run-Logs — und append-only ist ein Versprechen, das sich nicht leise brechen lässt. Also tragen diese Oberflächen überhaupt keine rohen persönlichen Identifikatoren: Die Akteur-Referenz ist ein gesalzenes, geschlüsseltes Commitment, auflösbar nur über einen Schlüssel pro Person. Eine Löschung nach DSGVO zerstört diesen Schlüssel. Die Historie wird nicht umgeschrieben — sie wird dauerhaft unlesbar als du, und genau das macht eine Löschgarantie mit einem append-only Log vereinbar.

Die ehrlichen Ränder#

Die ehrlichen Ränder stehen dabei, statt versteckt zu werden. Ein Hash persönlicher Daten ist weiterhin ein persönliches Datum — pseudonymisiert, nicht anonymisiert — und das Design tut nie so, als wäre es anders. Aufzeichnungen, die das Gesetz verlangt, werden zugriffsbeschränkt statt gelöscht und laufen mit ihrer gesetzlichen Frist ab. Inhalte, die du veröffentlicht hast, bleiben unter einem anonymisierten Autor-Tombstone erhalten, damit nichts zerbricht, was darauf aufbaut — und der Server behält sie alle, statt zu raten, welche davon Abhängige haben; das ist die sichere Richtung, und wir sagen sie so. Alles Private wird mit deinem Schlüssel geschreddert; und Kopien, die bereits auf fremde Geräte synchronisiert sind, lassen sich nicht zurückrufen. Die volle Liste steht auf der Honest-Limits-Seite.

Ehrlichkeit im föderierten Modus#

Scellis kann ein Modell über viele Geräte hinweg trainieren, ohne die Rohdaten zu bewegen. Die verlockende Aussage — „deine Daten verlassen das Gerät nie“ — ist genau die Art Aussage, die diese Seite nicht leichtfertig macht.

Achtung

Das rohe Dataset verlässt das Gerät nie, Modell-Updates aber schon — und ein Update ist eine verlustbehaftete, manchmal invertierbare Funktion der Daten. „Daten verlassen das Gerät nie“ stimmt für die Bytes und nicht für die Information — außer Differential Privacy, Gradient Clipping und Secure Aggregation sind aktiv.

Deshalb behandelt der föderierte Modus das nicht als Option. Ein Update zu senden ist selbst ein einwilligungspflichtiger, in Provenienz gestempelter Egress und verlangt immer bilanzierte Differential Privacy mit Clipping — verwaltet von einem monotonen (ε, δ)-Privacy-Budget, das Überziehung verweigert, statt davor zu warnen. Secure Aggregation kommt überall dazu, wo Kohortengröße und Fluktuation es erlauben; das regulierte Regime läuft nur mit permissionierten Peers. Ist das Budget aufgebraucht, läuft die Runde nicht. Das ist die Vertrauensgrenze, auf der der verteilte Compute-Pfad aufbaut.

Abb. 2 — Nichts geht unbeschnitten und unverrauscht hinaus. Secure Aggregation kommt überall dazu, wo die Kohorte es zulässt — und wo nicht, erfährst du es, statt beruhigt zu werden. Das Privacy-Budget kennt nur eine Richtung, und an der Obergrenze wird die Runde verweigert statt überzogen.

Dieselbe Disziplin regelt, wer handeln darf. Jede Anfrage an die Plattform trägt eine serverseitig abgeleitete Aufrufer-Klasse — UI, Copilot, Headless, API-Key, Login-frei oder externer Agent —, die kein Client fälschen kann, und jedes Verb ist als read, write oder destructive klassifiziert. Reads sind auto-erlaubt; ein Write braucht ein explizites Consent-Token, das die konkrete vorgeschlagene Operation zeigt; eine destruktive Aktion braucht Bestätigung und ein Rate-Limit. Geldbewegende Verben stehen ganz außerhalb dieser Leiter: Sie sind UI-only und verweigern jeden Nicht-UI-Aufrufer, sodass kein Agent — deiner oder irgendeiner — je dein Geld ausgeben kann. Wie eine API-Oberfläche UI, Copilot und externe Agenten gleichermaßen bedient, ist Thema der Agent-Oberfläche. Das ist die Form der ganzen Seite: Die Garantie ist strukturell, wo sie es sein kann, und wo nicht, steht die Grenze im Klartext.