Four internal inconsistencies in the free binary on darwin-arm64, with a same-machine control (window vs screen, WebRTC, heap size, UA version)

I measured the free binary against a consistency scorer - not "does any single detector flag it", but "do the values it reports agree with each other" - and four of them do not. Each is reproducible, and I ran a control on the same laptop, same day, same scorer build, so you can see which findings are the binary's and which are my machine.

Setup: pip install cloakbrowser (0.5.10), launch(headless=False, args=["--remote-debugging-port=PORT"]), free tier, binary chromium-145.0.7632.109.2, macOS arm64, no proxy. Scored over CDP from outside the browser so nothing in-page sees the scorer.

41/100 for CloakBrowser vs 74/100 for stock Chrome on the same machine. Findings, with the control:

1. The window is larger than the screen it reports (−15). screen is 1440×900 with availHeight 805, while outerHeight is 905. A window cannot be taller than the available area of the display it is on, so the reported screen and the real window disagree. Stock Chrome on the same display reports a window that fits. This is independent of maximizing - identical with _suppress_maximize=True.

screen: [1440, 900, 1440, 805]   // width, height, availWidth, availHeight
window: [1200, 784, 1200, 905]   // innerWidth, innerHeight, outerWidth, outerHeight

2. WebRTC gathers zero ICE candidates (−12). A peer connection completes gathering with no candidates at all. Real Chrome always produces at least one host candidate, so "none" is not a quiet setting, it is a distinguishing value - the absence is itself the signal. Stock Chrome on the same machine does not produce this finding.

3. The heap limit is the Windows value while the UA claims macOS (−8). performance.memory.jsHeapSizeLimit is 4294967296, exactly 4096 MiB, which is what Chrome reports on Windows. navigator.platform is MacIntel and the UA says Macintosh. Stock Chrome on this machine reports 4192 MB. One number was left at a default that contradicts the platform being presented.

4. The free binary is Chrome 145 while the README advertises 151 (−6). navigator.userAgent from the binary that ensure_binary() actually downloads:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/145.0.0.0 Safari/537.36

The comparison table in the README lists Chrome/151.0.0.0 under "UA string". Stable is around 153, so 145 is roughly eight majors behind, and a Chrome that far behind is itself unusual enough to be worth points. binary_info() reports version: 145.0.7632.109.2 with bundled_version: 146.0.7680.177.5, so the table may be describing the Pro build - if so, marking which rows are Pro-only would stop a free-tier user from reading the table as a description of what they just installed.

Two things I am handing back as mine, not yours.

The timezone finding is my setup: no proxy, so the exit IP geolocates to Hong Kong while the browser reports Asia/Shanghai. It fires on stock Chrome here too.

The colorDepth finding is my scorer being wrong, and I would rather say so than let it sit in the list. It flags colorDepth=30, but stock Chrome on this wide-gamut macOS display reports 30 as well, so it is a real value and the check is a false positive on this hardware. I found that by running the control for this report and will fix it. Six findings minus the two that are mine leaves four, and 41 vs 74 becomes 59 vs 92 once both machines' shared noise is subtracted.

Reproducing: the scorer is npx liarjs --cdp http://127.0.0.1:PORT --page https://example.com/ --json out.json against an already-running browser - it does not launch anything, so it can be pointed at your own CI. One thing worth knowing if you do reproduce: run the probes on a real https:// page rather than about:blank, because several checks are inert there and scoring on about:blank quietly inflates the result.

Happy to re-run against a Pro build or a newer binary if the picture differs there; I only have the free tier.