Create free account Dashboard
Legal Documentation

Privacy & Data
Processing Policy

Last Updated: November 6, 2026

Sentinel Edge Networks LTD (company number 17150600) is responsible for this notice. We are the controller for account, website, support, business-contact, service-security, abuse-prevention, and pseudonymous service-wide device-sighting data where we determine why and how that data is used. When a customer sends end-user data to the Maskbreak API for its own fraud decisions, the customer is normally the controller and Maskbreak acts as its processor under the customer’s instructions. The customer remains responsible for its decision rules and notices to its users.

This notice explains what personal data we receive, where it comes from, why we use it, how long we keep it, who receives it, and the choices available to individuals. It applies to maskbreak.com, Maskbreak accounts, support interactions, and the Maskbreak API and SDK.

1. Data We Collect on Behalf of Customers

When an End-User interacts with a Customer's platform protected by Maskbreak’s script (SDK) or API, we act as a Data Processor. We collect specific technical information required to determine whether a request originates from a legitimate human user, an automated bot, or a malicious actor. This data includes:

Customers may optionally send their own pseudonymous accountId so they can detect one device being used across multiple accounts. Maskbreak stores a keyed hash of that value to link the customer’s own accounts and, since 18 October 2026, an encrypted copy so that customer’s console can show which of its accounts are linked (Section 3). Customers are instructed not to use a name, email address, or other directly identifying value as an accountId. Customers may also optionally submit an end-user email address for a disposable-domain (“burner email”) check: the address is compared in memory against a public list of disposable-email providers and immediately discarded — only the resulting true/false flag is stored with the evaluation record, never the address itself. The fraud-detection API is not designed to receive passwords, payment-card numbers, names, or postal addresses.

End-user telemetry comes from the end-user’s browser or network request, from the customer integrating Maskbreak, and from our network- and device-intelligence providers. The customer decides whether its end users are contractually or legally required to provide this data and must explain any consequences of not providing it.

The script tag’s site report (optional, since 17 October 2026): when a customer puts its site ID in the script tag (data-site, a public identifier of the customer’s account, not a secret), each page view that loads the script sends one request to maskbreak.com (or to the customer’s own script address, Section 3) carrying only that ID; the end-user’s browser adds the page’s origin (scheme, host name and port), as it does for any request to another site. The request carries no cookies, no page path or query and nothing about the end-user, and the script stores nothing on the device for it. We keep no record of the visit: we store only, per customer account, the website origins the script was seen on and when, and, for a report whose site ID matches no account, the page’s origin with the first and last time and the number of such reports, for 30 days (Section 3). Like any request, it reaches us from the end-user’s network address; our server uses that address only to count requests against a short in-memory rate limit and does not store it, and our hosting sees it like any request and keeps it only in its logs (Section 3). A tag without data-site sends no such request.

What the stored evaluation record contains: each API evaluation is stored for the customer’s own dashboard as a row holding the IP address (one-way hashed after 7 days — see retention below), a two-letter country code, boolean signal flags (VPN, proxy, datacenter, anonymous network, bot, tampering, antidetect, incognito, burner-email flag), the returned risk score and decision, the reason codes returned with them (signal names such as vpn_detected — never an address, email or time-zone value) and, where a customer rule or exception changed the decision, the engine’s own decision, the network service classification label where one was identified (e.g. the VPN provider name), a coarse browser and operating-system label (e.g. “Chrome 150”, “Windows 11” — never a full User-Agent string), a pseudonymous device key derived as a one-way SHA-256 hash of the device-intelligence identifier — the raw identifier itself is never stored — and, where the customer sent an accountId, a keyed hash of it, removed 90 days after the evaluation. These records are visible only to the customer whose API key ran the evaluation and are never linked across customers. Address lookups (GET /v1/lookup/{ip} and the MCP lookup_ip tool) are stored for the customer’s dashboard the same way: the looked-up IP address (one-way hashed after 7 days), its country code, the flags, reason codes, score and decision the lookup returned, and the network service label where one was identified. A customer may also send the end user’s browser time zone for the time-zone mismatch check; it is compared in memory and not stored, only the resulting reason code is.

Email and phone check (in the console, since 18 October 2026): when an account holder types one email address or one phone number into the console’s email and phone check, we process that value on the customer’s behalf: our server sends it to our email- and phone-intelligence provider (Section 5) and shows the account holder a summary of the answer, such as whether the address accepts mail, its domain’s details, how long it has been seen online and on how many sites, in how many known data breaches it appears, a phone number’s validity, line type and carrier, how many businesses checked it before or reported it as fraud, and the provider’s risk score. The summary leaves out what the provider returns about the person behind the value (names, postal addresses, the kinds of sites an account was found on, breach names). We store neither the value nor the answer (Section 3). The customer decides whether it may check a person’s email address or phone number this way.

Login protection (since 23 October 2026): login protection is on for every account. It processes nothing until the customer’s server sends us a login attempt or an account event with the customer’s own account ID, which is that customer’s instruction to use it, and a customer can turn it off in its Settings. When its server sends us a login attempt (a visitor check marked as a login, with the customer’s own account ID), we send the details of that attempt to our login-protection provider, Sift (Section 5), and return Sift’s account-takeover score with our answer. For each such login Sift receives: keyed one-way hashes of the customer’s account ID, of its session ID (or of our device key when no session ID is sent) and of our device key, made with a key that differs for every Maskbreak customer, so Sift never sees the customer’s own identifiers and cannot match one customer’s users with another’s; whether the password was right; the end user’s IP address and browser user-agent string; the end user’s email address when the customer sends one; the customer’s website domain; and our own result for the visit (the decision and risk score; the VPN, proxy, Apple privacy-relay, Tor, cloud-server and anonymous-network flags; when the browser check ran, the fake-browser, tampered-browser, automation, emulator, virtual-machine and private-browsing flags; whether the email address is a throwaway one; the VPN service’s name and the IP address’s country). One Sift account holds the login attempts of every customer that uses login protection, so Sift’s scores for one customer’s logins draw on what it has learned from the logins of all of them. Since the same day the customer’s server can also report, the same way, a signup, a password change, a verification, a logout or an account-detail change for an account; each goes to Sift as that event, with the same data as a login and no score in return, so that Sift knows what is normal for the account. Nothing reaches Sift from a customer whose server sends no login or account event, or that has turned login protection off, and logins or events sent with a test key or test tokens, or from the console, never do. What we keep of Sift’s answer is in Section 3.

Email and phone intelligence (since 23 October 2026): email and phone intelligence is on for accounts created on or after 23 October 2026 and off for accounts created before, which can turn it on in their Settings; any account can turn it off there. Nothing is sent until an email address or a phone number arrives with a visitor check. When it is on and the customer’s server sends an email address or a phone number with a visitor check, our server sends that value to our email- and phone-intelligence provider (Section 5; the same provider as the console’s check above) and returns the provider’s risk score for it with our answer, with the names of the provider’s reasons and a few facts (whether the address accepts mail, when its domain was registered, on how many sites it was seen, in how many known data breaches it appears; a number’s validity, line type and carrier). The provider receives the address or the number and nothing else about the visitor. We store neither the address nor the number nor the provider’s full answer: the stored evaluation record keeps the scores and the reason names (Section 3). Each address or number scored counts toward the customer’s plan’s daily number of email and phone checks. Nothing reaches the provider from a customer that has it off, and checks sent with a test key or test tokens, or from the console’s own checks, never do. The customer decides whether it may check its visitors’ email addresses and phone numbers this way, and turns it off if not.

1.1 Data We Collect From Our Own Customers

When you create a Maskbreak account, we act as a Data Controller for your account data: your email address, a bcrypt hash of your password (never the password itself), the IP address used at signup (kept with the account) and at each sign-in (kept with that session, Section 3) for abuse prevention, API usage counts, any organization membership you configure (team invitations you send hold the invitee’s email address: an invitation is valid for 14 days, expired or revoked invitations are deleted 30 days after they were sent, and accepted invitations are kept as the record of how the member joined until the inviting account is deleted), any alert-webhook URL you save (used only to deliver your threat alerts), and — if you add a passkey — the passkey's public key, credential identifier, and a label naming the browser and system you added it from (for example “Safari · macOS”). A passkey's private key and your biometrics never leave your device; we store only the public half needed to verify sign-ins, and you can remove any passkey from the Security page at any time (removal is immediate; since 6 November 2026 it asks for your password, or a recent Google or GitHub sign-in). A password reset does not remove passkeys: since 6 November 2026 the email confirming the reset lists each one by its label and the date it was added (never its credential identifier), so you can remove any you do not recognise. If you sign in with Google or GitHub, we store the provider's stable account identifier to link future sign-ins. We also store a display name if you set one, any IP addresses you allow to use your API key (the optional API-key allowlist), and your website’s address once your first complete check confirms it (Section 3). When you sign up or change your account’s email address, we read only the part after the @ and refuse addresses at known temporary-inbox services (a public list and our own short list of such services) and at email-alias (forwarding) services; the refusal is written to our application log with the domain only, never the full address (Section 3). Existing accounts are not affected. If you answer the optional question about how you heard of Maskbreak (since 22 October 2026 on the signup page while your code is on its way, otherwise in the dashboard, which asks once in the first 30 days of an account), we store your answer, one choice from a fixed list with no free text, and the time you gave it; choosing Skip in the dashboard is stored as well so that we do not ask again. It is kept with the account and deleted with it. If you answer the dashboard’s setup question “What do you want to do with Maskbreak?” (since 8 October 2026), we store your answer, one choice from a fixed list with no free text, so that the dashboard shows the setup steps for it and, since 10 October 2026, the setup emails described below match it; we also read the answers, per account in our admin console and in total, to see which setup paths new accounts need. You can change it at any time, and it is deleted with the account. If you remove a linked Google or GitHub sign-in on the Security page, we keep a hash of that identifier with your account so the removed identity cannot link itself again; it is deleted with the account. If you locked the Growth founding price while it was offered (an early offer, not today’s Growth plan; it was withdrawn on 16 August 2026 and nobody was charged), we keep the record of which plan you chose and when, because it is the reason your account carries its own hourly request limit in place of the standard free allowance. We also keep minimal service-notice bookkeeping (a count of rate-limit rejections, the number of visitor checks and IP lookups counted against your plan’s allowance in the current calendar month, and the time of the last limit notice we emailed you, including the notices at about 80% and 100% of a monthly allowance and, since 27 October 2026, one reminder when your calls are still being refused three days or more after it was used up) so we can alert you when your API quota is nearly exhausted without repeating ourselves. For the same reason we record which setup, onboarding, summary, first-threat and allowance emails, and which notices about changes to our service, we have sent you and when (and, since 27 October 2026, that a first-threat note was not sent because an earlier visitor check had already been flagged, or, since 28 October 2026, that it is still to be sent because our own email limits held it back), so that none is sent twice; that record is deleted with the account. For sign-in security alerts we store a one-way hash of the browser identifier (user-agent string) of each browser you have signed in from — never the raw string — so we can email you when your account is accessed from a browser we have not seen before; security notification emails (password changes, key rotation, passkey changes, new sign-ins, a correct password followed by wrong two-factor codes, security changes a Maskbreak operator makes to your account — such as a key rotation, removing two-factor authentication, signing you out everywhere or lifting a suspension — and, for organisation owners, invitations, joins and removals made by another organisation admin) are transactional and cannot be disabled. If you configure a threat-alert webhook we also generate and store a signing secret so your endpoint can verify our deliveries, and we keep a log of recent delivery attempts — the event type, HTTP outcome, and any error string, never the payload and never end-user IP addresses — so you can debug your endpoint from the dashboard; delivery-log entries are deleted automatically after 30 days, or with your account. Evaluation records are retained for the life of your account (raw IP addresses are one-way hashed after 7 days as described below) and can be exported as CSV from the dashboard at any time; they are deleted with your account. Transactional email (OTP codes, password resets) is delivered through our email sub-processor. While a signup or account email change is pending verification, we hold the submitted address, a bcrypt hash of the chosen password and the IP address of the signup request (signup only), and a keyed one-way hash of the verification code — never the code itself. The code is valid for 10 minutes; the record is deleted when the verification completes or, if it does not, by a cleanup that runs every six hours after the code expires. A password-reset request is held the same way: your email address with a keyed hash of the emailed code for 10 minutes, removed when the reset completes or by the same cleanup. If you set up authenticator-based two-factor authentication, we store the shared TOTP secret needed to verify your codes (while you replace your authenticator, the new secret is held beside the current one until you confirm a code from it); both are removed when two-factor authentication is disabled or the account is deleted. We also store one-way hashes of your ten single-use recovery codes (the recovery codes themselves are shown once and never stored). If you expressly subscribe to our newsletter, we record your email address, request IP, source and the time of the request for subscription and abuse-prevention records. Since 10 October 2026 a subscription has to be confirmed (double opt-in): we send one email to the address with a confirmation link that works once, for 7 days, and keep a keyed one-way hash of the link’s token, never the token itself. An inbox gets at most one such email a day, however often its address is entered, and the newsletter sends it nothing else until the link is used. Confirming records the time of the confirmation and starts the newsletter with a welcome email; only confirmed addresses receive the newsletter. A request that is not confirmed is deleted, with its address, request IP and token hash, 7 days after the last confirmation email we sent for it, by a cleanup that runs every six hours. Subscriptions made through the earlier form, which started the newsletter at once (until double opt-in began on 10 October 2026), count as confirmed and are not asked again. A confirmed subscription is kept until you unsubscribe or request deletion; deleting your Maskbreak account also removes a subscription under the same address. Bulk IP lookups no longer request or store an email address and do not subscribe anyone. Addresses previously captured through bulk lookup are excluded from future newsletter batches unless the person separately subscribes and confirms; those existing records remain available for access or deletion requests. You can unsubscribe using the link in any newsletter. Since 23 September 2026 every new account receives a few setup emails in its first days, about getting the account working: one about an hour after signup if no API call has arrived yet and, since 6 November 2026 only once your key has made a call (a counted call, a test call or a check sent with your test key), one on day three and, since 8 October 2026, one on day seven if your site has not yet sent a complete visitor check. Since 10 October 2026 they follow your setup answer and your latest check: if you chose to check IP addresses or to look around, the day-three email is about that (for IP addresses, with how many lookups your key has made) and no day-seven email follows; the day-three and day-seven emails start with what your latest check lacked, when it is something you can fix; and when a check from your account does not finish the setup before any complete one has (for example it arrived without its browser part, or used a test key), we send at most one note, between 45 minutes and a day later, saying what was missing and the likely fix. Since 27 October 2026 they also include two notes about an account that works: when your site has already sent a complete visitor check, the day-three email (three to five days after signup) says your integration works and what to add next; and shortly after the first visitor Maskbreak flags on your own traffic, one note says so (test-key and console checks never send it, and it is not sent at all if an earlier visitor check of yours had already been flagged; address lookups do not count). Each contains a one-click unsubscribe link that stops them, as do the Setup emails switch under Email preferences in Settings and the unsubscribe link in any onboarding or monthly-summary email. Accounts created before this change do not receive them, except that an older account that still receives our product emails (see below) can get the one-time note about an incomplete check and the first-threat note. They use the email address you signed up with, a stored on/off preference, your setup answer, whether your key has made a call, the number of address lookups your key has made and the latest integration result described in Section 3; no new personal data is collected for them. Our founder may also write to you in person about a setup that seems stuck, and, since 21 October 2026, about an older account whose checks have kept arriving incomplete for a day or more; we do not write once you have turned the setup emails off. Other product-update and onboarding-tip emails are sent only if you turn on Tips and product news under Email preferences in Settings; no account created since 21 July 2026 is enrolled in those automatically, and every such email contains an unsubscribe link. Accounts created before 21 July 2026 keep the email setting they had then, so they may receive the monthly usage summary and a one-time first-threat notice until they switch it off in Settings or use the unsubscribe link. If you press “Email me these steps” in the dashboard, we send the setup steps once to your own account address; that email never contains your API key. Transactional and security emails are unaffected by these preferences. Account data is retained until you delete your account — deletion via the Security page removes your data from live systems immediately (GDPR Art. 17), except the records Section 3 says we keep after deletion: billing records, and our operations and admin logs, which name the account by its number only. Encrypted daily backups are stored in the EU; the nightly job that creates them runs on GitHub Actions (Sections 3 and 5). Our existing 60-day deletion commitment and the current verification work are explained in Section 3. Copies that providers keep under their own retention (for example email delivery logs, error reports, analytics and chat transcripts) are not removed by account deletion; ask us if you want them deleted.

Paid plans and billing (since 30 September 2026): if you subscribe to a paid plan, payments, invoices and receipts are handled by our payment provider, Stripe (Section 5). You enter your card or other payment details on checkout and billing-portal pages hosted by Stripe on its own website; they are sent to Stripe and never reach our servers, and no Stripe script runs on maskbreak.com. With your account we store the identifiers Stripe gives us for you as a customer and for your subscription, the plan you chose, the subscription’s status (for example active, past due or cancelled) and the end of the current billing period, so that the right allowance applies to your API key, and the time you last opened a checkout page, so that a payment we were not told about is still found within three days. Stripe holds the payment and billing details you give it (such as the card or payment method, billing name and address and any VAT number) and the receipts and invoices it sends you as the merchant of record (shown as Link); we can see these, and the payment history, in our Stripe account. We do not receive full card numbers. Billing records are kept as described in Section 3.

1.2 Contact, programme applications, and support

If you contact us or apply for public-interest access (or wrote in the website chat while it ran, until 30 September 2026), we process the contact details, organisation, message, and other information you choose to provide. Contact and programme forms also supply request IP and network-risk context for abuse prevention. Form submissions are relayed by email to our support mailbox (hosted on Google Workspace), and the sender gets a short receipt that does not repeat the message; they are not stored as a separate application table in the product database. Copies remain in the support mailbox and the relevant delivery provider (for chat conversations, the former chat provider) while needed to handle the request, manage the relationship, or meet legal obligations. Please do not include patient records, passwords, payment-card details, or other sensitive personal information in these forms.

1.3 The live check on our own website

When you open our homepage or the IP-lookup page, the live check runs by itself: the scripts of our network- and device-intelligence providers (Section 5) measure your connection and browser, and our server asks them for the result and shows it to you. On the IP-lookup page the connection is measured since 6 November 2026 by our proxy-detection provider (Section 5) instead, whose encrypted answer our server opens itself, and our server looks your address up in that provider’s IP database. We do not store that result; we keep only the counter behind the Visits line (device sighting counters, Section 3) and short application-log lines (Section 3). Addresses you type into the IP lookup are checked against lists held in memory and are not stored. What these scripts keep in your browser is listed in the Cookie Policy.

1.4 People we contact about Maskbreak

Our founder sometimes writes first to people at companies Maskbreak may help, mostly people who have said in public, for example in a LinkedIn post or comment, that their own product is hit by fake signups or free-trial abuse. For this we keep the person’s name, job title, company, LinkedIn profile address and the time zone of the location on their profile (so that messages arrive during their working hours), a line about the public post or comment that led us to them, and the messages we exchange. Since 22 October 2026 these LinkedIn connection requests and messages go out from the founder’s own LinkedIn account through Needle, a LinkedIn outreach service that holds these details for us (Section 5). The messages are a fixed text with one line about the post that led us to the person; we do not use Needle’s feature that writes messages with AI. Earlier first emails were written by hand from our support mailbox, to work addresses found with Hunter.io, an email-finding service. If you do not want to hear from us, say so in a reply or write to support@maskbreak.com: we stop, and keep only your LinkedIn profile address or email address on a do-not-contact list so that you are not contacted again. Otherwise we delete these details within 12 months of our last message, unless you become a customer (Section 1.1).

2. How We Use the Data

We use security telemetry to protect Maskbreak and our customers’ applications. We use account and contact data to operate accounts, answer requests, and administer the service as described below. Security uses include:

2.1 Lawful bases by purpose

We do not use special-category data to produce risk scores and ask customers not to submit it. We do not use end-user telemetry for advertising.

3. Data retention and pseudonymisation

Website confirmation: since 8 October 2026 we record your website’s address (its origin: scheme, host name and port) and the time from your first complete check, that is the first live check from your own server whose browser event, as our device-intelligence provider reports it to our server, came from a public website, so that your dashboard can confirm the installation and we can help you with it. Local and test addresses (such as localhost or private network addresses) are never recorded, and paths, query strings, raw browser event identifiers and visitor details are not copied into this record. It records receipt of complete evidence, not domain ownership or enforcement of a decision. The first confirmed address is kept until the account is deleted, with backups subject to the policy below; an address typed into the earlier optional website check (17 September to 8 October 2026), with the time that check was started, is kept the same way until a confirmation replaces it.

Script seen on your site: since 17 October 2026 your account has a public site ID, which the dashboard puts in the script tag it gives you (data-site). When a page with that tag loads, the visitor’s browser reports the ID and the page’s origin (scheme, host name and port) to us, and we store, per account, the first origin seen with its time and the latest origin with its time (the latest time is updated at most once every 10 minutes), so that your dashboard can show that the script runs on your site before any server code is in place, and so that we can help you set it up. Local and private addresses (such as localhost or private network addresses) are never recorded, and no visitor data, page path or query is recorded. Anyone who knows a site ID (it is visible in the page source of a site that uses it) can send such a report, so it shows that the script was seen, not who owns a website: it never confirms a website or changes a decision. The site ID and these records are kept until the account is deleted, with backups subject to the policy below. Since 6 November 2026, a report whose site ID matches no account (for example a tag whose data-site was typed by hand or by a coding tool) is kept by the page’s origin only, with the first and last time it arrived and how many arrived, for 30 days; it is shown on the account that origin belongs to by what that account already has with us (its confirmed website, the website its own live checks came from in the last 7 days, or the domain of its sign-in email when no other account uses that domain), like a report carrying the account’s own site ID.

Checking a page from the dashboard (since 20 October 2026): when you use “Check your page” on the dashboard’s setup screen, the address you enter is sent to Cloudflare’s browser service (Browser Run, Section 5), where a browser opens that page once, as a new visitor would, and tells our server what it saw of our script: whether the script tag is there and runs, whether its network and browser parts answered, which of our sources the page’s Content-Security-Policy refused, and whether the page’s forms got their fields. Since 6 November 2026, before the page is opened, our server looks up the addresses of the page’s name, and the browser service those of each name the page then loads from, through Cloudflare’s public DNS resolver (Section 5), which receives only those names; a page, or a part of it, whose name points to a private network address is not opened. We show you the result and keep neither the address nor the result; our log records only your account, the outcome and how long the check took. The browser does not send your form, and no end-user data is involved. Our script on that page runs as it does on any visit, so it may report your site ID as described above.

Your own script address (since 20 October 2026): if you add a subdomain of your site in Settings so that our script loads from it (for example fp.example.com), we store that name with your account, with its state and when it was added and first worked, and give the name to Cloudflare (Section 5), which issues its certificate and serves the script on it. Since 5 November 2026, when you add a name, and while it waits for its TXT record, our server looks up the name’s DNS records and the TXT record _maskbreak. followed by the name through Cloudflare’s public DNS resolver (1.1.1.1), which receives only those names, and we store when that TXT record was found. Requests to that name reach our server as requests to maskbreak.com do, as described above; nothing more about end-users is collected or stored for it. The name is removed from Cloudflare and from our records when you remove it, when its DNS records have not appeared within 7 days or has stopped pointing to us for 14 days, and when the account is deleted. When the account is deleted we ask Cloudflare to remove the name at once; if Cloudflare does not confirm it, a job that runs every hour asks again until it does, so the name is normally gone within about an hour. Until then we keep only the name and Cloudflare’s reference for it.

Account setup diagnostics: to help you install the service and improve onboarding, we keep an account-linked count and first/last timestamps of complete live checks, plus the first later UTC day with another complete check. These milestones remain until account deletion and are not proof of installation on a website. The latest integration result is a fixed category, such as missing browser evidence or a rate limit, with the time of the latest check and the time this result first appeared. It is shown for seven days and removed by startup/hourly cleanup, normally within seven days and one hour. We do not copy API keys, visitor IPs, request bodies or raw errors into these diagnostics. Daily signup/sign-in outcome counts contain no account identifiers and are retained for 365 days. Since 21 October 2026 the emails at about 80% and 100% of a monthly allowance also say what your latest checks were missing, when that is the case. We use this information for our legitimate interests in reliable service operation and improving account setup; you may object as described below.

Refused API requests and the clients that call (since 17 October 2026): when a request that carries your API key is refused (your server’s address is not on your allowed list, an hourly or monthly limit, an invalid token, a suspended account, a check that could not finish), we keep the time, the endpoint, the HTTP status, the reason and the name your client software sends in its User-Agent header (for example “sentinel-node 0.3.9”), for 7 days, so the console’s Health page can show why it failed. We also count, per account, how many requests each client name made and when, until 30 days after a name was last seen (since 28 October 2026; at most 20 names an account a day, the rest counted together as “other”). Neither record holds anything about your end users. A request whose key matches no account leaves no record. Both are deleted with the account.

Nightly backups: a scheduled job on GitHub Actions (a GitHub-hosted runner) reads the whole application database for a few minutes each night, compresses it and uploads it to Cloudflare R2 storage in Cloudflare’s EU jurisdiction (kept in data centres in the EU), where it is encrypted at rest. Until 16 October 2026 the copies went to Amazon Web Services S3 in Stockholm (see the end of this section). The copy exists on the runner only while the job runs. Since 22 October 2026 the same job also encrypts each copy before it leaves the runner, with a key that only we hold, and uploads it to a shared drive in our Google Workspace (Google Drive), so that the backups do not depend on one provider; Google holds the encrypted file and cannot read it. Backup retention is described at the end of this section.

Application logs: our server writes operational logs: for errors and refused requests, the request method, path and status and a description of the error; timing; security events such as rate-limit refusals and sign-in locks; and a line for each request to our internal admin tools naming the operator, the route, the account concerned, the outcome and the operator’s IP address. Our hosting provider keeps them for 7 days (Cloudflare, since 20 October 2026; the lines Railway kept before that are deleted by Railway within 30 days), and since 22 October 2026 we also keep a copy for 30 days in Cloudflare R2, in its EU jurisdiction, where each line is deleted 30 days after it was written; keys, tokens and our own secrets are removed from a line before that copy is made. They are used to run, secure and troubleshoot the service, not to profile visitors. Most lines identify an account or record by its number rather than by email address, and API keys and tokens are not logged on purpose; some lines can still contain personal data, for example the operator’s email address in admin lines, a recipient’s email address when a newsletter email fails to send, the domain of an email address refused at signup as a temporary inbox or alias (which can identify a person who owns that domain), or an IP address or email address inside a request path or error message. Since 29 September 2026 the live check on our website and API evaluations also write a short line of connection facts beside the resulting decision, so we can measure whether they would improve detection before any decision uses them: round-trip time and distance in broad bands, whether the round trip was faster than light allows for the place the IP address is said to be, the HTTP and TLS versions and the TLS cipher suite, the length of the connecting software’s opening TLS message, and yes/no or low/medium/high answers from our providers (for example whether a relay or an operating-system mismatch was seen, or which kind of proxy). These lines hold no IP address, location coordinates, device identifier, user agent or account identifier; no decision, score or answer uses them yet, and they are kept for the same 30 days. Since 18 October 2026 our homepage and sign-up page also run a short browser check, written to such a line for the same purpose: whether some of the browser’s built-in anti-fraud features are set up and agree with the browser it says it is, whether a known AI agent is working in the page (the on-screen controls or page code such tools add while they act), short codes from two test drawings, one of them a widely used public test (devices of the same type draw them the same way and share the codes), how long the drawing took, counts of pointer, keyboard and scroll activity up to your first click (for example how often the pointer moved and how quickly keys followed one another, never which keys, what you type or where you click) and, on the homepage, the live check’s own result. The line names the type of browser and system the request says it is (such as Chrome on macOS) and holds no IP address, device identifier, user agent or account identifier. When a page request carries an AI agent’s cryptographic signature, we check it against the keys that agent publishes and log the outcome with the page’s address. We also count how often each test-drawing code appears for each type of browser, with nothing about the visitor, and keep those counts for up to 90 days (codes seen only once, 30 days). No decision, score or answer uses any of these yet.

Our own admin records (since 20 October 2026): beside those logs, our database keeps three records for running the service. An operations log of what happened: our own alerts, payments and failed payments (the amount, the plan and the account’s number), a deleted account by its number only, a new version of our server going live and our notices to search engines; email and IP addresses are cut out of each line, and it is kept for 180 days. A log of each request to our internal admin tools, kept in our database as well as in the application logs: the operator, the operator’s IP address, the route, the account or record it concerned and the outcome, kept for one year so we can see who looked at or changed an account. And short notes our staff may write about an account, for example a conversation or something agreed; they are deleted with the account. None of these is used to profile visitors or end users.

Independent monitoring: GitHub Actions runs scheduled checks using public pages and, when configured, a dedicated test account. Private operational run logs contain named pass/fail/unknown outcomes, timestamps and the monitoring scope, not credentials, response bodies or customer records. Run-log retention is controlled by GitHub settings, separate from the incident retention below. A separate Cloudflare monitor stores its latest public-check timestamp and fixed outcomes in Workers KV for up to 24 hours, replacing the previous snapshot. This snapshot contains no account, device or visitor identifiers and is publicly readable. Cloudflare operational logs and traces have provider-managed retention, separate from the snapshot's expiry.

Service incident records: automated monitoring records the affected feature, detection and recovery times, severity, and a fixed error category. These records contain no customer emails, IP addresses, request bodies, credentials, or device identifiers. Automated incident records are retained for 90 days after the last update, with daily cleanup while the service and database are available. To prevent repeated operations emails, we also store the incident identifier, notification phase and attempt time. These notification markers expire after both the incident record has expired and 90 days have passed since the attempt. They contain no recipient addresses or email content. Public summaries appear on our status page; reviewed incident reports may remain longer. Copies in database backups follow the existing backup policy. Hosting logs are separate and may contain other operational data; this 90-day rule does not describe their provider-managed retention.

Server error reports: since 24 September 2026, reports of unexpected server errors are sent to Sentry (Section 5) with request headers, cookies, bodies, query strings, IP addresses, email addresses, API keys, secrets and tokens removed first; the removal is pattern-based, so it is a strong safeguard rather than a guarantee. Sentry keeps them for 30 days on its free Developer plan, and up to 90 days on paid plans and during a trial.

Network and device signals are processed for real-time analysis. Customer API evaluations also create the stored records described in Section 1; processing is not confined to temporary edge memory.

Abuse-prevention counters: to limit password guessing, verification-code reuse and bulk email sending, we keep keyed hashes of account, address, network or challenge identifiers with attempt counts and expiry times in our application database. Email-send reservations contain a keyed recipient hash, which sending pool they count against, a timestamp and, for account security notices, a keyed hash of the account whose action triggered the notice and the kind of notice; never the address or message. These are pseudonymous security records. Counters expire after their protection window (at most 26 hours); email reservations count for 24 hours. Expired records are removed on startup and by hourly cleanup while the application is running, normally within 27 hours of creation. Database backups are subject to the existing backup commitment and assurance note below.

In stored evaluation records and false-positive reports, raw IP addresses are replaced after 7 days with a keyed one-way hash by a cleanup that runs every six hours, so an address can remain up to about 7 days and 6 hours (longer only if the cleanup is delayed). The same applies to an address recorded in an evaluation because it matched a customer’s IP exception. Since 28 September 2026 the hash uses a secret key held by our server, not in the database, and differs per customer, so a hashed address cannot be reversed by trying every address without that key and cannot be matched across customers. Records hashed before then used an earlier, unkeyed hash; the same cleanup re-keys them with the secret key, and backup copies made before that keep the older form until they expire (60 days). This rule does not apply to every record we hold: account details, customer-managed IP exceptions, support messages, and infrastructure security logs serve different purposes. Hashes and other linkable identifiers remain pseudonymous personal data, not automatically anonymous data.

Exception pins: customers may configure explicit “always allow” or “always block” entries for a specific IP address or pseudonymous device hash. These are customer-managed policy configuration, stored until the customer removes them or deletes their account — they are not tracking records, and the device entry is the same one-way hash used elsewhere (the raw device identifier is never stored).

False-positive reports: when a customer reports an evaluation as incorrectly scored, we keep a copy of that single event’s technical details (IP address, pseudonymous device hash, decision) together with the customer’s note so we can investigate and tune detection quality. The IP address in a report is replaced with the same keyed hash on the same 7-day schedule as evaluation logs, and reports are deleted with the customer’s account.

Device sighting counters: to power “how many times has this device been seen” signals (the times_seen API field and the Visits line of the live check on our homepage), we store a one-way SHA-256 hash of a device identifier together with a counter and first/last-seen timestamps. The raw identifier is never stored, and no IP address, user-agent, cookie, or account information is attached to these records — they are pseudonymous device statistics. A repeated hash still allows recognition of the same device, and must not be treated as anonymous. Sighting records are automatically deleted after 90 days of inactivity.

Multi-account device links: where a customer submits a pseudonymous accountId (Section 1), the resulting device-to-account link is stored only as one-way hashes, is scoped to that single customer, and is deleted automatically after 90 days of inactivity — and with the customer’s account.

Account network (since 18 October 2026): where a customer submits an accountId, we also keep, for that customer only: the accountId encrypted with a key of that customer’s own, so the customer’s console can show it (it is used for nothing else); and which devices (the same one-way device hash the evaluation record uses) and which network addresses the account used. Since 5 November 2026 a sign-in attempt the customer has not reported as successful (a login, a second-factor check or a password change sent without success) is kept with the same keys but marked as an attempt: it counts toward how many of the customer’s accounts that device or address tried, and is not counted as a device or an address the account used. An address is kept only as a keyed one-way hash for that customer, and never when it is a shared exit (a VPN, proxy, datacenter address, Tor exit, Apple’s iCloud Private Relay or a mobile carrier’s shared address). From these we count how many of the customer’s accounts share a device or an address and return those counts with the evaluation; nothing is linked across customers. These records are deleted 90 days after the account was last checked, and with the customer’s account. Test-key traffic and the console’s own checks are not recorded.

Email and phone check (since 18 October 2026): the email address or phone number an account holder checks in the console, and the answer, are not stored: the answer is shown once, in that browser tab. We keep only how many checks each account made in a UTC day, to hold it to its plan’s daily number, and delete those counts after 3 days and with the account. Our server log notes that a check ran, whether it was an email address or a phone number and how it ended, never the value. With email and phone intelligence on (Section 1), the stored evaluation record keeps the provider’s score for the address and for the number the customer sent, the names of the provider’s reasons and the facts named in Section 1, and on a high score the reason code email_high_risk or phone_high_risk; never the address or the number, which are not stored or logged. Those scores are kept like the rest of the record and deleted with it; each such check also counts toward the plan’s daily number.

Login protection (since 23 October 2026): the stored evaluation record of a login keeps what Sift answered: the account-takeover score, the names of Sift’s reasons (such as a new device or a new location, never their values), Sift’s pseudonymous user ID for that account (the keyed hash described above) and, when the customer reports the login in its console as the real user or as a takeover, that report; a high score also leaves the reason code account_takeover_risk. All of it is kept like the rest of the record and deleted with it. A report goes to Sift as a label on that pseudonymous user, nothing else. An account event the customer reports (a signup, a password change, a verification, a logout or an account-detail change) is stored like any other check, with the event’s name; Sift answers it with no score. Whether login protection is on, and when it was last switched, is stored with the customer’s account. Our server log notes that a login was checked and how it ended, with the customer’s account number only, never an identifier, email or IP address. Sift keeps what it receives under its agreement with us and its own terms.

Customer device history: the separate device.customer_history feature records a hashed, provider-verified event identifier, a hashed device identifier, its timestamp, and (when supplied by the customer’s backend) a customer-specific keyed hash of the account identifier. It counts distinct events and associated accounts within a rolling 90-day window, only for that customer. Repeated submissions of the same event do not add visits or account links. Test-key traffic is excluded. These records contain no raw account identifiers, email addresses, IP addresses or user-agent strings. They are pseudonymous personal data, not anonymous statistics.

Optional GPU evidence beta: this experiment is off by default and requires both an account administrator to enable it and an explicit call to the separate browser collector. Loading our usual SDK does not run it. The collector measures GPU execution ordering and reduces it to 128 numeric features; it does not collect a GPU serial number or enumerate the browser’s full set of properties. We store the latest feature vector per device encrypted, with a hashed event identifier, device hash, sample count and timestamp, for up to 30 days after its last accepted sample, with a maximum of 200 devices per customer. Comparisons stay within that customer. Similarity is experimental, may be spoofed, and is not proof of identity or fraud; it does not automatically link accounts, change scores or block visitors. Short-lived challenge records contain hashes of the challenge and event, a device hash and expiry time; challenges expire after two minutes and may be used once. Disabling the beta removes its samples and challenges from live storage. The on/off preference stays until changed or the account is deleted.

Optional browser-consistency check: compares browser and operating-system families reported by the page and a background worker, broad WebGL/WebGPU vendor families, the rendering backend named in the WebGL renderer string, the outputs of two small challenge-dependent calculations, and — since 17 October 2026 — short hashes of fixed canvas drawings (never the image itself). It does not retain or transmit full user-agent strings, collect GPU serial numbers or enumerate the browser’s full set of properties. Maskbreak’s own pages do not run this check; since 18 October 2026 our homepage and sign-up page run the separate, log-only browser check described under Application logs above. Customer integrations may explicitly submit these reports through the existing opt-in beta, with a fresh event-bound challenge; Maskbreak recomputes the findings transiently and returns the summary, and raw consistency reports are not saved in the event log or GPU sample table. Since 17 October 2026, three kinds of finding can change the returned decision (only ever raising an otherwise-clean result to “review”, never to a block): a graphics report that contradicts itself — a GPU vendor or render backend impossible for the reported operating system, or the WebGL vendor and renderer strings naming different vendors, which a genuine graphics driver never does; one end-user account showing two different canvas fingerprints from two browsers on the same machine type (only when your integration supplies your own end user’s account identifier with the check, and since 5 November 2026 not for a sign-in attempt it has not reported as successful); and five or more new browsers on one machine type within a day, each showing its own canvas fingerprint — the signature of an antidetect browser running many profiles on one machine. Identical real machines show the same canvas fingerprint, so owning identical devices triggers neither. For those two checks we store, per customer and for 30 days from the last sighting: keyed one-way hashes of the canvas readings and of the machine type they describe, the one-way hash of the browser’s device identifier that the Events log already uses, whether a second browser has shown the same reading, and, when you supply one, a keyed one-way hash of the account identifier. These hashes describe a graphics-hardware model and a browser, not a name or address; they are keyed with a secret held by Maskbreak, are never linked across customers, and are removed when your account is deleted. Since 18 October 2026 we also keep, the same way and for the same 30 days, which of those canvas readings each browser showed on one machine type and browser version, to measure whether one browser’s reading changes between visits (an antidetect profile cycling its fingerprint); the result is written to our application logs only and changes no score or decision yet. Other browser-reported findings remain informational and do not change scores, decisions or account links.

Customer-history and GPU records are excluded from results at their expiry time and removed by cleanup approximately every six hours while the service is running. Account deletion removes these customer-scoped records from live systems; backup copies follow the existing backup policy below. Customers must explain this processing to their visitors, establish an appropriate legal basis, and obtain any required consent before collection. Enabling a dashboard preference is not visitor consent, and the beta is not approved for advertising or cross-site tracking.

Webhook delivery log: attempts to deliver a customer’s threat-alert webhooks are logged with the event type, HTTP outcome, and any error string — never the payload and never end-user IP addresses. Delivery-log entries are deleted automatically after 30 days, or with the account.

Signed-in sessions: each dashboard sign-in creates a session record holding a one-way hash of the sign-in token, your account identifier, the IP address and browser identifier (user-agent string) the session started from, and when it was created and last active. It lets you review and end sessions on the Security page and makes signing out take effect on every device. A session lasts up to 30 days. In your browser, since 14 October 2026, it is kept in a cookie that page scripts cannot read, beside one holding only your account number (Cookie Policy). Its record is deleted when you sign out or end that session on the Security page; changing your password or email address ends every session, and turning two-factor authentication on or off or removing a passkey ends every other session; all records go with the account. Otherwise a scheduled cleanup deletes the record shortly after its 30 days end.

Console language: When you explicitly select a console language, we save the language code under your account identifier in local storage in that browser. It remains until you change it or clear browser storage. Since 27 October 2026 a new account’s console starts in the language of the page it signed up on (English, German or Estonian); you can switch it at any time at the bottom of the console’s sidebar. This preference is not used for advertising.

Billing records: invoices, receipts, credit notes and the payment and subscription records behind them are kept for six years from the end of the financial year they relate to, because UK tax law (HMRC’s record-keeping rules for company tax and VAT) requires us to keep them for that long; this applies even if you delete your account, and those records are then used only to meet those obligations or to establish or defend legal claims. They are held in our Stripe account and in our own accounting records. Stripe also keeps records under its own legal obligations and privacy policy.

People we contact about Maskbreak (Section 1.4): deleted within 12 months of our last message, unless you become a customer. If you ask us to stop, only your LinkedIn profile address or email address stays, on a do-not-contact list, for as long as we contact people this way.

The whole database, account and evaluation records included, is additionally protected by encrypted daily backups for disaster recovery: since 17 October 2026 in Cloudflare R2 (EU jurisdiction), where a rule removes each copy after 40 days, and since 22 October 2026 also a second copy in Google Drive, encrypted with a key only we hold, where each copy is moved to the trash after 25 days (after 30 days until 5 November 2026) and Google deletes it 30 days later. Our existing retention commitment is a maximum of 60 days, for disaster recovery only. A daily audit lists the R2 copies and fails if any is older than that rule allows. The nightly backup job moves the expired Drive copies to the trash itself, also on a night its upload fails, and alerts us when it cannot, so that we can move them by hand before any copy passes 60 days. The copies made up to 16 October 2026 are held by our former backup provider, Amazon Web Services (S3, Stockholm region), where a rule set to delete them within the 60-day limit was in place (the audit confirmed it from 10 October 2026 until the account was suspended); that account is suspended and we are not restoring access to it, so we can no longer check or delete those copies ourselves. Restoring a backup stays blocked until we can show that deleted accounts stay deleted after a restore. Our database (Cloudflare D1) also keeps its own history for 30 days (Time Travel), so a record deleted from it can still be recovered from that history for 30 days, within the 60-day commitment; we would use it only to recover from a failure of the database itself, and account deletions made after the point restored would be carried out again. See the retention-assurance note. None of this extends the commitment or authorises use of deleted account data.

4. Your data protection rights

Depending on your location and the lawful basis, you may have rights to access, correct, erase, or restrict personal data; receive portable data you provided to us; and object to processing based on legitimate interests or to direct marketing. These rights are not absolute and exemptions may apply. Where we rely on consent, you may withdraw it at any time without affecting earlier processing.

If Maskbreak processed your data for one of our customers, contact that customer first because it controls the purpose of the processing. We assist customers with verified requests. For Maskbreak account or website data, email support@maskbreak.com. We normally respond without undue delay and within one calendar month, and may ask for information needed to verify your identity. If a lawful extension is needed because of the complexity or number of requests, we will explain it within the initial month.

Your right to object: you may object to processing based on legitimate interests, including fraud-prevention profiling, by contacting us or the relevant customer. The controller will stop unless it demonstrates compelling legitimate grounds or the processing is needed for legal claims.

4.1 Automated decision-making and profiling

Maskbreak automatically analyses technical signals and returns risk indicators, reason codes, and a score to the customer. Maskbreak does not decide whether an end user may open an account, complete a purchase, or access a customer’s service. Customers determine their own rules and should provide human review or a way to challenge decisions where their use of Maskbreak could have a legal or similarly significant effect.

4.2 Children

Maskbreak accounts and business services are not directed to children. We do not knowingly request children’s names or contact details through the fraud-detection API. Customers serving children remain responsible for the additional notices, safeguards, and lawful basis their use case requires.

4.3 California disclosures

We do not sell personal information and do not share it for cross-context behavioural advertising. Subject to applicable thresholds and exceptions, California residents may request access, correction, or deletion and may exercise rights without discriminatory treatment. Requests can be sent to support@maskbreak.com.

5. Sub-processors and Security

We do not sell data to third parties. We share data with the providers below strictly to provide our service. We are putting data-processing terms in place with each provider that processes data on our behalf, and the current status for each provider is available on request; sign-in providers you choose (Google and GitHub Sign-In) act as independent controllers under their own terms, Stripe acts as an independent controller for part of its processing (see its entry below), and Have I Been Pwned receives no personal data. Each provider’s region is listed at maskbreak.com/sub-processors.

Our specialised detection sub-processors are identified above by category rather than by name, as the composition of our detection stack is confidential security information. Their names are available on request: customers can request the full named sub-processor list (including each provider's address, processing location and privacy policy) under our Data Processing Agreement, published self-serve at maskbreak.com/dpa, from support@maskbreak.com, and anyone asking which recipients received their own personal data is told who they are. A countersigned DPA is available from the same address. We give customers at least 30 days' notice before adding or replacing a sub-processor that processes customer data, by a dated entry in the change log at maskbreak.com/sub-processors.

We implement automated bot detection and rate limiting to protect our platform. Automated or excessive access may be restricted. Data is encrypted in transit, and the database and backups are encrypted at rest; account passwords are hashed with bcrypt; API keys are randomly generated with crypto.randomBytes.

5.1 Former providers

We no longer send these providers anything. Each may still hold data from the time we used it, as described.

No advertising tag runs on our pages: Google Ads tags and conversion-event calls were removed from the website and dashboard on 6 September 2026 (Cookie Policy §2.3). Before that, the tag ran with consent settings denied but still sent measurement pings to Google. This does not affect the optional Google Sign-In.

5.2 International Transfers

Our application hosting (Cloudflare, Eastern North America, since 20 October 2026; Railway, US East, before) and primary database (Cloudflare D1, Eastern North America, since 19 October 2026; Turso, AWS us-east-1, before) are in the United States, so account data and customer evaluation records are stored and processed there. Our detection providers, Sift (login protection, for the logins and account events customers’ servers send), the email- and phone-intelligence provider behind the console’s email and phone check, our former email provider (Resend, until 19 October 2026) and GitHub are also in the United States, Stripe processes payment data in the United States and other countries, and other providers may process data outside the United Kingdom and European Economic Area as described in Section 5. Backups are stored in the EU (Cloudflare R2, EU jurisdiction; copies made up to 16 October 2026 with Amazon Web Services in Stockholm); since 22 October 2026 a second copy, encrypted with a key only we hold, is kept in Google Drive (United States and other Google locations). Where required, we use an applicable adequacy regulation or contractual safeguards such as the UK International Data Transfer Agreement/Addendum and EU Standard Contractual Clauses. Information about the relevant safeguard is available by contacting us.

5.3 Personal data breaches

We maintain technical and organizational measures to prevent personal-data breaches. If a breach affecting personal data we process as a controller is likely to result in a risk to individuals, we will notify the Information Commissioner’s Office without undue delay and, where feasible, within 72 hours of becoming aware of it, and will inform affected individuals where the breach is likely to result in a high risk to them. Where we process end-user data as a processor on a customer’s behalf, we will notify that customer without undue delay after becoming aware of a breach so they can meet their own notification duties, as set out in our Data Processing Agreement.

6. Contact and complaints

Questions and rights requests can be sent to our privacy contact:

Maskbreak Privacy Team

support@maskbreak.com

134a West Hendon Broadway, London, NW9 7AA, United Kingdom · Company number: 17150600

To make a formal data-protection complaint, email support@maskbreak.com with the subject Data protection complaint and describe the processing and outcome you are concerned about. We will acknowledge the complaint within 30 days, investigate it without undue delay, keep you informed where an investigation takes longer, and explain the outcome and any action taken. We keep a record of complaints as required to demonstrate how they were handled.

If you are dissatisfied with our response, you may complain to the Information Commissioner’s Office at ico.org.uk/make-a-complaint, telephone 0303 123 1113, or to the data-protection authority where you live or work.