What your antidetect vendor can see

There is a two minute test that settles most of this and almost nobody runs it.

Log out of your antidetect browser, click forgot password, and reset it through the email link. Then look at what came back. If all your profiles are sitting there intact, cookies included, logged into everything they were logged into before, then the key that decrypts them was on the vendor’s side. It has to have been. They just restored your access to data an email link was sufficient to unlock.

If instead you land in an empty account and the profiles need a recovery phrase you wrote down at setup, the encryption claim on the marketing page was true.

I run mobile proxy lines on carrier SIMs in Singapore and a rack of Android phones rented by the hour, so I am on both sides of this. Other operators paste credentials for my lines into products I did not write. I paste theirs into the same products. That is what got me thinking about the box you type a proxy into.

No vendor is named in any of what follows. The argument is structural and it applies identically to a product built by careful, honest people.

A profile is a row in someone’s database

Strip the interface off and a profile is a record. A name you typed, a creation timestamp, a fingerprint, a proxy string, notes, tags, a group, and a last-opened time.

Every one of those fields has to be readable by the software. In most products in this category it lives on the vendor’s servers, because server-side storage is what lets the same profile open on your laptop and your desktop.

So the vendor holds an inventory of your operation. How many identities you run. When each one was created. Which ones you stopped opening in March. The naming scheme you use, which for most people is far more descriptive than they would pick if they pictured a stranger reading it.

Session timing rides along with it. These products record when a profile opened and closed because that is how seat limits and device limits get enforced. Enough of that log and it describes your working hours, your timezone, your days off, and the four accounts important enough to open every morning.

The fingerprint came out of their generator

People talk about a fingerprint as a mask the browser wears. Somebody made the mask.

A generator on the vendor’s side picked the GPU renderer string, the screen dimensions, the font list, the hardware concurrency value, and wrote them against your profile ID. That is a mapping table, and whoever holds it can take a fingerprint observed in the wild and ask whether it came out of their own generator, and for which customer.

Nobody in this category advertises that, and it is also unavoidable. A generator that hands out fingerprints has to record which one it handed to whom, or it would hand you the same one twice.

The proxy field can’t be hashed

The one field with no privacy-preserving version is the proxy.

Passwords in a well built system are hashed, so the system can check yours without being able to read it. That is not available here. The browser has to present your proxy username and password to a proxy server on every connection it opens, which means the credential has to come back out in usable form at the moment of use. It can be encrypted at rest. It cannot be one way.

Store a credential in software you did not compile and it sits in that software’s custody. I flinched the first time I typed a carrier line’s username and password into a profile, for exactly that reason. If someone else ever used it, that traffic would leave the same exit IP as mine and I would have no way to separate it from my own.

Sync means the profile left your machine

Cloud sync is the default across most of this category and it is sold as convenience. Open a profile from anywhere. Hand it to a teammate. Get your work back when a disk dies. Genuinely useful, and I use it.

Mechanically, sync copies the profile folder somewhere else. Not just the settings row. The cookie jar, local storage, the indexed databases, and the live session tokens sitting inside them.

So the question of whether the vendor holds your logged in sessions usually answers itself. Yes, by design, and it was in the feature list you bought the product for.

A few products keep profiles on local disk by default and treat sync as something you switch on. That is a real difference between products and it is worth checking before you commit, not after you have 80 profiles in one.

This is the part that undoes the rest.

You built the isolation properly. A distinct fingerprint per profile, a distinct line per profile, everything checked against a fingerprint tester. Facing the platform, 40 profiles are 40 strangers.

Facing the vendor, they are one customer’s inventory. One email address. One payment method. One billing address. One subscription renewing on the same card each month. The account boundary sits above the profile boundary, and no configuration inside the tool moves it.

People try to split it across two subscriptions with two emails. Then both get paid on the same card, from the same IP, on the same afternoon, and the split is decorative.

The usual version of this argument is about a card linking your accounts to a platform, which is an inference a fraud team has to make. This one is smaller and much tidier. The vendor reads its own billing table. The join was written there at signup, by you, on a form. That same account is the lookup key when a support agent opens the ticket you filed about one misbehaving profile.

What a break costs on each side

Take my machine and you get the profiles on my machine. Bad, and bounded.

Take the store holding sync data and you get profiles, fingerprints, proxy credentials, and the mapping from all of it to one paying customer with a billing address on file. The whole picture in a single object, arriving pre-correlated.

Legal process has the same shape. A request served on a company holding an account list gets an account list. There is no guessing about which profiles belong together, because the schema already says so.

Ownership of that record can also change hands through an acquisition or a wind-down, which is a separate subject and a long one.

“We can’t see your data” is a claim about a schema

That sentence is standard copy now and it is worth nothing on its own, because it is compatible with almost every architecture anyone has shipped.

The version I will accept is specific. The profile is encrypted on my machine with a key derived from a passphrase I chose, and that passphrase never reaches the server. What the server stores is a block it cannot open. The password reset test at the top of this piece checks exactly that, and it costs two minutes.

Ask where the sync data physically sits too, in which jurisdiction and under which law. “The cloud” is not an answer. A company can be entirely honest and still be somewhere that can compel it.

What I can’t check from outside

I cannot read their servers. Nobody outside can.

What I can do is watch the client on my own machine. What it sends, how often, how big the payload is, whether a profile marked local still produces API traffic the moment I open it. That tells me something left. It says nothing about what happens after it lands.

A product could encrypt correctly and still keep a copy of the key so support can rescue people who lock themselves out. A product could describe itself as local only and quietly post an inventory. I can catch the second with a packet capture. The first is invisible from out here, and anyone claiming they audited a closed source binary’s server behaviour from the outside is selling you something.

I also read this wrong for about a year. I treated sync as synchronisation, in the sense of two folders kept identical, and never as a copy living on someone else’s disk. It took a friend asking where his profiles actually lived before I thought about it properly.

Choose per profile, not per product

Find out where profiles live in the product you already pay for. It is one settings screen and one support question. Local, cloud, or a hybrid where settings sync and browsing state does not.

Then decide per profile. Anything that would genuinely hurt to lose control of stays off sync, on one machine, and you accept that this machine is the only place it opens. The disposable ones can sync all day.

The local answer has a price and it should be said out loud: no recovery when a disk dies, no handover while you are away, and a backup routine somebody has to actually run. That cost is most of the reason the category drifted toward the cloud in the first place.

Keep the highest value credential out of the profile entirely. A live session token in a synced profile is the login. A password manager on your own disk is not in the sync payload. And if a team touches those profiles, every share is another copy in another place.

The isolation these tools sell has a direction. It points outward at the sites you visit, and it cannot point at the company you bought it from, because a tool that generates your fingerprints, uses your proxies and syncs your sessions has to be able to see all three. So stop expecting a product to protect you from itself and start choosing which company gets that view.

Full written reviews and the tested picks I actually trust are at Anti-Detect Review.

Get new guides and videos first — join the Telegram channel.