ShardX Launcher: engine-level fingerprint spoofing in a patched Chromium build

The multi-identity problem ShardX is aimed at

Running many browser accounts from one machine fails in a specific way. Cookies and storage can be separated with a profile directory, but the browser still reports the same GPU, the same font list, the same screen metrics and the same TLS handshake to every site it visits. Sites that care about this correlate those signals across accounts and link them. ShardX Launcher is built for that situation: the README describes it as an anti-detect browser launcher for web scraping and multi-accounting, and the unit of work is a profile that defines a complete device identity, including GPU, screen, fonts, audio settings, timezone, locale, WebGL and WebGPU capabilities, TLS ClientHello, UA-CH, WebRTC policy, geolocation and cookies. The stated goal is that the signals within a profile stay consistent with one another. The audience is therefore narrow but well defined: scraping teams and multi-account operators who need dozens or hundreds of distinct identities from one host, and who are willing to manage a proxy fleet alongside the browser. It is not a privacy tool for a single person browsing the web, and nothing in the material suggests it is meant to be.

Why patching Chromium beats injecting JavaScript

The central design choice is where the spoofing happens. ShardX ships a patched Chromium build and applies fingerprint changes inside the C++ engine, in Blink, V8 and the network stack. The README states plainly that the project does not rely on JavaScript injection, and gives the reason: the same values are visible in frames, workers, developer tools and headless sessions. That matters because most JavaScript-level stealth patches live in the page's main world and can be detected or simply missed in a worker context, and a page that reads a property before the patch loads sees the real value. Moving the change into the engine removes that ordering problem. The cost is that you are running a vendor-patched browser, not stock Chrome, so you inherit whatever Chromium version the project has patched and you cannot simply point the launcher at your own Chrome binary. The material names Chromium 152 in the README and Chromium 148 in the repository description, which is a discrepancy worth resolving before you plan a deployment around a specific engine version.

Profiles, proxies and the network path

Each profile gets an isolated user-data-dir with persistent cookies, and you bind a SOCKS5 or HTTP proxy to it. From the proxy exit country the launcher resolves timezone, locale and geolocation, which is the mechanism that keeps the network-level story aligned with the browser-level story. The README also mentions Widevine pre-warming and QUIC over the proxy UDP relay. The network side is where the ProxyShard relationship shows: ProxyShard proxies provide SOCKS5 UDP relay per RFC 1928 section 7 and p0f TCP fingerprint spoofing at the proxy exit, which the README says keeps the operating system presented by the proxy consistent with the SYN/ACK shape seen by websites. Other proxy providers can be used, but the README is explicit that full QUIC and WebRTC operation requires SOCKS5 UDP relay support. Read that as a real constraint rather than a footnote. A TCP-only SOCKS5 proxy will still carry ordinary HTTP traffic, but the QUIC and WebRTC paths described here depend on UDP being relayed, and HTTP/3 falls back to TCP when it is not.

Four control surfaces over one local state

The launcher exposes the same profiles through four interfaces, and the README notes they share the same local state so no extra synchronization is needed. The desktop UI is a workspace for profiles, proxies, cookies and a fingerprint editor. The local HTTP API listens on 127.0.0.1:40325 with Bearer JWT authentication, and lets you create, start and stop profiles from any language before handing back a CDP endpoint. An MCP server connects the launcher to Claude Desktop, Cursor and other MCP clients for natural-language profile orchestration through the HTTP API and CDP. Standalone SDKs exist for Python, Node and Rust, published as shardx on PyPI, @proxyshard/shardx on npm and shardx on crates.io, and the README says they ship the browser engine and run without the desktop UI, intended for scrapers, CI jobs and servers. That last point is the most consequential architectural fact here: the SDKs are not thin clients for a running launcher, they carry the engine. The CDP endpoint is the integration seam for existing Puppeteer and Playwright code, which is why those names appear in the repository topics.

Getting a profile running

The README's install path is the package registries rather than a build from source: pip install shardx, npm install @proxyshard/shardx, or the shardx crate for Rust. For the desktop route, the README points at the releases page and the browser guide under docs.proxyshard.com. The HTTP API is the surface with documented specifics: it binds to 127.0.0.1:40325 and expects a Bearer JWT, after which you create a profile, start it, and read back a CDP endpoint to attach a driver to. The README does not reproduce the full request and response schemas inline, so the exact JSON bodies for profile creation are in the external usage documentation rather than in the repository README. That is a gap if you are evaluating the project from the repository alone: you can confirm the port, the auth scheme and the lifecycle verbs from the README, but not the field names for binding a proxy or selecting one of the 170 device profiles. Plan to read docs.proxyshard.com before writing integration code, and treat the README as a map rather than a reference.

Where the design will not fit

The clearest limitation is the proxy dependency. QUIC and WebRTC over SOCKS5 UDP relay is a capability the README attributes to ProxyShard's own proxies, with the caveat that other providers work only if they support UDP relay. If your infrastructure is HTTP proxies or TCP-only SOCKS5, you are running ShardX with part of its networking story disabled, and the fingerprint consistency argument weakens because the p0f spoofing at the exit is also a ProxyShard-side feature. A second limitation is the patched engine itself. You are pinned to the Chromium version the project has patched, and the README and repository description disagree on whether that is 148 or 152, so version-sensitive work needs checking against the actual release you install. Third, anti-detect tooling is adversarial by nature: the README's own verification table is truncated in the material available here, so its test results cannot be assessed. Nothing in this material is a substitute for testing against the specific sites you intend to target.

How it differs from Playwright with a stealth plugin

The obvious alternative for most teams is Playwright or Puppeteer driving stock Chromium with a stealth plugin such as playwright-extra with puppeteer-extra-plugin-stealth, plus a proxy per context. The difference in approach is the layer at which the disguise is applied. The plugin route patches JavaScript-visible surfaces from inside the page, which is why it needs constant maintenance as detection moves, and why worker and frame contexts need separate handling. ShardX moves the same changes into Blink, V8 and the network stack, and adds TLS ClientHello and UA-CH control that a page-level plugin cannot reach at all. The trade is control and familiarity for coverage: with Playwright you choose your Chromium build and upgrade it whenever you like, and your existing test tooling works unchanged. With ShardX you accept a vendor-patched engine on the vendor's release cadence in exchange for signals that are consistent across frames, workers, devtools and headless sessions. If your problem is one identity with a rotating IP, Playwright is the smaller tool and the right one.

Maintenance, releases and the MIT licence

The release history in the material shows v0.1.10 in June 2026, then v2.0.0 and v2.0.1 in September 2026, so the project jumped a major version within roughly ten weeks and has shipped a patch since. The last push to the default branch is the same day as v2.0.1, which suggests active development at the time of writing. The practical maintenance cost is the patched Chromium: upstream security fixes arrive only when the project rebases onto a newer engine, so you are trusting someone else's cadence for browser patches, and that is a real operational consideration for anything long-lived. On licensing, the repository is MIT, which permits commercial use and modification, but the licence covers the launcher code, not the Chromium build it ships or the ProxyShard services it is designed to use. Those are separate relationships with their own terms and this is not legal advice; read the LICENSE file and the ProxyShard service terms before shipping anything commercial.

Editorial conclusion

Adopt ShardX if you run many isolated browser identities and you already control a SOCKS5 proxy with UDP relay, or if you need a browser engine embedded in a Python, Node or Rust job rather than a desktop app. Skip it if a single headless Chrome with a rotating proxy is enough, or if your proxy only speaks TCP, because the QUIC and WebRTC path depends on SOCKS5 UDP. Before committing, verify three things against your own proxy: that the release you install actually reports Chromium 152 as the README claims, that a profile bound to your proxy resolves timezone and locale from the exit country, and that WebRTC does not expose the host IP under your network conditions.

Official sources

1. Issues
2. License: MIT
3. ProxyShard/ShardBrowser on GitHub
4. README
5. Releases