Proxy für Brave Search: Eigener Index, Query-Kontrolle und Messung

Was Brave Search von anderen datenschutzorientierten Frontends unterscheidet, ist, dass ein Großteil der Ergebnisse nicht von einer anderen Suchmaschine übernommen, sondern aus der eigenen Crawling- und Indexierungsinfrastruktur erzeugt wird. Dieser Index, der aus anonymen Beiträgen teilnehmender Browser gespeist wird, funktioniert ohne Nutzerkonto.

Aus Proxy-Sicht ergibt sich ein übersichtliches Bild: Gibt es serverseitig kein dauerhaftes Profil, das Sie identifiziert, beschränken sich die Signale zur Einordnung der Anfrage auf Ihre Exit-Adresse, die Header der Verbindung und die Parameter in der Adresszeile. Alle drei können Sie kontrollieren.

Die folgenden Abschnitte behandeln diese drei Signale einzeln; danach folgen Einrichtung, Verifizierung und Tempomanagement. Wenn Sie vergleichen wollen, müssen Sie für jede Suchmaschine gesondert wissen, woher sie ihre Ergebnisse bezieht; mit der Ergebnisquelle ändert sich auch das Gewicht der Proxy-Entscheidung.

Welchen Weg nimmt eine Suchanfrage bis zum Frontend?

Wenn die Anfrage den Browser verlässt, trägt sie drei Arten von Informationen: die Zieladresse, die Netzwerkidentität der Verbindung und die Header der Anfrage. Der Proxy verändert nur die zweite. Sprachliste, Client-Kennungs-Header (User-Agent und Client Hints mit niedriger Entropie) sowie ggf. lokale Einstellungen bleiben unverändert; die Bildschirmgröße steht nicht im Header, sondern ergibt sich aus dem Viewport-Wert, den die Skripte der Seite auslesen. Hinweise wie Viewport oder Pixeldichte trägt der Browser nur dann im Anfrage-Header mit, wenn die Site sie über Accept-CH ausdrücklich anfordert; standardmäßig nicht. Deshalb erzeugt der bloße Wechsel des Exits noch kein Erscheinungsbild „eines anderen Nutzers“.

Die zweite Station ist der Proxy-Server. Bei HTTPS-Traffic geschieht hier nur eines: CONNECT öffnet einen Tunnel und transportiert die verschlüsselten Bytes; der Inhalt wird nicht gelesen. Das Frontend sieht, dass die Anfrage von diesem Server kommt, und kann das Netz einordnen, zu dem die Adresse gehört. Grundlage dieser Einordnung ist die Autonomous-System-Information (ASN und IP-Reputation).

An der dritten Station findet die Suchanfrage ihre Entsprechung im Index. Da Ergebnisse aus dem eigenen Index und aus externen Quellen ergänzte Ergebnisse auf derselben Seite zusammenlaufen können, sollten Sie kleine Unterschiede zwischen Listen aus zwei verschiedenen Exits nicht direkt als „regionalen Unterschied“ deuten. Nehmen Sie zuerst zwei Durchläufe mit demselben Exit, um das Grundrauschen zu messen, und wechseln Sie erst dann den Exit.

Das Schmalbild-Template ändert nicht die Ergebnismenge, sondern das Layout

In einem eigenständigen Index wird die Entsprechung einer Suchanfrage an einer Stelle erzeugt; beim Wechsel auf ein schmales Display ändert sich nicht diese Entsprechung, sondern ihre Darstellung. Die zurückgegebenen Domains bleiben weitgehend gleich, das Layout wird jedoch komprimiert, Seitenblöcke rücken in die Liste, und die Zahl der im ersten Bildschirm sichtbaren Zeilen sinkt. Praktisch läuft die Unterscheidung darauf hinaus: Messen Sie „auf welcher Position“, liefern beide Templates in den meisten Durchläufen dieselbe Antwort; messen Sie „war es im ersten Bildschirm“, hängt die Antwort unmittelbar vom Template ab. Positionsverfolgung können Sie in einer Reihe führen, Sichtbarkeitsverfolgung nicht.

Der zweite, weniger bekannte Punkt ist, wie der Filterstatus im Schmalbild mitgeführt wird. Die Auswahl eines Goggle oder der sicheren Suche wird an den Link der Suchanfrage angehängt; auch bei geändertem Template gilt die Regel weiter, solange der Link derselbe bleibt. Das Problem entsteht, wenn im Schmalbild der Link manuell gekürzt oder die Suchanfrage über die Verknüpfung in der Oberfläche neu gestellt wird: Die Regel fällt still weg, das Ranking kehrt in seinen Standardzustand zurück, und Sie halten diesen Rückfall für einen Template-Unterschied. Prüfen Sie vor Abschluss des Durchlaufs, dass der Name des aktiven Regelwerks noch auf dem Bildschirm steht, und halten Sie ihn im Durchlaufprotokoll fest.

Template-Seite und Netzwerkseite sind getrennte Entscheidungen: Wenn Sie messen wollen, wie eine Anfrage aus dem Mobilfunknetz behandelt wird, geht es nicht mehr um das Layout, sondern um die Klasse des Exits, und Mobile Proxy wird dafür als eigene Reihe aufgesetzt.

Klären Sie, bevor Sie sich für zwei Reihen entscheiden, Folgendes: Ist die Schmalbildausgabe in Ihrem Bericht eine eigenständige Zeile oder die Bestätigung des Breitbildergebnisses? Dient sie der Bestätigung, genügt ein wöchentlicher Stichprobendurchlauf, und Sie müssen nicht in jedem Durchlauf beide Templates fahren. Ist sie eine eigenständige Zeile, benennen Sie die beiden Reihen von Anfang an getrennt; zwei nachträglich zusammengeführte Reihen lassen sich rückwirkend nicht mehr trennen, weil sich das Template zwischenzeitlich geändert hat.

Berücksichtigen Sie schließlich das Datenvolumen. Das Schmalbild-Template überträgt in der Regel weniger Bilder, zwei Reihen parallel zu fahren verdoppelt jedoch die Gesamtübertragung. Bei einem nach Kontingent abgerechneten Pool zeigt sich dieser Unterschied auf der Monatsrechnung; begrenzen Sie die Zahl der Reihen auf Ihren Bedarf und schließen Sie ungenutzte Profile.

Ergebnisse mit Operatoren und Goggles eingrenzen

Der günstigste Weg, Rauschen in der Messung zu reduzieren, führt nicht über die Netzwerkseite, sondern über die Query-Seite. Eine wortwörtliche Phrase in Anführungszeichen zu suchen, mit site: auf eine einzelne Domain einzugrenzen oder einen unerwünschten Begriff auszuschließen, engt die Ursache des Unterschieds zwischen zwei Durchläufen ein. Je präziser die Suchanfrage, desto besser interpretierbar ist der Unterschied, den Sie beim Wechsel des Exits sehen.

Brave Search legt darüber eine Schicht namens Goggles: öffentlich zugängliche Regelwerke, die die Ergebnismenge neu ordnen. Ein Goggle zieht bestimmte Domains nach vorn oder schiebt sie nach hinten; die Suchanfrage bleibt gleich, während sich das Ranking-Kriterium ändert. Halten Sie bei einer Messung nicht fest, welches Goggle aktiv war, riskieren Sie, den Unterschied zwischen zwei Durchläufen dem Exit-Land zuzuschreiben.

Die dritte Variable sind die Regions- und Sprachauswahlen in der Oberfläche. Diese Auswahlen können die Liste unabhängig von der Exit-Adresse auf einen anderen Markt umstellen. Widersprechen sich Exit-Land und Auswahl, entspricht das entstehende Bild der Ansicht keines realen Nutzers; stellen Sie beide gemeinsam ein und dokumentieren Sie beide.

Der Einsatz von Operatoren hat über die Messung hinaus einen weiteren Nutzen: Ergebnisse einzugrenzen senkt auch die Zahl der gesendeten Anfragen. Statt fünf breiter Suchanfragen zwei präzise zu formulieren, liefert eine leichter interpretierbare Ausgabe und reduziert zugleich den Traffic über Ihren Exit. Bei nach Kontingent abgerechneten Pools ist das unmittelbar ein Kostenfaktor (Bandbreitenberechnung).

• Frieren Sie das Suchanfragen-Set samt Operatoren ein; fügen Sie nachträglich keine Operatoren hinzu.
• Halten Sie in jedem Durchlauf den Namen des aktiven Goggle oder Filters fest.
• Stellen Sie die Regionsauswahl auf dieselbe Zielrichtung wie das Exit-Land ein.
• Fixieren Sie die Stufe der sicheren Suche; ein Wechsel zwischen aus und ein verändert die Ergebnismenge.

Welcher Exit-Typ passt zu welcher Aufgabe?

Die Wahl des Exit-Typs denkt man entlang zweier Achsen: wie breit der Pool ist und wie lange Sie auf einer einzelnen Adresse bleiben können. Diese beiden Eigenschaften wirken gegenläufig. Ein breiter Pool befreit Sie von der Bindung an eine einzige Adresse, aber bei jeder Anfrage von einer anderen Adresse auszugehen, zerstört die Session-Konsistenz.

Bei einer langlaufenden Monitoring-Reihe überwiegt meist die Verweildauer auf der Adresse. Monatelang durch dasselbe Fenster zu schauen, über einen einzelnen ISP-Exit , erzeugt eine besser lesbare Reihe, als bei jedem Durchlauf von einer anderen Adresse auszugehen. Wollen Sie dagegen die Ausgaben verschiedener Städte nebeneinanderstellen, brauchen Sie die Stadtaufschlüsselung eines Residential-Pools.

Ein Rotating-Setup eignet sich dafür, die Last bei Aufgaben ohne Session-Bindung und mit öffentlichem Datenabruf zu verteilen. Ein Setup, das bei jeder Anfrage die Adresse wechselt, für die Ranking-Verfolgung einzusetzen, macht die Messung selbst zur Rauschquelle: Sie können nicht mehr trennen, ob der Unterschied zwischen zwei Durchläufen von der Suchmaschine oder vom neuen Exit stammt.