Seitenberichte-API-Referenz

Fünf Endpunkte auf einer laufenden Session beantworten strukturelle Fragen zu einer Seite, ohne je ein Modell aufzurufen: welche Consent-Plattform erscheint und was der Browser schon vor jeder Entscheidung hielt, wie der Baum des Agenten aussieht, wohin jedes Bedienelement führt, ob eine Kündigungsmöglichkeit erreichbar ist, und ein Bild der Seite. Alle fünf sind POSTs gegen eine Session-ID mit deinem bb_-Schlüssel als Bearer-Token, und alle fünf entstehen aus derselben Wahrnehmung, auf der auch der Agent arbeitet. Genau deshalb funktionieren sie auf einem Deployment, das Sessions hat und überhaupt kein Inference-Gateway.

Sie kamen mit Protokoll 1.5. Ein Client, der x-browserberg-protocol: 1.5.0 an einen älteren Server meldet, wird mit protocol_incompatible abgewiesen, statt die Lücke Route für Route zu entdecken. Ein Deployment, das die Berichte anbietet, führt reports im Array features von GET /v1/me; eines ohne sie registriert die Routen gar nicht, ein Aufruf bekommt also not_found.

Drei Fehler lohnen eine eigene Verzweigung. Ein Body, der die Validierung nicht besteht, ist invalid_request (400), mit den ersten zehn Schema-Beanstandungen in details.issues. Eine Session, die es nicht gibt oder die einer anderen Organisation gehört, ist not_found (404) — bewusst dieselbe Antwort für beides. Eine Adresse, die der Browser nicht öffnen kann, wegen DNS, TLS oder eines gesperrten Schemas, ist navigation_failed (422). Eine Seite, die einfach nie fertig lädt, ist dagegen kein Fehler: Nach fünfzehn Sekunden wird der Bericht so genommen, wie die Seite steht, und eine Zeile landet in warnings.

Eine Cookie-Zeile ist {name, domain, path, expiresAt, secure, httpOnly, sameSite?, thirdParty}. expiresAt ist ISO 8601, oder null bei einem Sitzungscookie, und thirdParty vergleicht die registrierbare Site des Cookies mit der der Seite. Eine Host-Zeile ist {site, requests, thirdParty}, wobei site die registrierbare Site (eTLD+1) ist: cdn.example.com und example.com fallen in eine Zeile mit einer Zählung zusammen. Sortiert wird nach Anzahl der Anfragen, die lauteste zuerst.

Der Sammler für Anfragen hängt vor der Navigation, nicht danach — nur deshalb tauchen die Dritten überhaupt auf, die eine Seite beim Laden anspricht. Cookies werden über Network.getAllCookies gelesen und, wo ein neueres Chromium das abgeschafft hat, über Storage.getCookies; antwortet keines von beiden, bekommst du eine leere Liste und eine Warnung dazu, niemals eine Schätzung. newCookiesAfterReject zählt die Cookies, die nach dem Ablehnen da sind und vorher fehlten, verglichen über Domain, Pfad und Name zusammen.

jsClickable kennzeichnet ein Element ohne eigene interaktive Rolle, das nur anklickbar ist, weil ein Skript darauf lauscht — üblich bei Portalen, die aus gestylten divs gebaut sind. hasAccessibleName ist false für ein Bedienelement, das weder ein Agent noch ein Screenreader beim Namen ansprechen kann, und das ist meist die nützlichste Zahl der Seite: Eine Oberfläche, deren halbe Schaltflächen namenlos sind, macht einem Agenten aus Gründen zu schaffen, die mit dem Modell nichts zu tun haben.

Der gerenderte text ist Seiteninhalt. Behandle ihn als nicht vertrauenswürdig und zäune ihn ein, bevor er in einen weiteren Prompt gerät — genau wie den Baum, den observe zurückgibt.

action ist das, was ein Agent mit dem Element täte — click, type, select oder scroll —, entschieden aus Rolle und Tag, nie aus einer Anweisung. destination ist {url, via, method?, target?, hasFileInput?, unresolved?}, und via hält fest, woher das Ziel stammt: href, ancestor-href, formaction, form, implicit-submit, script, wenn nur Code weiß, wohin es geht, oder none, wenn gar nichts gefunden wurde.

risk ist der Befund des Ziel-Wächters für dieses eine Element, einzeln beurteilt. Der Wächter hält sonst beim ersten blockierten Schritt eines Plans an, was für einen Plan richtig und für eine Zählung falsch ist, also läuft jedes Element für sich hindurch. off_site_submit, insecure_submit und unsafe_scheme werden schon unter der Standard-Policy verweigert und setzen blockedUnderDefault; off_site_navigation ist standardmäßig erlaubt — eine SSO-Weiterleitung verlässt die Site aus gutem Grund — und setzt nur blockedUnderStrict. Ein href mit Skript-Schema ist überhaupt kein Risiko: Alte Portale schreiben so etwas an jeden Tabellenlink, der Wächter lässt es in Ruhe, und der Bericht sagt nur, was er gesehen hat.

Gefolgt wird dem ersten Kandidaten, dessen Ziel eine Adresse hat und nicht auf eine andere registrierbare Site führt. Einem Kandidaten, dessen Ziel nur ein Skript kennt, kann man ohne Drücken nicht folgen, und eine Kündigung unbeaufsichtigt zu drücken ist genau das, was das Produkt verweigert — er wird also übersprungen, und eine Warnung sagt warum. followed ist deshalb in vier verschiedenen Lagen null: kein Kandidat gefunden, follow war false, alle Kandidaten führten weg von der Site oder waren skriptgesteuert, oder das Ziel ließ sich nicht öffnen.

Wurde eine Seite gefolgt, listet confirmationControls die Schaltflächen und Links darauf, deren Beschriftung nach dem bestätigenden Druck klingt — wieder der Kündigungs-Wortschatz, dazu die üblichen Bestätigungs- und Absende-Wörter auf Deutsch und Englisch. fields listet, was die Seite verlangt, als {role, name, required}, wobei required null ist, wenn die Seite dazu nichts gesagt hat. Das ist die interessante Hälfte für eine Verbraucherfrage: Eine Kündigung, die einen Klick entfernt ist und dann eine Kundennummer verlangt, ist eine andere Erfahrung als eine, die das nicht tut.