HideFirst Privacy Statement
Effective date: [EFFECTIVE DATE]
This statement explains what personal data HideFirst handles, why, on what legal basis, for how long, and what rights you have. It covers our website, the account service (account.hidefirst.com), the HideFirst browser extension and the HideFirst API (api.hidefirst.com), including the JavaScript SDK and Python helper when they talk to the API.
1. Who we are
The controller is HideFirst, Inc., a Delaware corporation, [REGISTERED ADDRESS].
- EU establishment / representative (GDPR art. 27): [EU REPRESENTATIVE / EU ESTABLISHMENT]
- Privacy contact: [privacy@hidefirst.com]
2. Two roles
The role we have depends on the data.
(a) We are the controller for: account data, billing data, usage counts, technical logs, website visits and support e-mail. We decide why and how this data is processed. Section 4 describes it.
(b) We are the processor for the number payloads that our business customers send through the API. A payload is the set of number rows the customer's SDK or extension derives from the customer's text (see section 3). The customer decides why the payload is sent; we process it only to return scores, on the customer's instructions, under the data processing agreement (DPA, [DPA URL]). If you are a person whose data appears in a customer's documents, your first contact is that customer.
How this applies to each way of using HideFirst:
- Business customer using the API or SDK. The customer is the controller of its documents and of the payloads derived from them. HideFirst is its processor, under the DPA. HideFirst is controller of the customer's account, billing, usage and log data.
- Extension used under an organisation's account. The organisation is the controller of what the extension processes on its users' behalf. HideFirst is its processor for the payloads, and controller of the account and usage data described in this statement.
- Self-employed professional who signs up on their own. The same as a business customer: you are the controller of your documents and the payloads derived from them, HideFirst is your processor for the payloads under the DPA, and controller of your account, API key, usage counts and technical logs. Payloads are processed transiently to return scores and are never stored. HideFirst does not offer the Services to consumers.
3. What we do not process
- Your document text. The text you type, paste or send never reaches HideFirst. The SDK or extension turns it into number rows on your device.
- Your alias book. The map from real names to placeholders stays on your device, encrypted. We never receive it.
- Your browsing history. The extension does not collect it.
- The content of the chat sites (chatgpt.com, claude.ai, gemini.google.com), other than the derived number rows described below.
What the API does receive, honestly: for each word, number rows describing it (case, length bucket, digit and punctuation flags, rule flags, position, punctuation distances), the id of one of 200 common function words or of one of about 33,600 certified common words, document-local group numbers, about 40 per-document style columns, and the order and count of tokens. It never receives letters, hashes of words or character offsets. The common-word lookup itself is blinded (OPRF, RFC 9497), so during the lookup the server learns neither the word nor whether it is listed. For a word that is on the list of about 33,600 certified common words, the client then sends that word's id in the number rows, so the server does see which common word it is. Names and other words not on the list are sent as 0.
These number rows are not the text, but they are not anonymous either. Some of them (for example common words, which reach the server as an id that stands for the word, and the per-document style columns) could, in some cases, allow a determined analyst with a server's view to infer some names or to match a document to a public copy. That is why we do not store payloads and why we treat them as personal data, handled under the DPA, rather than as anonymous data.
4. What we process as controller, and why
| Purpose | Data | Legal basis | Retention |
|---|---|---|---|
| Create and run your account; sign you in | E-mail, password hash, display name, locale, organisation and memberships, roles, invitations, session tokens (stored hashed; no user agent recorded), OAuth codes and tokens | Art. 6(1)(b) contract | Life of the account, then [RETENTION: 30 days after closure] |
| Issue and manage API keys | API keys (signed tokens; revocable); the extension's sign-in issues a 24-hour key | Art. 6(1)(b) contract | Until revoked or expired, then [RETENTION: 30 days] |
| Metering and plan limits | Usage counts per key per hour (requests, tokens, OPRF elements) and per account per day (documents, characters). These carry no content. | Art. 6(1)(b) contract; art. 6(1)(f) legitimate interest in metering fairly | [RETENTION: 13 months] |
| Security, abuse prevention (including attempts to copy or extract our models), reliability | Technical logs: method, path, status, token count, timing, per-key counts. Usage signals per API key and hour, computed from request metadata only: request volume, request sizes (number of words), counts of short requests and of invalid requests, requests for detailed label scores, and common-word lookup alarms, and the copy-detection flags computed from these counts. No payload, no response content, nothing derived from the content of a request. Rate-limit and OPRF-lookup counters. | Art. 6(1)(f) legitimate interest in securing the service, preventing abuse and protecting our models | 30 days |
| Proof of acceptance of the Terms and the DPA | Account and organisation ids, the version accepted, time, client IP address | Art. 6(1)(f) legitimate interest in proving the contract and defending claims; art. 6(1)(c) where the law requires the record | Life of the account plus 5 years; the IP address shortened after 90 days |
| Account security events (audit log) | Time, organisation and account ids, the action and its outcome, the client IP address, and the ids of what was acted on (no names, e-mail addresses or content). Events: sign-up, sign-in (successful and failed), sign-out, password changes and resets, account and organisation deletion, invitations, role and membership changes, API key creation and revocation, extension sign-in and token events, operator actions, unusual-usage alerts. After an account is deleted, its events remain with ids only | Art. 6(1)(f) legitimate interest in securing accounts, investigating incidents and keeping evidence of access | 12 months |
| Transactional e-mail | E-mail address and message content (confirmations, password resets, invitations), sent through Resend | Art. 6(1)(b) contract | [RETENTION: per Resend delivery log, 30 days] |
| Billing, once paid plans launch | Subscription status, billing contact, invoices; payment is handled by Stripe | Art. 6(1)(b) contract; art. 6(1)(c) legal obligation (invoicing, tax and accounting records) | [RETENTION: 10 years, Belgian VAT and accounting rules, where they apply] |
| Support | Your e-mail address and what you write to us | Art. 6(1)(b) contract or art. 6(1)(f) legitimate interest in answering you | [RETENTION: 2 years after last contact] |
| Website | Server logs of visits (IP address, page, time) at [WEBSITE HOST]; strictly necessary session cookies on the account site | Art. 6(1)(f) legitimate interest in running and securing the site | [RETENTION: 30 days] |
| Legal claims and obligations | Records needed to establish or defend a claim, or to answer an authority | Art. 6(1)(c) or (f) | [RETENTION: until the claim is closed] |
Where we get your data (art. 14). Most of this data comes from you. If an organisation's administrator invites you to an account, we receive your e-mail address from that administrator, and we use it to send the invitation and to create your account if you accept.
The per-organisation customer key and word table used for the OPRF lookup belong to the organisation's account and are kept for the life of the account.
Drafting note: the retention figures are proposals, not facts from the product. Confirm each against what is actually configured before publishing.
5. The payload (processor role)
When the API scores a payload it works statelessly: nothing from the payload is stored, and the response is not logged. Logs hold counts and timings only. We do not sell payloads, do not use them to train models, and do not read them. Details are in the DPA.
6. Recipients and sub-processors
| Recipient | Role | Purpose | Location |
|---|---|---|---|
| Hetzner Online GmbH | Processor (and sub-processor for payloads, under the DPA) | Server hosting (API and account service) | Falkenstein, Germany |
| Cloudflare | Provider | DNS only; API and account traffic does not pass through Cloudflare | [CLOUDFLARE: confirm, DNS queries only] |
| Resend | Processor | Transactional e-mail | [RESEND REGION] |
| Stripe | Processor / independent controller [confirm] | Payments, when paid plans launch | [STRIPE ENTITY] |
| [WEBSITE HOST] | Processor | Website hosting | [LOCATION] |
We also disclose data when the law requires it, or to professional advisers under confidentiality.
7. International transfers
The API and account service are hosted in Germany. For the data we control, a transfer to a third country happens only when a provider outside the EEA (Resend, Stripe, Cloudflare, possibly the website host) receives data. We rely on [SAFEGUARD: EU-US Data Privacy Framework certification of the recipient / Standard Contractual Clauses with supplementary measures], and you can ask us for a copy of the safeguard through the privacy contact. For payloads, where we are the processor, transfers are governed by the transfer clause of the DPA.
8. Cookies and automated decisions
The account site uses only strictly necessary session cookies. We use no advertising cookies and no analytics cookies [confirm for the website]. The extension has no analytics and no telemetry.
The API returns a probability that a word should be masked. A person or a customer's own policy then decides what to do with it. It is not a decision with legal or similarly significant effects on any individual, and we take no such decisions.
We do not sell data. We do not train models on customer payloads.
9. Limited Use (Chrome extension)
The use of information received from Chrome APIs and user data will adhere to the Chrome Web Store User Data Policy, including the Limited Use requirements. In practice: we use the data only to provide the extension's single purpose (hiding names and identifiers before text is sent to a chat site, and restoring them in the answer); no human reads it except with your consent, for security, or where the law requires; we use it for no advertising; and we transfer it only to provide the single purpose, for security, to comply with the law, or as part of a merger, acquisition or sale of assets, which requires your explicit prior consent.
10. Your rights
You can ask us for access, rectification, erasure, restriction, portability of your data, and you can object to processing based on legitimate interest. Where processing rests on consent, you can withdraw it at any time. Write to [privacy@hidefirst.com]. We answer within one month. We may ask you to prove who you are.
If your data is in a payload that a customer sent, we may refer you to that customer, who is the controller, and we will help it answer you. Because we store no payloads, we usually cannot find your data in them.
You may complain to the Belgian Data Protection Authority (Gegevensbeschermingsautoriteit / Autorité de protection des données), Drukpersstraat 35, 1000 Brussel, contact@apd-gba.be, or to the supervisory authority in your own member state.
11. Security
We protect data with encrypted transport, hosting in Germany, signed model bundles, revocable keys and rate limits, and we store no payloads. What we do and do not protect against is set out in plain terms on our security page ([SECURITY PAGE URL]).
12. Changes
We will update this statement when our processing changes. We will publish the new version with its date, and tell account holders by e-mail before a material change takes effect. Last updated: [EFFECTIVE DATE].
Terms of Service | Data Processing Agreement | Privacy Statement | Acceptable Use Policy