Privacy Policy

Karma sells itself partly on where your data does not go. That claim is only worth something if this page is specific, so it is: what is collected, what leaves your account, what we cannot see at all, and how long any of it lives.

Version 1.0 · Effective 26 August 2026 · Governing language: English

1. Who is responsible, and for what

File Master LLC, Serena app., office C13, Golden Sands, Varna 9007, Bulgaria, VAT 180842207, operates Karma.

There are two distinct relationships on this page, and they must not be confused:

1. Your account. For the data of the person who signs up — name, email, team membership, billing — we are the controller. Sections 2, 7, 8 and 9 cover this.
2. Your visitors. For the data Karma receives about people visiting your sites, you are the controller and we are your processor. We act on your instructions, which you give by configuring your account. Sections 3 to 6 cover this, and the Data Processing Agreement is the contract for it.

Your visitors have no relationship with us and will not think to look for this page. Telling them that a bot-detection processor sees their session is your obligation as controller, not ours. Section 3 exists so you can describe it accurately in your own privacy notice.

2. Account and organisation data

We collect, as controller:

• email address, and name if you give one;
• a password hash (Argon2id) — never the password itself;
• where you sign in with Google or GitHub: the identifier, email and display name that provider returns, and nothing else from your account there;
• organisation name, team members and their roles;
• session and security metadata: sign-in times, the IP address and user agent used, refresh token identifiers, and an audit log of administrative actions taken in the panel;
• your configuration: sites, allow and deny lists, gateway policy, capture rules.

3. What the snippet collects from your visitors

This is the section to copy into your own privacy notice. For each session on a site where you have installed the snippet, Karma receives:

• the network address the request came from, and the port and protocol version;
• transport fingerprints — the ordered set of TLS cipher suites, extensions and curves offered in the handshake, summarised as a JA3/JA3N hash, and the HTTP/2 settings frame. These describe the client software stack: which library or browser build made the connection. They do not describe the person and are not a cross-site tracking identifier;
• request headers including user agent, accepted languages and encodings, and referrer, plus the requested path on your site;
• behavioural signals — timing between events, the shape of pointer movement, how focus moves through a form, whether resources the page requested were actually executed. These are recorded as statistical properties of the interaction, not as a replay of what the visitor did;
• timestamps and the resulting verdict with the signals behind it.

A single page that fires three asynchronous requests is one session, and produces one verdict. Sessions from confirmed legitimate crawlers are identified and excluded from billing.

4. What we derive from an address

From the network address we derive the autonomous system number, the network operator and the country, using the public iptoasn dataset (CC0). The dataset is downloaded and used on our own infrastructure; no address is sent to a geolocation service to look it up.

Karma treats shared exit addresses — corporate NAT, mobile carrier CGNAT, VPN endpoints — differently from addresses that appear to be used by one party, precisely so that one person's behaviour behind a shared address does not condemn everyone behind it.

5. Field capture, if you switch it on

Field capture is off by default. If you enable it, you choose CSS selectors and a mode for each: not at all, presence only (whether the field had been filled), or the value itself.

• The snippet never transmits password fields.
• A value that passes a Luhn check and has the shape of a payment card number is replaced with a redaction marker before it is stored. We never hold a card number captured this way.
• Beyond those two, whatever you point value mode at, we will receive. A selector tells us nothing about what a field contains. You are the controller of that choice and of what your visitors are told about it.

Captured values are visible only within your own account, are never contributed to the shared pool, and are deleted with the rest of your tenant's data under section 14.

6. The shared reputation pool

Karma keeps a reputation base per account and a pool shared across accounts. Two independent switches control your relationship with the pool.

• Contributing to it is on by default. Observations about network addresses seen on your sites — the address, the signal-level facts about its behaviour, and when — are added to the pool. You can turn contribution off at any time in your Karma settings, on any plan including the free one. Detection on your own account is unaffected either way.
• Reading it is off by default and available from the Protect+ plan upwards.

What is never contributed:

• your URLs, page content, or which of your pages an address visited;
• anything captured under section 5;
• your customers' identities, account identifiers or form contents;
• anything that identifies you as the source of an observation. Other accounts see that an address has a reputation, not who reported it.

A network address is personal data under the GDPR. Contributing it to a cross-tenant pool is a disclosure, and as controller you need a basis for it — ordinarily legitimate interests in preventing automated abuse, which is the basis Recital 49 contemplates. If you would rather not make that assessment, turn contribution off; nothing else about your account changes.

7. Billing data

We do not see or store card numbers. Payments are handled by the provider you choose at checkout, which collects the payment details directly.

We store: which plan you bought, the amount, the currency, the provider, the provider's transaction identifier, the status, timestamps, and — where you enable auto-renewal — an opaque token the provider gives us to charge that same method again. The token cannot be used anywhere but with that provider.

Invoices and records are kept as long as accounting law requires.

8. This website, cookies and analytics

• Strictly necessary cookies only for the panel: session and refresh tokens, your language and theme preference. No advertising cookies, no cross-site tracking.
• Analytics. The marketing site uses Google Analytics to count visits and understand which pages are read. It is loaded through a first-party script path and set to anonymise addresses. It does not run in the authenticated panel.
• No third-party embeds in your pages. The Karma snippet loads from our domain, sets no cookie in your visitors' browsers, and does not place an iframe in your page. This is the difference from a CAPTCHA and it is deliberate.

9. Support correspondence

If you email us, we keep the correspondence and whatever you include in it, so we can answer and refer back to it later. Please do not paste your visitors' personal data into a support ticket; describe the case and point us at an identifier in your panel instead.

10. What we do not collect

• Passwords typed by your visitors, in any mode.
• Payment card numbers — neither yours nor your visitors'.
• The content of your pages, your database, or your application's own logs.
• A cross-site identifier for your visitors. Karma has no cookie, no browser storage and no persistent device identifier in the visitor's browser. It scores what a session does and what address it came from — nothing follows the person to the next site.
• Special-category data as defined by Article 9 GDPR. The service is not designed for it and you must not instruct us to collect it.
• Anything from your visitors that we then sell, rent, or use for advertising. There is no advertising business here to feed.

11. Legal bases

For your visitors' data you determine the basis, not us. We process it on your documented instructions under the DPA.

12. Sub-processors and recipients

Payment providers and OAuth providers act as independent controllers for what they collect directly from you; their own policies apply to that. The current list of sub-processors for your visitors' data is Annex 3 of the DPA, and we give notice before adding to it.

We also disclose data where the law compels it. Where we are legally permitted to tell you first, we will.

13. International transfers

Verdict processing and storage happen on infrastructure in the European Union. Where a recipient in section 12 is outside the EEA, the transfer relies on the European Commission's Standard Contractual Clauses, on an adequacy decision, or on Article 49 where the transfer is necessary to perform the contract you asked for — a payment you initiated, for instance.

14. Retention

15. Security

• Everything in transit is over TLS. The snippet will not send signals over plain HTTP.
• Passwords are hashed with Argon2id; API keys are stored hashed and shown once.
• Tenant data is separated at the database level by row-level security, so a query for one account cannot return another account's rows even if application code is wrong.
• Access to production is limited to staff who need it, and administrative actions are logged.
• Backups are encrypted and restores are tested.

No system is perfectly secure. If we become aware of a breach affecting personal data, we notify the supervisory authority and affected customers as required, and under the DPA we notify you without undue delay so you can meet your own obligations.

16. Your rights, and your visitors' rights

As a customer you may request access, rectification, erasure, restriction, portability, or object to processing based on legitimate interests. Write to the address in section 18. We answer within one month and do not charge for a reasonable request. You may also complain to your supervisory authority; in Bulgaria that is the Commission for Personal Data Protection.

If you are a visitor to a site protected by Karma and want to exercise a right over data collected there, contact that site's operator: they are the controller and we cannot act on their data without their instruction. If you tell us which site it was, we will pass your request on and tell you we have done so.

17. Changes

We may update this policy. Material changes are announced by email or in the panel at least 30 days before they take effect, and the version and date at the top always reflect the current text.

18. Contact

File Master LLC · Serena app., office C13, Golden Sands, Varna 9007, Bulgaria · VAT 180842207
Email: tech.support@recoverytoolbox.com

See also the Terms of Service and the Data Processing Agreement.