Zusammenfassung

  • Die neue Community Group will Grundsätze für den Import und Export von Browserdaten in einem Community Group Report festhalten. Sie schließt einen starren Implementierungsstandard aus und will keine Specifications veröffentlichen.
  • Fünf Unterstützer ermöglichten den Start. Unterstützung, Mitgliedschaft, Konsens, Bericht, Übernahme in den Standards Track, Rechtsverpflichtung, Herstellerzusage, Implementierung und geprüfte Interoperabilität sind jedoch unterschiedliche Beweisstufen.
  • Apples und Chromes dokumentierte Abläufe sowie der DMA-Kontext belegen reale Implementierungen und Regulierung. Sie erteilen der neuen Gruppe weder ein rechtliches Mandat noch belegen sie eine branchenweite Übernahme.

Ein realer Datentransfer mit engen Grenzen

Apple beschreibt für iOS 27 den Export ausgewählter Safari-Daten: Lesezeichen, Verlauf, Erweiterungen, Kreditkartendaten und Passwörter. Das Ergebnis ist eine unverschlüsselte ZIP-Datei, die nach dem Import gelöscht werden sollte. Die Chrome-Hilfe für iPhone und iPad erklärt anschließend die Auswahl der Datei, die Vorschau, den Umgang mit Passwortkonflikten und den Import. BrowserKit stellt zusätzlich systemvermittelte Import- und Exportfunktionen für Verlauf, Lesezeichen, Leselisten und Erweiterungen bereit.

Diese Unterlagen beweisen Funktionen bestimmter Versionen. Sie beweisen weder ein universelles Format noch eine Übertragung in jede Richtung. Ebenso wenig zeigen sie, dass Apple, Google oder Chrome der neuen Gruppe beigetreten sind oder einen künftigen Bericht umsetzen wollen.

Der öffentliche Auftrag der Gruppe setzt früher an. Browserentwickler und Implementierer sollen sich über Nutzerbedürfnisse beim Wechsel zwischen Browsern verständigen. Das geplante Ergebnis ist ein Bericht mit Import- und Exportgrundsätzen, der konsistentere Resultate über Geräte, Plattformen und Browser hinweg fördern soll. Zugleich heißt es ausdrücklich, dass kein starrer Implementierungsstandard festgelegt und keine Specification veröffentlicht werden soll.

Diese Begrenzung ist kein Kleingedrucktes. Sie beschreibt die derzeitige Befugnis.

Fünf Unterstützer sind keine Branchenmehrheit

Tom Fish schlug die Gruppe am 11. September vor. Als Unterstützer nennt die Startmeldung Dominique Hazaël-Massieux, Johannes Ernst, Bruce Lawson, Chris Riley und Tom Fish. Nach der W3C-FAQ reichen fünf Unterstützer aus, um eine Community Group zu starten.

Mehr sagt die Zahl nicht. Einen Start zu unterstützen bedeutet nicht, der Gruppe beizutreten. Eine persönliche Teilnahme bedeutet nicht, eine Organisation zu vertreten. Teilnahme bedeutet nicht Zustimmung zu einem Text. Ein Gruppenbericht bedeutet nicht, dass ein Hersteller Code liefern wird.

Am 20. September zeigte die öffentliche Seite einen Teilnehmer, Tom Fish, und noch keinen Vorsitz. Das ist eine Momentaufnahme; beides kann sich ändern. Für die Bewertung des Starts ist sie dennoch wichtig. Sichtbar waren noch kein Vorsitz, kein Berichtsentwurf, keine protokollierte Entscheidung, kein versioniertes Datenmodell und kein Prüfprogramm.

Zum Beitritt ist ein W3C-Konto nötig, aber keine W3C-Mitgliedschaft. Das W3C weist außerdem darauf hin, dass das Hosting weder eine Billigung der Tätigkeit noch eine Position seiner Mitglieder oder Beschäftigten bedeutet. Ein institutionelles Forum überträgt nicht automatisch institutionelle Autorität.

Zwischen Bericht und Standard liegt ein Verfahren

Der offizielle Vergleich der Gruppentypen ordnet Community Group Reports außerhalb des Standards Track ein. Community Groups erzeugen keine W3C-Standards. Soll die Arbeit später normativ werden, muss eine Working Group mit passendem Mandat sie in einem anderen Verfahren aufnehmen.

Mindestens sieben Zustände sind deshalb auseinanderzuhalten: offene Diskussion, Community Group Report, formaler W3C-Standard, regulatorische Pflicht, Herstellerzusage, Produktimplementierung und geprüfte Interoperabilität. Jeder Zustand hat einen anderen Entscheider und einen anderen Beleg.

Ein Bericht zeigt, was die Gruppe in einer bestimmten Fassung veröffentlicht hat. Ein Standard braucht das Standards-Track-Verfahren. Eine Rechtsverpflichtung braucht Norm, Gebiet, Adressaten und zuständige Behörde. Eine Herstellerzusage braucht eine überprüfbare Erklärung. Eine Implementierung braucht Produkt- oder API-Versionen. Interoperabilität braucht benannte Endpunkte, Testumgebung, Erfolgskriterien und dokumentierte Fehler.

Der Name W3C füllt fehlende Felder nicht aus. Umgekehrt belegt eine bereits ausgelieferte Funktion nicht, dass ein Multistakeholder-Verfahren ihr Design gebilligt hat.

Der DMA ist eine eigene Autoritätsquelle

Die Europäische Kommission stellte im Mai 2026 die Browserdatenportabilität auf iOS und iPadOS als Ergebnis eines zweijährigen regulatorischen Dialogs zum Digital Markets Act dar. Der Mechanismus arbeitet App-zu-App, durch Betriebssystem und Nutzer vermittelt, und umfasst unter anderem Lesezeichen, Verlauf, Passwörter, Kreditkartendaten und Erweiterungen. Einige Drittbrowser unterstützen laut Kommission bereits den Import aus Safari.

Die Verbindlichkeit dieser Entwicklung stammt aus dem Recht, nicht aus der Community Group. Artikel 6 Absatz 9 DMA richtet Portabilitätspflichten an Gatekeeper und betrifft Nutzerautorisierung, kostenlose Werkzeuge sowie in geeigneten Fällen kontinuierlichen Echtzeitzugriff. Geltungsbereich, Adressaten und Durchsetzung sind europarechtlich bestimmt. Ein künftiger Community-Bericht kann daraus keine weltweite Browserpflicht machen.

Regulierung kann eine Implementierung anstoßen. Implementierung kann einer Community Erkenntnisse liefern. Eine Community kann Grundsätze veröffentlichen. Die Wirkungsketten berühren sich, ihre Mandate bleiben getrennt.

Eine Portabilitäts- und Autoritätsquittung

Der künftige Bericht sollte jede wichtige Aussage mit einer prüfbaren Quittung verbinden. Sie nennt Ergebnisart, Status, Version, unveränderliche URL und Datum sowie Autoren, Gründungsunterstützer, aktuelle Teilnehmer, Organisationsvertretung, Interessen, Vorsitz und Redaktion. Auch Entscheidungsverfahren, Einwände und deren Behandlung gehören hinein.

Technisch müssen Datenkategorie, Exporteur, Importeur, Richtung und Auslöser sowie Grenzen von Gerät, Betriebssystem, Browser, Profil und Konto feststehen. Format, Verschlüsselung und Aufbewahrung sind besonders bei Zugangsdaten und Zahlungen entscheidend. Wer sich auf Recht beruft, nennt Rechtsgrundlage, Gebiet, reguliertes Unternehmen, Behörde und Geltungsdatum. Eine Herstellerübernahme braucht den Wortlaut der Zusage und die Berichtsversion. Eine Interoperabilitätsbehauptung braucht Produkt- oder API-Versionen, Umgebung, Erfolgskriterien, bekannte Fehler, Konfliktbehandlung, Abbruch und Rückweg.

Unbekanntes bleibt als unbekannt markiert. W3C-Hosting, ein bekannter Firmenname oder ein Exportknopf sind kein Ersatzbeleg.

Die Quittung soll eine frühe Diskussion nicht in eine Zertifizierungsstelle verwandeln. Sie verhindert nur, dass sich der Status einer Behauptung unterwegs verändert. Aus „wir wollen Grundsätze beraten“ wird nicht „wir haben einen Standard“. Aus „ein Produkt importiert“ wird nicht „der Hersteller hat den Bericht übernommen“. Aus einem erfolgreichen Testpaar wird keine allgemeine Browserinteroperabilität.

Ein glaubwürdiger erster Erfolg wäre ein versionierter Bericht, der seine Grenzen sichtbar macht: sensible Zugangsdaten von Lesezeichen trennt, Import und Export unterscheidet, Einweg- und Zweiwegpfade benennt und saubere Übergaben an Hersteller, Normung, Regulierung und Tests ermöglicht. Die Gruppe darf derzeit einberufen, beraten und berichten. Gerade die genaue Nutzung dieses Mandats kann ihr Gewicht verleihen.

Quellen