Tool suggestion: AntiBrow - keeps each research profile's cookies, fingerprint and proxy separate at the engine level

Disclosure: I maintain AntiBrow. Submitting our own tool, and flagging upfront that part of it is not open source (details under Cost and Limitations).

**Name:** AntiBrow
**URL:** https://antibrow.com
**Docs:** https://antibrow.com/docs
**Source:** https://github.com/antibrow/antibrow (SDK, MIT)
**Suggested section:** Stay Safe, or Data Organization & Analysis - see the note at the end, I am not sure this fits the toolkit's scope and would rather ask than assume.
**Cost:** Free tier is unlimited local profiles with one concurrent browser, no account needed to start. Paid tiers price concurrency. The SDK is MIT; the browser kernel it downloads is closed source under separate terms.

## What it does

A Chromium fork where a browser profile is a persistent, isolated identity: its cookies, local storage and fingerprint configuration survive between runs, and each profile answers its own proxy inside the engine rather than through an extension or a system-wide setting. Several profiles can be open at once without sharing state.

It can be driven by hand, from TypeScript or Python through the Playwright API, or from a local MCP server when an agent is doing the work.

## Why it may be relevant to open source research

Research accounts are documented practice in this field - Bellingcat's own community has written about them, and so have SANS and OSINT Curious. The failure mode is not exotic: an investigator's research identity and personal identity end up sharing a cookie jar, a fingerprint, and a home IP address. The usual mitigations are a separate browser profile (shares the fingerprint and the IP), a separate VM (heavy, and one per identity gets expensive), or a VPN (system-wide, so all identities move together).

What this does instead is bind the isolation to the profile: profile A can sit on a residential exit in one country while profile B is on another, in the same session, with no shared storage between them. Timezone and locale follow the exit rather than the host machine, which is the inconsistency that most often gives a research account away.

## Relationship to what the toolkit already lists

I went through the 337 tool pages in this repository and did not find a browser or a profile-isolation tool among them - the nearest material is the Stay Safe resources section, which is guidance rather than tooling. So this is not a duplicate of anything listed, but it may be outside the scope you have drawn on purpose.

## Limitations, and what it does not do

- It does not make any site accept an automated session, and it does not defeat account verification. Platforms that want a phone number still want a phone number.
- The kernel is closed source. For a toolkit aimed at investigators that is a real limitation and I am not going to argue around it: you can read and audit the SDK, not the engine.
- Fingerprint control reduces cross-profile correlation; it does not make a profile anonymous. Behaviour and request timing remain identifying, and for adversarial situations Tor Browser's approach - everyone looking identical - is a different and often better threat model than everyone looking distinct.
- Same category of dual-use as several tools already in the toolkit: the same isolation that keeps an investigator's identities apart can be used to run many accounts on a platform that forbids it. We do not sell it for that and our docs do not teach it, but it would be dishonest to pretend the capability is one-directional.

## If this is out of scope

If the toolkit deliberately excludes browsers and opsec tooling, or excludes anything with a closed component, just close this - a no is a useful answer and I would rather have it than a maybe.

Review the existing Stay Safe and Data Organization & Analysis tool pages, along with the repository’s existing tool pages, to understand their structure and scope. Confirm whether browser or opsec tools and closed-source kernels fit the toolkit; done means recording a clear accept-or-close decision and, if accepted, identifying the appropriate section for AntiBrow.

Written by the indexing model from the issue text.