Our fingerprint work is a patched Chromium, not a script injected into someone else's browser. If your platform needs that binary to be yours, shipped in your image and called by your customers, that is a licensing conversation, not a policy violation.
Three shapes of buyer. If you recognise yourself here, the terms below already cover you.
Your users hand you a task and you run a browser for them. The browser has to look like a person, and it has to be yours, not a dependency your users are told to install.
You sell sessions by the hour or by the page. Every cold start is a cost line, so the browser has to already be in the image.
Your product automates one industry deeply and the browser is an implementation detail your customers should never see, install or license separately.
Depending on our SDK is not redistribution. You can build and sell a commercial product on top of it today, with no agreement and no conversation with us, because your users fetch the kernel themselves from our endpoint under their own licence.
| Scenario | Redistribution? | Needs an agreement? |
|---|---|---|
| Your open-source tool lists the SDK as a dependency | No | No |
| Your commercial CLI installs the SDK from npm or PyPI at install time | No | No, each user brings their own key |
| Your Dockerfile installs the SDK and the image pulls the kernel at container start | No | No |
| Your Docker image ships with the kernel already baked in and is published publicly | Yes | Standard OEM grant |
| You mirror the kernel archive to your own CDN, S3 bucket or artifact registry | Yes | Standard OEM grant |
| You run a SaaS where your customers' automation drives kernels you host | Not redistribution | The main OEM use case |
The last three rows are not edge cases we tolerate. They are the three things this programme exists to license. Baked-in images in particular are the default grant, not an exception: we know that pulling a Chromium archive at container start is not viable for anything with a cold start budget.
Selected per deal. All of these are on the table.
Ship the kernel inside your installer, container image or artifact registry. Your users never touch our download endpoint.
Your customers' automation drives kernels you operate, under your own license terms with them.
Ship it under your product name. Binary strings, process name, user-agent product token and update endpoint can be customised.
Freeze on a specific kernel build for the term, with an agreed migration window. You are not forced onto our release train.
Available on annual commitments above an agreed threshold. Release triggers: our insolvency, or discontinuation of the kernel.
The default licence token is short-lived and refreshed online, which is fine for an end user and unacceptable for a platform whose own customers depend on it. An OEM agreement replaces that arrangement rather than asking you to live with it.
Verification is local, against a key compiled into the kernel. Validity period and delivery mechanism are terms of the agreement, agreed per deal, so your startup path does not depend on reaching us.
Token issuance is out-of-band. Networks that never reach the public internet are a supported deployment, not a workaround.
What happens when our licensing endpoint is unreachable is written into the agreement: already-licensed deployments keep starting, for a period agreed per deal.
A contractual maximum lag behind upstream Chromium stable, and a contractual response window for detection regressions on the sites you name.
We publish reproducible detection runs with the date and the method attached, so you can check the claim rather than take it. Under an OEM agreement we run the same method against the sites you actually care about, and those runs are available as pre-sales and acceptance material.
AntiBrow operates its own end-user product at antibrow.com. We do not operate a browser-infrastructure API or a scraping API, and an OEM agreement commits us not to launch one that targets a licensee's named market during the term. If that changes, it changes at renewal, in writing, not silently.
We put this in the licence rather than in a sales call because it is the first thing anyone building on a supplier should ask, and an answer that only exists in a conversation is not an answer.
The answers here are the licence's answers. Where the two ever differ, the licence wins.
No. The kernel is not in the npm or PyPI package. Your users fetch it at first run from our distribution endpoint, onto their own machine, under their own licence, so you never handled the binary. You can publish and sell a commercial product on top of the SDK with no agreement and no conversation with us. The licence states this explicitly in §4.
That is redistribution and it needs an OEM agreement, but it is the default grant rather than an exception. Pulling a Chromium archive at container start is not viable for anything with a cold start budget, and we know it.
The default licence token is short-lived and refreshed online. An OEM agreement replaces that with long-lived, offline-verifiable tokens and out-of-band issuance for air-gapped networks, plus a written grace period for when our licensing endpoint is unreachable. Validity period and grace length are terms of the agreement, agreed per deal.
Yes. Version pinning is one of the grants: freeze on a specific build for the term with an agreed migration window, so a kernel release never lands in the week before your own launch.
Yes. Binary strings, process name, user-agent product token and update endpoint can be customised, and attribution is optional throughout - there is no "powered by" requirement.
We run our own end-user product and no browser-infrastructure or scraping API. An OEM agreement commits us not to launch one that targets a licensee's named market during the term, and if that changes it changes at renewal, in writing.
Pricing is based on concurrency, per deployment, with an annual minimum commitment. Four things get us to a number: concurrency now and in twelve months, the sites you need to hold against, how you deploy, and which grants you need.
Pricing is based on concurrency, with an annual minimum commitment. Four things get us to a number: your concurrency now and in a year, the sites you need to hold against, how you deploy, and which grants you need.
Attribution is optional. There is no "powered by" requirement.