Antidetect browsers are being pushed out of the fingerprint business

Chrome 145 reached stable on 10 February 2026. Its release notes list Device Bound Session Credentials among the security changes: "Device Bound Session Credentials (DBSC) lets websites bind a user's session to their specific device, making it significantly harder for stolen session cookies to be used on other machines."

For a category whose product is a portable, copyable browser identity, that is an uncomfortable sentence. It is also a much smaller event than it first looks.

Start with what DBSC actually requires. Per Chrome's own developer documentation, it is opt-in per site and does nothing by itself. A site has to respond at login with a Secure-Session-Registration header, stand up a registration endpoint that ties a public key to the session and swaps the long-lived cookie for a short-lived one, then run a refresh endpoint that checks key possession when the short cookie expires. Chrome generates the key pair at login and "stores the private key in secure hardware, such as a Trusted Platform Module (TPM), when available." Where that hardware is missing, the documentation says DBSC "gracefully falls back to standard behavior without breaking the authentication flow."

So the browser half is in stable Chrome. The constraint exists only on properties that have built the server half, and there is no public register of which those are. Chrome's own Platform Status entry for the feature, read on 27 July 2026, still carries the status "In development" against desktop milestone 145 and a shipping year of 2026, which is either stale metadata or a sign the rollout is unfinished. Two follow-on entries, one for a DBSC JavaScript API and one for DBSC across SSO flows, both read "Proposed" with no milestone at all.

Treat this as direction of travel rather than something breaking your crawlers this quarter. The direction has been consistent since Google announced the work on 2 April 2024 in a post titled "Fighting cookie theft using device bound sessions", which stated the goal plainly: "By binding authentication sessions to the device, DBSC aims to disrupt the cookie theft industry since exfiltrating these cookies will no longer have any value."

Read that clause again with an antidetect browser in mind. The target is malware. The mechanism is making session state non-portable. Portable session state is the thing these products sell.

The premise the category was built on

The antidetect browser category rests on one assumption: a site identifies a visitor by the sum of the client-side traits their browser exposes, so a convincing forged set of traits buys a fresh identity. Everything else in the product follows from that.

You can see the assumption in how the tools are marketed. GoLogin, AdsPower and Dolphin Anty all lead with the number of fingerprint parameters a profile can vary across canvas, WebGL, fonts, timezone and client hints. Multilogin went further and maintains its own rendering engines rather than patching one browser's outputs, so profiles differ below the level a script can inspect.

The parameter counts are the tell. When the headline number is how many traits you can vary, the product is betting that traits are what get compared.

What actually changed

Detection stopped being a client-side trait comparison some years ago. The shift happened in layers, and each one sits further from anything a profile manager controls.

Transport came first. A TLS handshake carries an ordered cipher list and extension set that a genuine Chrome build produces in a particular way and an automation stack usually does not. That signature is available before a single byte of JavaScript executes, so no amount of canvas noise reaches it. HTTP/2 frame ordering and header casing carry the same kind of tell.

Network reputation came next. Address class, ASN, historical abuse and the correlation between an address and the traffic pattern arriving from it are all evaluated server-side. This is why nearly every serious antidetect vendor now bundles or resells proxies: Nstbrowser and Octo Browser both sell pooled residential and datacenter access alongside the browser itself. The fingerprint was never sufficient on its own, and the vendors' own bundling concedes it.

Behavior arrived third, and it is the layer that gives fingerprint spoofing the most trouble. Timing between events, pointer paths, scroll cadence, how long a page sits before first interaction, whether a request sequence matches how a person moves through a funnel. A modern anti-bot system scores a session across its lifetime rather than gating on a single page load, which is why a profile can clear the door and fail twenty minutes later. Our guide to why scrapers get blocked walks the diagnostic order, and the useful habit is to work down from transport instead of starting at the fingerprint.

Session binding is the fourth layer and the one still arriving. Its design point is that a session is tied to a private key held in device hardware, with the browser periodically proving possession. Where a site implements it, exporting a profile and its cookies to another machine stops working. The fingerprint has nothing to do with that failure. The credential itself will not travel.

What the products are becoming

These products probably do not die. The fingerprint just stops being the reason anyone picks one.

Look at where the vendors put engineering effort now. Kameleo ships a local control API with SDKs that attach Selenium and Playwright to a running profile. Multilogin and Octo Browser sell team permissions, activity logs and bulk profile creation. That is session and profile management rather than evasion: who holds which authenticated session, on what schedule it gets used, which teammate touched it, and whether the automation attached to it behaved. We covered the mechanics of driving profiles from code in a separate guide on antidetect automation.

That is a legitimate and rather boring infrastructure job. Plenty of teams hold real credentials for supplier portals, marketplace seller consoles, ad platforms and internal SaaS reporting tools, and need those sessions to stay alive, stay usable from automation, and leave an audit trail. Nothing there requires deceiving anyone. It requires isolation, persistence and access control.

It is worth being straight about the other half of the market. These same vendors describe their products, in their own copy, as tools for running many accounts on large consumer platforms without those accounts being linked. That is multi-accounting, it generally violates the platform's terms, and it is a meaningful share of the category's revenue. A data team should not pretend the tooling is neutral, and should not buy an evasion posture it does not need. The question worth asking internally is whether you are managing access you are entitled to or manufacturing access you are not.

The cloud browser question

If the real requirement is automated collection from sites where you hold a legitimate login, the desktop antidetect model starts to look like the wrong shape. It puts state on a workstation, makes concurrency a licensing question, and buries the important configuration in a GUI rather than an API.

Browserbase attacks the same problem from the browser infrastructure side. Its Contexts feature persists the Chromium user data directory across sessions, and its documentation is specific about the contents: session cookies, localStorage, IndexedDB and session storage are carried over, while the HTTP cache is not. You attach a context by id and set persist: true, and the login survives. Notably, that documentation says nothing about fingerprinting at all, which is roughly the point. Surfsky sits between the two models, pairing antidetect Chromium with proxy management over CDP for Playwright, Puppeteer and Selenium.

Both make session state a server-side resource you can scale, snapshot and inspect. If binding does spread, the cloud model has the easier migration, because the session already lives on one durable machine instead of being exported between laptops. Whether that beats running your own fleet is a separate calculation, worked through in our self-hosted versus managed browsers guide. It usually turns on ops load rather than instance price.

What this means for a team collecting web data

Stop treating fingerprint parameter counts as a buying criterion. A vendor advertising fifty-plus spoofable traits is describing effort spent on the layer that decides the least. Ask instead what the product does about TLS signature, address quality and behavioral pacing, and what happens to a session challenged mid-run.

Separate your targets by whether they need a session at all. Anonymous collection at volume is a throughput problem, and an unblocking endpoint or scraping API handles it better than any profile manager; we argued that in the piece on unblockers becoming the default proxy purchase, and the antidetect versus scraping API guide draws the line in more detail. Authenticated collection from a handful of portals is a session problem, and that is where isolation genuinely earns its keep.

If you run authenticated collection, treat every session as an asset with an owner, a location and a log. That discipline pays off whatever Chrome ships next, and it is the part that survives a move to hardware-bound credentials.

Do not build a pipeline whose viability depends on copying session state between machines. That is the specific capability the platform is deliberately removing. It may take another two years, and it may stall on adoption rather than on code. It is still not a foundation to plan around.

The category will be fine. It just will not be a fingerprint business for much longer.