- name
- multi-account-isolation
- description
- Verify that browser profiles are actually isolated from one another instead of assuming it - confirm each profile's timezone agrees with its own exit IP, that WebRTC exposes only the proxy, that canvas and WebGL hashes stay identical across relaunches of one profile, and that no two profiles share a persona, a cookie jar, or an address. Use when several of your own accounts or test identities run from one machine and the setup needs checking, when a profile tested clean but something still looks off, when choosing which detection suites to run (CreepJS, whoer, browserleaks WebRTC, pixelscan, liarjs), when auditing what a vendor runtime does with API and proxy credentials, or when asking which layers browser isolation cannot cover at all. Also for 'profile isolation check', 'fingerprint consistency test', 'timezone mismatch', 'WebRTC leak', 'canvas hash unstable', 'account association', 'temporary profile', '防关联', '多账号', '隔离自检'. The SDK is anti-detect-browser; MCP is browser-mcp-agent.
- license
- MIT
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
Profiles are unlimited and free on every antibrow plan, so there is never a reason to reuse one. "Log out and log back in as the other identity" inside one profile defeats the entire setup - the cookie jar and localStorage are the point.
Setup under test
import { AntiDetectBrowser } from 'anti-detect-browser'
const ab = new AntiDetectBrowser({ key: process.env.ANTI_DETECT_BROWSER_KEY })
const identities = [
{ profile: 'fixture-us-01', proxy: process.env.PROXY_US_1, tags: ['Windows 10', 'Chrome'] },
{ profile: 'fixture-us-02', proxy: process.env.PROXY_US_2, tags: ['Apple Mac', 'Safari'] },
{ profile: 'fixture-de-01', proxy: process.env.PROXY_DE_1, tags: ['Windows 10', 'Edge'] },
]
for (const id of identities) {
const { browser, page } = await ab.launch({
profile: id.profile, // isolated cookies, storage, login state
proxy: id.proxy, // from the environment, one per identity
fingerprint: { tags: id.tags }, // drawn once, frozen, replayed after
label: id.profile, // address-bar tag drawn by the kernel, unreadable from the page
})
// ... run the checks below, then ...
await browser.close()
}