Docs / Security & Privacy
Technical reference

Security & Privacy

Every claim on this page references the specific mechanism that implements it, so it can be checked against how Tareea actually behaves, not just what we say about it.

Current as of July 3, 2026
Tareea encrypts your note and task content on your device, before it ever reaches us.
Metadata is minimized, not eliminated — some structural information stays visible so the app can function.
Connected Mode and BYOAI change what can leave your browser, deliberately and narrowly, and only if you turn them on.
Content
Encrypted, always
Metadata
Partly visible: status, dates, IDs
Keys
Generated in your browser, never uploaded raw
Connected Mode
Optional, mirrors labels only, server-readable
AI (BYOAI)
Direct browser-to-provider, only if you enable it

What's encrypted

Encrypted end to end
  • Note title & body
  • Note search index
  • Note & task tags
  • Task title & description
  • Folio name & description
  • Tag names
  • Day Pins
  • Sub-note relationships
  • Handoff payloads
  • Your AI provider keys
Visible to the server
  • Row IDs, timestamps
  • Workspace ownership
  • Task status & priority
  • Due date & time
  • Folio membership, position
  • Pin state
  • Encryption version
  • Account email (via Supabase Auth)

How encryption works

Standard, well-reviewed primitives — no proprietary cipher, no invented scheme.

ComponentImplementation
Content cipherAES-256-GCM via the browser's native Web Crypto API. Older rows on XChaCha20-Poly1305 (libsodium) are transparently re-sealed on next edit.
Master key256-bit, generated client-side from a CSPRNG.
Password → keyArgon2id, opslimit=3, memlimit=64 MiB, locked parameters, ~500ms on a mid-range 2026 phone.
Recovery key → keyBLAKE2b-256 over 200 bits of random entropy.
Nonces12 bytes (GCM) / 24 bytes (XChaCha), fresh-random per call, never reused.
Version bindingEvery blob is bound to a versioned associated-data string. A v1 blob can't be silently opened as v2 — mismatches fail verification, not decrypt into garbage.
"Zero-knowledge" or "end-to-end encrypted"?

End-to-end encrypted is the term we stand behind. "Zero-knowledge" gets used loosely across the industry, and we'd rather be precise than impressive. The metadata table above is real and visible. Content is E2E. Metadata is minimized, not eliminated.

Keys and recovery

The recovery key is a 40-character string, 200 bits of entropy, shown exactly once:

tareea-AAAAA-BBBBB-CCCCC-DDDDD-EEEEE-FFFFF-GGGGG-HHHHH

It's not a hint. It's the second key that unwraps your master key if your password is ever lost.

If both are lost

Your data is permanently unrecoverable. There's no back door and no exception we can make — that's the actual trade for encryption that's real rather than promised. Print the recovery key. Keep it somewhere your account password doesn't also protect.

Two-factor authentication

Optional, and separate from your encryption keys entirely. Turn on TOTP-based 2FA in Settings — any standard authenticator app works — and generate one-time backup codes at enrollment for the case where you lose your authenticator device. 2FA protects account access, not content directly: content is already protected by encryption that doesn't depend on your login session. Even a compromised login can't decrypt your notes without your password or recovery key.

What the server can see

A support engineer, a legal request, and a compromised internal account all hit the same wall: the ciphertext exists, the key doesn't. There's nothing to hand over, because there's nothing here that can read it.

Connected Mode

Opt-in, Pro-only, per workspace. Turn it on, and three plaintext mirror fields appear: title_plain, tags_plain, name_plain, so server-side features like calendar feeds and email digests can say "you have a task called X" without holding your key. Bodies and descriptions stay encrypted either way. Turn it back off, and new writes stop mirroring; existing mirrors clear the next time that item is edited.

BYOAI

Your AI requests never pass through Tareea's servers — not stored, not logged, not even seen in transit.

Because we're never in the request path, there's nothing on our side to log. Your relationship for those calls is with the provider you chose, on the terms they publish.

Data handling

WhatWhere
App serversParis (Vercel)
Database & authLondon (Supabase)
Encrypted backupsEU jurisdiction (Cloudflare R2)
Email deliveryUS (Resend)

Deletion and exports

Deleting your account

  1. Your password is re-verified server-side before anything happens.
  2. Every table tied to your account — notes, tasks, Folios, tags, Handoffs, everything — cascades and drops in the same transaction.
  3. An audit-log entry retains your user ID for compliance, never your content.
  4. A confirmation email is sent to the address on file.

Deletion is immediate — no 30-day grace period, unlike the soft-delete on individual notes or tasks. Encrypted nightly backups roll off within 30 days, and were never readable without a key that's already gone.

Exporting your data

Settings → Privacy & data exports everything you own: notes, tasks, Folios, tags, Day Pins, note versions — decrypted in your browser, packaged as Markdown plus a JSON manifest. No server involvement in the decrypt path; it works offline as long as your key is loaded.

Compliance and trust

GDPR

We built Tareea's architecture around the rights GDPR protects — not as a compliance project bolted on afterward. Here's what that means in practice:

None of this makes Tareea "GDPR certified" — that isn't a real certification GDPR itself issues. The rights it's built to protect are implemented as working features, not promises pending a compliance project.

Responsible disclosure

Email security@tareea.com. Acknowledgement within 72 hours, credit if you want it, coordinated disclosure on your timeline.

When things go wrong

If Tareea shuts down

Your export stays available with at least 30 days' notice before any shutdown — see Deletion and exports above.

If our servers go down

Notes and tasks you've already opened stay readable and editable offline. New writes queue locally and sync once you're back. What doesn't work offline: syncing from other devices, sharing, or triggering digests. Nothing becomes newly readable during an outage — the offline layer only holds what was already decrypted in memory before the connection dropped.

What we won't overclaim

Still have a question this page didn't answer?

This page covers what we think a careful reader would actually want to know — but we're aware we might have missed your specific question. We'll answer honestly — whether that means pointing you to something already true, or telling you plainly that it isn't built yet. Gio and Pat read every one.

Contact us →