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 connection characteristics.
- 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).
- Behavioral Signals: Anomalous interaction patterns (e.g., highly rigid mouse movements or automated scrolling indicative of scripted bot activity).
- 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 hashes that value before storage. 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.
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), and a pseudonymous device key derived as a one-way SHA-256 hash of the device-intelligence identifier — the raw identifier itself is never stored. These records are visible only to the customer whose API key ran the evaluation and are never linked across customers.
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, 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, or an emailed sign-in link via Auth0, where those options are offered), we store the provider's stable account identifier to link future sign-ins. 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 and the time of the last limit notice we emailed you) so we can alert you when your API quota is nearly exhausted without repeating ourselves. 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) 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 (signup only), and a one-way hash of the verification code — never the code itself — for up to 10 minutes; expired or completed verification records are deleted automatically. If you set up authenticator-based two-factor authentication, we store the shared TOTP secret needed to verify your codes; it is 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 subscription time for subscription and abuse-prevention records, until you unsubscribe or request deletion. 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; those existing records remain available for access or deletion requests. You can unsubscribe using the link in any newsletter. Optional product-update and onboarding-tip emails are sent only if you opt in — via the optional checkbox at signup or the Email preferences toggle in Settings; accounts created through Google or (where offered) GitHub sign-in are never enrolled automatically — and every such email contains an unsubscribe link. 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. Our existing 60-day deletion commitment and the current verification work are explained in Section 3.
1.2 Contact, programme applications, and support
If you contact us, apply for public-interest access, or open live chat, 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, including a receipt, rather than stored as a separate application table in the product database. Copies remain in the support mailbox and relevant delivery or 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 (partial hash only — actual passwords are never transmitted).
2.1 Lawful bases by purpose
- Widgo chat, browser storage and visitor analytics: our legitimate interest in offering website help (Article 6(1)(f)). Since 22 September 2026 the chat loads by itself on public marketing pages after the page has finished loading; it does not load on sign-in or private account pages, and it is not loaded automatically for browsers that send the Global Privacy Control signal, which instead see a plain “Chat” button. Using the chat is your choice; email support is always available instead. The identifiers Widgo stores are listed in Cookie Policy §2.4. Objecting or blocking the widget does not undo earlier processing or delete existing support records.
- 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.
- Tax, company, sanctions, and lawful disclosure obligations: compliance with legal obligations where applicable.
- 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 setup checks: if you start a website-specific check in the dashboard, we store the site origin (scheme, hostname and port), the start time and, if successful, the confirmation time. Paths, query strings, raw browser event identifiers and visitor details are not copied into this receipt. We compare fresh, server-verified browser event metadata with your chosen site during a 30-minute window. This records receipt of complete evidence, not domain ownership or enforcement of a decision. The latest configuration and receipt remain until you replace them or delete the account, with backups subject to the policy below.
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 a timestamp. 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.
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.
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 and timestamp, not the address or message. These are pseudonymous security records. Counters expire after their protection window (at most 24 hours); email reservations count for 24 hours. Expired records are removed on startup and by hourly cleanup while the application is running, normally within 25 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 one-way hashed after 7 days by a scheduled cleanup. 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 one-way hashed 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.
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, and the outputs of two small challenge-dependent calculations. It does not retain or transmit full user-agent strings, collect GPU serial numbers or create a persistent device identifier. On the homepage, “Check my browser” runs only when clicked: results remain in page memory, are not uploaded or stored in cookies/browser storage, and are discarded when cleared or the page is left. Customer integrations may explicitly submit these reports through the existing opt-in beta, with a fresh event-bound challenge. Maskbreak recomputes findings transiently and returns the summary; neither raw consistency reports nor their summaries are saved in the event log or GPU sample table. Existing hashed challenge/event records retain the lifetimes described above. These browser-reported checks do not establish identity or fraud 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.
Customer account data (Section 1.1) is additionally protected by encrypted daily backups stored within the EU (Stockholm region) for disaster recovery. Our existing retention commitment is a maximum of 60 days, for disaster recovery only. A review of backup expiry and deletion handling is in progress; see the retention-assurance note. This review does not extend the commitment or authorise 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 trusted sub-processors strictly to provide our service. All sub-processors are bound by Data Processing Agreements (DPAs) and follow industry-standard security practices.
- Network intelligence provider — network-layer threat intelligence: VPN, residential proxy, datacenter, and Tor exit detection. Receives IP address and an encrypted SDK token.
- Device intelligence provider — device-layer intelligence: tampering, antidetect-browser detection, bot/automation, emulator/VM detection. Receives device telemetry and IP address.
- Cloudflare — CDN, DDoS protection, and DNS. Receives request metadata and IP. Privacy.
- Railway — application hosting. Privacy.
- Turso — managed cloud database (libSQL) for account records and API keys. Privacy.
- Resend — transactional email (OTP codes, password resets, contact-form receipts). Privacy.
- Amazon Web Services (S3) — encrypted nightly database backups for disaster recovery, stored in the EU Stockholm region (eu-north-1) with 60-day rolling retention (see Section 3). Privacy.
- Google Sign-In — optional OAuth authentication. Receives and returns the information needed to complete sign-in. Privacy.
- Auth0 — “Email me a sign-in link”, where offered on the sign-in page: Auth0 delivers a one-time link and confirms you hold the address; Maskbreak then issues its own session. It receives your email address only when you use that option, and nothing otherwise. Auth0 privacy notice.
- GitHub Sign-In — optional OAuth authentication, where offered on the sign-in page (not currently enabled in production; GitHub receives nothing until it is). When enabled it receives and returns only the information needed to complete sign-in. 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.
- 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) — AI chat on public marketing pages. Since 22 September 2026 the widget loads by itself once a public page has finished loading; browsers that send the Global Privacy Control signal get a plain “Chat” button and Widgo loads only when it is pressed. Once loaded, Widgo receives IP address, browser/device characteristics, page and referring-page information, campaign parameters and interaction timing, and, if you write to it, chat messages and replies and any contact details you volunteer. It uses browser identifiers, visitor analytics and possible company-level identification to answer questions and help us understand enquiries. Session replay is disabled. The widget is not loaded on sign-in or private account pages and is not supplied with account records, API keys or evaluation records. AI answers may be inaccurate; do not submit secrets or sensitive records. Processing may take place in the US, EU and other locations described in Widgo’s privacy policy, not exclusively in the EU. Conversations remain in the workspace until removed under our support-retention process or a verified deletion request; this is not automatic deletion when you close chat. Widgo describes separate security-log and backup retention in its policy. To keep Widgo from loading, enable Global Privacy Control in your browser or block
cdn.widgo.ai; existing browser storage and transcripts are not erased by that. See Cookie Policy §2.4. - Crisp (Crisp IM SAS, France) — former live-chat provider. New website chat was switched to Widgo on 8 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. Our Data Processing Agreement is published self-serve at maskbreak.com/dpa; customers can request the full named sub-processor list (including each vendor's privacy policy) under it from support@maskbreak.com, and a countersigned copy is available from support@maskbreak.com. We give customers at least 30 days' notice before adding a sub-processor that processes customer data — the current list and a dated change log are published 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 stored encrypted in transit; account passwords are hashed with bcrypt; API keys are randomly generated with crypto.randomBytes.
5.2 International Transfers
Some sub-processors handle data outside the United Kingdom and European Economic Area, including in the United States. 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.