Privacy Policy

1. The short version

Three questions decide whether a detection engine is being honest about itself: what happens on your device, what leaves it, and how long what leaves it is kept. They are answered here in five lines, and at length in the rest of this document.

Nothing in this summary is a simplification walked back further down. Where the detail adds something, it adds precision, never an exception.

In short:

• Measurements run inside your browser. Canvas bitmaps, audio buffers, font probes and rendered geometry are reduced to hashes and small numbers on your own device, and only those leave it.
• Yes, we store hashes — a visitor id and several per-surface hashes. Recognising the same browser profile again is not a side effect of this service; it is the service.
• Yes, we store IP addresses, in full, beside the visit they belong to.
• No keystrokes, no typed text, no field values, no form contents and no clipboard, on any surface, ever.
• Records delete themselves on a clock. A visit lasts 90 days by default, less on a smaller plan, and a later visit never extends an earlier one.

2. Who answers for what

On hideguard.io we are the controller. We decide what the public pages measure and we answer for it.

On a customer's website we are a processor. That customer decided to install the SDK, that customer owns the records it produces, and that customer's own privacy notice is the one to read first — it is the notice that has to name us. We act on their instructions, we do not use their records for our own purposes, and the records of two customers are never combined.

A dashboard account itself — the email address, the name, the sessions — is ours to answer for, and for that we are the controller.

3. How client-side data is processed

The SDK is a single script on the customer's page. It runs in your browser, it measures, and it sends one request.

Every measurement is taken locally, and the pattern is the same on every surface: the script draws, synthesises or lays something out, reads the result back, and reduces it to a digest or a handful of numbers before anything is sent. The artefact itself — the bitmap, the audio buffer, the glyph geometry — stays in your browser and is gone when the page closes. We hold no bitmap, no recording and no picture of anything on your screen, because we were never sent one.

There is normally one request per page view, and the behaviour window rides on the request that was going out anyway rather than adding its own. Three things do make a request of their own, and each is named here because none of them follows from the first: a heartbeat every 15 seconds while the page is open (60 while the tab is in the background), which carries a token and nothing measured and exists only so a customer can count pages that are still open; one request as you leave the page, which delivers the window that would otherwise die with the document; and, where the customer switches it on, one request to a capture host, so that the characteristics of your connection are read from the connection you made yourself rather than from a relay.

What the script asks your browser for:

• Device and display — screen size, colour depth, pixel ratio, CPU core count, declared memory, touch points.
• Software claims — user agent, platform, languages, timezone, and which of a fixed list of fonts answers.
• Rendering — canvas, WebGL vendor, renderer, parameters and image hashes, audio-stack hashes, text anti-aliasing grey levels, client-rectangle geometry, floating-point maths results.
• Automation markers — the handful of property names a driver leaves behind on a page, and the browser's own automation flag. Their presence, never anything they contain.
• Network vantage — the address this request arrived from, optionally the address a second host sees, and optionally the TCP/IP characteristics of your own connection.
• Page context — the path you are on including its query string, the document title, and the page you came from.
• The shape of what you did on the page, where the customer leaves that on. It has its own section below.
• Nothing else. The script does not read page text, input values, cookies belonging to other origins, local storage, the clipboard, the camera, the microphone, your location, or anything at all about your other tabs.

4. What a stored visit contains

One record is written per collected page view. It holds:

The readings are kept as readings. A detection model changes, and a record that stored only the conclusion could never be re-examined under the new one — so the verdict is kept beside the measurements rather than instead of them, which is also what makes it possible to establish later that a visitor was judged wrongly.

• A record id, the time it was collected, and which customer site it came from.
• The visitor id described in the next section.
• Every signal reading listed above, as it arrived.
• Hashes our server derives from those readings, to group visits made by the same machine.
• The verdict — allow, challenge or block — the score behind it, and each reason that contributed.
• The IP address in full, and what is known about it: network operator, autonomous system, city, country, timezone.
• The request headers the verdict actually read, as they arrived.
• The page path, its query string, the document title and the referrer.
• The user agent, and the browser, operating system and device type parsed from it.
• The behaviour window, if there was one.
• A written assessment, only where a staff member asked for one on that specific record.

5. Hashes: what is kept, and what it is

Yes, hashes are stored, and they are the point of the product rather than an implementation detail. A service that could not recognise the same browser profile twice could not tell a returning customer from a hundred fresh identities made in an hour.

The main one is the visitor id: a SHA-256 over the components of your browser that survive a restart — rendering hashes, GPU strings and driver limits, platform, timezone, languages, screen geometry, core count, declared memory, font list — truncated to 32 hexadecimal characters. It is computed on our server from what the browser reported, never sent by the browser, because an identifier the client chooses is a cookie with extra steps. Your IP address is deliberately not one of the inputs: moving from wifi to mobile data does not make you a different visitor, and everyone behind one office router is not the same one.

These are pseudonymous identifiers. They are personal data under the GDPR and we treat them as such. They cannot be turned back into a name, a face, an address or a document; they can, by design, recognise the same browser profile again.

• Visitor id — one per browser profile, stable across sessions and across a change of address.
• Surface hashes — canvas, audio, maths and WebGL parameters, computed in your browser before they are sent.
• Hardware hashes — derived on our server from the stored readings, used to group visits and, where an operator decides, to refuse one machine.
• No reverse table. We hold nothing that maps a hash back to the bitmap or the audio buffer it came from, because no bitmap and no buffer was ever sent to us.

6. IP addresses

Yes. The address is stored in full, beside the visit, for the visit's retention period. It is not hashed and not truncated to a network: the question being asked is whether one specific address is a datacentre egress, a residential proxy exit or a Tor relay, and a truncated network cannot answer it.

It is used to classify the connection — proxy, VPN, Tor, hosting, known abuse source — to place it as far as a city, and to compare it with what the browser claims about itself. A browser reporting a Vietnamese timezone over a German datacentre address is exactly the kind of disagreement this engine exists to notice.

Classification is answered first from licensed databases held on our own server, so in the ordinary case your address is sent nowhere at all. Where those cannot answer, an address alone — never a visitor id, never a page, never a reading — may be sent to one of the IP reputation providers named below, under a daily limit.

A record also says whether the address was measured at all. Where a request reaches us through a relay and the address belongs to that relay rather than to a visitor, the record is marked as such instead of silently presenting our own address as yours. The optional connection-characteristics probe exists for the same reason: it is served from a host deliberately kept off our edge network, so that what is measured is your own connection rather than a proxy of ours, and it reads the headers of the packet that opened that connection and nothing from inside it.

7. Behaviour: shape, never content

Where the customer leaves it on, the SDK keeps a rolling window of what happened on the page — pointer movement, clicks, scrolling, focus changes, whether the tab was visible, how long the history is — in memory, and attaches it to the request that was already going out. It is capped at 256 events. One attribute on the script tag turns it off.

It records shape and never content. The following are excluded from every path, including the click that would be the easiest place to leak them:

Nothing scores this window today. The verdict, the score and the signed response we return are identical with and without it. It is stored as it was observed so that it can be scored later, after a model has been calibrated against real traffic — because an uncalibrated model in front of a payment page refuses real customers.

• Key codes and typed text. A keystroke is recorded as the fact that a key was pressed, and nothing about which one.
• The value of any field.
• The text of any element, including the one that was clicked.
• Link targets, and the query string of any destination. Where a departure is recorded, the destination is the host and path only.
• Anything inside an editable region of a page.
• Anything in a password, email or telephone field, or in a field whose autocomplete attribute asks for a card number, a current or new password, or a one-time code — read off the element itself rather than off the markup, so that renaming an input does not expose it.
• The clipboard, in either direction.

8. Cookies and local storage

On hideguard.io: a session cookie once you sign in to the dashboard, valid for seven days and deleted when you sign out, and your language choice in local storage. Both are strictly necessary for what they do. There are no advertising cookies, no analytics cookies and no third-party trackers on any page of this site.

The SDK sets no cookie of ours on a visitor. Its request to the collector is sent with credentials omitted, so no cookie of this domain travels with it and none can be set by it. The collector identifies a browser profile by what it renders, which is why it needs none.

The SDK can set one first-party cookie on the customer's own domain: one value, the visitor id, for one year, same-site lax. It exists so the customer's own server can ask us about a request before it serves anything, which is the only way a decision can reach a client that never runs JavaScript. It is the customer's cookie on the customer's domain, it belongs in their cookie notice, and they can switch it off with one attribute.

9. How long anything is kept

Everything expires on its own. Each record below is written with its own expiry and the database removes it when it passes; nothing is kept "until further notice", and a later visit does not extend an earlier one.

The periods in this table are read from the code that sweeps the records rather than written here by hand, and a test fails the build if the two ever disagree.

Deletion on request is separate from all of this and does not wait for a clock — see Your rights.

10. History included with a plan

A visit's own period is the shorter of what the deployment is configured for — 90 days unless the operator sets otherwise — and what the customer's plan includes. The shorter of the two always wins, so a plan can only shorten retention, never extend it.

A customer moving to a larger plan does not have history extended on the records they already hold; those keep the expiry they were written with and disappear on it.

11. Who else sees any of this

We sell nothing, we rent nothing, and no record here is used for advertising, for marketing profiles, or for training a general-purpose model. The parties below receive something because the service cannot be delivered otherwise:

A written assessment, when a staff member asks for one on a single record, sends a brief to the model provider the operator configured: the engine's readings, the reasons, where the address is placed, the address itself, the visitor id and the paths that visitor saw. Not the raw evidence — no hashes, no font lists. Nothing it answers feeds a score, a rule, or the decision at the payment page.

We also disclose a record where the law requires it of us, and we will tell the customer whose record it is unless we are forbidden from doing so.

• Cloudflare — DNS, TLS and edge for hideguard.io. Deliberately not in front of the connection-characteristics host, because an edge network there would measure itself.
• Licensed IP databases from ipapi.is, held on our own server. The copy is refreshed on a schedule; no visitor's address goes out to fetch it.
• IP reputation providers — IPQualityScore, Scamalytics, the ipapi.is API, and a checker we run ourselves — consulted only when the local databases cannot answer. They receive an address and nothing else.
• Fingerprint (fpjs.io) — on the public demo pages only, and reached through our own server. No customer's visitor is sent to it.
• Google — public STUN servers for the WebRTC leak test, reCAPTCHA on the captcha-score tool, and a reachability check behind the voice test. Public demo pages only.
• A model provider chosen by the operator — Anthropic, Google, or an OpenAI-compatible host — for a written assessment, as described above, and only when a person presses the button.
• An email provider, for account, alert and digest email to customers. Visitors are never emailed.
• The customer's own systems — their webhook endpoint and their backend, which receive their own visits. That is a customer receiving their own data, not a disclosure to a third party.

12. The public pages on hideguard.io

The checks on our own pages run in your browser and the result is drawn on your screen. A demo run is not written into the visits database — that path requires a customer's site key — and nothing you do on these pages places you in a profile a customer can read.

These pages do make requests, because otherwise there is nothing to measure: to our own endpoints for your address and round-trip time, to the third parties named above, to public STUN servers for the WebRTC test, and to our own map-tile proxy, so that no map host learns which part of the world you are looking at. The developer-tools and audio timing checks visible on the demo are measurements of this page in this browser and are not retained.

Our edge and our web server keep ordinary access logs — address, time, path, user agent, response — for operations, debugging and abuse handling, for a short operational period. They are not joined to any visitor id and are not used to build a profile.

13. Why we are allowed to do this

Where the GDPR or a comparable law applies, we rely on:

• Performance of a contract — running the collector for the customer who asked us to, and running an account for the person who opened it.
• Legitimate interests — preventing payment fraud and account takeover on the sites we guard. That interest is also the visitor's: the cost of card testing is carried by the people whose cards and whose shops are used. We balance it by storing shape rather than content, hashes rather than artefacts, and by deleting on a clock.
• Legitimate interests — keeping our own service available, and detecting abuse of it.
• Consent, where a customer's own legal advice requires it before the script runs. The SDK is one script that does nothing until a page loads it, which is what makes gating it on consent possible.

14. Your rights

Where the law gives you these rights, you have them here: access to your records, correction, erasure, restriction of processing, objection, portability, and a complaint to your supervisory authority.

If a HideGuard record exists about you, it exists because you visited a website that installed our SDK, and the operator of that website is the controller of it. Ask them first: they can find and delete your records from their dashboard, and we act on their instruction. If you do not know which site it was, write to us with what you do know and we will try to identify the records ourselves.

We cannot always identify you, and this is a limit rather than a refusal. A visitor id is derived from what a browser renders, so finding your records needs a measurement from the same browser profile, or the address and the rough time of the visit. We will not accept an identity document as proof, because holding one would be worse for you than the records you are asking about.

On automated decisions: the verdict we return is advice to the website, not a decision we take about you. The website decides what to do with it, and our terms require them not to refuse a person on the strength of it alone where that refusal would have a legal or similarly significant effect, without a human being able to look at it.

• Access — a copy of the records held about the browser profile you can demonstrate.
• Erasure — deletion of those records, carried out rather than scheduled.
• Objection — to processing based on our legitimate interests.
• Restriction — processing paused while a dispute about accuracy is resolved.
• Portability — the records in a machine-readable form.
• Complaint — to your own supervisory authority, whether or not you raised it with us first.

15. How any of it is protected

The measures that matter most to what is described above:

• Everything travels over TLS, and the collector refuses a request from an origin a customer has not registered.
• A customer's secret is kept only as a SHA-256 digest. It is shown once, at creation, and no route returns it afterwards.
• Signing keys are sealed with a separate master key before they are written, so a copy of the database cannot sign anything.
• Staff access is by named account and role; no shared token opens the operator console, and every staff write is recorded in an audit trail with the account that made it.
• Our answer to a customer's page is signed with Ed25519, so their backend can tell our verdict from one a visitor wrote themselves.

16. Where it is stored

Records are stored in a database on servers we operate ourselves rather than in a managed cloud database, and the dashboard reads them from there. The IP databases sit on the same machine, which is why an ordinary classification involves no outbound request at all.

Where a provider named in this policy is outside your own country, that transfer rests on the provider's own standard contractual clauses or an equivalent mechanism. We will name the hosting region to any customer or visitor who asks.

17. Children

This service is not for children. It is sold for payment and account protection on sites transacting with adults, our terms forbid deploying it on a service directed at children, and we do not knowingly hold records about a child. If you believe we hold one, write to us and it will be deleted.

18. Changes to this policy

The date at the top of this page moves when the words move. A change that widens what is collected, lengthens how long it is kept, or adds a party that receives it is announced to customers before it takes effect, and is never applied retroactively to records already written under the previous version.

19. Contact

Write to [email protected] about anything in this policy, including a request to exercise any of the rights above. We answer within 30 days, and sooner where the law requires it.

If you are a visitor to a customer's site and your request is about their records, naming the site in your message lets us route it to the controller instead of asking you twice.