Privacy Policy

Last updated: 13 June 2026

BrightBlur is a photo sharing app built for groups that include children. Nurseries, schools, sports clubs, families. It exists because sharing photos of children through WhatsApp groups or Facebook is a privacy problem that everyone acknowledges and nobody fixes.

This policy explains what data BrightBlur collects, what it does with that data, and what it cannot do. We have tried to write it in plain English. Where a legal term is unavoidable, we explain it.

The short version

Faces in photos are detected on your device, pixelated permanently, and encrypted before they ever leave your phone. The server stores encrypted blobs it cannot read. Only people you have explicitly authorised can see a clear face. BrightBlur cannot see the faces. BrightBlur’s hosting provider cannot see the faces. A database breach would expose encrypted data that is useless without keys held only on users’ devices.

What happens when you create an account

You register with an email address and either a password or a passkey. During setup, BrightBlur generates a 12-word recovery phrase and, from it, your cryptographic keypair. Your master seed (the root of those keys) is wrapped — encrypted — using a secret that only your passkey can produce, and only the wrapped form is stored on the server, which cannot unwrap it. The recovery phrase is a separate way to regenerate the same keys; it is shown to you once. Write it down. BrightBlur cannot recover it for you.

What the server stores about your account:

• Your email address and a hashed password (scrypt — the plaintext password is never stored)
• Your BrightBlur identifier (a unique DID)
• Your public key
• Your wrapped master seed (which the server cannot unwrap without your passkey’s secret, and that secret never leaves your device)
• Passkey credentials, if registered

What the server does not store:

• Your plaintext password
• Your recovery phrase
• Your unencrypted private key

What happens when you upload a photo

1. Your device runs face detection locally, in your browser. No image data is sent to the server for detection.
2. You tag each detected face: assign it to a person, skip it (leave it pixelated), or mark it as safe to show.
3. Tagged and skipped faces are permanently destroyed in the base image: each face region is overwritten on your device with a coarse grid of averaged colour blocks, and the original pixels are never stored or transmitted. What remains is designed to defeat automated face recognition — it does not carry the detail an automated matcher would need to identify the person or reconstruct the original face. (It is not intended to stop someone who already knows the child from guessing from context such as clothing or setting; that is not what the blur is for.)
4. Clear face crops are encrypted individually, each to the cryptographic key of the person they belong to.
5. The pixelated base image is encrypted for the people the photo is shared with — you, and everyone connected to a face in it.
6. All encryption happens on your device. The server receives only encrypted data.

What happens with face recognition

BrightBlur uses on-device face recognition to suggest who is in a photo. It computes a numerical fingerprint for each detected face, then compares it against stored fingerprints of known people.

• Fingerprints are computed on your device using a neural network that runs in your browser. Nothing is sent to the server for comparison.
• Before a fingerprint leaves your device, it is encrypted to the person’s cryptographic key.
• The server stores only encrypted fingerprints. It cannot decrypt them.
• When you upload a new photo, your device downloads the encrypted fingerprints, decrypts them locally, and compares them against the new faces.

Face recognition is not perfect. It may suggest the wrong person. All suggestions require your confirmation before publishing. You can undo any automatic tag.

What the server can and cannot see

The server stores but cannot read:

• Base images (encrypted)
• Face crops (encrypted per person)
• Face fingerprints (encrypted per person)
• Captions and comments (encrypted)
• Group private keys (encrypted per user)

The server can read:

• Your email address, hashed password, and BrightBlur identifier
• Group names and membership lists
• Which photos are shared with which people
• Photo timestamps (captions themselves are encrypted)
• Access request statuses and notification metadata
• How many face fingerprints exist per person (but not their content)

In other words: the server knows the shape of your social graph (who is in which group, when photos were shared) but cannot see any face data, any photo content, or any biometric information.

Encryption

BrightBlur encrypts content with a hybrid scheme that combines a classical algorithm (X25519) with a post-quantum one (ML-KEM-768, NIST-standardised) into a single key. An attacker would need to break both to read your data — so even if a quantum computer capable of breaking classical encryption is built in the future, data encrypted today remains protected.

Regenerating your keys from the 12-word phrase uses Argon2id, a deliberately slow, memory-hard key-derivation function that makes brute-forcing the phrase impractical. The database itself is encrypted at rest by Cloudflare D1.

Children’s data

BrightBlur processes photographs of children. Children are data subjects, not users. They do not create accounts, they do not interact with the app, and no data is collected from them directly.

• Every child’s face is encrypted by default. No face is visible without explicit permission from a controller — the person who manages access to that child’s face data (typically a parent or nursery administrator).
• Privacy settings default to maximum restriction.
• There is no profiling, no algorithmic recommendation, no behavioural tracking, and no advertising.
• BrightBlur complies with the ICO’s Age Appropriate Design Code (Children’s Code).

Face detection is not perfect

No face detection system is 100% accurate. Faces may be missed if they are partially hidden, at an extreme angle, very small in the frame, or obscured by face paint, costumes, or unusual lighting. If a face is not detected, it will not be pixelated.

BrightBlur addresses this through several layers:

• The uploader reviews all detected faces before publishing and can manually draw regions around missed faces.
• Zero-face photos prompt a warning asking the uploader to confirm there are genuinely no faces.
• Any viewer can report a missed face for re-processing.

We are honest about this limitation because we believe transparency is more trustworthy than false promises of perfection.

Data sharing

BrightBlur does not share your data with third parties. There are no analytics services, no advertising networks, no data brokers. The app contains no third-party tracking code.

Photos are shared only with the people you choose. Face data is accessible only to people you have granted access to that person. These boundaries are enforced cryptographically, not just by access control rules.

Deletion

Deleting a person: A controller can delete a person, which permanently removes all face data, fingerprints, cryptographic keys, and access records in a single operation. The pixelated base images remain because they contain no recoverable face data.

Deleting a photo: The uploader can delete any photo they uploaded. This removes the base image, all face slices, and all associated data.

Deleting your account: Removes the photos you uploaded and their associated data, your comments, your pending access requests, your person record, your group memberships, your sessions, and your encryption keys. Face fingerprints you contributed to other people’s profiles are anonymised — the link to you is removed — rather than deleted, so other people’s recognition of their own profiles is unaffected. Abuse reports you have filed and security access logs are retained where we have a legal or safety basis to keep them.

What deletion cannot do: If another user has already viewed and cached a decrypted photo on their device, BrightBlur cannot force that cached data to be deleted. This is an inherent limitation of end-to-end encryption. Once data has been decrypted and displayed, the recipient holds a copy.

Cookies and local storage

• Authentication cookie: Keeps you logged in. Expires after 15 minutes, at which point it is silently renewed. Contains only your BrightBlur identifier. Not accessible to JavaScript (httpOnly).
• Refresh token cookie: Renews your authentication cookie. Expires after 30 days of inactivity. Not accessible to JavaScript (httpOnly).
• Local storage (IndexedDB): Caches your passkey’s unlock key and your wrapped (still-encrypted) seed so you stay unlocked across page loads. The unwrapped seed itself is kept only in memory, never written to storage. Cleared on logout.

There are no third-party cookies, no analytics cookies, and no tracking of any kind.

Your rights under UK GDPR

• Access: You can view all data associated with your account through the app.
• Erasure: Use the deletion features described above. For requests that cannot be handled through the app, contact us.
• Withdraw consent: Leave any group at any time. Delete your person record to withdraw consent for biometric processing.
• Portability: Planned for a future release.
• Complaint: You may lodge a complaint with the Information Commissioner’s Office (ICO) at ico.org.uk.

Infrastructure

BrightBlur runs on Cloudflare Workers. The database is Cloudflare D1 (built on SQLite). Encrypted blob storage uses Cloudflare R2. Both provide encryption at rest. Because all sensitive data is end-to-end encrypted before it reaches the server, a breach of the infrastructure would expose only encrypted blobs and the social graph metadata described above.

Contact

For privacy questions or data deletion requests that cannot be handled through the app:

Email: privacy@brightblur.app

Changes to this policy

We will notify users of material changes via in-app notification. The “last updated” date at the top of this page reflects the most recent revision.