Zusammenfassung

  • Am 24. August 2026 warnte die IAB, Alterskontrollen durch Dienste, Prüfunternehmen oder Netze könnten sensible Daten konzentrieren, Privatsphäre und Verschlüsselung schwächen, riskante Umgehungen fördern und das Internet entlang von Rechtsräumen zerteilen.
  • Ihr Zielbild ist schmaler: ein zweckgebundenes minimales Alterssignal, das keine Aktivität meldet, nicht websiteübergreifend verknüpft werden kann, dem Aussteller keine Ziele verrät und keinen zentralen Speicher sensibler Daten erzeugt.
  • Gerätebasierte Verfahren hält die IAB gegenwärtig für am aussichtsreichsten. Sie räumt aber ein, dass Geräte- und Betriebssystemanbieter beträchtlichen Einfluss erhalten; zudem brauchen gemeinsam genutzte Geräte eine belastbare Mehrbenutzerlösung.
  • Die Erklärung ist Architekturberatung, kein Gesetz, keine Produktzertifizierung, kein IETF-Standard und keine Einführungsanordnung. RFC 9998 ist ein gesonderter Workshopbericht; die dort wiedergegebenen Teilnehmerpositionen sind nicht automatisch Positionen von IAB oder W3C.
  • Eine tragfähige Ordnung braucht einen Austauschbeleg: Schutzziel, minimale Semantik und Beschwerdeweg müssen einen Wechsel von Gerät, Betriebssystem, Browser, Nachweismethode oder Anbieter überstehen.

Noch vor der Altersentscheidung wird Herrschaft verteilt

Altersnachweise werden gern als Genauigkeitsproblem beschrieben. Wie viele Minderjährige werden fälschlich zugelassen, wie viele Erwachsene abgewiesen? Das muss gemessen werden, doch der institutionelle Entwurf liegt bereits davor. Wer darf einen Nachweis verlangen? Welche Unterlagen gelten? Wohin fließen die Daten? Wer sieht den besuchten Dienst? Wer sperrt bei einem Fehler?

Prüft jede Website selbst, wird der Dienst zum Datensammler oder beauftragt einen Dritten. Blockiert das Netz nicht prüfende Angebote, muss der Zugangsanbieter Ziele erkennen und Regeln im Kommunikationspfad durchsetzen. Liefert das Endgerät ein Attribut, kann die Identität lokal bleiben; dafür wird die Geräte- und Betriebssystemschicht zur entscheidenden Zugangsinstanz.

Das sind keine beliebigen Einbauorte für denselben neutralen Schalter. Jeder Ort verteilt Haftung, Leckrisiko, Ablehnungsmacht und Marktzugang neu. Weniger Offenlegung gegenüber Websites kann mit stärkerer Plattformabhängigkeit erkauft sein. Was regulatorisch nach Vereinfachung aussieht, kann einen unabhängigen Browser von der praktisch anerkannten Schnittstelle ausschließen.

Die aktuelle IAB-Erklärung liefert kein fertiges Protokoll. Sie stellt die Beschaffungsfrage um: nicht zuerst, welcher Anbieter den heutigen Zeitdruck bedient, sondern welche Eigenschaften jede Technik einhalten und bei einem späteren Wechsel bewahren muss.

Warum Dienst- und Netzpflichten denselben Grundfehler teilen können

Die Fassung im IETF-Ankündigungsarchiv dokumentiert Datum und vollständigen Wortlaut. Die IAB teilt das Ziel, Kinder online zu schützen. Sie wendet sich gegen Mittel, die scheitern und zugleich eine verletzlichere Infrastruktur hinterlassen können.

Ein externer Altersprüfer kann Dokumente, Attribute und Zugangsentscheidungen in einem wertvollen Angriffsziel sammeln. Muss jede Website das Alter feststellen, vervielfachen sich Erhebungspunkte, und Identitätsabfragen werden beim Surfen normal. Auch eine bloße Altersklasse verhindert kein Tracking, wenn Protokolle, dauerhafte Kennungen oder Zielkenntnis beim Aussteller die Wege wieder zusammenführen.

Netzblockaden verschieben die Frage. Um einen Dienst ohne anerkannte Prüfung zu sperren, muss das Netz ihn identifizieren. Das erhöht den Sichtbarkeitsbedarf und damit den Druck auf Verschlüsselung, auf die Privatpersonen, Unternehmen und Staaten angewiesen sind. Der von der Erklärung genannte RFC 7754 behandelt Ort, Granularität, Kollateralschäden, Transparenz und Fehlerbehebung als technische Eigenschaften einer Filterarchitektur.

Umgehung gehört zur Sicherheitsbilanz. Wechselt ein Jugendlicher zu einem kostenlosen VPN unbekannter Herkunft, geliehenen Zugangsdaten oder einer App aus einem grauen Markt, kann die eine Schranke verschwinden, während Malware- und Diebstahlrisiken steigen. Die Zahl abgewehrter Aufrufe ist kein Ersatz für gemessenen Kinderschutz.

Unterschiedliche Rechtsräume verschärfen das Problem. Fordert jedes Land andere Daten, zertifizierte Anbieter oder Durchsetzungsorte, ziehen sich Dienste womöglich zurück. Rechtliche Souveränität ist territorial; eine starre technische Wahl kann sie in weltweit unterschiedliche Geräte, Clients und Dienstverfügbarkeit einschreiben.

Sieben Eigenschaften machen aus Identität ein enges Attribut

Die IAB nennt sieben Bedingungen. Offenbart werden soll nur ein minimales, zweckgebundenes Alterssignal. Der Mechanismus meldet keine Nutzeraktivität, erzeugt keine websiteübergreifend verknüpfbaren Signale und verrät der altersfeststellenden Stelle nicht die besuchten Ziele. Er schafft keinen zentralen Sensitivdatenspeicher, verursacht keine erheblichen Zusatzschäden für Menschen irgendeines Alters und nutzt offene, interoperable Schnittstellen.

Damit werden Rollen getrennt. Ein Aussteller verarbeitet genug, um ein Attribut festzustellen, erhält aber kein Surfprotokoll. Ein Dienst bekommt genug, um eine Regel anzuwenden, jedoch nicht automatisch die bürgerliche Identität. Zwei Websites bekommen keinen stabilen Griff, um ihre Beobachtungen zu verbinden. Das Gerät vermittelt eine Antwort, ohne zugleich Aussteller, Beobachter, Regelauswähler und universelle Sperrinstanz zu werden.

„Minimal“ muss in einem prüfbaren Schema stehen. Reicht für eine Handlung die Aussage, eine Schwelle sei erreicht, braucht es weder Geburtsdatum noch exaktes Alter, Dokumentart, Familienbeziehung oder frühere Prüfungen. Zweckbindung muss Felder, Lebensdauer, Protokollierung und Wiedergabeschutz erfassen.

„Offen“ ist mehr als veröffentlichter Quellcode eines Clients. Interoperabilität verlangt gemeinsame Anfrage- und Antwortsemantik, Fehlerzustände, Versionsaushandlung, Datenschutzmerkmale und Konformitätstests. Eine unabhängige Implementierung muss den Vertrag erfüllen können, ohne Kontensystem oder Identitätsdatenbank des ersten Anbieters zu kopieren.

Diese Eigenschaften beweisen weder die Legitimität jeder Altersregel noch ihre gesellschaftliche Wirkung. Sie begrenzen die Technik, wenn ein Rechtsraum eine solche Regel beschließt. So kann Architekturberatung Schäden beschreiben, ohne die politische Entscheidung an sich zu reißen.

Lokale Identität bedeutet noch keine lokale Kontrolle

Beim gegenwärtigen Reifegrad sieht die IAB gerätebasierte Verfahren als am aussichtsreichsten an. Die Formulierung ist bewusst vorläufig. „Aussichtsreich“ heißt weder „ausgewählt“ noch „bewiesen“. Kein Protokoll, Betriebssystem, Browser, Wallet, Aussteller oder Produkt wird zugelassen.

Der mögliche Vorteil ist klar. Eine Person könnte eine Alterseigenschaft einmal im Gerätekontext etablieren und später nur das enge Ergebnis zeigen. Websites erhielten nicht die volle Identität, der Aussteller sähe nicht jedes Ziel, und sensible Unterlagen müssten nicht in wenigen Servern zusammenlaufen. Die Vermittlung fände auf Hardware im Besitz des Nutzers statt.

Die Plattform kann dennoch festlegen, welche Beweise zählen, wie Haushaltsmitglieder dargestellt werden, ob ein anderer Browser gleichberechtigt zugreift, wie lange das Signal gilt, wie Fehler angefochten werden und welche Länder unterstützt sind. Sie kann eine Version beenden. Der Dienst interpretiert weiterhin das Ergebnis, der Aussteller kann Menschen ohne anerkannte Dokumente ausschließen.

Gemeinsam genutzte Geräte zeigen die Lücke sofort. Ein Familientablet hat kein einheitliches Alter. Erwachsene, Jugendliche und Kinder brauchen getrennte Zustände. Schwache Trennung lässt Minderjährige Erwachsenenrechte übernehmen; umständliche Trennung sperrt Erwachsene aus oder lädt zur Umgehung ein. Deshalb nennt die Erklärung robuste Mehrbenutzerunterstützung ausdrücklich.

Die offene Schnittstelle soll verhindern, dass lokale Vermittlung zur Plattformsouveränität wird. Jedes konforme Gerät, Betriebssystem oder jeder Browser sollte dieselbe Semantik umsetzen können. Die Website fragt ein definiertes Attribut ab, nicht das Konto oder Privatverfahren einer Marke. Im API-Schaubild ist das eine kleine Differenz; im Markt entscheidet sie über Wettbewerb oder eine Vertriebsmaut.

RFC 9998 und die IAB-Erklärung haben verschiedene Aussagegewichte

IAB und W3C veranstalteten den gemeinsamen Workshop im Oktober 2025. Die AGEWS-Seite beschreibt das Ziel, Architekturen zu vergleichen und ein gemeinsames Verständnis aufzubauen, ohne zwingend eine einzige Lösung zu finden. Datenschutz, Gleichbehandlung, Zentralisierung, Umgehung, Kosten, Genauigkeit, Jurisdiktion und Zensur gehörten dazu.

Der Call for Papers schloss die inhaltliche Entscheidung aus, welche Inhalte Regulierer begrenzen sollten. Untersucht wurde die technische Umsetzung und ihre Wirkung auf Internet und Web. Teilnahme gab es auf Einladung unter einer angepassten Chatham House Rule; als Ergebnis war ein Bericht vorgesehen.

Der Bericht erschien im Juni 2026 als RFC 9998. Er ist ein Informational-Dokument im IAB Stream, keine Internet-Standards-Track-Spezifikation. Zudem erklärt er, dass die wiedergegebenen Ansichten von Teilnehmern stammen, nicht zwingend IAB oder W3C vertreten und keinen Workshopkonsens beanspruchen.

Diese Grenze verhindert geliehene Autorität. Ein Workshopbeitrag kann wertvolle Evidenz sein, ohne institutioneller Beschluss zu werden. Die Erklärung vom 24. August ist die Nachricht, weil die IAB darin ihre eigene aktuelle Position formuliert. Der Bericht liefert Hintergrund, aber keinen IAB-Stempel für jede Äußerung.

RFC 7841 erklärt, dass nicht jeder RFC standardbezogen ist und Nicht-IETF-Streams im Regelfall weder IETF-weiten Last Call noch IESG-Genehmigung durchlaufen. Workshopbeobachtung, IAB-Erklärung, Spezifikationsentwurf, genehmigter Standard, Zertifikat, Rechtsgebot und Betrieb müssen getrennte Zustände bleiben.

Die IAB berät Architektur, sie erlässt kein Zugangsrecht

RFC 2850 chartert die IAB als Ausschuss der IETF und beratendes Gremium der Internet Society. Dazu gehören langfristige Architekturaufsicht, Aufsicht und Berufung im Standardsprozess, Beratung sowie externe Beziehungen.

RFC 9281 behält diese Rollenverteilung in einer jüngeren Übersicht bei: Die IAB dient allgemein als Quelle technischer, architektonischer, verfahrensbezogener und politischer Beratung. Sie ist weder Gesetzgeber eines Staates noch Produktprüfstelle.

Die Begrenzung macht die Warnung nützlich. Die IAB kann vor entstehender Abhängigkeit zeigen, dass eine Technologievorgabe Verschlüsselung bedrängt oder Identität konzentriert. Der Regulierer bleibt für Rechtsgrundlage, Umfang, Abhilfe und Ergebnis verantwortlich. Standardisierung definiert Semantik und Tests. Anbieter implementieren, Dienste wenden rechtmäßige Regeln an, Betroffene fechten Fehler an.

Jeder Akt beweist nur seinen Teil. Eine Erklärung belegt eine Architekturposition. Ein Standard belegt den Status einer Spezifikation. Ein Zertifikat belegt bestimmte Prüfungen. Ein Gesetz belegt eine territoriale Pflicht. Betriebsdaten belegen beobachtetes Verhalten. Kein Institutionensiegel ersetzt alle Belege.

RFC 3935 setzt eine weitere Grenze: IETF-Standards beschreiben die korrekte Umsetzung bei behaupteter Konformität; sie schreiben Nutzung nicht vor und überwachen sie nicht. Auch ein künftiger Altersstandard würde allein weder Rechtspflicht noch Wirksamkeit schaffen.

Ein Austauschbeleg gegen die Versteinerung

Die IAB nennt die schwere Ablösbarkeit einer von Anreizen und Abhängigkeiten umgebenen Architektur „Ossification“. Ergebnisvorgaben und interoperable Schnittstellen sollen besseren Verfahren später den Eintritt ermöglichen.

Daniel Kade schlägt dafür einen Austauschbeleg vor. Zuerst wird das Ergebnis ohne Anbietername definiert: betroffene Personen, Dienste und Rechtsraum, verlangte Zugangsentscheidung, erwarteter Sicherheitsgewinn, zulässige Fehler und Beschwerdeweg. „Anbieter X verwenden“ ist kein Ergebnis.

Danach wird der Signalvertrag festgehalten: Minimalfelder, Schwellenbedeutung, Kontext, Gültigkeit, Wiedergabeschutz, Unverknüpfbarkeit, Version und Fehlerverhalten. Mindestens zwei unabhängig kontrollierte Implementierungen müssen dieselben Konformitätstests bestehen. Braucht der Dienst für jeden Anbieter eine Privatintegration, existiert keine gemeinsame Schnittstelle.

Migration muss geprobt werden. Aussteller, Gerät und Browser werden getrennt gewechselt. Dabei ist zu prüfen, ob Offenlegung zunimmt, Haushaltszustände getrennt bleiben, Dienste das Signal weiter verstehen, Beschwerden möglich bleiben und alte Verknüpfungskennungen wertlos werden.

Schließlich öffnen Nachweise die Entscheidung neu: hohe Fehlablehnung, ungleicher Ausschluss, konzentrierte Lecks, gefährliche Umgehung, Verschlüsselungsdruck, Diensterückzug oder übermäßige Anbieterkonzentration. Das Mittel zu überprüfen heißt nicht, das Schutzziel aufzugeben. Es bewahrt die Chance, dasselbe Ziel mit weniger Schaden zu erreichen.

Quellen

  1. IETF Datatracker: IAB Statement on Age-Based Restrictions and Online Safety
  2. Volltext im IETF-Ankündigungsarchiv
  3. IAB-Ankündigungsindex
  4. Register der IAB-Erklärungen
  5. RFC 9998: Bericht des IAB/W3C-Workshops
  6. Statusseite zu RFC 9998
  7. IAB-Ankündigung zu RFC 9998
  8. AGEWS-Eintrag im IETF Datatracker
  9. Call for Papers des AGEWS-Workshops
  10. RFC 7754: Technische Überlegungen zu Sperren und Filtern
  11. Statusseite zu RFC 7754
  12. RFC 2850: Charta des Internet Architecture Board
  13. RFC 9281: Beteiligte im IETF-Standardisierungsprozess
  14. RFC 3935: Mission Statement der IETF
  15. RFC 7841: RFC Streams, Header und Statusbausteine