Deterministic Hardware Fingerprinting (Seed Persistence) for Session Reuse

[Admix2077]

Is your feature request related to a problem? Please describe.

The Problem:
Currently, persistent_context=True successfully persists storage states (Cookies, LocalStorage), but it does not persist the randomization seeds used for hardware fingerprinting.

Every time the browser instance is restarted (even with the same user_data_dir), Camoufox regenerates:

1. Canvas/WebGL/Audio Noise Seeds: Causing the "Fingerprint ID" / "VisitorID" to change completely.
2. Hardware Concurrency: The CPU core count reported by navigator.hardwareConcurrency drifts randomly (e.g., 16 -> 12 -> 14).
3. GPU Renderer Strings: Often switch between different mocked vendors.

The Impact:
For automation workflows requiring long-term session reuse, this behavior is problematic. Anti-fraud systems interpret this as "Session Hijacking" because the user identity (Cookies) remains the same, but the device characteristics (Hardware Fingerprint) abruptly change.

Describe the solution you'd like

I request a mechanism to make the hardware fingerprint deterministic based on the profile data.

Proposed Logic:

1. When a user_data_dir is initialized, generate the randomization seeds (Canvas/WebGL noise, Hardware Concurrency value, etc.) once.
2. Save these seeds/configurations into a file within the user_data_dir (e.g., fingerprint_config.json or inside user.js).
3. On subsequent launches pointing to this directory, load these existing seeds instead of generating new random ones.

This would ensure that a specific profile always "looks" like the exact same device, enabling true session persistence.

Describe alternatives you've considered

1. Commercial Anti-detect Browsers + Playwright/Rebrowser:
   • Failure: We attempted to automate popular commercial fingerprint browsers using Playwright and Rebrowser patches. However, the external CDP connection often triggers Cloudflare checks immediately. Camoufox's internal integration proves to be much stealthier against Cloudflare, which is why we prefer sticking with Camoufox if the persistence issue can be solved.
2. JS Injection (e.g., page.add_init_script):
   • Limitation: This fails to cover Web Workers, which are commonly used by advanced fingerprinting libraries to detect inconsistencies.
3. Keeping the browser open indefinitely:
   • Limitation: Not scalable for resource-constrained environments.

Additional context

• OS: Linux / Windows
• Use Case: RPA with strict consistency requirements.

[icepaq]

@heydryft this should be pretty doable right? Just a matter of figuring out the profile used from browserforge?

[Admix2077]

@heydryft this should be pretty doable right? Just a matter of figuring out the profile used from browserforge?

@icepaq Thanks for the quick follow-up!

Actually, I tried to implement this myself based on v146, but I hit a wall with the build environment. Compiling for Windows has been a nightmare on my end—I'm running into constant toolchain errors that I haven't been able to resolve despite multiple attempts.

Since it seems like it's just a matter of mapping the browserforge profile as you mentioned, and you guys have a stable build pipeline, it would be a huge help if this could be officially integrated.