Warum wir keine Kopie Ihres Adressbuchs speichern

Der naheliegende Weg, ein Produkt zum Teilen von Kontakten zu bauen, ist: alles importieren. Jeden Kontakt aus jedem verbundenen Konto in die eigene Datenbank ziehen, diese als Wahrheitsquelle behandeln und Änderungen wieder hinausschreiben. Das macht die Entwicklung leichter: Abfragen sind schnell, man kontrolliert das Schema, und Synchronisierung wird zu „meine Datenbank gegen deren Datenbank abgleichen”.

Wir haben Rolyio bewusst nicht so gebaut. Ihre Kontakte leben bei Google und Microsoft. Rolyio speichert die Freigabebeziehungen und Berechtigungen — die Verknüpfungen zwischen den Kopien eines Kontakts über Konten hinweg — und keinen Spiegel Ihres Adressbuchs. Dieser Beitrag erklärt, was das konkret bedeutet und warum wir es für den richtigen Kompromiss halten.

Was wir tatsächlich speichern

Wenn Sie ein Konto verbinden und ein Label freigeben, enthält Rolyios Datenbank:

• Kontodatensätze und OAuth-Tokens — die Tokens im Ruhezustand mit AES-256-GCM verschlüsselt.
• Label-Metadaten — eine dünne Schicht über den echten Strukturen des Anbieters. Ein Label ist eine Google-Kontaktgruppe oder eine Outlook-Kategorie; wir speichern, welcher Gruppe bzw. Kategorie es zugeordnet ist und für wen es freigegeben ist.
• Freigaben und Rollen — wer auf welchem Label Ansehen, Bearbeiten oder Darf weiterteilen hat, einschließlich ausstehender Freigaben für Personen, die sich noch nicht angemeldet haben.
• Verknüpfungscluster — der Datensatz, der besagt: „Kontakt X im Google-Konto des Eigentümers und Kontakt Y im Outlook-Konto eines Empfängers sind dieselbe Person.” Das ist der Kern des Systems: Identitätszuordnung, keine Inhaltsspeicherung.
• Sync-Zustand — inkrementelle Sync-Tokens, Änderungs-Fingerprints für den Echoschutz und Zeitstempel für die Konfliktauflösung.

Was nicht dort liegt: eine Tabelle mit Ihren Kontakten. Läuft die Synchronisierung, fließen die Kontaktdaten durch die Sync-Engine von einem Anbieterkonto zum anderen, gesteuert von den Verknüpfungen und Rollen — sie setzen sich nicht in einem Lager auf unserer Seite ab.

Es gibt eine bewusste, eng begrenzte Ausnahme: Wird ein geteilter Kontakt gelöscht, bewahren wir einen Schnappschuss 30 Tage lang im Papierkorb auf, damit eine versehentliche Löschung — Ihre oder die eines Teammitglieds — wiederherstellbar ist. Nach 30 Tagen wird der Schnappschuss endgültig gelöscht. Das ist ein Sicherheitsnetz mit Verfallsdatum, kein Schatten-Adressbuch. (Sie können es auch selbst leeren; siehe Papierkorb und Wiederherstellung und Ihre Daten löschen.)

Warum Verknüpfungen Spiegel schlagen

Eine kleinere Angriffsfläche

Sicherheitsarchitektur beginnt mit einer unbequemen Annahme: Jedes System kann kompromittiert werden. Die Frage ist, was ein Angreifer bekommt. In einer Spiegel-Architektur lautet die Antwort: jeder Kontakt jedes Kunden — Namen, Telefonnummern, Beziehungen — versammelt in einer Datenbank. In einer Verknüpfungs-Architektur sind die Kontaktdaten, auf die es ein Angreifer abgesehen hätte, schlicht nicht da. Was existiert, sind Metadaten: welche Labels für wen freigegeben sind, plus verschlüsselte Tokens, deren Schlüssel getrennt von der Datenbank aufbewahrt wird.

Wir wollen kein Honigtopf sein. Die risikoärmsten Daten sind die, die man nie gespeichert hat.

Keine zweite Wahrheitsquelle

Jeder Spiegel widerspricht irgendwann seinem Original. Eine gespiegelte Kontaktdatenbank und Googles Kopie laufen auseinander — hier ein fehlgeschlagener Sync, dort eine Race Condition — und dann muss das Produkt entscheiden, welche Version die echte ist. Die Nutzer verlieren in beiden Fällen: Entweder zeigt das Tool veraltete Daten, oder schlimmer, es „korrigiert” die Kopie des Anbieters mit der eigenen veralteten Version.

Indem der Anbieter maßgeblich bleibt, umgeht Rolyio diese ganze Problemklasse. Was Sie in contacts.google.com oder Outlook sehen, ist die Wahrheit. Legen Sie eine Kontaktgruppe in Google an, erscheint sie in Rolyio; benennen Sie ein Label in Rolyio um, wird es in Google umbenannt. Die Aufgabe der Sync-Engine ist es, Änderungen zwischen den Kopien der Anbieter zu bewegen — mit Last-write-wins-Konfliktauflösung, die die Rollen respektiert, und fingerprint-basiertem Echoschutz, damit unsere eigenen Schreibvorgänge nie für Nutzeränderungen gehalten werden. Die Mechanik ist unter So funktioniert die Synchronisierung dokumentiert.

Freigaben, die enden, wenn sie enden

Verknüpfungen haben eine weitere Eigenschaft, die Spiegeln fehlt: Sie lassen sich günstig und vollständig kappen. Wenn Sie die Freigabe eines Labels aufheben, entfernt Rolyio die geteilten Kontakte aus den Adressbüchern der Empfänger und verwirft die zugehörigen Verknüpfungen. Es bleibt keine Restkopie der Empfängeransicht in unserer Datenbank zurück, weil es nie eine gab. Widerruf ist Subtraktion, kein Aufräumprojekt.

Dieselbe Logik gilt, wenn Sie Rolyio ganz verlassen. Ihr Adressbuch war nie in unseren Händen — es gibt also nichts zurückzuexportieren und nichts, bei dessen Löschung Sie uns vertrauen müssten. Das Löschen Ihres Kontos löscht Beziehungen und verschlüsselte Tokens, und Ihre Kontakte bleiben genau dort, wo sie immer waren: in Ihrem Google- oder Microsoft-Konto.

Was es uns kostet

Ehrlichkeit verlangt, auch die Nachteile aufzuzählen — wir bezahlen sie täglich:

• Die Synchronisierung ist schwerer zu bauen. Ohne zentrale Kopie muss jede Operation über N anbieterseitige Kopien nachdenken, die durch Verknüpfungen verbunden sind. Konfliktauflösung, Löschsemantik (Tombstones, die Rollen respektieren) und E-Mail-basierte Deduplizierung müssen alle in einem verteilten Umfeld funktionieren.
• Wir erben die Beschränkungen der Anbieter. Google bietet keine Push-Benachrichtigungen für Kontakte, daher synchronisiert die Google-Seite per Abfrage etwa alle 60 Sekunden mit inkrementellen Tokens. Microsoft Graph liefert uns Webhooks, die Microsoft-Seite ist also nahezu in Echtzeit — aber Graph lässt uns keine Kategorie umbenennen. Ein Spiegel könnte solche Asymmetrien übertünchen; wir machen sie sichtbar und konstruieren um sie herum.
• Manche Funktionen sind schlicht ausgeschlossen. Alles, was eine serverseitige Analyse Ihres gesamten Adressbuchs erfordert, kollidiert damit, dass wir Ihr gesamtes Adressbuch nicht haben. Wir betrachten diese Einschränkung als Feature.

Der Test, den wir anwenden

Wenn wir eine neue Fähigkeit bewerten, lautet die Frage: Lässt sich das aus Verknüpfungen, Rollen und Anbieter-APIs bauen, ohne dass sich Kontaktdaten auf unserer Seite ansammeln? Wenn ja, bauen wir es. Wenn nein, suchen wir eine andere Form. Ökosystemübergreifendes Teilen zwischen Google Workspace und Microsoft 365 — das prägende Merkmal des Produkts — hat diesen Test bestanden: Es braucht Identitätsverknüpfungen über Ökosysteme hinweg und rollenbewusste Synchronisierung, kein zentrales Kontaktlager.

Wenn diese Architektur dem entspricht, wie Infrastruktur Ihrer Meinung nach mit Ihren Daten umgehen sollte: Verbinden Sie ein Konto und schauen Sie sich an, was wir anfragen — die inkrementellen OAuth-Scopes erzählen dieselbe Geschichte wie dieser Beitrag.