Proxy for Brave Search: Independent Index, Query Control and Measurement

What sets Brave Search apart from other privacy-focused front ends is that it produces most of its results from its own crawling and indexing infrastructure rather than taking them from another engine. Fed by anonymous contributions from participating browsers, this index works without a user account.

From a proxy point of view, the outcome becomes a simple picture: if there is no persistent profile identifying you on the server side, the signals that classify the request are limited to your exit address, the headers the connection carries and the parameters in the address bar. You can control all three.

The sections below take these three signals one by one; setup, verification and pacing follow. If you plan to compare engines, you need to learn where each one produces its results from, individually; as the result source changes, so does the weight of the proxy decision.

Where does a query travel before it reaches the front end?

When the request leaves the browser it carries three kinds of information: the target address, the network identity establishing the connection, and the request headers. The proxy changes only the second. The language list, client identification headers (user-agent and low-entropy client hints) and any local preferences remain unchanged; screen size, on the other hand, is not in a header but is derived from the viewport value read by the scripts on the page. The browser carries hints such as viewport or pixel density in the request header only when the site explicitly requests them with Accept-CH ; by default it does not. Changing the exit alone therefore does not produce the appearance of "a different user".

The second stop is the proxy server. On HTTPS traffic the only thing done here is to open a tunnel with CONNECT and carry the encrypted bytes; the content is not read. The front end sees that the request comes from this server and can classify the network the address belongs to. The basis for that classification is autonomous system information (ASN and IP reputation).

At the third stop, the query finds its match in the index. Because results from the in-house index and results supplemented from external sources can be combined on the same page, do not interpret small differences between lists obtained from two different exits directly as "regional differences". First take two runs with the same exit to measure the baseline noise, then change the exit.

The narrow-screen template changes the layout, not the result set

In an independent index, the match for a query is produced in a single place; when you switch to a narrow screen, what changes is not that match itself but the way it is presented. The domains returned remain largely the same, while the layout tightens, side blocks move into the list and the number of rows visible on the first screen drops. In practice, the distinction comes down to this: if the quantity you measure is "what position was it in", both templates give the same answer in most runs; if it is "was it on the first screen", the answer depends directly on the template. You can run position tracking as a single series; you cannot run visibility tracking that way.

The second and less well-known issue is how filter state is carried on a narrow screen. A Goggle or safe-search selection is attached to the query's link; even if the template changes, the rule continues to be applied as long as the link stays the same. The problem arises on a narrow screen when the link is shortened manually or the query is re-issued from the shortcut in the interface: the rule silently drops, the ranking reverts to its plain form, and you mistake that reversion for a template difference. Before closing the run, confirm that the name of the active rule is still displayed on screen and write it into the run log.

The template side and the network side are separate decisions: if you want to measure how a request coming from a carrier network is handled, the subject is no longer layout but the class of the exit, and mobile proxy is set up as a separate series for this.

Before deciding to run two series, clarify this: in your report, is the narrow-screen output a line in its own right, or a confirmation of the wide-screen result? If it is for confirmation, a weekly sample run is enough and you do not need to run both templates in every round. If it is a line in its own right, name the two series separately from the start; two series merged after the fact cannot be separated retroactively, because the template changed in between.

Finally, take data volume into account. The narrow-screen template usually carries fewer images, but running two series in parallel doubles total transfer. In a pool billed by quota, that difference shows up on the monthly invoice; limit the number of series to what you need and close unused profiles.

Narrowing the result with operators and Goggles

The cheapest way to reduce noise in measurement is to work on the query side, not the network side. Searching for an exact phrase in quotation marks, using site: to limit results to a single domain, or excluding an unwanted term narrows down the source of the difference between two runs. The more specific the query, the more interpretable the difference you see when you change the exit.

On top of this, Brave Search adds a layer called Goggles: publicly available rule sets that re-rank the result set. A Goggle pushes certain domains up or down; the query stays the same while the ranking criterion changes. If you do not record which Goggle was active during measurement, you risk attributing the difference between two runs to the exit country.

The third variable is the region and language selectors in the interface. These selectors can switch the list to another market independently of the exit address. If the exit country and the selector conflict, the resulting picture is no real user's view; set the two together and record both in your log.

Using operators has one more benefit beyond measurement: narrowing the result also reduces the number of requests you send. Writing two sharp queries instead of five broad ones both gives output that is easy to interpret and reduces the traffic passing through your exit. In pools billed by quota, that is a direct cost item (bandwidth calculation).

• Freeze the query set together with its operators; do not add operators later.
• Record the name of the active Goggle or filter in every run.
• Set the region selector in the same direction as the exit country.
• Fix the safe-search level; switching it off and on changes the set.

Which exit type suits which job?

The choice of exit type is considered along two axes: how large the pool is and how long you can stay on a single address. These two properties work against each other. A large pool frees you from being tied to a single address, but going out from a different address on every request breaks session consistency.

In a long-running monitoring series, address retention usually outweighs everything else. Looking through the same window for months with a single ISP exit produces a more readable series than going out from a different address in each round. If, on the other hand, you plan to place the output of different cities side by side, you need the city-level breakdown of a residential pool.

A rotating setup, meanwhile, is suitable for distributing load in jobs that carry no session and read public data. Using a setup that changes address on every request for rank tracking turns the measurement itself into a source of noise: you cannot tell whether the difference between two runs comes from the engine's movement or from the new exit.