---
title: "Privacy notice"
description: "What the server holds about you, what it never receives, and how to exercise your rights over it."
canonical: https://keepitlocal.app/privacy
last-updated: 2026-09-13
---

# Privacy notice

What the server holds about you, what it never receives, and how to exercise your rights over it.


Version 0.2 (draft). Last updated 11 September 2026.

This notice explains what KeepItLocal Redact for the web does with personal data, under
Articles 13 and 14 of the UK and EU General Data Protection Regulation. It describes the
service as it is actually built. Where a control is still being built, this notice says so
rather than describing it as finished.

## The short version

- The documents you redact are processed inside your browser tab. They are never uploaded,
  and there is no code path in the service that could receive them.
- When you export a redacted file, the server receives two SHA-256 checksums and a few
  counts, so that it can sign a certificate. It does not receive the file, the file name or
  any text out of it.
- The account data we do hold is small: an email address, a display name, session records,
  an audit trail and export counters.
- We count visits ourselves, on our own server, with a daily-rotating hash of your network
  address and browser that cannot identify anyone and is not kept in a form that could. No
  cookie is involved, no third-party script, no advertising. Crawlers are counted by name.
  The only cookies we set are the ones that keep you signed in, so there is no cookie banner.

## Who is responsible

The controller of the personal data described here is:

- KeepItLocal, [registered company name to be filled in]
- [registered address to be filled in]
- [company registration number to be filled in]

Contact for any privacy question or request: hello@keepitlocal.app.

We have not appointed a data protection officer. Our processing is not large scale, does not
involve regular and systematic monitoring, and does not involve special category data, so
Article 37 does not require one. Contact the address above instead. [Confirm with counsel.]

## What we hold, why, and on what basis

| Data | What it contains | Why we hold it | Lawful basis | Kept for |
| --- | --- | --- | --- | --- |
| Account email and name | Your email address, your display name, your avatar (either a generated pattern or the photo URL from your Google account), and a hash of your password if you set one | To create your account, sign you in, contact you about the service, and place you in a workspace | Article 6(1)(b), performance of the contract with you | The life of the account, then deleted with it |
| Session metadata | For each active sign-in: a hash of the session token (never the token), when it was created, when it expires, the browser user agent string, and the network address the session was created from | To keep you signed in, to show you your own active sessions, and to let you end a session you do not recognise | Article 6(1)(b) and Article 6(1)(f), our legitimate interest in account security | Idle timeout 1 day, absolute cap 14 days; expired records are purged on the next retention sweep |
| IP hashes | A keyed, truncated hash of the network address, kept where counting is all we need: the view log of a shared report link is stored this way, so we can tell you the link was opened without keeping who opened it. Elsewhere, on session and audit rows and on rate-limit keys, the address itself is still stored; see the open items | To count views without keeping an identifier, and to stop password guessing, sign-up abuse and scraping | Article 6(1)(f), our legitimate interest in keeping the service available and accounts secure | Rate-limit keys until their window closes, then the next retention sweep; the view log of a shared report 90 days |
| Audit rows | What happened (for example a sign-in, a failed sign-in, a role change, a plan change), who did it, in which workspace, against which target, when, from which network address and user agent, plus a small scrubbed metadata object | To detect and investigate misuse, to answer "who changed this", and to meet our accountability obligations | Article 6(1)(f), our legitimate interest in security and accountability | 365 days |
| Certificate hashes and counts | The SHA-256 of the original file, the SHA-256 of the exported file, the number of redactions applied, the page count, the engine version, the time of issue, and the account and workspace identifiers | To issue and later verify the export certificate that proves a file is the one that was redacted | Article 6(1)(b) | Life of the workspace; beyond the life of the account where the workspace continues, see "Certificates and erasure" below |
| Shared report metadata | If you share a redaction report: the report itself (file name, both checksums, counts, per detector tallies), an optional password hash, an expiry, and a log of when the link was opened | To serve the shared report link you created and to let you see whether it has been opened | Article 6(1)(b) | The report until you delete it or it expires; the view log for 90 days |
| Email delivery records | For each account email we attempt: the recipient's DOMAIN only, the subject line, the provider and the delivery status. No message body is ever stored, so a verification or reset link is never in this table | To confirm a message was attempted and to diagnose a delivery failure at a provider | Article 6(1)(f), our legitimate interest in the service working | 30 days |
| Early access requests | The email address and organisation you type into the early access form | To contact you when access opens | Article 6(1)(a), your consent | Until you ask us to remove it, or until the early access programme closes |
| Billing data held by Paddle | Paddle acts as merchant of record. Your name, billing address, tax status and payment instrument are held by Paddle, not by us. We hold the subscription reference, the plan tier and the renewal date | To sell and renew a paid plan | Article 6(1)(b) | The life of the subscription plus the period tax law requires of Paddle |

Billing is not live yet. Until it is, no billing data of any kind exists.

Providing the account email is a contractual requirement: we cannot create an account
without it. Everything else above is either produced by using the service or is optional.

## What never reaches us

Redaction happens in your browser through a WebAssembly engine. The document you open, the
pages we render for you, the text the detectors find and the file you export all stay in the
tab. Nothing in the service uploads them.

That is enforced, not promised. The page is served with a content security policy whose
`connect-src` directive is `'self'`, so the browser itself refuses to let the engine send
anything to any other origin, and every request it can make is one you can watch in your own
network panel.

When you export, the browser sends the certificate request described in the table above: two
checksums, a mark count, a page count and an engine version. A checksum cannot be turned back
into a document. One honest caveat: a checksum of a short or templated document can be
confirmed by someone who already holds a copy of that exact document, so it is a pointer
rather than an opaque value.

## Cookies and local storage

We set only cookies that are strictly necessary to provide the service you asked for, so
under the ePrivacy rules no consent banner is required and we do not show one:

- a session cookie that keeps you signed in
- a cookie recording which workspace you are currently working in
- a short-lived cookie during two-factor sign-in, and, during Google sign-in, the state,
  code-verifier and return-path cookies that make that exchange safe
- a separate session cookie for the administration console
- if you open a password-protected shared report, a cookie proving you passed that gate
- if you press the light or dark theme switch, a cookie holding that one word, so the page
  arrives already in your choice; it carries no identifier and we keep no record of it

Your light or dark theme choice is also kept in your browser's local storage. Visit counting
sets no cookie and stores nothing in your browser (see "How we count visits" below). We run
no advertising and no third-party tags.

## How we count visits

We count visits ourselves, on our own server, with no third-party service. When a page of the
public site or of the signed-in app is served, the server writes one row holding the page
address (every signed-in page is recorded as one bucket, never the page itself), the site you
came from (its host name only, and nothing when you came from within this site), a coarse
device class (desktop, mobile or tablet), a campaign tag if the link carried one, and a
visitor key. The visitor key is a hash of the day, your network address, your browser's
user-agent string and a secret held by the server, truncated to 32 characters. The address
and the user-agent string are hashed and discarded in the same moment; neither is stored. The
key changes every day, so the same person is a different visitor tomorrow, and it cannot be
reversed or joined to an account. No cookie is set and nothing is stored in your browser.

Requests from the automated crawlers of search engines and assistants are counted by the
crawler's name and are never counted as visitors.

Your browser also sends us, once per page, three page-speed measurements and, if a script on
our page fails, the class of the error (for example "TypeError"): never the message, the
file or anything about you.

These rows exist so that we know how many people and which crawlers read the site and whether
its pages perform. The lawful basis is Article 6(1)(f), our legitimate interest in running a
site we can see, which we consider proportionate because the row identifies nobody. They are
kept for 400 days and deleted by the retention sweep.

## Who else processes this data

We use a small number of sub-processors. Each one, what it is used for, what it receives and
where it runs, is listed on the [sub-processors page](/subprocessors). We will update that
page before adding a new sub-processor.

## International transfers

Our hosting region is the European Union. [Provider to be confirmed.]

Some sub-processors are outside the EEA and the UK. Where that is the case, the transfer is
made under the European Commission's standard contractual clauses and the UK international
data transfer addendum, together with the supplementary measures described on the
sub-processors page, which names the region and the transfer mechanism for each one.

## How long we keep things

Each category above says how long it is kept, and the periods are these: audit rows 365 days,
the view log of a shared report 90 days, email delivery records 30 days, export counters 400
days, visit counts 400 days, and expired sessions, tokens, invitations, export permits and rate-limit keys on the
next retention sweep. Deletion is carried out by that sweep, and each run is recorded. Until
a scheduler is provisioned the sweep is triggered by hand rather than nightly; see the open
items. The internal retention schedule holds the same numbers together with the
exceptions and who approved them, and it is available on request; if the two ever disagree,
this notice will be corrected.

A backup taken before a deletion still holds the deleted rows until that backup ages out of
its own retention window. A backup is never restored in order to bring deleted rows back.

## Certificates and erasure

An export certificate exists to let a third party check, possibly years later, that a file is
the file that was redacted. If a certificate disappeared when its issuer closed their account,
it would be worthless as evidence, so certificates outlive the account that produced them.

There is one exception, and it runs the other way. Certificates in a workspace that continues
without you outlive your account. Certificates in a workspace that is deleted along with your
account go with it, because that workspace's evidence is going too. If you are the recipient
of a certificate, keep the file you were given rather than relying on the link alone.

Today the signed payload includes the account and workspace identifiers alongside the two
checksums and the counts. We intend to remove them from certificates issued in future, so that
what remains identifies a document rather than a person; that change is not made yet, and this
notice will be corrected on the day it is. Certificates already issued keep those identifiers
and are retained under Article 17(3)(b) and (e). [Position to be confirmed with counsel.]

## Your rights

Under the GDPR you have the right to ask us for a copy of your data, to correct it, to have it
erased, to restrict or object to our processing of it, and to receive it in a portable form.
Where we rely on consent, you can withdraw it at any time without affecting what we did before
you withdrew it.

How to exercise them:

- **Erasure.** Settings, then Account, has a delete control that removes your account, your
  sessions, your two-factor secret and any workspace only you own. It asks for your password
  first, or, if you signed in with Google and have no password, for you to type DELETE to
  confirm. Either way the check is made on our side, not only in the browser.
- **Access and portability.** Settings has a download that produces a zip of what the server
  holds about your account: your profile, your active sessions, your workspace memberships,
  the certificates you issued, the reports you published, and the audit rows where you are
  the actor. Invitations you sent are not in it, because an invitee's address is their data
  rather than yours, and our record of an email we sent holds the recipient's domain rather
  than the address. It also states inside itself that no document content exists to export,
  because none ever reached us.
- **Rectification.** You can change your name and avatar in Settings. To change the email
  address on the account, email us; a self-service control is on the list.
- **Objection and restriction.** Email us, and say which processing you are objecting to.

We answer within one month, and we do not charge for it.

If you think we have handled your data badly, please tell us first. You also have the right to
complain to your supervisory authority. [Lead supervisory authority to be confirmed once the
place of establishment is fixed.]

## Automated decision-making

We do not make automated decisions with legal or similarly significant effects about anyone,
and we do not profile you. The detectors that find personal data inside your document run in
your browser and produce suggestions for you to accept or reject; nothing is decided about you
or by us.

## Where the data came from, if not from you

Article 14 applies in two cases:

- **A workspace invitation.** If a colleague invites you, we receive your email address from
  them so that we can send the invitation. If you do not accept, the invitation expires and is
  deleted on the retention schedule.
- **Google sign-in.** If you choose to sign in with Google, Google sends us your email
  address, whether it is verified, your name and a link to your profile photo. We ask for
  nothing else.

## Children

The service is built for professional use and is not directed at children. We do not knowingly
collect data about anyone under 16.

## Changes

We will update this notice when the service changes. The version and date at the top always
say which text you are reading, and material changes will be announced in the product before
they take effect.

## Open items before this notice is published

Recorded here so that no reader is misled by a control that is still being built:

- Session rows, audit rows and rate-limit keys still hold the network address itself rather
  than a hash of it. The retention windows bound how long, but the address is there.
- The nightly purge runs on request rather than on a schedule until a scheduler exists
  to call it. Each run is recorded either way.
- Hosting is Hetzner in the EU. Nightly backups and the restore drill are still open.
- The controller identity, the registered address, the supervisory authority and the data
  protection officer position are placeholders for counsel to fill in.