Sub-processors
The companies that process data on Maskbreak’s behalf: what each one does, what it handles and where. Annex C of the DPA gives the same regions. Our application server and database run in the United States; backups are stored in the EU. A new sub-processor that processes customer data is announced in the change log below at least 30 days in advance, with the right to object.
Last updated 6 November 2026 · maintained by Sentinel Edge Networks LTD
Current sub-processors
| Provider | Purpose | Data touched | Region |
|---|---|---|---|
| Cloudflare |
|
| Application server and database: United States (Eastern North America); backups and the 30-day log copy: EU (R2 EU jurisdiction); network, email, page check and DNS resolver: Cloudflare’s global network |
| GitHub (GitHub, Inc.) | GitHub Actions: the nightly backup job, which for a few minutes each night reads the full database on a GitHub-hosted runner, compresses it and uploads it to Cloudflare R2 (and, since 22 October 2026, an encrypted copy to Google Drive); also our scheduled monitoring checks. GitHub Sign-In (OAuth), used only when an account holder chooses it. No analytics, no advertising | Backup job: the full database while the job runs (including account records and evaluation records with raw end-user IP addresses under 7 days old). Monitoring: pass/fail outcomes, no customer records. Sign-In: the account holder’s OAuth identity assertion | United States and other locations where GitHub-hosted runners operate |
| Stripe (Stripe, Inc. and its affiliates) | Sells our paid plans as the merchant of record through its Managed Payments service (shown to buyers as Link), since 30 September 2026: payments, subscriptions, tax, invoices and receipts. Checkout and the billing portal are pages hosted by Stripe on its own website; no Stripe script runs on maskbreak.com. Also acts as an independent controller for its own fraud-prevention and regulatory purposes. Listed for transparency: it receives no customer end-user data | Account holders’ billing data only: the account’s email address and plan, payment and billing details entered on Stripe’s pages (card details go straight to Stripe and never reach our servers), and the IP address and browser details of the device used there. Provider privacy policy | United States and other countries where Stripe operates |
| Network-intelligence provider and device-intelligence provider (listed by category) | VPN/proxy/Tor/datacenter classification and device-integrity signals for evaluations; their scripts run in the visitor’s browser from maskbreak.com subdomains. Their 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 | IP address and an encrypted network token; browser/device characteristics, pseudonymous device identifiers and security signals. Each provider’s name, address and processing location are given to customers on request under the DPA, as confidential information (support@maskbreak.com) | United States |
| Proxy-detection provider (listed by category), since 6 November 2026 | The proxy check of the live check on our own IP-lookup page, and nowhere else: its script runs in the visitor’s browser on that page, from the provider’s own domain, and returns an encrypted answer that our server opens itself; our server also looks the visitor’s address up in the provider’s IP database (VPN, Tor, relay, data-centre and proxy addresses). It stores nothing in the visitor’s browser. Listed for transparency: it processes only visitors to our own page, never customer end-user data | The IP address and connection measurements of visitors to maskbreak.com/ip-lookup; no account, API-key or evaluation records | United States |
| Email- and phone-intelligence provider (listed by category), since 18 October 2026 | The console’s email and phone check: when an account holder types one email address or one phone number into it, our server sends that value to this provider and shows the account holder a summary of the answer (whether the address accepts mail and 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). A daily number of checks per account, set by its plan. Email and phone intelligence on API checks (since 23 October 2026; on by default for accounts created from that day, off for older accounts until they turn it on in Settings, and any account can turn it off there): the email addresses and phone numbers a customer that has it on sends with its visitor checks go to this provider too, and our answer carries the provider’s score for each, the names of its reasons and a few facts (whether an address accepts mail, when its domain was registered, on how many sites it was seen, in how many known data breaches it appears; a number’s validity, line type and carrier); each counts toward the same daily number. 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 | Only the email address or phone number the account holder types and, for a customer that has email and phone intelligence on, the email addresses and phone numbers it sends with its visitor checks: no account, API-key, evaluation or visitor records. Maskbreak stores neither the value nor the answer of a console check, only how many checks the account made that day and, since 5 November 2026, how many unanswered checks were given back to it that day (kept 3 days); of an API check it stores the scores and the reason names on the evaluation record, never the address or the number. The provider’s name, address and processing location are given to customers on request under the DPA, as confidential information (support@maskbreak.com) | United States |
| Sift (Sift Science, Inc.), since 23 October 2026 | Login protection: on for every account since 23 October 2026 (a customer can turn it off in Settings; it processes nothing until the customer’s server sends a login or an account event with its own account ID), each login attempt its server sends us as a login (a visitor check with the customer’s own account ID) goes to Sift, and we return Sift’s account-takeover score with our answer; the account events that customer reports the same way (a signup, a password change, a verification, a logout, an account-detail change) go to Sift too, with no score in return. One Sift account serves every customer that uses login protection, so Sift’s scores for one customer’s logins learn from the logins of all of them. Sift’s own service privacy notice says it also uses the data it receives to improve its services, including the models behind its scores; for that use it acts under its own terms | For each such login: keyed one-way hashes of the customer’s account ID, of its session ID (or of our device key) and of our device key, made with a key that differs for every Maskbreak customer (never the identifiers themselves); whether the password was right; the end user’s IP address and browser user-agent string; the end user’s email address when the customer sends one; the customer’s website domain; our own result for the visit (decision, risk score, network and browser flags, VPN service name, IP country). Nothing from a customer whose server sends no login or account event or that has turned login protection off, nothing sent with a test key or from the console, and no account, API-key or billing records. Of Sift’s answer Maskbreak stores, on the evaluation record of a login, the score, the names of Sift’s reasons, Sift’s pseudonymous user ID for the account (the keyed hash) and the customer’s own report of the login as the real user or a takeover (sent to Sift as a label on that pseudonymous user); a high score also leaves the reason code account_takeover_risk | United States |
| PostHog (PostHog, Inc.) | Product analytics and session recordings on public pages, /signup and the dashboard since 23 September 2026, without a consent prompt; skipped under Global Privacy Control, Do Not Track and Save-Data. Never on sign-in, reset, verification, invitation, settings, security, members, admin or result pages. The library is served from maskbreak.com at a fixed version; PostHog receives data, never runs code on our pages. | Pages viewed, clicks, referrer, browser/device type, IP address, a random browser identifier, page-speed measurements, and session recordings with every form field, the visitor’s own network readouts and all dashboard text masked. Since 17 October 2026, on public pages and /signup only, also clicks that changed nothing on the page and errors in the page’s own scripts, with addresses, emails and key-like strings removed. Not supplied with account, API-key or evaluation records. Provider privacy policy | EU (PostHog EU Cloud, Frankfurt); PostHog’s DPA permits processing elsewhere, including the United States |
| Sentry (Functional Software, Inc.) | Error reports from Maskbreak’s server software since 24 September 2026, sent only when the server hits an unexpected error. Server-side only: no Sentry code on our pages and nothing stored in visitors’ browsers. Errors only — no performance tracing, profiling, log forwarding or session replay. | Error type, message and stack trace, runtime details, 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 segments replaced by placeholders, and, for up to 30 recent outgoing calls, only the method, status code and origin (scheme, host name and port; 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, secrets and tokens are removed before sending, so it is designed not to receive customer or end-user personal data; the removal is pattern-based, a strong safeguard rather than a guarantee. Sentry’s generative AI features are off, so error data is not sent to its AI sub-processors. Provider privacy policy | EU (Sentry EU region, Frankfurt); Sentry’s DPA permits processing in the United States |
Optional Google Sign-In. On /login Google’s sign-in client also loads by itself after the page has loaded (since 24 September 2026) to offer its “Continue as …” prompt (One Tap), except for browsers that send Global Privacy Control or Do Not Track. Also Google Workspace, which hosts our support@maskbreak.com mailbox and, since 22 October 2026, the Google Chat space our operations alerts are posted to and a shared drive (Google Drive) holding a second, encrypted copy of our nightly database backup. | OAuth identity assertion and sign-in request metadata when this option is used; on /login, the visitor’s IP address and browser details when the client loads, whether or not the prompt is used. Workspace: the emails sent to support@maskbreak.com (including relayed contact and programme forms) and our replies; customer end-user data only where a customer writes it into an email. Chat: our operations alerts, which can name an account by its email address. Drive: the full database (customer end-user data included), encrypted before upload with a key Google does not hold; each copy is moved to the drive’s trash after 25 days (after 30 days until 5 November 2026), every night by the backup job itself, and Google deletes it 30 days later | United States and other Google locations | |
| Have I Been Pwned | Password breach check via k-anonymity | 5-character SHA-1 prefix only — never the password | Global service; receives no personal data |
| flagcdn.com | Flag images in the console’s test panel, fetched by the account holder’s browser when a console test result is shown. Listed for transparency; it receives no customer end-user data | The account holder’s IP address and browser details, and the two-letter country code of the test result | Not published by the provider |
Fonts and the dashboard map are served from maskbreak.com. There is no chat widget and no advertising tag on our pages: the Widgo chat was removed on 30 September 2026 and Google Ads on 6 September 2026. The Auth0 tenant behind the former emailed sign-in link was deleted on 6 October 2026. See the Privacy Policy and Cookie Policy for what is stored in your browser.
Former providers
We no longer send these providers anything. Each may still hold data from the time we used it, as described.
| Provider | What it did | What it may still hold | Region |
|---|---|---|---|
| Railway | Application hosting and application logs, until 20 October 2026, when we shut our service there down | Application logs (request paths, error descriptions and security events), which Railway deletes within 30 days | United States (US East) |
| Turso | Primary database (managed libSQL), until 19 October 2026; the database was deleted and our account closed the same night | Only copies in Turso’s own backups, which follow its retention terms: account data and sessions (IP address and user agent), API keys, evaluation records (raw end-user IP addresses for up to 7 days, then a keyed hash), abuse-prevention counters, newsletter subscriptions | United States (AWS us-east-1, Virginia) |
| Resend | Email delivery, until 19 October 2026; our account was closed the same night | Only copies in Resend’s own backups, which follow its retention terms: email addresses and message content | United States |
| Amazon Web Services (S3) | Storage for the encrypted nightly database backups, until 16 October 2026 | The backups made up to 16 October 2026, full database snapshots encrypted at rest. A rule set to delete them within the 60-day limit was in place; the account is suspended and we are not restoring access to it, so we can no longer check or delete these copies ourselves | EU (Stockholm, eu-north-1) |
| Widgo (Widgo, Inc.) | AI chat on public marketing pages, from 8 September 2026 (opened by a click until 22 September) until its removal on 30 September 2026 | Historical chat transcripts, volunteered details and the visit data it received while loaded (IP, browser/device identifiers, page/referrer/campaign data, interaction timing), kept while needed for support or legal obligations; access and deletion requests remain available. Never supplied with Maskbreak account, API-key or evaluation records. Provider privacy policy | United States, EU and other locations in Widgo’s privacy policy |
| Crisp (Crisp IM SAS) | Live chat, until it was replaced on 8 September 2026 | Historical chat transcripts and metadata while needed for support or legal obligations; access and deletion requests remain available | EU (France) |
Change log
| Date | Change |
|---|---|
| 2026-11-06 | Added: a proxy-detection provider (listed by category; United States), for our own IP-lookup page only. Since 6 November 2026 the live check on maskbreak.com/ip-lookup measures the connection with this provider’s proxy check, and looks the visitor’s address up in its IP database, in place of the network-intelligence provider, which still serves the homepage and the API. It processes only visitors to that page of ours, never customer end-user data, so it is not a sub-processor of customers’ data and its addition needs no notice under the DPA; it is listed here for transparency. |
| 2026-11-06 | DNS lookups for the page check. Since 6 November 2026, the dashboard’s page check looks up the addresses of the name of the page an account holder enters, and of each name that page loads from, through Cloudflare’s public DNS resolver (1.1.1.1), so that a page, or a part of it, whose name points to a private network address is not opened. Cloudflare, already listed above for the page check and the resolver, receives only those names: no end-user data and nothing else about the account. No sub-processor was added, replaced or removed, and no provider receives customer end-user data it did not receive before, so the 30-day advance-notice clause does not apply. Privacy Policy §3 was updated the same day. |
| 2026-11-05 | Cloudflare’s public DNS resolver for script subdomains; Google Drive backup copies kept 25 days. Since 5 November 2026, when an account holder adds a subdomain for our script in Settings, and while it waits for its TXT record, our server looks up the name’s DNS records and the TXT record _maskbreak. followed by the name through Cloudflare’s public DNS resolver (1.1.1.1), so that a name whose DNS already leads to us is set up only for the account whose value is in that TXT record. Cloudflare, already listed above for these subdomains, receives only those names: no end-user data and nothing else about the account. Each encrypted backup copy in Google Drive, listed above, is now moved to the drive’s trash after 25 days instead of 30, so Google deletes it within 56 days, and the nightly backup job does this every night, also when its upload fails. The row of the email- and phone-intelligence provider now says that the daily count we keep also holds how many unanswered checks were given back to the account that day. No sub-processor was added, replaced or removed, and no provider receives customer end-user data it did not receive before, so the 30-day advance-notice clause does not apply. Privacy Policy §3 was updated the same day; DPA version 1.23 and Security Whitepaper version 2.15 (5 November 2026) describe these changes. |
| 2026-10-23 | Added: Sift (Sift Science, Inc.), for login protection (processing in the United States). Since 23 October 2026 login protection is on for every account (a customer can turn it off in Settings); it processes nothing until the customer’s server sends us a login attempt or an account event with its own account ID, which is that customer’s instruction to use it, and from then on each login attempt its server sends us as a login goes to Sift, which returns an account-takeover score that we put in our answer. Sift receives a customer’s personal data only once that customer’s server sends such a login or event, and never from one that has turned login protection off: keyed one-way hashes of its account and session identifiers and of our device key (never the identifiers themselves), whether the password was right, the end user’s IP address, browser user-agent string and, when the customer sends it, email address, the customer’s website domain and our own result for the visit. One Sift account serves every customer that uses login protection, so Sift’s scores learn from all of their logins, and Sift’s own service privacy notice says it also uses the data to improve its services. This entry is the notice under DPA §6: nothing of a customer’s reaches Sift unless that customer sends a login or an account event, which is its instruction to use Sift for its logins, or after it turns login protection off, and a customer may object on reasonable data-protection grounds until 22 November 2026 (support@maskbreak.com). Privacy Policy §1, §3, §5 and §5.2 and the Cookie Policy were updated in the same change; DPA version 1.19 (Annex A and Annex C) and Security Whitepaper version 2.10, published the same day, list it too. |
| 2026-10-23 | The email- and phone-intelligence provider now also scores addresses and numbers sent with API checks; Sift also receives account events. Since 23 October 2026 email and phone intelligence is on by default for accounts created from that day and off for older accounts until they turn it on in Settings (any account can turn it off there); when it is on, the email addresses and phone numbers that customer sends with its visitor checks go to the email- and phone-intelligence provider already listed above (by category; processing in the United States), which returns a risk score, its reason names and a few facts that we put in our answer and keep on the evaluation record; we never store or log the address or the number, and each check counts toward the plan’s daily number. The provider receives nothing from a customer that has it off, nothing until an email address or a phone number arrives with a check, and nothing sent with a test key or from the console’s own checks. The same day, a customer with login protection on can also report an account’s signups, password changes, verifications, logouts and account-detail changes; each goes to Sift, listed above, as that event with the same data as a login and no score in return. Both are a change to the processing of an existing sub-processor and this entry is the notice under DPA §6: nothing of a customer’s reaches either provider unless that customer has the feature on and sends the data it scores (its instruction to use it), and a customer may object on reasonable data-protection grounds until 22 November 2026 (support@maskbreak.com). Privacy Policy §1, §3 and §5 were updated in the same change; DPA versions 1.20 and 1.21 (Annex A and Annex C) and Security Whitepaper versions 2.11 and 2.12, published the same day, describe both; 1.21 and 2.12 state the defaults. |
| 2026-10-22 | Google now also holds an encrypted backup copy; Google Chat alerts; logs kept 30 days. Since 22 October 2026 the nightly backup job also encrypts each database copy, with a key only Maskbreak holds, and stores it in a shared drive in our Google Workspace (Google Drive), so that the backups do not depend on one provider. The copy includes the end-user data customers send us, so this adds Google as a sub-processor of customer data; Google holds the encrypted file only. Each copy is moved to the drive’s trash after 30 days and Google deletes it 30 days later, within the unchanged 60-day commitment. This entry is the notice under DPA §6; the copy started the same day, and a customer may object on reasonable data-protection grounds until 21 November 2026. Our operations alerts are also posted to a Google Chat space in the same Workspace; they concern Maskbreak’s own operations, not the end-user data customers send us. Cloudflare, already listed above, also keeps a copy of our server’s application logs for 30 days in R2, in its EU jurisdiction (its hosting keeps them 7 days, as before): a change to the processing of an existing sub-processor. DPA versions 1.17 and 1.18 and Security Whitepaper versions 2.8 and 2.9 (22 October 2026) say so. |
| 2026-10-21 | Page reorganised; no provider added or removed. The list of current sub-processors now shows only the providers we use today. Railway, Turso, Resend, Amazon Web Services, Widgo and Crisp, which receive nothing from us any more, moved to their own table of former providers, with what each may still hold. The Cloudflare row now lists each service it runs for us, says that its Containers run our application server, which handles all traffic and all stored data, and gives the server’s region. The PostHog row now names the page-speed measurements, clicks that changed nothing and script errors it has received since 17 October 2026, which the Privacy Policy §5 and the Cookie Policy §2.5 already described, and the database’s own 30-day history (Cloudflare D1 Time Travel). DPA version 1.15 and Security Whitepaper version 2.7 (21 October 2026) list the former providers the same way and describe that history. No sub-processor was added, replaced or removed, so the 30-day advance-notice clause does not apply. |
| 2026-10-20 | Application hosting moved to Cloudflare. Our application server now runs on Cloudflare (Containers, Eastern North America), already listed above, which receives all traffic to the website and API, as Railway did, and keeps the application logs for 7 days. We shut our Railway service down the same day; the logs Railway kept are deleted within 30 days under its own retention. A customer may object to this change on reasonable data-protection grounds until 19 November 2026 (support@maskbreak.com). Cloudflare also runs the dashboard’s page check. Cloudflare, already listed above, now also opens, once, a page address an account holder enters in the dashboard’s setup screen (Browser Run) and tells our server what it saw of our script there. It receives the page address only: no end-user data, and we keep neither the address nor the result. Cloudflare also serves our script from customers’ own subdomains (custom hostnames), when an account holder adds one in Settings: it receives that name, issues its certificate, and passes requests to it to our server as it does for maskbreak.com. No new sub-processor was added: Cloudflare, already listed, took over hosting from Railway and runs the two new features, so this entry was published on the day of these changes rather than 30 days before them, and the right to object above applies to all three. DPA version 1.14 and Security Whitepaper version 2.6 (20 October 2026) describe them, with the database and email moves of 19 October. |
| 2026-10-19 | Email delivery moved to Cloudflare. Cloudflare, already listed above for the CDN, Workers and the backups, now also delivers our email through its Email Service (verification codes, password resets, security notices, form receipts, setup emails, monthly summaries and the newsletter). It receives what Resend received: the recipient’s address and the message. Resend, which delivered our email until then, was removed the same day and is listed above as a former provider. The primary database moved to Cloudflare too: since the same evening it is Cloudflare D1 (United States, Eastern North America), which our server reaches only through a Worker, and it holds what Turso held. Turso, the database until then, was deleted with our account the same night, and our Resend account was closed too; copies either may still hold in its own backups follow its retention terms. Both add a purpose to an existing sub-processor rather than a new one; if you object, tell us at support@maskbreak.com by 2026-11-18 (DPA Section 6). |
| 2026-10-18 | Added: an email- and phone-intelligence provider (listed by category; processing in the United States). Since 18 October 2026 the console offers an email and phone check: an account holder types one email address or one phone number, our server sends that value to this provider and shows the account holder a summary of the answer, with a daily limit of checks per account. The provider receives only the typed value, never account, API-key, evaluation or visitor records, and Maskbreak stores neither the value nor the answer. Its standard terms may also allow it to use the values it is asked about for its own purposes, such as the fraud history it keeps across its customers. The check was switched on the same day as this entry, not 30 days after it: a customer may object to this addition on reasonable data-protection grounds within 30 days of this entry, as DPA §6 provides (support@maskbreak.com), and the check is used only when an account holder starts one. The provider’s name, address and processing location are given to customers on request, as confidential information. Privacy Policy §1, §3, §5 and §5.2 were updated in the same change; DPA version 1.13 (Annex C) and security whitepaper version 2.5, published the same day, list it too. |
| 2026-10-17 | Backups moved from Amazon Web Services to Cloudflare R2. The AWS account that held the encrypted nightly database backups was suspended between the backups of 16 and 17 October 2026, and the backup of 17 October failed. To keep a working backup, the nightly job now uploads to Cloudflare R2 in Cloudflare’s EU jurisdiction (data stored in the EU). Cloudflare was already on this list for the CDN, firewall and Workers; it now also stores the backup copies, encrypted at rest, and a rule removes each copy after 40 days, within the unchanged 60-day commitment that the daily audit checks. The GitHub Actions job is unchanged apart from where it uploads. The copies made up to 16 October 2026 stay in the suspended AWS account, where a rule set to delete them within the 60-day limit was in place; we are not restoring access to it, so we can no longer check or delete them ourselves, and AWS stays on the list for those copies. A customer may object to this change on reasonable data-protection grounds within 30 days of this entry, as DPA §6 provides. Privacy Policy §3 and §5, Cookie Policy §3, the trust page and the responsible-disclosure policy were updated in the same change; DPA version 1.13 and security whitepaper version 2.5 (18 October 2026) describe the move too. |
| 2026-10-11 | Documents brought in line with this list; no sub-processor was added, replaced or removed, so the 30-day advance-notice clause does not apply. DPA version 1.12 Annex C no longer lists Auth0 (deleted 6 October 2026) and lists Widgo for legacy records only (chat removed 30 September 2026); security whitepaper version 2.4 does the same and adds Stripe, which was already on this list. On this page, the Cloudflare row now names its Workers (an uptime check and an edge answer for direct requests) instead of a scanner verdict our pages no longer request from the edge, and the AWS row says that the daily backup-retention audit first passed on 10 October 2026. The Google row now also names Google Workspace, which has hosted the support@maskbreak.com mailbox all along; nothing about its use changed, and the Privacy Policy §1.2 and §5 and the Cookie Policy §3 name it too. |
| 2026-10-06 | Auth0 taken off the list above: we deleted the Auth0 tenant on 6 October 2026, and with it the user record it held for each person who used the former emailed sign-in link. Nothing is sent to Auth0 any more; any copies left in Auth0’s own backups are removed under Auth0’s retention terms. Nothing new was added, so the 30-day advance-notice clause for sub-processors does not apply. Privacy Policy §5 and §5.2, Cookie Policy §3 and §5, the trust page and the responsible-disclosure policy were updated in the same change; DPA Annex C and the security whitepaper keep their dated text until their next versions. |
| 2026-10-05 | Auth0 removed: the emailed sign-in link (“Email me a sign-in link”) was retired on 5 October 2026 and no page or server route contacts Auth0 any more. It moves to the list above as a legacy-records provider: the user records it created for people who used the link stay in the Auth0 tenant until it is closed. Accounts created with the link keep working through Google, GitHub, a passkey or a password set with Forgot password. Nothing new was added, so the 30-day advance-notice clause for sub-processors does not apply. Privacy Policy §4 and §5 and Cookie Policy §2 and §3 were updated in the same change; DPA Annex C and the security whitepaper keep their dated text (“where offered”) until their next versions. |
Earlier entries, July to September 2026 (19)
| Date | Change |
|---|---|
| 2026-09-30 | Added Stripe (payments, subscriptions, invoices and receipts), because Maskbreak now offers paid plans. They are sold through Stripe’s Managed Payments, so Stripe (shown as Link) is the merchant of record and acts as an independent controller for the checkout and payment. Stripe processes only the billing data of Maskbreak’s own account holders who choose a paid plan: the account’s email address and plan, the payment and billing details they enter on Stripe’s hosted checkout and billing-portal pages, and the IP address and browser details of the device used there. Card details go straight to Stripe and never reach our servers, and no Stripe script runs on maskbreak.com. It never receives customer end-user or evaluation data, so the 30-day advance-notice clause for sub-processors that process customer data does not apply, and it is not added to DPA Annex C. The Privacy Policy §1.1, §2.1, §3 and §5 and the Terms of Service Sections 4 to 6 were updated in the same change. The same day, the Widgo chat was removed from every page: it no longer loads, our Content Security Policy no longer allows its hosts, and Widgo keeps only the historical chat and visit records it already holds (legacy records, as for Crisp). Removing a provider needs no advance notice; the Privacy Policy §1.2, §2.1 and §5, the Cookie Policy §2.4 and the Trust Center were updated. |
| 2026-09-28 | Correction: processing regions. The primary database (Turso) is in the United States (AWS us-east-1, Virginia), not the EU as DPA Annex C stated since the DPA was first published; application hosting (Railway) is in the United States (US East since 2026-09-23, US West before), not “EU / US”; the Auth0 tenant is in the United States. Nothing moved: these rows were wrong. This list now has a Region column, the network- and device-intelligence providers are shown as United States, and DPA Annex C (DPA version 1.10) states the same regions. Transfers continue under DPA Section 10. The Privacy Policy §5 and §5.2, the Cookie Policy §5, the security whitepaper and the trust page were corrected in the same change. |
| 2026-09-28 | Completeness correction: GitHub Actions. Since July 2026 our nightly database backup job has run on GitHub-hosted runners: for a few minutes each night it reads the full database (including evaluation records with raw end-user IP addresses under 7 days old), compresses it and uploads it to AWS S3 in Stockholm. GitHub was listed for sign-in only, so this processing was missing from this list and from DPA Annex C; both now include it. Like the 2026-07-18 entry, this corrects the published list for infrastructure that was already live; no new processing starts with this entry. The backup copy is encrypted at rest in S3. |
| 2026-09-28 | Corrections to sign-in rows. GitHub Sign-In and the Auth0 emailed sign-in link have been offered in production since at least 2026-09-24 (the exact switch-on date was not recorded); the rows that said GitHub was not enabled were out of date. The Google row now also describes the One Tap prompt that /login has loaded automatically since 2026-09-24, which sends Google the visitor’s IP address and browser details whether or not it is used (already stated in Privacy Policy §5 and Cookie Policy §3 on that date). Added flagcdn.com, which serves the flag images in the console’s test panel, for transparency; it receives no customer end-user data. |
| 2026-09-28 | Clarified the network- and device-intelligence providers and how notices are given. Their row now lists everything they process (IP address, encrypted network token, browser/device characteristics, pseudonymous device identifiers and security signals, not only “network metadata”), their region (United States), and that their standard terms may also let them 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); DPA Annex A and Annex C no longer call their processing “transient”. Their names, addresses and processing locations are given to customers on request under DPA Section 6. Sub-processor change notices are given by a dated entry in this change log at least 30 days before a new sub-processor that processes customer data goes live (DPA Section 6, version 1.11). Earlier versions offered email notices to customers who had subscribed, but there was never a way to subscribe; version 1.10, published earlier the same day, said notices would be emailed to account owners, and version 1.11 replaced it. |
| 2026-09-24 | Added Sentry (server error monitoring, Sentry EU region, Frankfurt) to this list and DPA Annex C (DPA version 1.9). When Maskbreak’s server hits an unexpected error it sends Sentry the error, its stack trace, runtime and release details, the request method and path, and the method, status code and origin of recent outgoing calls; request headers, cookies, bodies, query strings, IP addresses, email addresses, API keys, secrets and tokens are removed on our server first, including from error messages. It runs only on our server, never in a visitor’s browser, and sends errors only (no tracing, profiling, logs or replay). It is designed not to receive customer end-user data (evaluation records, end-user IP addresses or device identifiers), so we list it for transparency and have not treated it as a sub-processor that processes customer data under the 30-day advance-notice clause. The removal is pattern-based, a strong safeguard rather than a guarantee; anything it missed expires under Sentry’s retention (30 days on its free Developer plan; up to 90 days on paid plans and during a trial). Privacy Policy §2.1, §3 and §5, Cookie Policy §3 and §5, the trust page, the security whitepaper and the responsible-disclosure policy were updated in the same change. |
| 2026-09-23 | Added PostHog (product analytics and session recordings, PostHog EU Cloud) to this list and DPA Annex C (DPA version 1.8). It measures visits to maskbreak.com — public pages, /signup and the dashboard — from page load without a consent prompt; browsers sending Global Privacy Control or Do Not Track, or asking to save data, are not measured, and sign-in, reset, verification, invitation, settings, security, members, admin and result pages never load it. Form fields, the visitor’s own network readouts and all dashboard text are masked before anything is sent. It processes our own website and account holders’ usage as controller and is not supplied with customer API or evaluation records, so the 30-day advance-notice clause for data-processing sub-processors does not apply. Privacy Policy §2.1 and §5, Cookie Policy §2.3, §2.5, §3 and §5, the trust page and the security whitepaper were updated in the same change. |
| 2026-09-23 | Removed Upstash from DPA Annex C (DPA version 1.7). The application has not sent it any data since 2026-09-06 (see that entry), and the short-lived keys written before then have expired. |
| 2026-09-22 | Widgo chat now loads automatically on public marketing pages instead of behind a per-page consent notice, so the same public visit data reaches Widgo from page load rather than from a click. Nothing changed for sign-in, private account or result pages (no widget), for customer API or evaluation records (never supplied), or for session replay (still disabled). Browsers sending Global Privacy Control get a plain “Chat” button and Widgo loads only when it is pressed. Privacy Policy §4 and §5, Cookie Policy §2.4, the trust page and the security whitepaper were updated in the same change. |
| 2026-09-08 | Replaced new Crisp chat with consent-gated Widgo AI chat on reviewed public marketing pages. Replay is disabled; private/account pages offer email support. Widgo receives consenting visitors’ chat and visit data, not customer API/evaluation records. Historical Crisp support records are preserved. Updated privacy, cookies, DPA Annex C and security disclosures. This optional website service is distinct from processing customer end-user evaluations. |
| 2026-09-06 | Moved abuse-sensitive rate limits and email-send budgets into the existing application database using keyed hashes. The application no longer sends rate-limit keys to Upstash; previously written keys remain subject to their existing short expiry. No new sub-processor was added. Updated the Privacy Policy with the security records and cleanup schedule. |
| 2026-09-06 | Removed Google Ads measurement from public pages, signup, the dashboard, and shared page generators. Google Sign-In remains available. Corrected the current privacy, cookie, and security notices; earlier dated entries below describe historical use, not the current setup. Clarified same-tab chat continuation. No new sub-processor was introduced. |
| 2026-09-04 | Added Crisp (live chat). The chat button on every page loads nothing until it is clicked; from that click Crisp receives what the person types plus their IP address, browser details and current page. It never touches customer API or evaluation data, so the 30-day advance-notice clause for data-processing sub-processors does not apply. Privacy Policy §5 and Cookie Policy §2.4 and §3 were updated in the same change. |
| 2026-09-02 | Added Auth0 (emailed one-time sign-in link, where offered). The integration shipped on 2026-09-01 behind configuration, like GitHub Sign-In: Auth0 receives the account holder’s email address only when the option is enabled and used, and nothing otherwise. Completeness correction — the code landed before this list was updated. |
| 2026-08-29 | Clarified two rows without adding or removing anyone. GitHub: the sign-in integration exists in the codebase but no GitHub OAuth app is configured in production, so the option is not shown and GitHub receives no data; it stays on the list so that notice has already been given if it is enabled. Google: the row now also names the cookieless Google Ads measurement tag (Consent Mode v2, all storage denied) that public pages and the signed-in dashboard have loaded since 2026-07-19 and that Privacy Policy §5 and Cookie Policy §2.3 already disclose. The Privacy Policy, Cookie Policy, Terms, DPA and security whitepaper were corrected and re-dated in the same change. |
| 2026-08-02 | Added and removed Dreamdata (business-to-business marketing attribution) on the same day. It was live on public marketing pages for approximately 30 minutes. During that window its account-level component sent page URL, page title, canonical URL, referring URL and the requesting IP address to Dreamdata, which uses them to estimate the organisation a visit came from. Its visitor-level component was gated behind analytics consent, which this site does not grant — with one exception we want to be explicit about: the gate is read from Google’s consent framework, so a visitor whose browser blocked Google Tag Manager would have had the visitor-level component, including form tracking, initialise normally. It never ran on the console or on any signed-in page, and it received no customer API or evaluation data at any point. It has been fully removed; no Dreamdata code, endpoint or Content-Security-Policy entry remains. Recorded here for completeness rather than because any obligation attaches to a provider that is no longer used. |
| 2026-07-19 | Added GitHub (Sign-In only, OAuth) — an optional “Sign in with GitHub” for Maskbreak accounts. It touches only the account holder’s own OAuth identity assertion, never customer end-user evaluation data, so the 30-day advance-notice clause for data-processing sub-processors does not apply. Privacy Policy §5 and Cookie Policy §3 were updated in the same change. |
| 2026-07-18 | Added Upstash (rate-limit state) and Amazon Web Services / S3 (encrypted nightly backups). Both were already live infrastructure — this is a completeness correction to the published list, not a new-processor onboarding, so the 30-day advance-notice clause does not apply. Privacy Policy §5 and the security whitepaper were updated in the same change. |
| 2026-07-16 | Page published. List matches the sub-processors already disclosed in the Privacy Policy — no additions or removals. |
Getting notified
Sub-processor change notices are given by a dated entry in the change log above, at least 30 days before a new sub-processor that processes customer data goes live. Watch this page for them; changes are also summarised in the changelog.
Questions or objections: support@maskbreak.com.