Apply this

[aizen218]

https://github.com/arjunkishannohal/normal-browser

[pim97]

Consolidating #10 into this thread, since both are really the same question: what mobile support means for clearcote. Answering both here.

The linked project

We read the source rather than the feature table. It does not fit clearcote's target, for two reasons that are about scope rather than quality.

It builds against Chrome 130 on Android; clearcote is on 151 desktop. Most of the surface work is Android device modelling — SoC tables, build fingerprints, manufacturer traits, that platform's sandbox — which does not carry to a Windows or Linux persona even in principle, and the Chromium internals it hooks have moved considerably across 21 majors.

It also is not a fork that builds as-is. apply_patches.sh copies files into a tree, and the script's own closing notes leave the BUILD.gn changes and the hook-points in existing Chromium files as manual steps; several copied files are reference implementations carrying "replace this node in that file" instructions in their headers. It reads as a detailed design document with reference code attached.

Two ideas from it we are taking, implemented independently:

1. Coherence validation as a build-time gate. Validating a generated device profile for internal consistency before it is ever used, and failing loudly when two coupled fields disagree, is a better place to catch that class of problem than a browser test. Going into CI over a large sample of generated identities.
2. Binding more of a persona to a single hardware identity. Deriving more traits from one coherent device choice rather than sampling them independently. We already do this for some fields and will extend it.

On iOS (from #10)

Worth being precise about why this is a different situation from Android rather than just more work.

Android support in clearcote is a persona, not a port. The browser is a desktop build presenting a coherent Android Chrome device — UA and client hints, screen and DPR, touch and pointer, mobile GPU strings, hardware values. That works because clearcote is Chrome: Android Chrome and desktop Chrome are the same engine, so the values presented and the engine underneath agree. Nothing has to be faked below the surface.

iOS breaks that on both readings:

Running clearcote on iOS. Browsers there use WebKit — Chrome for iOS is a WKWebView wrapper. Clearcote's value is engine-level: the fingerprint surfaces are implemented in the engine, not injected as JavaScript. Inside a WKWebView there is no engine to modify, and the fallback of injecting script into the page is exactly what a check running in a Worker exposes. BrowserEngineKit has allowed alternative engines since iOS 17.4, but it is EU-only and entitlement-gated, with no production non-WebKit engine to build on.

Presenting an iOS/Safari persona from the desktop engine. This is the closer analogue to Android and the one we have decided against. Safari runs JavaScriptCore; we run V8. They differ in error message text, stack trace format, Function.prototype.toString output, Intl and number formatting, and a long tail of API surface — all readable in a line or two of script, none of it changed by a UA string. Since even Chrome on iOS is WebKit, there is no iOS browser a Blink engine can honestly claim to be. A Safari persona on Blink would contradict itself in hundreds of places, which is the failure mode clearcote exists to avoid. We would rather not ship it than ship something convincing in the UA that falls apart on the first real check.

If the underlying need is mobile traffic rather than iOS specifically, --fingerprint-platform=android already gives a coherent mobile device today.

If you have a concrete case that genuinely requires iOS, describe it here — it is useful input even though the answer above is unlikely to change.