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 the Maskbreak Edge 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:
- Network Data: IP addresses, Autonomous System Numbers (ASN), proxy/VPN detection signals, and TCP/IP and TLS connection characteristics (for example the connection’s round-trip time, the HTTP and TLS versions used, and the approximate location our network provider associates with the IP address).
- Device & Browser Telemetry: User-Agent strings, browser version, screen resolution, language settings, hardware concurrency, canvas and WebGL fingerprints, and browser tampering indicators (antidetect browser detection).
- Automation Signals: Indicators that a browser is controlled by automation software rather than a person (for example a WebDriver flag or headless-browser traits).
- Device Intelligence: Incognito/private mode detection, virtual machine detection, emulator detection, and bot classification signals.
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 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 (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.
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 and login (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 device label you choose. 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). If you sign in with Google or GitHub, where those options are offered, 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 in the dashboard about how you heard of Maskbreak (asked 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 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 (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 a higher hourly request limit than 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) 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 and first-threat emails we have sent you and when, 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, 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. Each contains a one-click unsubscribe link that stops them, as does 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. They use the email address you signed up with, a stored on/off preference, your setup answer, 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. While they are on, our founder may also write to you in person about a setup that seems stuck. Other product-update and onboarding-tip emails are sent only if you opt in with the Email preferences toggle 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). 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 invoices it issues for us; 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.
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:
- Detect and block account takeovers (ATO), credential stuffing, scraping bots, and antidetect browser abuse.
- Identify high-risk infrastructure such as commercial residential proxies, TOR exit nodes, anonymous datacenters, and spoofed devices.
- Generate an abstract, mathematical "Risk Score" and device intelligence assessment returned to our Customer's API.
- Verify password safety against known breach databases using k-anonymity (only a partial hash is sent to the breach database — your password is never sent to it).
2.1 Lawful bases by purpose
- Former Widgo chat, browser storage and visitor analytics: our legitimate interest in offering website help (Article 6(1)(f)) while the chat ran on public marketing pages, from 22 September 2026 until we removed it on 30 September 2026, and in handling the support records it produced. No page loads it now. The identifiers it stored in browsers are listed in Cookie Policy §2.4. The removal does not undo earlier processing or delete existing support records; you can still object or ask for access or deletion.
- Product analytics and session recordings (PostHog): our legitimate interest in understanding how people use our website and dashboard, and where sign-up and setup go wrong, so that we can fix them (Article 6(1)(f)). Since 23 September 2026 this starts by itself, without a consent prompt, once a public page,
/signupor the dashboard has finished loading. It never runs on sign-in, password-reset, verification, invitation, settings, security (including two-factor), members, admin or result pages, and it does not start at all in browsers that send Global Privacy Control or Do Not Track or ask to save data. What is recorded, what is masked and the identifiers it stores are listed in Cookie Policy §2.5. You can object at any time by emailing us; objecting or blocking it does not undo earlier processing. - Server error reports (Sentry): our legitimate interest in running a reliable and secure service by finding and fixing faults in our own software (Article 6(1)(f)). Since 24 September 2026, when our server hits an unexpected error it sends a technical report to Sentry. This happens on our server only: nothing is loaded in your browser and nothing is stored on your device, and the report is built to leave personal data out (see Section 3 and Section 5).
- Providing accounts, authentication, support, and contracted services: performance of a contract or steps requested before entering a contract.
- Protecting Maskbreak, our customers, and end users from fraud, abuse, account takeover, and security threats: our and our customers’ legitimate interests in network and information security, balanced against the limited and pseudonymous nature of the telemetry.
- Service administration, audit logs, troubleshooting, and improving detection quality: legitimate interests in operating a reliable and accurate security service.
- Paid plans: taking payment, issuing invoices and managing subscriptions (through Stripe): performance of a contract or steps requested before entering a contract.
- Tax, company, sanctions, and lawful disclosure obligations, including keeping invoices and accounting records: compliance with legal obligations where applicable.
- Account setup emails (a few in the first days after signup, since 23 September 2026): our legitimate interest in helping you start using the account you opened (Article 6(1)(f)); they are about your account and carry no promotion of other products. Every one contains a one-click unsubscribe link. The same interest covers a personal note from our founder about a setup that seems stuck, which we offer only while those emails are on.
- Asking whether we may mention you on maskbreak.com (since 11 October 2026): our legitimate interest in showing who uses Maskbreak (Article 6(1)(f)): our founder may write once to an account whose website is confirmed, or that uses the API regularly, to ask, and sends no reminder if you do not reply. Publishing your company’s name or a quote from you: your consent (Article 6(1)(a)), given in writing for the exact wording and the page it appears on. You can withdraw it at any time by replying, and we then remove it from maskbreak.com.
- The dashboard’s setup question “What do you want to do with Maskbreak?” (since 8 October 2026): our legitimate interest in helping you set up the account you opened (Article 6(1)(f)). The answer chooses the setup steps the dashboard shows and the setup emails you receive; you can change it at any time.
- The optional “How did you hear about Maskbreak?” question (since 3 October 2026): your consent, given by choosing an answer (Article 6(1)(a)). It is voluntary, Skip stores only the fact that you skipped, and you can ask us to remove your answer at any time. We read the answers, per account in our admin console and in total, to decide where to publish and where to spend effort; we do not use them for advertising or to profile you.
- Optional product or newsletter messages: consent where required. You may unsubscribe at any time using the link in the message.
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.
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. 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.
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. 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. 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. 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. They are kept by our hosting provider for 7 days (Cloudflare, since 20 October 2026; the lines Railway kept before that are deleted by Railway within 30 days), and 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.
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. This state is no longer sent to Upstash.
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 visit counter in the homepage scanner demo), 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 was checked from. 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.
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 (the homepage demonstration was removed on 30 September 2026); 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 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. Since 24 September 2026 a session lasts up to 30 days (previously 24 hours). 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.
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.
Customer account data (Section 1.1) is additionally protected by encrypted daily backups stored within the EU for disaster recovery: since 17 October 2026 in Cloudflare R2 (EU jurisdiction), where a rule removes each copy after 40 days. Our existing retention commitment is a maximum of 60 days, for disaster recovery only. A daily audit checks that every backup copy is set to expire within that limit and that none older than 60 days is kept. 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. 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.
- Network intelligence provider (United States) — network-layer threat intelligence: VPN, residential proxy, datacenter, and Tor exit detection. Its script, served from a maskbreak.com subdomain, measures the connection and reads basic browser characteristics (user agent, languages, time zone, window size, processor count and an automation flag); the provider receives these with the IP address and returns an encrypted token, which our server sends back to it to obtain the result. When that subdomain cannot be reached from the homepage or does not answer within a few seconds, the homepage loads the same script from the provider’s own domain inside a hidden frame on maskbreak.com (Cookie Policy §3).
- Device intelligence provider (United States) — device-layer intelligence: tampering, antidetect-browser detection, bot/automation, emulator/VM detection. Receives device telemetry, pseudonymous device identifiers and the IP address. Both detection providers’ standard terms may also allow them to use signals collected through their scripts for their own purposes (for example to maintain and improve their services, for security, or in de-identified and aggregated form); for that use they act under their own terms.
- Email and phone intelligence provider (United States) — the console’s email and phone check, since 18 October 2026: receives only the email address or phone number an account holder types into the check, never account, API-key, evaluation or visitor records, and returns what it knows about it (Section 1). Its standard terms may also allow it to use the addresses and numbers it is asked about for its own purposes, such as the fraud history it keeps across its customers; for that use it acts under its own terms.
- Cloudflare — CDN, DDoS protection, and DNS. Receives request metadata and IP. Since 17 October 2026 also stores our encrypted nightly database backups in R2, in its EU jurisdiction, for disaster recovery: each copy is removed after 40 days, within the 60-day commitment a daily audit checks (see Section 3). Since 19 October 2026 also delivers our email (Email Service): it receives the recipient’s address and the message. Since the same day also our primary database (D1, in the United States, Eastern North America) for account and session records, API keys, evaluation records, abuse-prevention counters and newsletter subscriptions, which our server reaches only through a Worker. Since 20 October 2026 also our application hosting (Containers, in Eastern North America): our server runs there, receives every request to our website and API and writes the application logs described in Section 3 (kept 7 days). Since the same day also opens, once, a page address a customer enters in the dashboard’s page check (Browser Run); we keep neither the address nor the result. Privacy.
- Railway — application hosting in the United States (US East), including the application logs described in Section 3 (kept up to 30 days), until 20 October 2026; since then a stand-by copy of our server that receives no traffic, which we will remove by 27 October 2026. Privacy.
- Turso — our managed cloud database (libSQL) in the United States (AWS us-east-1, Virginia) until 19 October 2026, for account and session records, API keys, evaluation records, abuse-prevention counters and newsletter subscriptions. The database was deleted and our account closed the same night; copies Turso may still hold in its own backups follow its retention terms. Privacy.
- Resend (United States, former) — delivered all our email until 19 October 2026 (verification codes, password resets, security notices, form receipts, account setup emails, monthly summaries, and the newsletter and its confirmation emails), when Cloudflare took over; our account there was closed the same night, and copies Resend may still hold in its own backups follow its retention terms. Privacy.
- Stripe (Stripe, Inc. and its affiliates; United States and other locations) — payments, subscriptions, invoices and receipts for paid plans, since 30 September 2026. Checkout and the billing portal are pages hosted by Stripe on its own website, reached from the console; no Stripe script runs on maskbreak.com and card details never reach our servers. Stripe receives the account’s email address, the plan chosen, the payment and billing details you enter on its pages (for example card details, billing name and address and a VAT number), and the IP address and browser details of the device you use there. It receives no evaluation records or customer end-user data. Paid plans are sold through Stripe’s Managed Payments service, in which Stripe, shown to you as Link, is the merchant of record: Stripe acts as an independent controller for the checkout, the payment, tax, receipts and invoices, payment support and your optional Link account, and for preventing fraud and meeting its own legal and regulatory obligations, under Stripe’s privacy policy.
- Amazon Web Services (S3) — our backup store until 16 October 2026: it holds the encrypted nightly database backups made up to that date, in the EU Stockholm region (eu-north-1), under the same 60-day commitment. The account is suspended and we are not restoring access to it, so we can no longer check or delete those copies ourselves; the deletion rule that was in place when it was suspended is described in Section 3. Privacy.
- Google Sign-In — optional OAuth authentication. Receives and returns the information needed to complete sign-in. Since 24 September 2026 the log-in page (
/loginonly) also loads Google’s sign-in client by itself once the page has finished loading, so a browser already signed in to Google can be offered Google’s own “Continue as …” prompt (One Tap). Loading it sends Google the visitor’s IP address and browser details and lets Google read its own cookies, whether or not the prompt is used. It is not loaded for browsers that send Global Privacy Control or Do Not Track, it only signs in existing accounts (it never creates one), and nothing reaches Maskbreak unless the visitor picks an account in the prompt. Privacy. - Google Workspace (Google, United States and other Google locations) — hosts our support@maskbreak.com mailbox: the emails you send us, the contact and programme forms relayed to it, security reports and data-protection requests, and our replies. Privacy.
- Auth0 (former) — provided “Email me a sign-in link” on the sign-in and sign-up pages until 5 October 2026. While offered, Auth0 delivered a one-time link and confirmed you held the address, and it received your email address only when you used that option. We deleted our Auth0 tenant (United States) on 6 October 2026, and with it the user record (the address and sign-in metadata) it held for each person who used the link; any copies left in Auth0’s own backups are removed under Auth0’s retention terms. Nothing is sent to Auth0 any more. Auth0 privacy notice.
- GitHub (GitHub, Inc., United States) — two uses. GitHub Sign-In: optional OAuth authentication, where offered on the sign-in and sign-up pages. When you choose it, GitHub receives the sign-in request and returns your GitHub account ID, name and verified email address; it receives nothing from us if you do not use it. GitHub Actions: runs our scheduled monitoring checks and the nightly database backup job described in Section 3, so for a few minutes each night a GitHub-hosted runner processes a full copy of the database, including account records and, for evaluations less than 7 days old, raw end-user IP addresses. Privacy.
- Have I Been Pwned — password breach check via k-anonymity. The check runs on our server: only the first 5 characters of the password’s SHA-1 hash are sent to Have I Been Pwned, and neither the password nor the rest of the hash leaves our infrastructure. Privacy.
- flagcdn.com — serves the small flag images in the console’s test panel. When a console test result is shown, your browser requests the flag for that result’s two-letter country code from flagcdn.com, which receives your IP address, browser details and that country code. It receives no account records or customer end-user data.
- 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. New accounts start in English, independently of the website language; this preference is not used for advertising.
- Advertising measurement removed: Google Ads tags and conversion-event calls were removed from the website and dashboard on 6 September 2026. Previously, the tag operated with consent settings denied but still sent measurement pings to Google; “cookieless” did not mean no data transmission. See Cookie Policy §2.3. This change does not remove the optional Google Sign-In service.
- Widgo (Widgo, Inc., United States) — former AI chat provider on public marketing pages, from 22 September 2026 until its removal on 30 September 2026; no page loads it now. While loaded, Widgo received IP address, browser/device characteristics, page and referring-page information, campaign parameters and interaction timing, and, if you wrote to it, chat messages and replies and any contact details you volunteered; it was never supplied with account records, API keys or evaluation records. Conversations and records Widgo already holds remain in the workspace until removed under our support-retention process or a verified deletion request; the removal does not delete them. Processing may take place in the US, EU and other locations described in Widgo’s privacy policy. Contact us to request access or deletion. See Cookie Policy §2.4.
- PostHog (PostHog, Inc., United States; PostHog EU Cloud, hosted in Frankfurt, Germany) — product analytics and session recordings on maskbreak.com since 23 September 2026. The PostHog library is served from maskbreak.com at a fixed version, so PostHog cannot change or add code on our pages; the browser only sends data to
eu.i.posthog.comand reads settings fromeu-assets.i.posthog.com. PostHog receives the pages you view (addresses stripped of everything except campaign parameters), clicks, the referring page, browser, operating system, device type and screen size, the IP address of each request (from which it can derive an approximate location), a random identifier stored in your browser, and recordings of how public pages,/signupand the dashboard were used. Since 17 October 2026 it also receives page-speed measurements (Core Web Vitals) and, on public pages and/signup, clicks that changed nothing on the page and errors in the page’s own scripts (the error type, message and code location, with addresses in them cleaned the same way). The same identifier follows a browser from public pages through sign-up into the dashboard. Everything typed into a form field is masked in the browser before it is sent, as are the live check and IP-lookup results that show your own address, network and location, and the email address shown during sign-up; on the dashboard all text is masked. Console logs, network requests and canvas content are not recorded. We do not send PostHog your name, email address, account ID, API keys or evaluation records. It does not run on sign-in, password-reset, verification, invitation, settings, security, members, admin or result pages, nor at all in browsers that send Global Privacy Control or Do Not Track or ask to save data. Retention follows PostHog’s plan limits: events for up to one year and recordings for up to 30 days on its free plan, longer on paid plans. PostHog’s data processing agreement allows processing outside the UK and EEA, including in the US. See Cookie Policy §2.5 and PostHog’s privacy policy. - Sentry (Functional Software, Inc. d/b/a Sentry, United States; Sentry’s EU data region, hosted in Frankfurt, Germany) — error reports from our server software since 24 September 2026. Only our server talks to Sentry: no Sentry code runs on our pages or in your browser, and nothing is stored on your device. A report contains the error type, message and stack trace (file names, line numbers and the surrounding lines of our own source code), runtime details, the software release and environment, the request method and path with IP addresses, email addresses, identifiers (UUIDs, account and record numbers, long hexadecimal strings) and token-like parts replaced by placeholders (for example
/v1/lookup/:ip), and, for up to 30 of the server’s recent outgoing requests (for example to our providers or to a customer’s webhook endpoint), only the method, the status code and the origin: scheme, host name and port, with no path or query, so a customer’s webhook host name can appear. Request headers, cookies, bodies, query strings, IP addresses, email addresses, the user/account profile, API keys, webhook secrets, sign-in tokens and database credentials are removed on our server before a report is sent, including from error messages; this removal is pattern-based, so it is a strong safeguard rather than a guarantee. Performance tracing, profiling, log forwarding and session replay are not used. Sentry’s generative AI features are turned off for our account, so error reports are not passed to its AI sub-processors, and Sentry’s own IP-address storage is turned off. Retention follows Sentry’s plan limits: 30 days on its free Developer plan; up to 90 days on paid plans and during a trial. Error reports are stored in Sentry’s EU region, but Sentry’s data processing agreement allows processing in the US and other countries where it or its sub-processors operate, and Sentry keeps account and project settings in the US. Sentry’s privacy policy. - Crisp (Crisp IM SAS, France) — former live-chat provider. New website chat was switched to Widgo on 8 September 2026 (itself removed on 30 September 2026). Historical support conversations may remain in Crisp while needed to handle the request or legal obligations; the switch does not delete those records. Contact us to request access or deletion. Privacy.
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.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, 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). 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:
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.