Legal

Privacy Policy

Last updated 2 August 2026. This policy describes the InstantBlock detection engine and the InstantBlock console at instantblock.eu, operated by InstantNode.

Read this if you are a website visitor. InstantBlock is anti-bot software that other websites embed. If you reached this page after seeing a browser check on someone else's site, the section What we collect from visitors describes exactly what was read from your browser, and Who is responsible explains who to contact about it.

Who is responsible for what

InstantBlock operates in two distinct roles, and your rights differ depending on which applies.

As a processor — when a customer embeds InstantBlock on their website, that customer decides to run the check and is the controller of their visitors' data. We process it on their instructions, under the Data Processing Agreement. If you are a visitor to a customer's site, direct access, deletion and objection requests to that site operator first; we will support them in answering you, and we will act on a request routed to us directly where we can identify the records.
As a controller — for our own customer accounts, our own website, and the browser check we run on our own sign-in and sign-up pages. Here we decide the purposes ourselves and you can exercise your rights against us directly.

The short version

We read a large amount of technical detail from the browser — around 300 distinct signals per check — to tell an automated client from a person.
Most of it is stored in its original form, not hashed or anonymised. We say so plainly below rather than describing this as "anonymous technical data", because it is not anonymous.
We derive a persistent device identifier that is stable across visits and, today, is shared across all sites using InstantBlock.
We do not collect the page path, query string, referrer, page content, form values, or the characters you type. We do not sell data or use it for advertising or profiling unrelated to bot detection.
Behavioural signals are timing and movement statistics. We do not record which keys you press and we do not retain a reconstructable cursor path outside the captcha flow.
One third party receives data as a direct consequence of the check: Google, via a STUN network request. This is described in Third parties.

What we collect from visitors

Each verification produces a record of roughly 300 fields. The table groups them by what they describe. Where a value is transformed before it leaves the browser, we say which; where it is not, it is stored verbatim.

Rendering & graphics

Canvas rendering hashes — we draw text, shapes and emoji to an off-screen canvas and store a short non-cryptographic hash of the result, plus text-measurement values. The image itself is not transmitted.
GPU vendor and renderer strings — stored verbatim, e.g. ANGLE (Intel, Mesa Intel(R) Iris(R) Xe Graphics (ADL GT2), OpenGL ES 3.2).
WebGL capability parameters and the full list of supported extensions — roughly forty values, stored verbatim.
WebGL and font rendering pixel hashes — we render a shader and a set of pangrams and store short hashes of the pixel output.

Device & system

Screen and window geometry, including available screen area, colour depth, pixel ratio, and desktop window position.
Reported CPU core count and device memory.
Platform, full User-Agent string, and User-Agent Client Hints including architecture, model and platform version — all verbatim.
IANA timezone name and configured languages — verbatim.
Installed-font detection: a hash of the detected font list, plus individual font presence results.
Browser plugin names and MIME types, audio hardware sample rate, media-device counts (not identifiers or labels), battery level and charging state, permission states for camera, microphone, geolocation and notifications, storage quota estimate, and keyboard layout characters.

Automation & tamper probes

Around ninety probes checking whether standard browser functions have been replaced, wrapped or instrumented — the primary way automation frameworks are detected.
Developer-tools and debugger detection signals, and markers left by common automation tools.
Frame-timing summary statistics (mean, variance, minimum, maximum over thirty frames).

Behavioural signals

Collected while the check runs, and reduced to statistics in the browser before transmission:

Pointer movement — relative movements and timings only. Absolute cursor coordinates are held transiently to compute each step and are then discarded; no cursor path leaves the browser.
Typing rhythm — inter-keystroke intervals and key-hold durations. The identity of the keys is never read. The event handlers do not receive the key value, so we cannot know what you typed.
Click hold-times, pointer pressure, scroll intervals, touch events, and a session engagement duration.

Exception — captcha. If you are shown the InstantBlock captcha, that flow records the raw cursor and touch coordinate trace of your interaction with the widget, together with your User-Agent. This is a genuine movement recording, not a statistic, and it is the one place where a reconstructable path is stored.

Network & connection

TLS handshake characteristics and derived fingerprints, and HTTP protocol version.
Connection type and effective bandwidth as reported by the browser.
WebRTC ICE candidate types (for example host) — candidate IP addresses are not extracted for this signal.
Your IP address is used in transit to route the request and, where the deployment is configured to read it, for rate limiting, reputation scoring and binding a session to its origin. Where an IP is retained in our verification logs it is stored as a truncated SHA-256 hash. That hash is unsalted, and we do not claim it is anonymous — the IPv4 space is small enough to reverse by brute force.
If the address seen at the network layer disagrees with the one observed via WebRTC, the mismatch is recorded and the public IP address is written into that record in full.

Page context

The origin of the page running the check — scheme and host only, e.g. https://example.com — stored both hashed and in clear text.
Page protocol, the length (not the content) of the host string and document title.
We do not collect the path, query string, fragment, referrer, page content, or any form values.

The persistent device identifier

We derive a device identifier by hashing twelve stable characteristics — canvas hash, GPU vendor and renderer, WebGL render hash, screen width and height, colour depth, timezone, language, platform, CPU core count and font-list hash — and truncating the result. The same browser on the same machine produces the same identifier across visits, without any cookie or stored value on your device.

Against that identifier we keep a device profile containing a full fingerprint snapshot, an environment snapshot, first-seen and last-seen timestamps, a visit counter, a trust score, and a capped history of detection flags raised over time.

Cross-site scope. The device profile store is currently global, not partitioned by site. A device that visits two different sites protected by InstantBlock resolves to the same profile, and the profile records which site was seen most recently. This makes the identifier capable of linking a browser across unrelated websites. We treat this as a defect rather than a feature, and we are partitioning the store per customer; until that ships, this policy describes the behaviour as it is.

Where a new fingerprint closely resembles an existing device without matching it, we record a cross-reference noting the similarity and the other device's identifier. This does not merge the two identities — a new identifier is still issued.

Where the data is stored

All verification data is held on servers we operate in the European Union. There is no transfer to a third country as part of normal operation. Specifically:

Verification records — one JSON file per check, on disk, organised by site and date.
Device profiles — one JSON file per device identifier, rewritten on each sighting.
Aggregate statistics — per-site and per-day counters used to draw dashboard charts.
Captcha interaction traces — stored separately when the captcha is served.
Session state — held in memory only, for one hour, and lost on restart.

Third parties

These are the only third parties that receive data, and exactly what they receive:

Google (STUN server, stun.l.google.com) — during verification your browser contacts Google's public STUN service to discover your public IP address, which we compare against the address we see. As a direct consequence, Google receives your IP address. We do not send Google anything else, and we do not receive anything from Google about you. We are removing this dependency in favour of a self-hosted STUN endpoint.
Our hosting and network provider, and the TLS-terminating reverse proxy we run in front of the application, which necessarily handle connection metadata.

The instantblock.eu website and console load no third-party resources at all. There is no font CDN, no icon CDN, no analytics and no tag manager: typography uses the fonts already on your device and the icons are embedded in the page. Loading any page of this site therefore discloses your IP address to us and to no one else. Our Content-Security-Policy restricts the page to our own origin, which is independently verifiable in your browser's network inspector.

We do not use analytics, advertising, tag managers, session replay, or social plugins. We do not sell, rent or share personal data, and we do not use verification data to build advertising or marketing profiles.

Cookies and local storage

On customer sites, the detection engine sets no persistent cookie and stores no identifier on your device. Two things do touch terminal storage during a check, both strictly to test whether the capability works — a common tell for automated clients:

A transient first-party cookie _ib_p=1 is written, read back once to confirm the round-trip, and immediately expired. Only the boolean result is kept; no value is retained or used as an identifier.
An IndexedDB database named __ib_probe is opened to confirm storage is available. It holds no data. It is currently not removed afterwards, which we are fixing.

On our own website, a single strictly-necessary session cookie ib_sid is set when you sign in. It is HTTP-only, SameSite=Lax, marked Secure in production, and expires after fourteen days. There are no analytics or advertising cookies, which is why the site shows no cookie banner.

Customer account data

If you create an InstantBlock account we store your email address, display name, an indicator of whether the account is an administrator, the creation timestamp, and a password hash produced with scrypt (N=16384, r=8, p=1). We never store your password. We also store the configuration and credentials of the sites you protect.

Sign-up is restricted to company email addresses; a built-in list of twenty-three consumer email providers is refused. Sign-in and sign-up attempts are logged with the email address, the stage reached, and the outcome — including for attempts that are rejected, which means an address that never became an account may still appear in our operational logs.

Our own sign-in pages run the full browser check. The InstantBlock login and sign-up pages embed a hidden frame that runs the same verification described above, under a dedicated internal site key, to protect against credential stuffing. Loading those pages therefore produces a full fingerprint record and a device profile, whether or not you complete sign-in. For this processing we are the controller.

What our customers can see

A customer signed in to the console sees, for their own sites only: verdict counts over time, the distribution of detection flags, and a live feed of recent verdicts showing the timestamp, decision, score and flag names. Customer access is scoped to sites owned by their account. Customers do not have access to other customers' data. The full fingerprint of a specific verification is available through the API to the customer that owns the site key it was collected under.

Why we process this data, and on what basis

To distinguish automated clients from people — the sole purpose of the fingerprint, behavioural and network signals. For customer sites, our customer relies on legitimate interests (securing their service against automated abuse) and is responsible for that assessment; we act on their instructions. For our own sign-in pages, we rely on our legitimate interest in preventing credential stuffing and automated account creation.
To operate accounts and provide the service — performance of our contract with you.
To keep the service secure and available — rate limiting, abuse prevention, diagnostics: our legitimate interests.
To improve detection accuracy — analysing recorded verifications to tune detection rules. Read the note below on model training.

On automated decision-making. InstantBlock produces an automated verdict that can cause a website to refuse, challenge or allow a request. That decision is made by our software without human review. It governs access to the site you are visiting; it does not produce a legal effect of its own, and the site operator decides what to do with the verdict. If you believe you were wrongly refused, contact the site operator, or us at the address below, and we will investigate. We do not use this data to make decisions about you in any other context.

On training models. We analyse recorded verifications to tune and evaluate our detection rules. We do not currently train machine-learning models on visitor data. If that changes, we will update this policy before doing so and will describe the safeguards. Customers on the Scale plan may export TLS fingerprint data derived from their own traffic; that export contains no direct identifiers.

How long we keep it

Our retention commitments:

Verification records and device profiles — 90 days from last activity, then deleted.
Captcha interaction traces — 90 days.
Aggregate statistics — retained per plan (Free 7 days, Pro 90 days, Scale 1 year). These are counters, not per-visitor records.
Session state — one hour, in memory only.
Operational logs containing account email addresses — 90 days.
Account data — for the life of the account, then deleted within 30 days of closure, except where we must retain billing records to meet a legal obligation.

Where a device keeps returning, its profile is refreshed on each visit and the 90-day period runs from the last sighting rather than the first.

Your rights

Under the GDPR you may request access to your personal data, correction, erasure, restriction, portability, and you may object to processing based on legitimate interests. You may also complain to your national supervisory authority.

For visitor data collected on a customer's site, please contact that site operator first — they are the controller and can identify their own records. For anything we hold as controller, contact us directly.

An honest limitation. We cannot identify you by name in verification data, and we hold no contact details for visitors. To locate your records we generally need the device identifier or a verification identifier, which the site operator can obtain. If we cannot identify you from what you give us, we are not required to collect additional data purely to do so, and we will tell you if that is the case rather than guess.

Security

Verification payloads are encrypted in transit with a per-session key. Site secrets and API keys are shown once at creation. Passwords are hashed with scrypt. Access to production systems is limited to personnel who need it.

We do not claim any certification we do not hold. We are not currently ISO 27001 or SOC 2 certified.

Contact and changes

Privacy enquiries and rights requests: privacy@instantblock.eu. Postal and company details are on the Imprint.

If we change this policy materially we will update the date at the top and, for changes affecting customers, notify account holders by email. We will not apply a materially different use to data already collected without a fresh basis for doing so.