Privacy Policy

This policy explains how [Company name] ("we") handles personal data in Zeno, a device identification service for fraud prevention, at zeno.id. It covers three groups of people: our customers' users, whose browsers our customers identify with Zeno; visitors of our own website; and people with a dashboard account.

Our role

When a customer runs the Zeno agent on their website, the customer decides why and how their users are identified, and we process that data on their behalf as a processor. Their privacy policy is the one that applies, and requests about that data are best sent to them; we help them answer it.

For our own website, the live demo on it and dashboard accounts, we decide what is collected and are the controller.

What we collect

When a customer identifies a browser, the agent sends:

Browser and device characteristics, such as the browser and operating system, the user agent, screen size, languages and time zone, graphics and audio processing results, installed fonts and the browser's storage and privacy settings. Large values are reduced to a hash in the browser before they're sent.
The IP address. From it, an IP lookup adds a location: country, region, city, postal code, latitude and longitude, with a rating of how accurate they are. They describe where the network is, not where the person is, and the browser is never asked for its location. The lookup also adds network details: the internet provider and its network, and whether the address is a VPN, proxy, Tor exit, data center or known for abuse.
The page address and referrer, cut to the site and path in the browser (the query string and fragment, which can hold tokens or email addresses, are never sent), or only the site or nothing at all when the customer chooses so.
Whether the browser completed a WebSocket handshake with our service, kept with the IP address for an hour.
Two fingerprints of the connection's TLS handshake (JA4 and JA3: the encryption settings the browser offers when it connects), which our content delivery network reads from the connection, not from the browser. They're kept on the identification, and the JA4 is counted per browser family without anything about the customer or the person, to tell real browsers from scripts.
An identifier of the user in the customer's own system, if the customer passes one (an "external ID"), what the visitor was doing as the customer names it (an "action", like a login or a checkout), and metadata the customer attaches to the event, like an order number. The metadata is kept like the event and is never used to detect anything.

From this we compute a visitor ID for the device, a set of signals (like a VPN, automation or a private window) and a risk score. We keep the browser and device characteristics to recognise the device next time, but never pass them on. The customer gets, through the dashboard, the API, webhooks and encrypted "sealed results": the visitor ID, the IP address with its location (coordinates and postal code included) and network details, the page address and referrer as kept, the external ID, action and metadata, the signals, the score, the TLS fingerprint and a summary of the browser, VPN and tampering checks.

The agent also stores the visitor ID in the browser, and, if the customer turns on its cache, the last identification for each external ID. The Cookie Policy lists every entry.

On our website, the live demo identifies your browser the same way, in a separate demo project, to show you what Zeno sees, once you start it; until then it collects nothing. Our server reads the country your IP address is in (from our CDN) with each page, to show the site in that country's language on your first visit and to suggest your country when you sign up; nothing about it is stored on our side, and your browser keeps only the language, in a cookie.

For dashboard accounts, we keep your email address, your name, company and country, a salted hash of your password, when you accepted our terms and verified your email, your sessions, when you last logged in, and the browser and IP address of each login, so we can protect the account. From those logins we keep the browsers you logged in from (a hash of a random key the browser keeps, their visitor ID in our own logins project, browser and system name, country and city, first and last use) to recognise a new one, and a login history (logins, wrong passwords and codes, new or forgotten browsers, changes to your password and two-factor authentication, each with its IP address, browser and place). If you turn on two-factor authentication, we keep its secret, the time step of the last code you used, and your recovery codes as hashes only; a login waiting for its code is kept for 10 minutes. Signing up, asking for a password reset or a new verification link identifies your browser the same way, to keep automated sign ups out. The links we email you (to verify your address or reset your password) are kept only as a hash until they're used or expire. A project's audit log records what its teammates change, with their IP address, and the email addresses of the people they invite. We also record which dashboard pages you open (the page's name, never its address) and clicks on a fixed set of controls, under fixed names, to see how the dashboard is used.

Support tickets, the only way to reach our support: we keep what you and our support staff write in a ticket, its subject, category and status, the organization and project it's about, who wrote each message and when, and when you last opened it. Our staff may add internal notes to a ticket, which you don't see. Our product analytics count tickets by category and priority, never what they say. Whether your organization pays, worked out from its usage, sets a ticket's priority.

When a teammate invites you, we keep your email address with the invite for a week and send you one email with the link. The invite names the teammate by their name and company, never their email address.

Emails we send you are about your account only: the verification link when you sign up, a welcome once you've verified, password reset links you ask for, notices when your password changes, a sign-in code when you log in with your password from a new browser, a notice when someone logs in to your account from a new browser without one, notices when two-factor authentication is turned on or off, and a notice when our support replies to a ticket you opened (that there's a reply and a link, never its text). If someone signs up with an address that already has an account, its owner gets an email saying so; the sign up page answers the same either way, so it never tells anyone whether an address has an account.

We don't collect names, payment card details, the browser's own location (GPS or the location permission), or the content of pages.

Why we use it

To identify returning devices and detect fraud, bots and abuse for our customers.
To protect dashboard accounts, for example by recognising logins from a new or shared browser.
To run, secure, measure and improve the service, and to bill customers for their usage.
To meet legal obligations.

We don't sell personal data, use it for advertising or build profiles across unrelated websites. A visitor ID is specific to one customer's project, so the same browser gets unrelated IDs with different customers.

How long we keep it

Identification events: until the customer deletes them, which is the default, or for the 30 days, 1, 3 or 5 years the customer picks instead. An expired event is removed within a day or two. A new retention applies to events identified from then on; stored events keep the expiry they got.
Device records and the links between a customer's users and their devices and IP addresses: as long as the events, counted from the device's last visit or the link's last event.
Copies of events sent to a customer's webhook, with the answers we got: 30 days.
The live demo on our website: its events 7 days, its device records 7 days after their last visit. Nothing else is made from them: no search copy, usage counts or links.
IP lookups: cached for 90 days, by IP address alone and shared by every customer, so a lookup isn't repeated. Erasing a visitor or an external ID doesn't remove the cached lookup of its IP address.
Request identifiers used to detect replayed requests: 7 days.
Emailed links: 24 hours for a verification, an hour for a password reset, and gone once used. An account whose email nobody verifies: 7 days.
Support tickets: as long as the organization they belong to. Deleting your account deletes the tickets you opened outside any organization; your messages in an organization's tickets stay with the organization and are no longer shown with your name.
Dashboard sessions: 30 days after they were last used; account data until the account is deleted, which you can do yourself from your profile. Deleting an account also erases its login records, browsers, login history and two-factor secret, and its dashboard usage records stay only as counts that no longer name the account.
Login history: 90 days. Your known browsers: until you forget them or delete your account. Two-factor secrets and recovery codes: until you turn two-factor off or delete your account; a two-factor setup you didn't finish, 15 minutes.
Invites: a week.
Audit logs and dashboard usage records: 2 years.
Our services' logs: 7 days.
Records of failed background jobs and error messages, which can hold the data a job was handling: until we remove them after dealing with the problem, with no fixed limit yet. Erasing a visitor or an external ID doesn't reach them.
Backups: the databases keep point-in-time backups for 35 days, so erased data can remain in them for up to 35 days.
A deleted project: its keys and webhook at once, and 90 days later its events, device records, links, webhook deliveries and audit log.
Usage records: each identification's request identifier, time, API key, signals and risk score, without the visitor's identifier, external ID, IP address or device data, for 32 days at most, also after its events are erased or the project is deleted. After that only hourly totals per project and API key are kept (how many identifications, capped requests and signals), without personal data, also after a project is deleted.

Amazon Web Services, which hosts the service in the EU (Ireland) and sends our emails. Requests reach the service through Amazon CloudFront, whose edge locations around the world, the one nearest to the visitor, pass them on encrypted.
ClickHouse, which stores a searchable copy of each identification event so customers can search them and see reports: the visitor ID, IP address, country, city, network owner, user agent, the site, the external ID and action, the signals and the score, without the browser characteristics. It also stores the audit logs and what dashboard accounts do there (logging in, creating or deleting projects and keys, changing settings, pages opened and marked clicks), which we use to understand how the dashboard is used. It runs on Amazon Web Services in the EU (Ireland).
ipapi.is, in Germany, which tells us the location and network of an IP address. It receives the IP address only.
The customer whose website identified the browser, through their dashboard, API and webhooks, without the browser characteristics.
Authorities, when the law requires it.

The sub-processor list names each provider, where it processes data and on what basis, and says how we announce changes.

Your choices

Customers can delete a user's data or a device at any time through the API, and must honour such requests from their users. You can ask us to access, correct or delete data we control, or object to how we use it, by writing to [privacy contact email]. If you're in the European Economic Area, the United Kingdom or Switzerland, the Europe Privacy Policy Addendum adds to this policy.

Security

Data is encrypted in transit and at rest, and secret API keys and passwords are stored only as hashes. Our support staff can read a project's events, usage and keys only while the project allows it: for 12 hours at a time, granted from the project's settings or by accepting a request, and every page they open is recorded in the project's audit log. The Security page describes the measures in more detail.

If a personal data breach affects a customer's data, we tell that customer without undue delay, and at most 48 hours after we become aware of it, with what we know: what happened, which data and how many people are affected, what we've done and what they should do. We follow up as we learn more. Where we are the controller, we notify the supervisory authority and the people affected as the law requires.

Changes

We'll update the date above when this policy changes, and tell customers about significant changes in advance.

Contact

[Company name], [Registered address]. Email: [privacy contact email].