How to detect the Surfinite antidetect browser
Surfinite is an antidetect browser: a fake browser that gives each profile its own fingerprint. Its site pitches it to "Manage multiple advertising cabinets, social media accounts, work with bookmakers and crypto exchanges", and says each profile's own fingerprint "reduces the risk of bans and restrictions to zero" (surfinite.com). Maskbreak's answer does not name the product. It checks what every such session has to fake (the device, the network path and often the hands on the keyboard) and blocks a fake browser by default.
What Surfinite is (October 2026)
It is a Chromium build: its documentation shows the browser at ".surfinite/browser/Chromium.app" and offers to automate it "with the use of Selenium", with "all the capabilities of Chrome DevTools Protocol" (how it works). Each profile can spoof the canvas, WebGL and audio separately (fingerprint settings), proxies can be SOCKS, HTTP or SSH (proxies), and it runs on Windows, Linux and macOS.
Its changelog is plain about the target: version 1.1.6 "Added protection against Kasada bot detection tool when using automation", and 1.1.13 added custom network requests "mainly for checking proxy's Fraud Score" (what's new). In August 2023 its Telegram channel announced a fix for audio codecs that had caused problems with Bet365 (Telegram).
Prices are not published: its site and documentation show none, and its terms say payments are in euros, with "a 7-day free trial to new users" (terms of use). The terms name SIA ADVERTIMO of Riga, Latvia. Its official release was on 31 October 2022 and the last public update we found was in November 2024, so whether it is still maintained is unclear; its site still worked on 26 October 2026.
How Maskbreak reads a Surfinite session
A Surfinite session makes three claims: a real device, an ordinary connection and a person at the keyboard. Maskbreak's device check and network intelligence test those claims separately. A fake browser, a script driving the browser or a proxy exit each blocks on its own by default; a VPN alone is flagged for review.
device.antidetect is true, the reason antidetect_browser is added and the decision is block, the same as for a proxy, Tor, automation or an emulator. It flags the class of tool; it does not say which product the visitor used.device.tampering_score is a 0–1 score from the device check, not a probability of fraud, and it can sit near zero while antidetect is true. Route on decision and reasons; do not build a threshold on the score.device.automation is true, the reason automation_detected is added and the visit is blocked. It does not name the framework; bot detection covers the signal in full.proxy_detected and blocks; a VPN alone adds vpn_detected and goes to review. A residential proxy it does not recognise passes this layer, which is why the device check matters.device.virtual_machine is true and the reason virtual_machine is listed; on its own it asks for review, never a block: plenty of developers browse from one. It raises the risk score next to other findings.device.times_seen counts how often the device appears in Maskbreak's retained history, across all customers, not only yours. Send your own accountId and device.linked_accounts counts how many of your accounts the device has been used for; more than one adds multi_account_device, and three or more of your accounts on one device within 24 hours add device_many_accounts and ask for review. Links stay inside your account, stored as keyed hashes. Profile switchers are built to defeat exactly this, so treat linking as an extra layer, not the main one.An example response: the fixture that GET /v1/evaluate/sample returns for ?scenario=bot (no key needed), a fake browser driven by a script on a clean-looking address, trimmed to the fields that matter. It is test data for your handler, not a measurement of Surfinite.
// example response, POST /v1/evaluate
{
"decision": "block",
"risk_score": 83,
"reasons": ["antidetect_browser", "automation_detected"],
"network": {
"vpn": false,
"proxy": false,
"datacenter": false,
"tor": false,
"residential": true,
"service": null
},
"device": {
"antidetect": true,
"automation": true,
"virtual_machine": false,
"tampering_score": 0.78
}
}
Either finding alone would block. residential is true only because no proxy or cloud-server flag fired; it does not prove a home connection.
Shipping it
Add the Maskbreak browser snippet to your signup, login and checkout forms. Your server forwards the two tokens the snippet collects to POST /v1/evaluate with your API key and gets allow, review or block back, with the reasons; the device and network blocks carry everything above. Start in watch mode: log each decision and let every visitor through, then enforce once the Events log looks right. Field-by-field docs live in the API reference and the quickstart has the handler.
If some of your own customers run fake browsers for agency or seller work, set the Fake browser (antidetect) rule to review on the console's Rules tab. A rule changes the answer only for the signal it names, so a proxy or a script on the same visit still blocks; when a rule does change the answer, engine_decision keeps the default. The antidetect hub explains how the detection works and compares the other browsers; the bonus abuse and multi-accounting playbooks cover the bookmaker and advertising accounts Surfinite is pitched for.
Free plan: 10,000 visitor checks a month, no card. Paid plans from €29 a month.