Browser Fingerprinting and Marketplace Account Bans, Explained

The message always arrives at the worst possible time. “Your account has been deactivated in accordance with our Seller Code of Conduct.” No warning, no named violation — and, this is the part that stings, your other account, the careful one, goes down within the hour. If you sell on Amazon, eBay or Etsy with more than one account, you have either lived through this or you know someone who has.

Most sellers blame the proxy, the VPN, or a competitor filing reports. The real culprit is usually quieter: the direct relationship between browser fingerprinting and marketplace account bans. A marketplace does not need your name to connect two accounts. It needs your device — and your browser volunteers a detailed description of that device on every single page load.

This guide unpacks how that linkage actually works, which signals each marketplace weighs most heavily, why the standard workarounds fail in predictable ways, and what genuine profile isolation looks like when your income depends on it. It is written for practitioners: e-commerce operators running a main account plus a backup, agencies managing storefronts for clients, and dropshippers who learned the hard way that “new email, new account” is not a strategy.

What a browser fingerprint actually is

A browser fingerprint is not one thing. It is a bundle of dozens of measurements a website can take without asking permission, combined into an identifier stable enough to recognise you across sessions, across accounts, and — crucially — across cookie wipes.

Some of it is declared openly: your user agent, screen resolution, timezone, configured languages, installed plugins. Some of it is measured: how your specific GPU and driver render a hidden Canvas drawing, which WebGL renderer string your graphics stack reports, how your audio pipeline processes a synthetic oscillator, which fonts are installed, how many logical CPU cores and how much device memory the browser exposes. None of these values is unique on its own. Combined, they routinely are. The EFF's Cover Your Tracks project has demonstrated this for more than a decade — run it on your own machine and it will usually report that your browser is unique among the hundreds of thousands it has tested recently.

The layers that matter

It helps to think of the fingerprint in four layers, because each layer fails differently when you try to hide it:

1. Hardware layer — canvas hash, WebGL renderer and vendor, audio fingerprint, CPU core count, device memory, GPU-dependent rendering quirks. This layer is the most stable and the most damning, because it describes the physical machine.
2. Environment layer — operating system and version, installed fonts, screen geometry and pixel density, timezone, locale and language list. Stable for months at a time.
3. Network layer — IP address, ASN (residential ISP vs datacenter), TLS handshake characteristics, DNS behaviour, WebRTC-exposed addresses.
4. Behavioural layer — typing cadence, mouse movement, session timing, the order in which you visit pages. Softer, but increasingly used as a tiebreaker.

If you want the attribute-by-attribute breakdown, our beginner's guide to browser fingerprinting covers each one in detail. For this article the important point is narrower: the hardware layer survives everything you normally think of as “starting fresh.” New email address, cleared cookies, a second Chrome profile, an incognito window, even a full browser reinstall — the canvas hash and the WebGL renderer string come out identical afterwards, because the machine underneath did not change. That is the mechanism by which one suspended account takes its siblings down with it.

One more thing worth knowing: browsers themselves are slowly reducing the declared signals. Chromium's user-agent reduction froze most of the detail that used to live in the UA string. The practical effect for sellers is the opposite of what you might hope — as the easy, low-entropy signals fade, detection vendors lean harder on the measured, high-entropy ones like canvas and WebGL, which are precisely the signals casual workarounds never touch.

Why marketplaces ban in clusters, not one at a time

To understand marketplace account bans you have to understand the marketplace's incentive structure, because it explains behaviour that otherwise looks arbitrary.

A marketplace sells trust. When a seller defrauds a buyer, ships counterfeits, or manipulates reviews, the platform eats the reputational cost. And the single most reliable predictor of future abuse is past abuse — which means the platform's most important adversary is not the first-time bad actor, it is the banned seller who comes back under a new name. Every major marketplace therefore invests heavily in re-registration detection, and the cheapest way to catch a re-registration is to fingerprint the device, not the identity. Names, emails and LLCs are cheap to replace. A laptop is not.

The policy layer reflects this. Amazon's Business Solutions Agreement has long allowed the operation of multiple accounts only with a legitimate business need for each, and its enforcement teams treat related accounts as a single unit: if one account is deactivated for a violation, accounts related to it are routinely deactivated too, regardless of their own record. eBay maintains an explicit linked-accounts practice — an account associated with another that has unpaid fees or an active suspension can be restricted purely by association. Etsy's terms similarly allow the platform to close all shops belonging to a member whose privileges have been terminated.

Notice what this means in practice: the ban is not a verdict on each account, it is a verdict on the cluster. Your second account does not need to do anything wrong. It only needs to be linked. And linkage is a data problem, which is why the fight over browser fingerprinting and marketplace account bans is really a fight over what your device reveals.

How Amazon, eBay and Etsy actually link accounts

No platform publishes its detection stack, for obvious reasons. But between leaked vendor documentation, seller-forum post-mortems, and what the detection industry openly advertises, the picture is consistent. Linkage decisions are built from weighted signals, roughly in this order:

Two details in that table deserve emphasis.

First, the top two rows are browser-level signals, and they compound. A shared canvas hash alone might be circumstantial — plenty of identical office laptops exist. A shared canvas hash plus a cookie that once lived in the same browser storage plus two sessions from the same residential IP within an hour is not circumstantial at all. Detection systems think in coincidence-stacking, and most multi-account sellers hand them three or four coincidences per session without realising it. We walk through the full detection pipeline in how websites detect multiple accounts on the same device.

Second, the marketplaces differ in flavour more than in substance. Amazon is the most aggressive and the most automated; its verification events (video calls, utility bills, re-verification of bank details) exist partly to force identity signals into the open when device signals are ambiguous. eBay's linked-account enforcement is older and blunter — association with a restricted account is often enough, which is why sellers running multiple eBay storefronts need discipline from day one (we cover the specifics in our guide to the best browser for managing multiple eBay accounts). Etsy leans harder on payment and identity overlap, but its device checks have tightened noticeably since 2024.

The signals sellers consistently underestimate

A few linkage vectors come up in ban post-mortems again and again, and they are rarely the ones sellers worry about:

• WebRTC leaks. Your browser can reveal your real local and public IP over WebRTC even while every HTTP request goes through a proxy. One leak, one linkage.
• Timezone and language mismatches. A “UK seller” whose browser reports America/New_York and en-US while connecting through a London proxy has not been linked to another account — but they have been flagged as someone hiding something, which invites the deeper checks that do link them.
• Login hygiene accidents. Logging into Account B from Account A's browser once — to answer one urgent message — writes Account B's session into Account A's storage. That association is durable and retroactive.
• Household collateral. A family member's account on the same laptop and home IP is, to the detection system, indistinguishable from your secret second account. Suspensions of an innocent spouse's account after a seller's ban are common enough to be a genre of forum post.

The lifecycle of a linkage ban

Sellers often conclude their setup is safe because it has worked for six months. This misreads how linkage enforcement operates. Marketplaces do not always act on a link the moment they see it. The typical lifecycle looks like this:

1. Silent association. The system observes shared signals between accounts and records the relationship. Nothing happens. Both accounts keep trading.
2. A trigger event. One account collects a policy strike, a spike in complaints, an IP claim, a failed verification — anything that puts it in front of an enforcement queue.
3. Cluster review. The flagged account's recorded associations are pulled up. Related accounts are evaluated as one entity.
4. The cascade. The cluster is actioned together. To the seller it looks like a simultaneous, inexplicable multi-account ban; internally it is one decision applied to one entity.

This is why “it's been fine so far” is evidence of nothing except that no trigger has fired yet. The association was likely recorded in the first week. It is also why post-ban recovery attempts fail so often: the seller appeals Account B on its own merits, but the platform is not judging Account B on its own merits — it is judging the cluster, and the cluster contains a violation.

Five mistakes that get multi-account sellers linked

1. Treating incognito as a new device

Incognito or private mode discards cookies when the window closes. It does nothing to the fingerprint. Canvas hash, WebGL strings, fonts, screen geometry, audio fingerprint — all identical to your normal window, because it is the same browser on the same machine. Worse, a fingerprint that arrives with no cookies and no history is itself a mild anomaly on a marketplace where legitimate users stay signed in for months.

2. Assuming Chrome profiles are isolation

Chrome's built-in profiles separate cookies and history, which is genuinely useful — for keeping work and personal email apart. They share everything else: the same binary, the same GPU, the same fonts, the same hardware-derived hashes. Two Chrome profiles are two rooms in the same house. A marketplace fingerprinting the hardware sees one house.

3. The VPN trap

A VPN changes your IP, and only your IP — one row of the table above, and not the top one. It also usually changes it badly for this purpose: consumer VPN exit nodes are datacenter IPs, flagged as anonymising infrastructure by every commercial IP-intelligence feed, and shared with thousands of strangers — including, statistically, other banned sellers whose reputation you now inherit. If the network story matters (it does), each account needs its own dedicated residential or ISP address that matches the account's registered region. Our residential proxies playbook covers how to pair them correctly.

4. Half-spoofed fingerprints

Browser extensions that randomise your canvas or fake your user agent tend to create the worst of both worlds: an internally inconsistent fingerprint. The UA claims Windows 11 while the fonts scream macOS; the canvas hash changes on every page load, which no real device does; the spoofing script itself is detectable because it patched native functions in ways JavaScript can inspect (a toString() on a patched API is a classic tell). Detection systems do not need to know who you are to flag you — “this device is lying” is itself the signal. Consistency beats randomness, a point we develop in how to change your browser fingerprint properly.

5. One careless login

The most common linkage in agency and VA contexts is human, not technical: someone logs into the wrong account from the wrong environment once, under deadline pressure, and the association is written. Tooling can make the right path the easy path — one click opens the right profile with the right proxy — but the rule has to exist: an account is only ever touched from its own environment. No exceptions for “just checking messages.”

What real profile isolation looks like

If the failure mode is shared signals, the fix is unglamorous: make every account's environment genuinely, consistently, durably separate. Four properties define a setup that holds up.

One profile, one device story, forever

Each account gets a browser profile with its own complete fingerprint — canvas, WebGL, audio, fonts, navigator properties, screen geometry, hardware concurrency — that is (a) plausible, meaning every value could co-exist on a real machine, and (b) persistent, meaning the account sees the same device today, next week, and next quarter. Real customers do not get a new GPU every morning. A fingerprint that mutates per session is as suspicious as one that matches a banned account.

Storage isolation is half the battle

The profile needs its own data directory: cookies, localStorage, IndexedDB, cache, service workers, session storage. Fully separate, so a session token from one account can never surface in another's requests — and fully persistent, so the account accumulates the months of normal cookie history that legitimate long-term sellers have. This is where Dual Login's architecture is deliberate: every profile runs as its own browser process with its own isolated data directory, so cross-contamination is structurally impossible rather than procedurally avoided.

Native spoofing beats JavaScript injection

How the fingerprint is applied matters as much as what it says. Most cheap tools inject JavaScript into every page to overwrite the fingerprinting APIs — and injected overrides leave inspectable seams: patched function signatures, prototype-chain anomalies, values that differ between the main thread and a Web Worker the script never reached. Dual Login applies the fingerprint natively, inside a custom Chromium engine, so the spoofed values are simply what the browser reports — everywhere, including workers and iframes — with no injected layer for a detector to catch mid-lie.

The network has to corroborate the story

Each profile gets its own dedicated residential or ISP proxy, geographically consistent with the account's registered address; the browser's timezone and language follow the proxy's location; WebRTC is masked to the proxy exit rather than disabled (disabling it is itself a flag). At that point the device story, the network story and the account's paperwork all agree — which is exactly what a real, boring, single-account seller looks like.

A workflow that keeps marketplace accounts separated

Tools set the ceiling; process determines whether you reach it. Here is the operating rhythm that experienced multi-account sellers converge on.

Onboarding a new account

Create the browser profile before the account exists, and register the account inside it, so the marketplace's first-ever sighting of this seller is already the clean environment. Warm the profile up first — a few days of ordinary browsing on the marketplace as a logged-out visitor builds the cookie history and behavioural texture of a normal user. Use genuinely distinct business details: separate email, phone, payment rails and, where the platform requires it, a separate legal entity. The fingerprint keeps the device story separate; it cannot launder a shared bank account.

Daily operations

One profile, one account, always — the profile is the only door to that account, on every machine you work from. Keep sessions human: log in at plausible hours, linger on pages, do not machine-gun through fifty listings in ninety seconds at 4 a.m. Check your proxies before launch rather than after a session on your real IP. And write down the mapping of profile → account → proxy → payment method somewhere your whole team can see, because the linkage that kills clusters is usually an improvisation someone made under pressure.

If an account gets flagged anyway

First, freeze — do not frantically log into every related account to check on it, from wherever you happen to be sitting; panic sessions create fresh association evidence at the worst moment. Diagnose which signal likely tripped (a performance metric? a verification event? an IP incident?) before you respond, and appeal only with the account's own facts. Amazon-specific triage — including what a Section 3 notice actually asks for — is covered in our Amazon seller ban playbook.

FAQ

Can marketplaces detect antidetect browsers?

They can detect bad ones. Tools that inject JavaScript to overwrite fingerprinting APIs leave measurable artefacts — patched natives, main-thread/worker mismatches, impossible value combinations — and those artefacts are themselves flags. A browser that applies an internally consistent fingerprint at the engine level presents nothing to detect: every API reports one coherent device, which is indistinguishable from that device simply existing.

Will clearing cookies unlink my accounts?

No. Cookies are one signal of many, and the durable ones — canvas hash, WebGL renderer, fonts, screen, IP history — survive a cookie wipe untouched. Worse, any association the platform already recorded is historical data on their side; nothing you delete locally removes it. Clearing cookies also resets your session history, which makes the next visit look less like an established seller, not more.

Do I need a separate computer for every account?

That is the brute-force answer, and it works, but it stops scaling around account three or four. An antidetect browser gives each profile what a separate computer would — a distinct, persistent hardware fingerprint and isolated storage — on one machine. The one thing hardware cannot buy you either is discipline: separate devices on the same home IP with the same bank account are still one cluster.

Are related-account bans permanent?

Often, but not always. Amazon reinstates related-account deactivations when a seller can document that the accounts are genuinely independent businesses or that the “relation” was a false positive (a shared coworking IP, a former employee). The burden of proof is on you, the process takes weeks, and success rates drop sharply once a real policy violation exists anywhere in the cluster — which is why preventing the linkage beats litigating it.

Is using an antidetect browser against marketplace rules?

The browser is a tool; the policies govern accounts. Amazon permits multiple seller accounts where there is a legitimate business need for each; eBay allows multiple accounts outright, provided none is used to evade a restriction; Etsy requires disclosure in some cases. Running legitimate, independently operated accounts with proper isolation is a compliance-hygiene practice. Using any tool to resurrect a banned account or dodge enforcement violates the same policies it always did.

Why did my second account get banned when it never broke a rule?

Because related-account enforcement judges the cluster, not the account. Once two accounts are linked — by fingerprint, IP, storage, payment or paperwork — a violation on either one is treated as a violation by the entity behind both. Your second account's clean record is not part of the equation; its association is.

Final thoughts

Browser fingerprinting and marketplace account bans are two halves of one mechanism: the platform identifies devices, and enforcement acts on everything a device touches. Sellers who lose account clusters almost never lose them to sophisticated detection — they lose them to shared canvas hashes, reused home IPs, and one careless login, months after the association was silently recorded.

The defence is equally unmysterious: one account, one complete and consistent device story, one matching network identity, maintained without exceptions. That is precisely the job Dual Login was built for — isolated browser profiles, each with a native, internally consistent fingerprint, its own persistent data directory, and its own proxy, launched as a real separate browser process. If you are running more than one marketplace account on hope and incognito windows, set up your first isolated profiles with Dual Login and give each account the separate device it should have had from day one.