Das Web braucht keine Gatekeeper: Cloudflares neuer Vorschlag für „Signed Agents“
(positiveblue.substack.com)- Cloudflares Richtlinie zu Signed Agents wird zwar mit Sicherheit begründet, ist in der Praxis aber ein geschlossener Versuch, den Webzugang genehmigungspflichtig zu machen
- Das Web ist historisch dank Offenheit und Standards gewachsen, und geschlossene Technologien wie Flash und Silverlight wurden am Ende von offenen Standards wie HTML5 verdrängt
- Die wichtigsten Nutzer des Webs werden künftig KI-Agenten sein; dafür braucht es verteilte, überprüfbare Authentifizierungssysteme und aufgabenspezifische Autorisierung
- Das richtige Modell kombiniert kettenbasierte Delegation + nachweisbasierte Autorisierung pro Anfrage, um vertrauenswürdige Authentifizierung und granulare Zugriffskontrolle umzusetzen
- Nicht ein einzelnes Unternehmen sollte die Schlüssel in der Hand halten, sondern das Web muss durch offene Protokolle und Standards so erhalten bleiben, dass alle teilnehmen und innovieren können
Kritik an Cloudflares Signed Agents
- Cloudflare hat ein neues System für Signed Agents vorgeschlagen, doch faktisch ist es eine zugriffskontrolle auf Basis einer Positivliste
- Wenn ein bestimmtes Unternehmen darüber entscheidet, ob ein Agent registriert wird, ist das kein Internetprotokoll, sondern lediglich ein herstellerbasiertes Genehmigungsmodell
- Das widerspricht dem offenen Charakter des Internets, und „ein Formular ausfüllen und eine Erlaubnis erhalten“ kann kein Standard sein
Das Web muss offen bleiben
- Microsofts „embrace and extend“-Strategie der 90er Jahre ist gescheitert, und das war möglich, weil das Web offen geblieben ist
- Geschlossene Laufzeitumgebungen wie Flash und Silverlight wurden letztlich durch den offenen Standard HTML5 ersetzt
- Die Geschichte zeigt immer wieder, dass offene Standards Innovation fördern
Das Zeitalter der Agenten beginnt
- KI-Agenten werden die zentralen Nutzer des Webs sein und Informationssuche, Automatisierung, Bezahlungen und Vertragsverhandlungen übernehmen
- Die Grenze zwischen menschlichem und agentischem Handeln wird verschwimmen, weshalb delegationsbasierte Authentifizierungssysteme unverzichtbar werden
Authentifizierung und Autorisierung
- Authentifizierung: Wer handelt?
- Autorisierung: Was darf getan werden?
- Cloudflare verwechselt diese beiden Konzepte und versucht, alle Probleme mit einem „Pass“ zu lösen, was grundsätzlich unmöglich ist
- Eine korrekte Authentifizierung sollte über Delegationsketten und Signaturen pro Anfrage umgesetzt werden und verteilte Verifizierungsmechanismen wie die Veröffentlichung öffentlicher Schlüssel über DNS nutzen
Rechteverwaltung
- In bisheriger Software funktionierte das OAuth-Scope-Modell dank begrenzter Scopes gut
- Agenten sind jedoch universell einsetzbar, daher braucht es aufgabenbezogene Autorisierung (Task-Scoped Authorization)
- Beispiel: Die Berechtigung für „Abendessen bezahlen“ und die Berechtigung für „Ausgabenverlauf der letzten 3 Monate einsehen“ sollten selbst beim gleichen Agenten verschiedene Tokens haben
- Dafür lassen sich einschränkungsbasierte Tokens wie Macaroons und Biscuits sowie Policy-Engines wie OPA/AWS Cedar nutzen
Protokolle zuerst, ohne Gatekeeper
- Authentifizierung, Autorisierung und Monetarisierung sollten nicht von einem einzelnen Unternehmen kontrolliert werden, sondern auf offenen und interoperablen Standards basieren
- Wenn einige wenige Unternehmen über die Gültigkeit von Agenten entscheiden, wird das Web schnell zu einem Walled Garden
- Deshalb werden kettenbasierte Delegation, nachweisbasierte Autorisierung pro Anfrage und aufgabenbezogene Autorisierung als Open Source vorgeschlagen, damit sie von allen implementiert werden können
Fazit
- Die Zukunft des Webs hängt nicht davon ab, wer das Tor kontrolliert, sondern von Protokollen, die alle gemeinsam aufbauen und mit denen alle innovieren können
1 Kommentare
Hacker-News-Kommentare
Ich finde es frustrierend, dass zwar alle von einem völlig freien und offenen Web träumen, Menschen mit kleinen Blogs oder Inhalten in der Praxis aber kaum Möglichkeiten haben, sich vor AI-Training-Bots zu schützen. Zu glauben, man könne Agents und Training-Bots unterscheiden und diese würden dann
robots.txttatsächlich respektieren, wirkt unrealistisch. Selbst wennrobots.txtbeachtet würde, bliebe das Konzept bestehen, Daten indirekt unter dem Vorwand „licensed data“ einzukaufen. Einzelpersonen haben keine Macht, sofern sie nicht Unternehmen wie Reddit, X, Google oder Meta mit nahezu unbegrenzten juristischen Ressourcen sind. Dazu empfehle ich auch dieses interessante Video.Der Wunsch nach einem freien und offenen Web und gleichzeitig der Wunsch, AI-Training-Bots auszusperren, wirken auf mich widersprüchlich. Wenn das Web für alle offen sein soll, dann müssten auch AI-Training-Bots ohne Ausnahme darauf zugreifen können.
(Zum Traum vom offenen Web) Der Traum von offenen Inhalten im Internet ist real. Mein Blog ist so eingerichtet, dass jeder frei darauf zugreifen kann — Mensch oder Maschine. Da ich meinen Server außerdem selbst zu Hause hoste, sehe ich keinen besonderen Grund, zwischen Menschen und AI zu unterscheiden. Wenn man befürchtet, dass eine Website zu viele Zugriffe bekommt, dann ist in Wahrheit übermäßiger Traffic an sich das Problem — unabhängig davon, ob er von Menschen oder AI kommt. Ich nutze
robots.txtnur als minimale Orientierung, damit Bots nicht in Schleifen geraten, und lasse das Crawlen ansonsten frei zu. Auch Amazonbot besucht meine Seite häufig und ist jederzeit willkommen.Ich denke, wir sollten freie Software entwickeln, die gegen feindliche Software kämpft. Große Unternehmen entwickeln feindliche AI-Agents, und fähige Hacker sollten im Gegenzug Anti-AI-Agents entwickeln. Diesem Defätismus nach dem Motto „Wir haben keine Macht“ stimme ich nicht zu.
Hier auf Hacker News gibt es unzählige Ingenieure aus großen IT-Unternehmen, und trotzdem reden sie bei ihrer eigenen Arbeit nie über Privatsphäre und Data Governance, sondern schreien immer nur bei anderen Themen auf. Falls jemand einen Spiegel zur Selbstreflexion braucht: Ich wäre bereit, einen zu kaufen.
Ich verstehe gar nicht, warum überhaupt die Frage aufkommt, ob kleine Blogs oder Inhalte vor AI-Training-Bots geschützt werden müssen. Wenn schon die grundlegende Erzeugung von HTML schwierig ist und man deshalb schwere, komplexe Frameworks verwenden muss, die dann zu viel CPU verbrauchen, dann ist das das eigentliche Problem. Oder man glaubt, die eigenen Online-Texte seien der Weg zu Reichtum und Ruhm als Content Creator — dann mag die Sorge nachvollziehbar sein. Andernfalls sehe ich hier überhaupt kein Problem.
Realistisch betrachtet ist das „Web“ schon seit Langem nicht mehr offen. Die meisten Interaktionen, Veröffentlichungen und Informationsflüsse finden hinter Authentifizierung statt, also nach dem Login. Die meisten großen sozialen Netzwerke, Zeitungen usw. beschränken oder blockieren nicht authentifizierten Zugriff. Blogs machen am gesamten Informationskonsum normaler Nutzer nur einen winzigen Anteil aus.
AI-Agents an sich stören mich nicht, solange dahinter tatsächlich ein realer Nutzer steht. Was mich aber sehr stört, ist das aggressive Crawling meiner Seite durch Meta, Perplexity, OpenAI und andere. AI-Crawling verbraucht mehr Ressourcen als echte Nutzer oder sogar die Google-Suche. Dass CPU-Kerne durch AI-Crawling gebunden werden, ist wirklich extrem nervig.
Bei mir ist es genauso. Ich habe mehrere persönliche Apps online, und im letzten Monat hat ein AI-Bot 1,6 TB Daten abgesaugt, sodass ich den AI-Bot-Schutz von Cloudflare einschalten musste. Es kamen ununterbrochen mehr als 1,3 Millionen Requests pro Tag herein, was nicht mehr beherrschbar war.
Auf einigen meiner Marketing-Sites kommen 200 bis 300 Requests pro Sekunde herein. Es ist nicht mehr kontrollierbar — sogar zufällig generierte, nicht existierende URLs werden aufgerufen.
Ich frage mich, wie viele CPU-Zyklen durch das Web-Crawling von AI-Unternehmen verbrannt werden. Wenn über die Umweltfolgen von AI gesprochen wird, betrachtet man meist nur Training oder Inferenz im Betrieb. Man sollte aber auch die zusätzliche Last durch Web-Crawling einbeziehen. Für einen sinnvollen Vergleich müsste man das dem Szenario gegenüberstellen, in dem menschliche Nutzer die gleichen Aktionen direkt ausführen. Wenn Bots so gestaltet werden, dass sie Traffic effizienter erzeugen — also Tracker, Bilder und andere Zusatzbestandteile minimieren und nur das abrufen, was für die Zielanfrage nötig ist — könnte die CPU-Last insgesamt sogar geringer sein, als wenn die gesamte Menschheit Seiten direkt im Browser besucht.
Bei mir ähnlich: Gegen einen AI-Agent habe ich wenig einzuwenden, solange im Hintergrund ein echter Nutzer steht und nicht abnormal exzessiv zugegriffen wird. (Ich hatte zwar nicht beabsichtigt, dass AI-Agents meine Dienste nutzen, aber mir ist egal, wer sie wie verwendet.) Exzessives Crawling mag ich allerdings nicht. Noch wichtiger ist aber, dass jemand vielleicht einfach mit
curleine Datei herunterladen oder einen textbasierten Browser wie Lynx verwenden möchte. Auch solche Szenarien sollten weiterhin unterstützt werden.Cloudflare unterscheidet zwischen einem „von einem Nutzer initiierten Agent“, der erlaubt wird, und wahllosem Crawling zur Sammlung von Trainingsdaten. Die meisten Requests von Meta, Perplexity und OpenAI sind Web-Suchfunktionen, die auf echte Nutzerprompts reagieren, und diese Requests werden nicht für das Training des nächsten LLM-Modells verwendet. Cloudflare verwischt diese Unterscheidung absichtlich. Offiziell spricht man vom „Schutz der Creator“, tatsächlich baut man aber ein System auf, das von LLM-Providern eine Art Wegezoll kassiert und daraus Gewinn zieht. Ich denke daher, dass nicht Fairness, sondern finanzielle Motive im Vordergrund stehen.
Ich nutze einen seltenen Browser, der nicht viele persönliche Informationen preisgibt, und aus Sicht von Cloudflare sehe ich damit praktisch auch wie ein Bot aus. In einer Umgebung, in der der Host beziehungsweise Website-Betreiber über Zugriffsrechte entscheidet, kann es meiner Meinung nach keine Privatsphäre geben. Rate Limiting zum Schutz vor Serverlast finde ich in Ordnung, aber automatisierten Zugriff an sich zu blockieren, ist praktisch unmöglich — und am Ende erschwert man damit nur echten Nutzern den Zugang.
Mich würde interessieren, ob du aktuell oft wegen Cloudflare oder Turnstile blockiert wirst. Du hast es oben schon angedeutet, aber ich würde das gern ausdrücklich bestätigt sehen.
Wenn Menschen in diktatorischen Staaten VPNs nutzen müssen, um Privatsphäre und Freiheit zu wahren, wird das Internet zu einer Captcha-Hölle, die von zwei oder drei Unternehmen betrieben wird. Beim normalen Surfen mit VPN und datenschutzfreundlichem Browser habe ich mehr Probleme als mit meinem selbstgebauten Bot beim Zugriff auf Cloudflare-geschützte Websites. Und wenn Microsoft für Web-Gatekeeping zuständig wäre, wäre es noch schlimmer. Vor allem mit VPN und Microsoft-Captchas braucht man gefühlt fünf Minuten höchste Konzentration und fast schon eine wissenschaftliche Abhandlung, um überhaupt durchzukommen.
Natürlich haben auch Website-Betreiber Rechte. Ihnen vorzuschreiben, sie dürften sich aus Gründen der finanziellen Nachhaltigkeit nicht für Gatekeeping entscheiden, ist eine überzogene Forderung.
Ich nutze ebenfalls einen seltenen Browser und werde oft von Bot-Blockern erwischt. Trotzdem denke ich auch, dass Hosts das Recht haben, meine Requests frei zu behandeln. Gerade bei staatlichen Websites finde ich aber, dass ihre Pflicht, allen einen fairen Zugang zu ermöglichen, deutlich größer ist.
Falls es eine bessere, offenere Alternative gibt, würde ich sie gern hören. Aber was Cloudflare derzeit macht, löst das reale Problem der AI-Bots ziemlich gut. Man hat vorher schon versucht, das mit IP-Blockierung oder
user-agent-Filtern zu lösen, aber das hatte klare Grenzen. Und auch andere Sicherheitsprobleme wurden in der Praxis oft auf ähnlich zentralisierte Weise gelöst. Zertifizierungsstellen (certificate authorities) sind ebenfalls kein offenes System, und Attestation-Anbieter sind es auch nicht — trotzdem funktioniert es.Wenn man eine offenere Lösung will, könnte Regulierung die Antwort sein. Requests von Crawlern, die nicht explizit in
robots.txterlaubt sind, könnten gesetzlich verboten und von Behörden direkt verfolgt werden. Wenn ein Website-Betreiber Bot-Traffic nachweisen kann, könnte er dies dem Staat melden, der dann hohe Bußgelder verhängt. Cloud-Anbieter könnten verpflichtet werden, zu protokollieren, wer welche IP verwendet hat. Das ist keine 100%-Lösung, aber bei guter Umsetzung hätte es eine starke abschreckende Wirkung.Das ist vielleicht nicht die beste Lösung, aber realistisch gesehen eine, die in gewissem Maß funktioniert. Viele weisen auf das Zentralisierungsproblem hin, aber wenn Cloudflare es schafft, die wichtigsten AI-Unternehmen und CDNs einzubinden, könnte sich das de facto als Standard etablieren.
Zertifikate blockieren Menschen nicht, weil sie fälschlich für Bots gehalten werden.
Ich glaube eher, dass AI Poisoning — also AI durch absichtlich falsche Daten zu stören — ein wirksamerer Schutz ist. Cloudflare könnte sogar selbst einen Dienst anbieten, der AI-Bots absichtlich mit falschen Daten versorgt.
Tatsächlich wurden CAs vor Let's Encrypt oft nur bei gewöhnlichen Unternehmenswebsites und dann auch nur auf einigen Login-Seiten eingesetzt. Ohne die offene Politik von Let's Encrypt wären unsere persönlichen Daten wahrscheinlich immer noch ISPs oder Man-in-the-Middle-Angreifern ausgesetzt. Auch Attestation-Anbieter sind oft zahnlos, etwa wenn sie selbst bei breit bekannten Geräteschwachstellen aus geschäftlichen Gründen die Widerrufung verweigern. Insgesamt scheint die Debatte in den meisten Fällen keine wirklich gute Alternative zu finden. Dass Cloudflare zum Gatekeeper des Internets wird, ist eine schlechte Lösung, aber das zugrunde liegende Problem ist noch viel gravierender. Vollständig verteilte Lösungen existieren bereits (z. B. Remote Attestation, bezahlte Besuche/Abomodelle, selbstgehostete Firewalls). Die Haltung, die Nebenwirkungen von AI zu ignorieren und einfach nur die Kosten zahlen zu lassen, hat Cloudflare überhaupt erst weiter groß gemacht. Wenn ISPs Probleme wie Spoofing, DDoS oder Botnets nicht ignoriert hätten, wäre Cloudflare wohl nur ein Konkurrent wie Akamai geblieben.
Wir leben ohnehin schon in einer Welt mit zu vielen Gatekeepern. Jeder weitere Versuch, zusätzliche Gatekeeper einzuführen, sollte als aggressiver Schritt betrachtet werden. Cloudflare und Google bauen ihre Gatekeeper-Position beide weiter aus. Wenn dieser Trend anhält, würde ich gern sehen, wie beide vollständig scheitern.
Verschiedene Unternehmen versuchen, Lösungen für das AI-Bot-Problem anzubieten, und wenn Cloudflare ausgewählt wird, wird das enorme Gewinne bringen. Aber nur weil Cloudflare sich zurückzieht, verschwindet das Problem nicht — dann setzt sich eben eine andere schlechte Alternative durch. Gatekeeping ist letztlich eine Option, die ein Website-Betreiber aus eigenem Willen wählt, etwa per Paywall, selbstgebauter Bot-Erkennung oder Identitätsprüfung. Cloudflare bietet solche Dienste bereits an, und wenn daraus sogar ein Standard wird, entstehen mehr Wahlmöglichkeiten und ein offenerer Markt — inklusive der Nebenwirkungen. Die Freiheit des wirklich offenen Webs gilt nicht nur für Besucher, sondern genauso für Website-Betreiber.
Der „Wunsch“, in Zukunft Gatekeeper zu werden, ist bei Google überzogen formuliert. Google ist durch den Marktanteil von Chrome seit Jahren bereits Gatekeeper. Auch Firefox spielt kaum noch eine Rolle. Aus dieser Sicht lenkt Google das gesamte WWW schon lange in die Richtung, die es will (
uBlock-Verbot, Durchdrücken des.webp-Formats usw.).Bevor man die von einem einzelnen Unternehmen betriebene Allowlist problematisiert, sollte man bedenken, dass sich Website-Betreiber freiwillig für diesen Dienst entscheiden. Interessant ist die widersprüchliche Realität, dass man ideologisch über „Fairness“ diskutiert und gleichzeitig AI-generierte Comics im eigenen Blog veröffentlicht — AI ist im Alltag längst tief verankert.
Cloudflare implementiert derzeit den entstehenden Standard Web Bot Auth, und wir bei Stytch setzen denselben Standard auch auf IsAgent.dev ein. Die aktuelle Diskussion ist etwas überhitzt, deshalb bin ich vorsichtig, aber letztlich ist die Allowlist nur eine Option, die Cloudflare seinen Kunden anbietet. Der Kern — etwa HTTP Message Signatures — ist offen und dezentral konzipiert, sodass ihn jeder nutzen kann.
Es ist kein großes Problem, wenn man sich freiwillig für die Allowlist eines Unternehmens entscheidet, aber dadurch wird sie noch nicht zu einem Protokoll. Und die Debatte über Fairness und der Einsatz von AI-Comics haben logisch gesehen wenig miteinander zu tun.
Das wirkt wie eine Situation zwischen Pest und Cholera, in der die Gefahr besteht, dass die Lösung eines bestimmten Unternehmens faktisch als Standard zurückbleibt. Dies hätte ein Moment sein können, in dem ein echtes Protokoll beziehungsweise eine echte standardbasierte Lösung entsteht, doch Cloudflare versucht stattdessen, sein eigenes Blue Ocean zu schaffen. Und der Hinweis, dass jemand Fairness fordert und gleichzeitig AI in vielen Bereichen des Alltags einsetzt, ist ein treffender, ironischer Seitenhieb.
Ich sehe Ähnlichkeiten zur Struktur von E-Mail. E-Mail basiert zwar auf offenen Internetstandards, aber die meisten Nutzer sind bei einer winzigen Zahl von Dienstanbietern wie Gmail. Cloudflare drückt ebenfalls offene Standards, aber die tatsächliche Macht kommt aus der riesigen Zahl großer Kunden. (Dazu passt auch die Frage: Was wäre überhaupt eine gute Alternative?) Und so wie bei E-Mail durch Spam-Filter die Zustellzuverlässigkeit sinkt und die Implementierung schwierig wird, könnte auch das Web einen ähnlichen Weg einschlagen.
Das Web braucht keine Attestation, keine Signed Agents und kein Cloudflare, das entscheidet, wer ein „echter“ Agent ist. Alle sollten sich wieder bewusst machen, was „public“ bedeutet. Wenn die Verarbeitung von Traffic schwierig wird, sollte man im Idealfall einfach nur grundlegendes Rate Limiting einsetzen. Das Web muss nicht unterscheiden, ob der Anfragende ein Mensch, ein Bot oder ein Hund ist — solange die Ressourcen reichen, sollte es allen Bytes liefern. Wenn diese Essenz des „offenen Webs“ verschwindet, werden wir das alle bedauern.
Schon grundlegendes Rate Limiting ist anfällig für Angriffe. Botnets lassen sich nicht ignorieren, und mit IPv6 wird sinnvolles Rate Limiting praktisch unmöglich. Wählt man die Buckets falsch, vergeben manche Netzbetreiber /48-Präfixe viel zu großzügig und machen das Limit wirkungslos; gleichzeitig können bei Mobilfunknutzern Hunderttausende Menschen in einem einzigen Rate Limit landen.
Im Ergebnis hieße das nichts anderes, als dass zahllose kleine Websites schließen sollen, weil sie den Traffic nicht bewältigen können. Das widerspricht dem Slogan vom „offenen Internet“.
Moderne AI-Crawler sind inzwischen von bösartigen Botnets nicht mehr zu unterscheiden. Normales Rate Limiting hat damit keinen wirklichen Nutzen mehr, und genau deshalb versucht Cloudflare, das Problem anzugehen.
Die Behauptung „public heißt PUBLIC“ wäre schön, wenn der Betrieb mit einfachem Rate Limiting möglich wäre. In der Praxis müsste man aber die zulässige Zugriffsgeschwindigkeit offen angeben. Tatsächlich werden Anfragen jedoch oft schon allein wegen eines anderen
user-agentgeblockt, selbst wenn nur einmal zugegriffen wurde. Betreiber neigen also dazu, nicht das Verhalten des Bots zu beurteilen, sondern allein anhand seiner Identität jede Anfrage abzulehnen. Die Kriterien sind grob, erzeugen viele False Positives, und selbst dann werden keinerlei Umstände oder Kontexte berücksichtigt — man blockiert einfach nur aufgrund der Identität.Selbst grundlegendes Rate Limiting ist oft nicht leicht umzusetzen. Solange kein spezieller Nachweis oder keine Rechteübertragung nötig ist, sollte für öffentliche Dateien aus meiner Sicht weder Authentifizierung noch Delegation erforderlich sein. Und selbst wenn es solche Delegationsfragen gibt, muss außer dem eigentlichen Delegierenden kein Dritter wie Cloudflare eingreifen.
Ich stimme der Meinung des Autors größtenteils zu. In Enterprise-Umgebungen stellt sich die Frage, wie sich das Verhalten von Agents in komplexen privaten Netzwerken kontrollieren lässt. Ich habe kürzlich selbst ein auf Biscuit basierendes „Identity Token“-System gebaut. Damit kann man sich zunächst authentifizieren und danach Delegationstokens erzeugen, die auch an untergeordnete Agents weitergegeben werden können. In meinem System kann man ohne Authorization Token nichts tun (Single Scope, Single Use). Für das offene Internet könnte ich mir vorstellen, ein Authorization Token im Tausch gegen ein Identity Token plus eine Mikrozahlung zu vergeben, zum Beispiel eine sehr kleine Krypto-Transaktion. Dann hätten menschliche Nutzer praktisch keine spürbaren Kosten, während AI-Crawler viel zahlen müssten.