← All docs

What the agent stores, for your cookie notice

The agent runs in your pages, so what it writes is written on your site, and your cookie notice is where your visitors learn of it. This page is what to put there, what each item is for, and how to turn each off. It is not legal advice: whether a use needs consent is your counsel's call, and the references at the end are where that call usually starts.

What it writes

Name Where What it holds How long Off with
_abid A first-party cookie, SameSite=Lax, Secure over HTTPS The receipt: the verdict of the browser's last identification, signed, which your edge and server check on its next requests Ten minutes sessionCookie: false: then no edge or server guard has a verdict to read
antibot:visitor localStorage The visitor hint: which visitor this browser was, signed by the service, so a returning browser is compared with its own visitor first Until the next answer replaces it; honoured for 400 days rememberVisitor: false, which also drops one kept before
_abvh A cookie set by the first-party proxy alone, HttpOnly, on its identify path only The same hint, kept where a browser keeps a script's storage only days 400 days rememberVisitor: false
antibot:result sessionStorage or localStorage, only if you choose either as cache The last result, so get() can answer without a round trip 30 minutes, or the cacheTtlMs you set The default, cache: "memory", keeps it in the page alone
__antibot_webrtc sessionStorage What the browser's WebRTC path reported this tab: the public addresses it was seen from, and how many candidates of each kind The tab, five minutes at most webrtc: false
__antibot_rtt sessionStorage A round-trip timing your first-party proxy started, for the tab's next identification to carry The tab, four minutes at most No proxy timing, no item
__antibot_clicks, __antibot_driven sessionStorage Whether the tab's last eight clicks landed dead centre on their target; whether a page was left by a browser driver's script The tab; clicks speak for 30 minutes —
antibot.gpu sessionStorage The graphics vendors WebGPU reported, so later pages do not ask again The tab —
antibot IndexedDB A signing key the page itself cannot export, for receipts bound to it Until site data is cleared Only with bindReceipt: true, off by default

Two more are written and removed at once, to learn whether storage works at all (private modes refuse it): __antibot in localStorage, and an IndexedDB database antibot-probe.

Nothing is written for any site but yours: the cookies are your site's own, and the hint names a visitor of your environment alone.

What it reads

Characteristics of the device and browser, as every device-intelligence agent does — the browser, its version and what it supports, the screen, fonts, graphics, audio, time zone and languages — and how the page is used: the statistics of pointer and keystroke timing, never a key, a character or a pointer position kept (behavioral biometrics). Each attribute is in a result's raw_device_attributes.

Keeping nothing past the tab

Antibot.load({ apiKey: "pk_live_…", rememberVisitor: false, sessionCookie: false })

Then the agent writes only what lives and dies with the tab. What it costs: a returning browser is recognised by its device alone, with less confidence once its rendering drifts; and with no receipt, an edge or a server guard judges its requests without the browser's verdict, as it would a client that ran no agent.

  • The ePrivacy Directive, Article 5(3): storing information on a device, or reading what is stored there, needs consent unless it is strictly necessary for a service the user explicitly asked for. The European Data Protection Board's Guidelines 2/2023 on its technical scope read it to cover reading a device's characteristics with a script, fingerprinting included, and not cookies alone.
  • The Article 29 Working Party's Opinion 04/2012 on the cookie consent exemption treats user-centric security cookies — its example is detecting repeated failed attempts to sign in — as exempt when they serve a service the user asked for.
  • The GDPR, Recital 47: processing strictly necessary to prevent fraud is a legitimate interest of the controller; Recital 49 says the same of network and information security.

So deployments commonly place the agent on the flows it protects — sign-in, sign-up, checkout, a form — as strictly necessary security, and load it elsewhere only once consent is given. For what the service does with the data it receives, you are the controller and LayerSift your processor, under the data processing agreement; how long it keeps what, and what you can have erased, is in privacy.