YSbrowser: a Chromium build whose environment is fixed by seeds

A Chromium build that ships binaries, not source

YSbrowser is a Windows desktop browser built on Chromium, and the newer version of it puts the environment configuration underneath the browser rather than inside a settings page. The project describes it as a stable, reproducible and independently configurable browser runtime.

What you download is a Windows archive. You take it from the releases, unpack it and run YSbrowser.exe. There is no build step, no package manifest and no source tree in the repository. The top level holds the two readmes, a docs directory and two image files, and the older documentation for previous versions lives under docs/legacy. So this is a distribution repository: the code you evaluate is a binary you run.

The version numbers track the Chromium underneath. The repository description names the current Chromium version as 154, and the newest release, 6.0, is labelled as the YSbrowser built on Chromium 154, dated 2026-10-11. Earlier releases were 5.5 on 2026-04-03 and 5.4 on 2026-03-24. The readme also warns that parameters differ between versions, so the documentation for the binary you actually have is the one to follow.

The repository description claims the browser defeats F12 anti-debugging, which is the kind of statement a reader should treat as the project's own claim rather than a measured property, since the documentation does not describe how it is implemented.

A seed string selects the environment, and the priority order is explicit

The mechanism that gives the browser its reproducible character is a seed. The same launch parameters and the same seed select the same environment, and the documentation lays the priority out in three levels: a module specific seed wins, then the overall fpseed, then plain Chromium default behaviour.

Modules can be seeded independently. The parameter table lists fpseed for the overall configuration, canvas-seed for the Canvas fingerprint, webgl-seed for WebGL, audio-seed for OfflineAudioContext output, font-seed for fonts, speech-seed for the SpeechSynthesis voice combination, screen-seed for an internally consistent desktop screen configuration, and rect-seed with domrect-seed and svgrect-seed for the DOMRect and SVGRect geometry, where the two specific seeds take priority over the shared one.

The example the readme gives shows the intended style: one overall seed for the account, separate seeds for Canvas and WebGL, and every module that accepts the overall seed deriving from it.

.\YSbrowser.exe `
  --user-data-dir="D:\YSbrowser\profiles\profile-02" `
  --fpseed="account-02" `
  --canvas-seed="canvas-02" `
  --webgl-seed="webgl-02"

Two limits are stated without hedging. The same string always maps to the same configuration, but changing a seed does not guarantee that every hash shown by every detection site changes, because sites draw different content and use different collection APIs. And the graphics implementation targets Windows x64 on Chromium's default ANGLE D3D11 path, so forcing Vulkan, OpenGL or SwiftShader means WebGL drawing results are not guaranteed to match D3D11.

One user data directory per instance, or Chromium locks fight back

The isolation mechanism is the user data directory, and the documentation is blunt about the failure mode.

Each simultaneously running instance must use a different user data directory. Opening the same directory from two processes at once can produce conflicts in Chromium's directory lock and in the data written there. The parameter is set with --user-data-dir, and every example in the readme uses a distinct path under a profiles folder. The minimal recommended launch looks like this:

.\YSbrowser.exe `
  --user-data-dir="D:\YSbrowser\profiles\profile-01" `
  --fpseed="profile-01" `
  --timezone="Asia/Shanghai" `
  --lang="zh-CN" `
  --accept-lang="zh-CN,zh,en"

What that directory buys is separation of state: cookies, cache, LocalStorage, IndexedDB and site permissions are isolated between instances. What it does not do is remember an identity. The readme states that the seed does not store cookies, IndexedDB, login state or the visitor ID that a site assigns on its servers, so a long-lived environment needs the user directory, the seeds and the full launch line kept together and reused.

The launch line itself is the profile. The minimal recommended configuration passes a user data directory, an fpseed, a timezone, a language and an accept-language value, and the fuller example adds CPU cores, memory, platform version, geolocation, a proxy and a WebRTC policy. Reproducing an environment later means replaying that line exactly, which is a discipline worth automating rather than typing.

Proxies, WebRTC candidates and geolocation are three separate levers

The proxy section is where the readme is most careful, because the three look like one setting and are not.

--proxy-server sets the HTTP, HTTPS or SOCKS5 proxy, and --proxy-auth supplies a username and password for an authenticated proxy. Switching the proxy while the browser is running is supported per instance, and switching it in one instance does not change another. An authenticated proxy is configured like this:

.\YSbrowser.exe `
  --user-data-dir="D:\YSbrowser\profiles\proxy-01" `
  --proxy-server="http://127.0.0.1:8080" `
  --proxy-auth="username:password" `
  --webrtc-ip-policy="proxy" `
  --webrtc-proxy-ip="203.0.113.10"

The readme then makes the distinction that matters: --webrtc-proxy-ip controls only the candidate addresses WebRTC presents to the outside, and does not replace the network proxy, because the exit for HTTP requests is still determined by --proxy-server or by the system network.

The WebRTC policy parameter has two documented values, disabled to stop WebRTC exposing address candidates at all, and proxy to enable the custom WebRTC address policy, with the displayed address set separately.

Geolocation is a third mechanism again. The parameter takes latitude, longitude and an accuracy in metres, formatted as --geolocation=latitude,longitude,accuracy, with the accuracy optional and defaulting to 100 metres. Latitude has to be between -90 and 90, longitude between -180 and 180, and the accuracy must not be negative. It sets the position returned by navigator.geolocation, but it does not grant permission: the page still needs a secure context and the user's permission to read a location.

One operational warning is worth repeating. Command line arguments can be read by local process management tools, so real proxy credentials should not appear in screenshots, logs or public issues.

CDP, Playwright and Puppeteer are the intended automation surface

The browser is built to be driven by other tools rather than clicked through.

Support is stated for CDP, Playwright, Patchright and Puppeteer, and the CDP route is opened with --remote-debugging-port, with 9222 given as the example value. A typical CDP launch is:

.\YSbrowser.exe `
  --user-data-dir="D:\YSbrowser\profiles\automation-01" `
  --remote-debugging-port=9222 `
  --iconumber=1 `
  --fpseed="automation-01"

A second instance needs its own directory and its own port, and the readme says the debugging port should only be opened on a trusted network. The window and taskbar icon can show an instance number, which is how you keep several identical-looking windows apart.

Three developer conveniences are switched on by default: extension developer mode is enabled, the DevTools console allows pasting directly, and JavaScript source maps are turned off. That last one is the one to think about. Source maps off means the stack traces you get are not the original TypeScript sources, which speeds up page loads and hides implementation detail, but makes debugging your own code harder.

None of this is a scripting framework. There is no project file format, no test runner and no scheduler in the documentation. The contract is the command line and the directory layout, so an automation setup has to keep the launch arguments, the seed and the profile directory together for each instance it manages.

The online sampling shows consistency, not invisibility

The readme includes an online sampling table, and it is worth reading as a set of claims rather than as a benchmark.

Across three representative configurations, the reported observations are that Fingerprint Playground showed tampering as false and anti_detect_browser as false, that the TZP Canvas Noise page produced a write hash equal to the two read hashes, that BrowserScan showed no graphics consistency warning and a WebGL hash that varied with the seed, that CreepJS showed Canvas and WebGL hashes varying with the seed, and that PixelScan displayed a browser fingerprint.

Read carefully, these results say two things. The browser is internally consistent, in the sense that repeated reads of the same drawing produce the same hash and the graphics values do not contradict each other. And the seed does what it claims, since the hashes change when the seed changes. They do not say that a site cannot tell what the browser is, and the last row is a reminder of that, since a fingerprint was still displayed.

The readme itself frames the sample as an online sampling of three configurations rather than as a systematic evaluation, so this is the kind of evidence to treat as a starting point for your own checks rather than as a guarantee. The broader point about hashes also applies here: the seed fixes what the browser reports, not what each individual site chooses to collect.

Licence unstated, documentation versioned, releases every few months

Two practical housekeeping points close the file.

First, licensing is unresolved. GitHub does not classify a licence for this repository and no licence file appears among the top-level entries, so there is no stated grant for the code, the binaries or the documentation. Anyone planning to redistribute or build on it needs that answered by the author rather than assumed.

Second, the documentation is versioned against the binary. The readme states that the page is the new version's documentation and points to separate legacy Chinese and English documents for the older browser, with a warning that parameters may differ between versions and that you should consult the documentation for the version you are running. That is an unusually honest warning to find in a browser project, and it matters because the seed parameters and the proxy arguments are exactly the kind of thing that shifts between builds.

On maintenance, the last push was on 2026-10-11 and the repository is not archived. The release history is 6.0 on 2026-10-11, 5.5 on 2026-04-03 and 5.4 on 2026-03-24, so the cadence is a couple of releases a year rather than a stream, which is consistent with a binary that has to be rebuilt and tested against a moving Chromium.

Editorial conclusion

Adopt YSbrowser if you run many Chromium instances on Windows and need each one to present a stable, self-consistent environment that you can rebuild from a seed string and a stored command line. Do not adopt it if you need source you can audit, because the repository publishes documentation and images rather than the browser code, and the licence is not stated, or if your work needs a platform other than Windows x64, since the graphics configuration is tied to Chromium's default ANGLE D3D11 path. Verify first that the seed strings and full launch parameters are stored alongside each user data directory, that proxy credentials are not left in shell history or screenshots, and that the CDP port is only bound on a network you trust.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. selfshore/YSbrowser on GitHub