Profile Isolation - verifying it, not assuming it

A profile that looks isolated usually is not. The failures are boring and mechanical: a timezone that does not match the exit IP, a WebRTC candidate carrying the real address, a canvas hash that changes on every read, two profiles that ended up on the same persona. This skill is the check list for catching those before they matter.

Authorized use only. This is for identities you own or are authorized to operate: your own accounts, your own test fixtures, your own QA fleet, and your own anti-fraud stack. It is not for accessing systems without authorization, for accounts that are not yours, or for creating fake accounts or engagement. Comply with the terms of the sites you automate and with applicable law - see Acceptable use.

What this does not claim. Passing every check below means the browser layer is internally consistent. It does not mean a given site will treat two profiles as unrelated: things entirely outside the browser - a shared payment instrument, a shared contact detail, identical activity patterns - are not something any browser setting reaches. Treat a clean result as "the technical layer is not the problem", not as a guarantee.

For the SDK that creates and launches these profiles, see the anti-detect-browser skill.

The configuration invariant

One identity gets one of everything. Any cell shared between two identities is a defect to find:

identity  →  profile  →  persona  →  proxy  →  timezone
   1      :     1     :     1     :    1    :     1