Nachschlagen

Was wir über eine Domain speichern

Geschrieben für Anwälte und Datenschutzbeauftragte. Jeder Fachbegriff wird dort erklärt, wo er zuerst vorkommt.

Diese Seite beantwortet eine Frage vollständig: Wenn MachineWitness eine Domain beobachtet, was genau landet im Archiv? Keine Zusammenfassung, sondern die tatsächlichen Felder. Wir gehen ein durchgerechnetes Beispiel durch, beispielfirma.example, vom Verbindungsaufbau unseres Beobachters bis zu dem Punkt, an dem ein Gericht den Datensatz Jahre später überprüfen könnte.

Bevor eine der unten genannten Dateien abgerufen wird, lesen wir die robots.txt der Domain und befolgen sie. Wo sie uns untersagt, eine Datei abzurufen, rufen wir sie nicht ab, und der Datensatz hält genau das fest: die Beobachtung dieses Tages wird als disallowed_by_robots aufgezeichnet, mit der Herkunftsangabe policy: robots_respected, anstelle einer Antwort. Das ist eine andere Aussage als die über einen Server, der nicht geantwortet hat, und das Archiv hält beides auseinander. Am 10. August 2026 betraf das rund 14.000 der 128.347 Domains des Rings, und zwar für die drei Dateien außer der robots.txt selbst. Wir könnten sie trotzdem abrufen (die Dateien sind öffentlich), und tun es nicht. Wie eine robots.txt gelesen wird, ist selbst datiert: bis zum 8. September 2026 werteten beide Zeugen sie mit Pythons urllib.robotparser aus, der älter ist als RFC 9309; Zeuge 2 liest sie seit dem 9. September 2026 nach RFC 9309 (protego), Zeuge 1 seit dem 11. September 2026. Die beiden Auswerter unterscheiden sich nur in Randfällen (Platzhalter, Vorrang der längsten Übereinstimmung); die aufgezeichnete Datei ist in beiden Fällen dieselbe, nur die Entscheidung, ob die übrigen Dateien abgerufen werden, kann an diesen Tagen abweichen.

Zwei Dinge vorweg. Erstens rufen wir nur ab, was jeder Browser ohne Anmeldung abrufen kann: eine Handvoll kleiner Regeldateien, die eine Seite für Maschinen veröffentlicht. Wir durchsuchen keine Seiteninhalte, folgen keinen Links in Anwendungen und zeichnen nichts über die Menschen auf, die eine Seite besuchen. Zweitens ist nichts davon geheim. Der Wert dieses Archivs liegt nicht darin, was es enthält (das könnte heute jeder selbst abrufen), sondern darin, dass wir es an einem bestimmten vergangenen Tag gehalten haben und nachweisen können, dass der Datensatz seither unverändert ist.

1. Was wir je Domain abrufen

Fünf Anfragen. Nichts weiter, niemals, für eine Domain in unserem breiten Ring.

Ressource	Was sie ist und warum sie rechtlich zählt
/robots.txt	Die älteste maschinenlesbare Anweisungsdatei des Webs. Sie sagt namentlich genannten Crawlern, welche Teile einer Seite sie abrufen dürfen. Da KI-Unternehmen die Namen ihrer Crawler veröffentlichen (GPTBot, ClaudeBot, Google-Extended und andere), ist diese Datei der Ort, an dem die meisten Seiten eine Ablehnung des KI-Trainings erklären, oder eben nicht erklären.
/ai.txt	Eine neuere, KI-spezifische Konvention für denselben Zweck. Noch nicht standardisiert, und gerade deshalb kann ihr Vorhandensein oder Fehlen an einem bestimmten Tag später bestritten werden.
/.well-known/tdmrep.json	Der förmliche maschinenlesbare Vorbehalt gegen Text- und Data-Mining (TDM Reservation Protocol, W3C). Nach Art. 4 Abs. 3 der EU-Richtlinie über das Urheberrecht im digitalen Binnenmarkt wirkt der Vorbehalt eines Rechteinhabers nur, wenn er maschinenlesbar ist; das OLG Hamburg hat im Dezember 2025 bestätigt, dass Bedingungen in natürlicher Sprache allein nicht genügen. Diese Datei ist der sauberste Weg, den Vorbehalt zu erklären.
/llms.txt	Eine aufkommende Konvention, die sich unmittelbar an große Sprachmodelle richtet.
/ (Startseite)	Wird nur wegen ihrer Antwort-Header und der ersten Kilobytes abgerufen, nie die ganze Seite. Manche Seiten erklären ihren TDM-Vorbehalt in einem HTTP-Header oder einer Meta-Angabe statt in einer Datei.

Jede Antwort ist durch eine harte Bytegrenze gedeckelt. Diese Dateien sind normalerweise wenige Kilobyte groß; die Grenze gibt es, damit ein falsch konfigurierter Server uns nicht dazu bringen kann, etwas Großes herunterzuladen.

Methodikänderung, wirksam ab 3. August 2026

Ab diesem Tag gelten für das Archiv die folgenden Regeln. Sie stehen hier ausdrücklich und werden nicht stillschweigend vorausgesetzt, weil eine Änderung der Methode ändert, wofür ein Datensatz von einem bestimmten Tag taugt. Nichts vor dem 3. August 2026 wurde geändert; für frühere Tage gilt die Methode, die galt, als sie versiegelt wurden.

Zwei Ringe. Die Regeln unterscheiden sich zwischen einem kleinen Kernring und einem großen breiten Ring. Der breite Ring ist durch ein genanntes Kriterium bestimmt, nicht durch Auswahl: alle EU-Domains innerhalb der Tranco-Top-1M-Liste, abgerufen am 2. August 2026. Der Kernring ist eine deutlich kleinere Menge von Domains, die enger beobachtet werden. Er wird von Hand zusammengestellt, und wir veröffentlichen dafür noch keine Kriterien; er ist deshalb als Arbeitsauswahl zu lesen, nicht als kuratiertes Verzeichnis.

Die vier Vorbehaltsdateien werden weiterhin täglich für jede Domain abgerufen. Das ist der Teil mit rechtlichem Gewicht, und er bleibt unverändert.
Die Startseite wird für Domains im breiten Ring wöchentlich abgerufen, nicht täglich. Die ehrliche Folge: Wo eine Seite ihren Vorbehalt ausschließlich in einer Meta-Angabe oder einem HTTP-Header der Startseite erklärt, ist unser Nachweis im breiten Ring wochengenau, nicht tagesgenau. Für den Kernring ändert sich nichts: dort wird die Startseite weiterhin täglich abgerufen.
Die Bytegrenzen unterscheiden sich je Ring. Kernring: ohne Deckel. Breiter Ring: 256 KB, alles darüber wird als truncated gekennzeichnet. Behalten wird immer der Anfang der Antwort, dort stehen diese Signale.
Fehlerantworten werden ohne ihren Inhalt aufgezeichnet. Statuscode, alle Header, Größe und Inhalts-Prüfsumme bleiben erhalten, sodass Tatsache und Gestalt des Fehlers nachweisbar bleiben; die Fehlerseite selbst wird nicht gespeichert. Eine Ausnahme: Inhalte von 403 Forbidden werden bis 32 KB behalten, weil eine an Crawler gerichtete Ablehnung manchmal auf dieser Seite steht.

Methodikänderung, wirksam ab 17. September 2026

Ab diesem Tag wächst der Bestand an drei Stellen. Wie bisher wurde nichts Früheres geändert: für Tage vor dem 17. September 2026 gilt die Methode, die galt, als sie versiegelt wurden. Der erste Crawl im neuen Umfang begann am 17. September 2026 um 03:00 UTC.

Der Kernring hat jetzt ein genanntes Kriterium. Bis zum 16. September 2026 war er eine von Hand zusammengestellte Arbeitsauswahl von 115 Domains. Seit dem 17. September umfasst er 1.133 Domains, die sich so zusammensetzen: 1.057 Domains von Organisationen in der EU, die publizieren und in Wikidata mit lebender Website verzeichnet sind, ob Zeitungen und Nachrichtenseiten, Rundfunkanstalten, Buchverlage, Nachrichten- und Bildagenturen oder Verwertungsgesellschaften, und deren Site zugleich ein an KI-Crawler gerichtetes Signal trug, das wir bereits beobachtet hatten: eine Regel für einen namentlich genannten KI-Bot in der robots.txt oder ein Content-Signal-Header. Sie liegen in 26 Mitgliedstaaten. Dazu kommen 43 weitere in Wikidata verzeichnete Publizierende, die schon vorher im Ring waren und kein solches Signal tragen; 14 Domains, die aus der früheren Auswahl mit genanntem Grund behalten wurden; 4 Domains, die ein solches Signal tragen, aber keinen Wikidata-Eintrag haben; und die 15 Domains des eigenen Unternehmens des Betreibers, als Kontrollreihe geführt statt versteckt. Für jede Kern-Domain nennt der Bestand jetzt die Organisation, ihr Land und ihre Wikidata-Kennung. Wo Wikidata eine Domain mehr als einer Organisation zuordnet, wurde die kürzeste Bezeichnung genommen und der Eintrag als ungeklärt markiert (61 Domains), zu korrigieren im Zuge der Kuration; die Domain selbst ist davon nicht berührt. Die Kernring-Regeln vom 3. August 2026, Startseite täglich und ohne Bytedeckel, gelten für alle ab dem 17. September. Der breite Ring ist unverändert. Eine Domain des eigenen Unternehmens des Betreibers, die im DNS nicht mehr auflöst, wurde am selben Tag aus dem Ring genommen, drei andere kamen hinzu; das Ring-Manifest dieses Datums führt jede Domain mit ihrem Ring auf.

Betreiber-Erklärungen. Für jeden von 13 Crawler-Betreibern (AI2, Amazon, Anthropic, Apple, Cohere, Common Crawl, Diffbot, DuckDuckGo, Google, Microsoft, Mistral, OpenAI, Perplexity) werden die vom Betreiber selbst veröffentlichten Erklärungen über seine Crawler, die Dokumentationsseite und die veröffentlichten IP-Bereiche (JSON), täglich und ohne Bytedeckel abgerufen und wie jedes andere Artefakt gehasht, versiegelt und verankert: 26 Adressen. Es wird nicht geprüft, ob ein Zugriff tatsächlich aus diesen Bereichen kam; bezeugt wird allein, was der Betreiber am Tag T erklärt hat. Wo eine Weiterleitung bestand, wird das Ziel aufgezeichnet, damit die Herkunftsangaben das Dokument tragen und nicht die Weiterleitung. Ausgelassen, mit genanntem Grund: Seiten, die einem Client ohne Browser nichts liefern (Metas Crawler-Dokumentation), weil eine leere Hülle nichts beweist.

Anbieter-Erklärungen. Auf demselben Weg die veröffentlichten Nutzungsrichtlinien, Bedingungen und Crawler-Richtlinien von 12 dieser Betreiber (AI2, Amazon, Anthropic, Apple, Cohere, Common Crawl, Diffbot, DuckDuckGo, Google, Meta, Microsoft, Mistral): 32 Adressen, täglich, ohne Bytedeckel. Zwei Betreiber, OpenAI und Perplexity, liefern diese Seiten einem Client, der kein Browser ist, nicht aus; ihre Bedingungen stehen deshalb nicht im Bestand, und das wird hier gesagt, statt die Lücke auf anderem Weg zu füllen. Zusammen sind sie das Gegenstück zu den Vorbehaltsdateien: was eine Site am Tag T vorbehalten hatte, und was der Betreiber am selben Tag über sein eigenes Verhalten erklärt hatte. Bewertet wird nichts: der Bestand hält den Text fest, kein Urteil darüber.

2. Was eine Beobachtung enthält

Eine Beobachtung ist eine Aufzeichnung einer Ressource zu einem Zeitpunkt. Hier ist eine vollständige für unsere Beispiel-Domain, in der Form, in der das Archiv sie hält.

Der Inhalt selbst

GET https://beispielfirma.example/robots.txt
→ HTTP 200, 412 bytes

User-agent: *
Allow: /

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

Genau die Bytes, die der Server ausgeliefert hat, unverändert und komprimiert gespeichert. Nicht unsere Zusammenfassung davon, keine Darstellung: die Bytes. Im Streit lautet die Frage nie „was steht in der Datei", sondern „was stand am 14. August 2027 darin".

Der Fingerabdruck

payload_sha256 = 9f2a41d7c8e05b3a…7d1e6084bb93c2f5
payload_size   = 412 bytes

Eine SHA-256-Prüfsumme ist ein kurzer Code fester Länge, berechnet aus genau den Bytes einer Datei. Ändert sich ein einziges Zeichen, ändert sich der Code vollständig, und es ist praktisch unmöglich, eine andere Datei mit demselben Code herzustellen. Er wirkt als Fingerabdruck einer ganz bestimmten Fassung eines Dokuments. Er ist zugleich das Aktenzeichen: der Inhalt wird unter seinem eigenen Fingerabdruck abgelegt, sodass sich nichts austauschen lässt, ohne dass die Beschriftung nicht mehr passt.

Die Umstände der Auslieferung

observed_at   = 2027-08-14 03:00:11 UTC
observer_id   = witness-1
status_code   = 200
final_url     = https://www.beispielfirma.example/robots.txt   (nach Weiterleitung)
http_version  = HTTP/1.1
headers       = content-type: text/plain; charset=UTF-8
                cache-control: max-age=600
                x-served-by: cache-fra-…
                (vollständige Antwort-Header, wortgetreu)
tls_version   = TLSv1.3
peer_cert     = subject:  *.beispielfirma.example
                issuer:   GlobalSign Atlas R3 DV TLS CA
                valid:    2027-06-01 → 2028-06-01
                sha256:   3b8c07f2ad91…e5240ac71f6b88
                (Fingerabdruck des Server-Zertifikats,
                 dazu die fünf oben ausgelesenen Felder)
peer_cert_chain = 3b8c07f2ad91…e5240ac71f6b88   (Server-Zertifikat)
                6f1d0ba47c33…9a7e1c40db2f51   (Zwischenzertifikat)
                c04e83fa1d67…2b95e7708aa361   (Zwischenzertifikat)
                (die Kette, wie der Server sie geliefert hat, in
                 dieser Reihenfolge; jedes Zertifikat vollständig)
observer_addr = die IP-Adresse, von der unser Beobachter verbunden hat
peer_addr     = die IP-Adresse, die geantwortet hat

Das ist, was Juristen die Beweismittelkette nennen: nicht bloß „diese Datei gab es", sondern „dieser Server hat, unter Vorlage dieses TLS-Zertifikats, diese Bytes zu diesem Zeitpunkt an diesen Beobachter ausgeliefert". Das TLS-Zertifikat zählt, weil es die Auslieferung an jemanden bindet, der ein Zertifikat für diese Domain erlangen konnte. All das wird gemeinsam mit dem Inhalt versiegelt, sodass sich kein Teil später austauschen lässt.

Was hier genau aufgezeichnet wird und was nicht. Seit dem 15. September 2026 speichern wir die vollständige Zertifikatskette, so wie der Server sie liefert: das Server-Zertifikat und die mitgeschickten Zwischenzertifikate, jedes vollständig, die Fingerabdrücke in der Reihenfolge ihrer Lieferung. Es ist keine Kette, die gegen unseren eigenen Vertrauensspeicher neu gebaut wurde: ein Zeuge zeichnet auf, was geliefert wurde; ob diese Kette gültig ist, ist die Frage des Prüfers, nicht unsere. Daneben zeichnen wir weiterhin den SHA-256-Fingerabdruck des Server-Zertifikats und die fünf oben gezeigten ausgelesenen Felder auf.

Die Änderung wirkt nicht zurück. Für Beobachtungen vor dem 15. September 2026 existiert nur der Fingerabdruck, nicht das Zertifikat; wird dieses Zertifikat gebraucht, lässt es sich in aller Regel unabhängig aus den öffentlichen Certificate-Transparency-Protokollen abrufen (RFC 6962), derselben Prüfinfrastruktur, auf die sich Browser stützen. Ältere Datensätze behalten den Stand, den sie damals hatten; es wird nichts nachträglich aufgefüllt. Damit ist die Zusage eingelöst, die diese Seite seit dem 1. August 2026 trägt.

Die Änderungsmarke

changed = true   (Fingerabdruck weicht von der vorigen Beobachtung ab)

Gesetzt, wenn der heutige Fingerabdruck derselben Ressource vom gestrigen abweicht. Sie ist der Grund, warum es dieses Archiv gibt: diese Dateien ändern sich lautlos, ohne öffentliche Historie, und die Änderung selbst ist oft die streitige Tatsache.

3. Wie eine fehlende Datei aussieht

Die Aufzeichnung „dort war nichts" ist ebenfalls ein Beweis und wird mit derselben Sorgfalt festgehalten wie ein Inhalt. Liefert unsere Beispiel-Domain keine ai.txt aus:

GET https://beispielfirma.example/ai.txt
→ HTTP 404, kein Inhalt gespeichert
   Status, vollständige Header, Inhalts-Fingerabdruck und
   TLS-Angaben wie oben aufgezeichnet

Diese Unterscheidung hat echtes Gewicht. „Die Seite hatte an diesem Tag keinen maschinenlesbaren KI-Vorbehalt veröffentlicht" ist häufig die entscheidende Tatsache in einem TDM-Streit, und sie lässt sich nur von jemandem zeigen, der nachgesehen und aufgeschrieben hat, dass er nichts fand. Zwei weitere Fälle werden ebenso ausdrücklich festgehalten: Ein Server, der unseren Beobachter abweist (HTTP 403), erzeugt einen Datensatz über die Abweisung, nicht über einen Inhalt; und eine Ressource, die uns die eigene robots.txt einer Seite zu holen untersagt, wird als bewusst nicht abgerufen festgehalten. Wir befolgen diese Anweisung und protokollieren, dass wir es getan haben.

4. Wie der Datensatz versiegelt wird

Ein Archiv, das von einer interessierten Partei geführt wird, beweist für sich genommen wenig: wir könnten unsere eigene Datenbank im Grundsatz umschreiben. Vier Schritte begegnen diesem Einwand, jeder unabhängig von den anderen.

Schritt 1 · am selben Tag

Alle Beobachtungen des Tages werden zu einer Zahl gebunden

Sämtliche an diesem Tag aufgezeichneten Fingerabdrücke werden paarweise, Ebene um Ebene, zusammengeführt, bis eine einzige Tageswurzel bleibt, die von jedem Datensatz darunter abhängt. Ändert man danach eine einzige Beobachtung, passt die Wurzel nicht mehr. Das ist die Konstruktion, die auch die öffentlichen Protokolle verwenden, mit denen Browser TLS-Zertifikate überprüfen (RFC 6962).

Schritt 2 · am selben Tag eingereicht

Diese Zahl wird außerhalb unseres Zugriffs hinterlegt

Die Tageswurzel wird noch am selben Tag bei OpenTimestamps eingereicht, das sie gebündelt in der Bitcoin-Blockchain verankert, und getrennt davon bei einer unabhängigen Zeitstempelstelle nach RFC 3161, die sofort ein signiertes Token zurückgibt. Seit dem 31. Juli 2026 kommt ein qualifizierter eIDAS-Zeitstempel hinzu. Keines davon können wir umschreiben. Das hebt das Siegel von einer internen Behauptung zu einem äußeren Nachweis: es zeigt, dass der Datensatz spätestens an diesem Tag bestand.

Stand des Bitcoin-Ankers: abgeschlossen am 7. August 2026. Die beiden Zeitstempelstellen geben ihren Nachweis sofort zurück, und diese Token liegen hier. OpenTimestamps arbeitet in zwei Stufen: die Wurzel wird sofort eingereicht, die entstehende Quittung wird aber erst dann für sich allein tragfähig, wenn die Bitcoin-Bestätigung in sie zurückgeholt ist. Bis zum 7. August 2026 hatten wir diesen zweiten Schritt nicht ausgeführt, und eine frühere Fassung dieser Passage sagte das auch. Er ist inzwischen für jeden versiegelten Tag auf beiden Zeugen nachgeholt, und ein täglicher Lauf erledigt ihn von da an, sodass die hier gespeicherten Quittungen auf Bitcoin-Blockköpfe verweisen statt auf Kalender-Server. Die Quittungen haben sich durch diesen Schritt geändert, das von ihnen Bezeugte nicht: die Prüfsumme, die jede Quittung bezeugt, wurde vorher und nachher festgehalten und ist für jeden Tag unverändert. Der Bitcoin-Weg hängt nicht mehr davon ab, dass jene Kalender-Server erreichbar bleiben. Die Anker nach RFC 3161 und der qualifizierte eIDAS-Zeitstempel waren durchgehend unberührt und stehen für sich.

Schritt 3 · am selben Tag

Die Wurzel wird veröffentlicht

Jede Tageswurzel erscheint in unserem öffentlichen Wurzelprotokoll, mit stabilen URLs und in maschinenlesbarer Form. Jeder darf sich am Tag des Erscheinens eine eigene Kopie nehmen; mehrere fremde Systeme erfassen sie automatisch.

Schritt 4 · in Betrieb seit 04.08.2026

Ein zweiter, unabhängiger Zeuge beobachtet dieselben Ziele

Ein getrenntes System, auf anderer Infrastruktur in einem anderen Land und mit anderem Betreiberschlüssel, zeichnet unabhängig auf und veröffentlicht seine eigene Tageswurzel. Keine der beiden Maschinen hält Zugangsdaten für die andere, und keine kann in die Datenbank der anderen schreiben. Zwei unabhängig geführte Aufzeichnungen sind schwerer beiseitezuschieben als ein Zeuge, der sich selbst wiederholt.

Zwei Grenzen, offen gesagt. Erstens begann das am 4. August 2026: jeder vom 22. Juli bis 3. August 2026 versiegelte Tag beruht allein auf dem ersten Zeugen, und das öffentliche Protokoll zeigt diese Lücke, statt sie zu verbergen. Zweitens sind die beiden Tageswurzeln bauartbedingt nie identisch: jeder Zeuge crawlt nach eigenem Zeitplan, die Menge der Beobachtungen hinter jeder Wurzel unterscheidet sich also. Ein Vergleich erfolgt deshalb Beobachtung für Beobachtung und nicht durch Abgleich zweier Wurzeln; identische Wurzeln wären sogar ein Anzeichen dafür, dass die beiden Systeme nicht unabhängig sind.

5. Was ein Beweisauszug enthält

Das Archiv ist bewusst nicht durchblätterbar. Was wir auf Anfrage für eine bestimmte Domain und einen Zeitraum erstellen, ist ein Beweisauszug: ein Paket mit

dem gespeicherten Inhalt jeder Beobachtung im Zeitraum, Byte für Byte;
den vollständigen versiegelten Umständen der Auslieferung, wie in Abschnitt 2 dargestellt;
dem Fingerabdruck jeder Beobachtung;
einem Zugehörigkeitsnachweis: einer kurzen mathematischen Quittung, die zeigt, dass genau diese Beobachtung in der Wurzel dieses Tages enthalten ist, überprüfbar, ohne uns zu vertrauen und ohne Zugang zum übrigen Archiv;
der Tageswurzel und den Quittungen der externen Zeitstempel;
einer Schritt-für-Schritt-Anleitung zur Überprüfung, der jeder fachkundige Sachverständige mit Standardwerkzeugen folgen kann.

Der Sinn des letzten Punktes gehört ausgesprochen: Der Auszug ist so gebaut, dass der Sachverständige der Gegenseite ihn überprüfen kann. Ein Nachweis, den nur eine Seite prüfen kann, ist kein Beweis.

Wie man einen Auszug anfordert, zu welchen Bedingungen er erteilt wird und was er kostet, steht auf der Seite Beweisauszug. Ob dieses Archiv eine bestimmte Domain überhaupt beobachtet, lässt sich vorab kostenlos mit der Abdeckungsprüfung klären.

6. Wenn jemand uns zur Löschung auffordert

Das meiste, was wir halten, enthält keine personenbezogenen Daten: es sind technische Regeldateien, die von Organisationen veröffentlicht werden. Betrifft ein berechtigtes Löschverlangen nach Art. 17 DSGVO doch einmal archivierte Inhalte, führen wir aus, was wir eine Löschmarke nennen: der gespeicherte Inhalt wird gelöscht und durch einen Marker ersetzt. Gelöscht heißt gelöscht, kein Backup holt ihn zurück.

Was bleibt, sind Fingerabdruck, Siegel und Nachweise. Die Folge gehört genau verstanden: danach kann niemand mehr erfahren, was in der Datei stand, aber es bleibt nachweisbar, dass eine Datei mit genau diesem Fingerabdruck an diesem Tag unter dieser Adresse stand und dass die umgebenden Datensätze dieses Tages unberührt sind. Den Fingerabdruck zu behalten stützt sich auf Art. 17 Abs. 3 Buchst. e DSGVO, denn ihn zu löschen würde die Nachweiskette für jede andere an diesem Tag versiegelte Beobachtung zerreißen, auch für solche unbeteiligter Dritter.

Auf Verlangen schließen wir eine Domain außerdem von jeder künftigen Beobachtung aus, mit oder ohne Löschung. Beides ist kostenlos, und beides braucht keine Begründung. Für einen Ausschluss bitten wir Sie allerdings, die Verfügungsgewalt über die Domain nachzuweisen: ein DNS-TXT-Eintrag oder eine Datei unter einem von uns genannten Pfad, was Ihnen leichter fällt. Nicht, weil das Verlangen einer Rechtfertigung bedürfte, sondern weil ein von jemand anderem verlangter Ausschluss eine Domain aus der Aufzeichnung nähme, ohne dass ihr Betreiber je davon erführe. Eine Löschung nach Art. 17 DSGVO kennt diesen Schritt nicht: dort fragen wir nur bei echten Zweifeln nach einer Identifizierung. Siehe Datenschutz und Crawler & Kontakt.

7. Was dieser Datensatz nicht beweist

Die Grenzen genau zu benennen gehört dazu, ein glaubwürdiger Zeuge zu sein.

Er zeigt, was ein Server unserem Beobachter zu den aufgezeichneten Zeitpunkten ausgeliefert hat. Über die Zeiträume zwischen den Beobachtungen sagt er nichts, und nichts darüber, was andere Besucher sahen.
Er zeigt Inhalt und Umstände der Auslieferung, nicht Urheberschaft, Absicht oder Rechtmäßigkeit. Ob ein Vorbehalt wirksam war, ob ein Crawler ihn beachtet hat und was daraus rechtlich folgt, sind Fragen für Anwaltschaft und Gericht.
Die externe Verankerung beweist, dass ein Datensatz spätestens zu seinem Ankerdatum bestand. Über frühere Zeitpunkte beweist sie nichts.
Eine fehlende Datei beweist, dass die Ressource zu diesem Zeitpunkt unter dieser Adresse nicht vorhanden war. Nicht, dass der Betreiber sich Rechte nie auf andere Weise vorbehalten hat.
Wir zeichnen öffentliche, maschinenlesbare Erklärungen von Organisationen auf. Wir beobachten keine privaten Daten, kein Nutzerverhalten und keine Einzelpersonen.

Wir sind der Flugschreiber, nicht der Ermittler. Was der Datensatz bedeutet, mögen andere ausstreiten.

Das obige Beispiel ist zur Veranschaulichung konstruiert. Ein durchgerechneter Auszug mit einer echten Domain, überprüfbar gegen das veröffentlichte Wurzelprotokoll, wird ergänzt, sobald diese Domain eine aussagekräftige Beobachtungshistorie angesammelt hat.