What A Chromium Fork Still Sends Home

Every anti-detect browser on the market is a Chromium fork. Multilogin, GoLogin, Kameleo, AdsPower, Dolphin Anty, all of them start from the same open source Chromium codebase and patch the parts that expose your canvas hash, your WebGL renderer string, your font list, your screen dimensions. That part gets a lot of attention in marketing copy and in comparison videos, mine included. What gets almost no attention is the other half of Chromium: the parts that were never built to fingerprint you, but that phone home anyway, because that is how stock Chromium was designed to behave.

If you run more than a handful of profiles for work, it is worth knowing what that traffic actually is, because “fingerprint protection” and “network silence” are two different engineering problems, and a vendor can solve one without touching the other.

Chromium was never built to be quiet

Google ships Chromium with several background services that talk to Google infrastructure by default, independent of anything you browse to. This is documented, not speculative. A short, non-exhaustive list of what a stock Chromium build calls out to on its own:

• Variations / field trials service. Chromium pings a Google endpoint on startup to fetch the “Finch” configuration that decides which experimental features and A/B test buckets your install falls into. This is how Google rolls out UI and engine changes gradually. It happens before you type a URL.
• Crash reporting. Crashpad, the crash handler compiled into Chromium, can upload crash dumps and stack traces to Google’s crash servers.
• Safe Browsing. Chromium checks visited URLs and downloaded files against Google’s Safe Browsing lists, either via local hash prefix lookups that still involve periodic list updates, or via full URL lookups depending on the mode.
• Google Update / Omaha. On many platforms Chromium and Chromium-based builds check for updates through Google’s Omaha protocol, which includes a persistent client ID unless that is stripped out.
• New Tab Page suggestions and favicon fetches. The default NTP can pull suggested sites and their icons from Google.
• Spellcheck and search suggestions. As-you-type text can be sent off to a suggestion service depending on settings.
• DNS prefetching and preconnect. Chromium resolves and sometimes opens connections to domains it predicts you will visit next, based on links on the current page.

None of this exists to fingerprint you specifically. It exists because Chromium is Google’s product and these features make the browser faster, safer against malware, and easier for Google to iterate on at scale. But from an operator’s chair, “not built to fingerprint you” and “harmless for multi-accounting” are not the same claim.

What forking removes, and what it usually doesn’t

There are two different engineering choices a Chromium fork can make, and they are not the same project.

The first is fingerprint surface patching: overriding navigator.userAgent, canvas toDataURL, WebGL parameters, AudioContext output, font enumeration, screen and timezone values, so that JavaScript running on a page reads back a consistent, chosen fingerprint instead of the real hardware’s. This is the visible, marketed part of every anti-detect browser, and it is real engineering work. It is also the part every comparison article, including the ones on this site, tends to test, because it is testable: you load a fingerprinting demo page and read the output.

The second is background network hygiene: stripping the Google API keys that let telemetry endpoints authenticate, disabling the variations pings, killing the update checker or pointing it at nothing, dropping Safe Browsing calls or making them local-only, removing the persistent client and install IDs those services rely on. This is closer to what projects like ungoogled-chromium set out to do as their entire purpose, rather than as a side effect of fingerprint patching.

Vendors differ on how far they go with the second category, and it is genuinely hard to know from the outside without watching the traffic yourself. A tool can ship excellent canvas and WebGL spoofing and still leave the update pinger running, still leave Safe Browsing hitting Google’s servers on every navigation, still leave WebRTC’s STUN requests exposing your real IP to any page that asks for it before your proxy layer ever gets a say. None of that shows up on a fingerprinting demo page, because those demos test what the page’s JavaScript can read, not what the browser process is doing on its own sockets in the background.

Why this matters specifically for multi-accounting

The whole premise of running isolated profiles is that platform A’s account and platform B’s account, or account 1 and account 2 on the same platform, look like they belong to unrelated people. Fingerprint spoofing addresses the signals a website’s own JavaScript can read. It does nothing about signals that leave the machine through a different channel.

If ten “isolated” profiles all still run stock Chromium’s update checker with a persistent client ID, that ID is a correlation key sitting outside your proxy and outside your fingerprint work entirely. If WebRTC is left unpatched, a page can enumerate your real local and public IP addresses via ICE candidates regardless of what your canvas hash says, which defeats a proxy silently rather than loudly. If DNS prefetch is left on and your proxy setup does not route DNS through the same path as the rest of the traffic, you get DNS leaking your real resolver, which is a mismatch between the “location” your fingerprint claims and the network path the request actually took.

None of this means any specific anti-detect browser is broken. It means fingerprint spoofing and network isolation are two separate jobs, and a vendor’s marketing page will always show you the job that is easy to demo, not the one that is boring to demo. This is why I run traffic capture alongside every fingerprint test when I evaluate a browser for the channel: a clean canvas result and a chatty network layer can sit in the same build.

Checking what your own setup actually sends

You do not need to reverse engineer anything to get a rough answer here. Point the profile’s traffic through a local proxy that logs outbound connections, then just use the profile normally for a few minutes without visiting anything: open it, sit on a blank tab, close it. Anything that shows up in that log happened without you doing anything, which means it is the browser’s own background behavior, not something a site pulled from you. Chromium’s own network log viewer, reachable at chrome://net-export in most Chromium-based builds, will also dump every connection the process makes, including the ones to Google’s own infrastructure, if the fork has not removed that page. This is diagnostic work on your own machine and your own traffic, not something aimed at a platform.

What this doesn’t mean

I want to be direct about the limits here, because this is the kind of topic that invites overclaiming in both directions. A Chromium fork that strips Google’s telemetry endpoints is not therefore undetectable, unbannable, or risk-free. Platforms correlate accounts through dozens of signals beyond background network chatter: behavioral patterns, payment details, device motion on mobile, IP reputation, account graph analysis on their own backend. Closing one leak does not close the others, and no anti-detect browser I have tested, regardless of price tier, gets you out of that reality. Conversely, a vendor leaving default Chromium telemetry running is not proof their fingerprint patching is bad, just that it is a separate piece of work they may or may not have prioritized.

The honest way to evaluate any of these tools is the same way you would evaluate any piece of infrastructure you are trusting with real accounts: watch what it actually does, on the network layer and not just in a browser fingerprint demo, and weigh that against what the vendor claims. That is the standard I hold every browser to on this channel, and it is the standard worth holding your own stack to.

For more breakdowns like this, and hands-on tests of the antidetect browsers people actually use for multi-accounting, head back to the homepage.

Get new guides and videos first — join the Telegram channel.