Browser Privacy Test Matrix: A Measured Lab Comparison

What this browser privacy test observed

This browser privacy test compared three automated browser engines on one host, using repeated HTTP address observations and WebRTC candidate gathering. We varied a local HTTP proxy setting and, for Chromium, a verified extension-controlled IP-handling policy. The dataset preserves the individual runs, including unavailable observations, instead of converting the experiment into a single privacy score.

The main browser privacy test finding concerns the distinction between visible candidates and adequate coverage. Chromium's restrictive policy produced completed gathering with no candidates, while the default policy exposed mDNS host candidates. Restoring the default policy restored that output in the measured configuration. Neither result supplied a server-reflexive address comparison, so neither established a general leak verdict.

The browser privacy test also recorded a material control failure: an independent host-side STUN request did not receive a validated binding response within its deadline. This prevents attributing missing public ICE evidence solely to browser behavior. The study retains that limitation prominently because a reassuring-looking empty result is particularly easy to overinterpret.

The table summarizes the final browser privacy test runs. Each condition was attempted three times. Candidate counts refer to distinct address, related-address, type and transport combinations retained before gathering completed or the twelve-second window ended. Ports and priorities are excluded from that identity. An empty end-of-generation event is recorded separately and is not counted as a network candidate.

This browser privacy test ran from 2026-09-28T18:07:25.784Z to 2026-09-28T18:12:40.777Z (UTC). Engine versions: Chromium 151.0.7922.34; Firefox 153.0; WebKit 26.5. Playwright 1.62.1, Darwin 25.6.0, arm64. Counts separated by slashes show repetitions one, two and three; observed fractions use three attempts as the denominator.

The browser privacy test retained no numeric host, server-reflexive, peer-reflexive or relay observations in this run. Firefox reported error code 701; the other engines did not supply that error code before their recorded ending states. All successful site-address and same-family HTTP comparisons matched. These are observations within this dataset, not proof of identical routing or complete privacy coverage.

Download the browser privacy test's aggregate observation record and measurement script. Reading this browser privacy test page does not start those measurements. The files identify the method and retained observations; they contain no raw addresses, address hashes, mDNS names or session descriptions from the experiment.

The browser privacy test environment

The browser privacy test used Playwright's bundled Chromium, Firefox and WebKit builds in headless mode on macOS. These are automation engines, not a sample of installed Chrome, Firefox and Safari products in ordinary user profiles. Engine versions and the runner version are recorded in the dataset. The distinction follows Playwright's browser documentation.

For a comparable browser privacy test, all Chromium conditions used the same full Chromium headless channel. Every condition started with a new temporary persistent profile and no granted camera, microphone or geolocation permission. The restrictive condition loaded one purpose-built extension; the reset condition loaded the same extension and verified the default policy before collecting its runs.

This browser privacy test left operating-system routes unchanged. It did not inventory every physical interface, establish a VPN-off state, or move the host to a second provider. The proxy was a local CONNECT forwarder using the same host's outgoing connections. It changed a browser setting and application path without claiming a separate physical network or exit location.

No account history, browsing history or installed personal extensions were included in the browser privacy test profiles. Temporary profiles were deleted after the run. These choices reduce uncontrolled profile differences, but they also limit relevance to real users whose policies, extensions, permissions and previous browser state differ from this deliberately small laboratory setup.

How the browser privacy test was performed

Each browser privacy test repetition opened the real HTTPS WebRTC-tool page before running the published measurement function in that origin. The function created one peer connection, one data channel and a local offer. It configured Cloudflare's named STUN endpoint, used no TURN server, and exchanged no session description with a remote peer.

The browser privacy test requested three HTTP observations in parallel with candidate gathering: the address reported by this site, an IPv4-specific ipify request and an IPv6-specific ipify request. Each HTTP operation had an eight-second deadline. Statuses distinguish an observed address from a transport error, a timeout, an HTTP error or an invalid response.

Candidate gathering in the browser privacy test ended on completion, error or a twelve-second deadline. The runner retained at most sixty-four distinct candidate observations and reported truncation if the limit was exceeded. It separated candidate type, transport and host-address form. It did not resolve mDNS names or interpret their random-looking text as a stable device identity.

The browser privacy test also distinguished a null candidate event from an empty candidate string. The former indicates that gathering has ended; the latter marks an end of a candidate generation rather than another address. This distinction is documented by the WebRTC icecandidate event reference. The published counts exclude empty events.

The HTTP proxy in this browser privacy test accepted CONNECT only for the three fixed measurement hosts on port 443 and listened only on loopback. It forwarded encrypted connections without decrypting content. Successful tunnel counts confirm that proxied requests actually reached the local forwarder; a configuration option alone would not supply that evidence.

For the restrictive browser privacy test condition, the extension selected disable_non_proxied_udp through Chromium's privacy API. The runner read the setting back and required the expected value plus control by that extension. A separate condition set it back to default and repeated the observations. The privacy API documentation explains why setting a preference without checking effective control is insufficient.

What the browser privacy test controls establish

Before and after the complete browser privacy test sequence, a separate host-side UDP/IPv4 probe sent a STUN binding request to the same named service. It checked the response type, message length, magic cookie, transaction identity and mapped-address attribute structure. The probe retained only an outcome category, not the mapped address or the response packet.

The host control in this browser privacy test did not obtain a validated response within four seconds. That is evidence of an unresolved operation on the tested path, not proof that the public service was globally offline. Host routing, UDP restrictions, endpoint behavior and timing remain possible factors. The experiment did not isolate which factor caused the missing reply.

Even a successful host control would not make every browser privacy test path equivalent. A browser can apply a different transport policy or route. The host probe is therefore an independent availability observation, not a substitute for a candidate returned to the web page. STUN's protocol specification describes the request and response structure used by the control.

The browser privacy test's HTTP observations provide another bounded control. A successful IPv4 response shows that this browser could complete that particular HTTPS exchange. It does not validate UDP reachability, recursive DNS attribution or IPv6 end-to-end connectivity. Conversely, an unsuccessful IPv6-specific request does not establish that the operating system has no IPv6 interfaces.

Three repetitions make inconsistencies visible within this browser privacy test, but they do not constitute three independent populations. Runs share a host, endpoints and a short observation window. We report the raw denominators rather than attach a statistical confidence interval or extrapolate a worldwide browser failure rate from this small convenience sample.

Read browser privacy test candidates without a safety score

A host candidate in a browser privacy test represents a possible local connectivity candidate. In these observations, the visible host values were mDNS names rather than numeric literals. This records what the page received. It does not establish that the browser had no underlying interface addresses, or that a separate application could not obtain different information.

A server-reflexive candidate would add a different comparison to the browser privacy test. The runner can compare its address with a successful same-family HTTP observation and retain only match, different or uncompared. Without a server-reflexive observation, all of those counters can remain zero. Zero comparisons is a coverage count, not evidence that every possible comparison matched.

A relay candidate would have a third meaning in a browser privacy test because it names a relay endpoint. No TURN service or credentials were configured here, so the absence of relay candidates is expected within the method. The experiment did not test application media quality, a completed peer connection, TURN fallback or the behavior of a real meeting service.

The restrictive policy changed the browser privacy test's visible output, but that does not make it a universal recommendation. A setting can reduce available connection choices as well as change exposure. The study did not measure resulting call reliability or quality. WebRTC's IP-handling requirements describe the relationship between proxy policy, candidate handling and connectivity tradeoffs.

A completed browser privacy test operation can therefore remain inconclusive. Completion tells you that the collection procedure reached its ending state; it does not guarantee that every source needed for an interpretation was available. The report keeps collection state, candidate evidence, HTTP references and independent controls separate so the reader can inspect that difference.

Repeat this browser privacy test

To repeat the browser privacy test, use a network you are authorized to test and a recent Node.js installation. Download the published script into a new working folder. Install Playwright and the requested browser binaries in that folder, review the destinations and behavior in the script, and choose a new output filename for your own aggregate record.

npm install playwright
npx playwright install chromium firefox webkit
node browser-privacy-2026-09-29.mjs --consent-network --output results.json

For a reproducible browser privacy test comparison, pin the Playwright version shown in the browser privacy test dataset rather than silently substituting a later release. Browser installation may require platform dependencies and downloads. The script records the engine versions it actually launches; having the same package name alone does not establish equivalent browser binaries or operating conditions.

The browser privacy test runner requires the explicit network-test flag because it opens browser sessions, contacts named endpoints and creates a temporary local forwarder. It does not start when you merely visit this article or download the file. The routine creates disposable profiles and closes its sockets and browser processes at the end of an ordinary completed run.

A new browser privacy test record should be kept separately from the published one. Compare timestamps, software versions, effective policy values, successful tunnel counts and health controls before comparing candidate totals. An unexpected result is worth investigating, but rerunning until a preferred outcome appears would undermine the value of a recorded experimental sequence.

Raw values are intentionally excluded from the browser privacy test output. Equality comparisons happen in memory, then only the outcome is returned. The dataset supports checking counts and distributions, but it cannot independently reveal which specific address was compared. There are also no deterministic address hashes that could be matched to an external address inventory.

Limits of this browser privacy test

This browser privacy test covers one host, three engine builds and a small number of explicitly configured conditions. It does not establish behavior on mobile devices, another operating system, another ISP, a commercial VPN, an enterprise policy estate or a population of installed extensions. The purpose-built extension tests one setting rather than a commercial privacy product.

The public STUN control remained unresolved in this browser privacy test. No positive public reflexive observation was available to show that the restrictive policy alone prevented a previously successful path. The policy comparison still records a change in visible gathering behavior, but the missing control prevents a stronger claim about protection against a demonstrated public-IP exposure.

DNS resolver exposure was not measured by this browser privacy test. Identifying the resolver behind a browser request requires controlled authoritative observations for the requested names. A server-side DNS lookup or a completed page request would answer a different question. The dataset explicitly records that the DNS observer was not configured for these runs.

There was no independent remote proxy exit in this browser privacy test. Because the loopback forwarder used the same host egress, equal HTTP observations do not show that browser traffic traversed a separate privacy service. The recorded tunnel connections verify application proxy use; they do not establish a second network's location, ownership or routing policy.

The browser privacy test measures only the selected endpoints in its observation window. It does not enumerate every potential connection route or inspect other applications. Timeouts are bounded observations, not permanent properties. A later browser release or network change can alter the result without implying that the original dated observation was fabricated or that the new one is wrong.

Use the browser privacy test in a real investigation

Start your own browser privacy test with the question you need answered. If you want to compare HTTP exits, record the relevant same-family observations and their times. If you need WebRTC evidence, preserve candidate type and collection state. If you need resolver attribution, use a healthy authoritative observer. These are separate measurements with separate missing-data conditions.

The WebRTC tool, IPv6 test and IP comparison tool help collect current observations. This browser privacy test supplies a dated example of how to read incomplete evidence alongside those operations. It is not a live result for your device, an endorsement of a browser, or a replacement for a properly controlled before-and-after VPN test.

When citing this browser privacy test, include the study date, tested engine and condition, and the unresolved STUN and DNS coverage. Cite the aggregate record when discussing a count and the method when explaining a limitation. The useful conclusion is the one the retained evidence supports, with its uncertainty visible beside it.