Repository navigation
Release 0.5.0: real fingerprint mode for persistent profiles - #5
Merged
Merged
Conversation
A profile with fingerprint { mode: 'real' } resolves to engine "real": no generated fingerprint, no UA/Client Hints override, no injected script, no auto-attach, no kernel or anti-detect flags, and TZ/--lang only when the profile pins them. Asking a real profile for engine kernel or inject throws an actionable INVALID_CONFIG error. Lock files, reuse and launch results carry the resolved engine. A real profile gets no default timezone or GPU at create, and entering real mode drops the stored timezone.
resolveTimezone moves to proxy.ts to keep launch.ts from growing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
profile.create and profile.update take fingerprint: generated | real (--fingerprint on the CLI). A real profile rejects platform; switching to real keeps only the language. browser.status reports each browser's engine and profile.list shows a Fingerprint column. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
State what a real profile does and does not protect, the new fingerprint field on create/update, engine "real" in open/status output, and the Unreleased changelog entry. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Real profiles hold logged-in accounts and browse untrusted pages, so they no longer inherit BASE_FLAGS (--no-sandbox, --disable-background-networking, --disable-client-side-phishing-detection, --disable-popup-blocking, --disable-sync and the rest). REAL_BASE_FLAGS adds only --no-first-run and --no-default-browser-check. Spoofing modes are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
huanthuyon671
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Accounts signed in by hand (Google, store consoles, dashboards) read a spoofed fingerprint as a new device. A real profile keeps Chrome's own identity so one tool can manage both anti-detect and real profiles, driven over the same CDP endpoint.
What
fingerprint: { mode: 'real' }on a profile (library,--fingerprint realon the CLI,fingerprintfield over MCP); stored JSON withoutmodestays generated.--lang.--no-sandbox, Safe Browsing, popup blocking and updates stay on.navigator.webdriverstays false; WebRTC proxy policy is kept when a proxy is set.engine: kernel|injectfails withINVALID_CONFIG. Launch results, lock files andbrowser statusreportengine: real.Checks
npm run typecheck,npm test(217 passed, 10 skipped e2e),npm run buildBROWSER_PROFILES_E2E=1real-profile e2e on Chrome 154 (macOS), headed and headless, without--no-sandboxNot verified yet: a real Google sign-in avoiding the new-device check.
🤖 Generated with Claude Code