Privacy Policy
Effective date: June 28, 2026
[ Your Browser ]
│
├─ You enter your vault passphrase
├─ Encryption key derived locally (PBKDF2 · 310,000 iterations)
├─ Data encrypted before leaving (AES-256-GCM · unique IV per field)
│
│ ← server boundary →
│
▼
[ Fern & Echo Servers ]
│
├─ Receive : encrypted blobs only
├─ Store : ciphertext (mathematically unreadable without your key)
├─ Never : your passphrase, derived key, or entry contents/titles
├─ Always : section names, entry counts, timestamps (structural metadata only)
├─ Opt-in : field usage patterns (boolean filled/not-filled per field, no values)
├─ Exception: continuity release window — see Section 4
│
▼
[ You unlock on any device ]
│
├─ Encrypted blobs retrieved from server
├─ Decrypted locally in your browser
└─ Plaintext exists only in your session · never written to disk or server
What Fern & Echo Can and Cannot See
The table below shows every category of data we handle, a real example of what it looks like in our database, and the realistic risk if that data were exposed. We believe you deserve to see this clearly.
| Data | Example | Risk if exposed | Visibility |
|---|---|---|---|
| Account information — always collected | |||
| Name | eyJpdiI6Ilo4d1c3... | Encrypted server-side using AES-256. Not readable without the application key. | Encrypted |
| eyJpdiI6IkMyeStO... + SHA-256 hash | Encrypted server-side. A separate SHA-256 hash is stored for login lookup only — no plaintext email is retained. | Encrypted | |
| Subscription tier | free / monthly / annual | Indicates financial relationship with service | Plaintext |
| Account created | 2026-05-04 16:47:11 | Low risk — account age only | Plaintext |
| Structural metadata — always collected | |||
| Section names & types | JQgasCNP2aIsPY+c:... · type: financial | Section names encrypted client-side before leaving the browser. Section type (e.g. financial, medical) remains plaintext for navigation. | Encrypted |
| Entry counts per section | Banking — 2 entries · Email — 1 entry | Low risk alone. Combined with section names reveals vault completeness and account density | Plaintext |
| Entry timestamps | created: 2026-05-04 · updated: 2026-05-04 | Activity patterns. Rapid updates can correlate to life events — estate planning, account changes, emergencies | Plaintext |
| Dependency graph | entry:55 → entry:56 (depends) | ID-only edges. Low risk without titles — reveals account structure but not account names | Plaintext |
| Entry content — client-side encrypted | |||
| Entry titles | ifmvSzkcD/kGZHAL:akj... | Ciphertext only. Previously the highest-value leak — now encrypted client-side | Encrypted |
| MFA methods | Cy1jFSu4sorjUnOR:D5M... | Ciphertext only. Would reveal security posture — now encrypted | Encrypted |
| Credentials, URLs, notes | url_encrypted · notes_encrypted · extra_encrypted | Ciphertext only. Mathematically unreadable without vault key | Encrypted |
| Continuity release — temporary, consent-gated | |||
| Vault key (release window) | Held only during active release window | Exists on server only during the waiting period. Deleted permanently once sent to continuity contact. Never retained beyond the window. | Temporary |
| Field usage analytics — opt-in only | |||
| Field usage logs | [financial] url: empty · custom:test: filled | Boolean only — no values collected. Reveals which fields users fill, not what they contain. Used for form improvements only | Opt-in |
1. What We Collect
We collect the minimum information necessary to operate the service:
- Account information — your name and email address, used for authentication and service communications.
- Encrypted vault data — ciphertext blobs generated in your browser. We store these blobs but they are mathematically unreadable to us without your vault key, which never leaves your device.
- Access logs — timestamps and IP addresses of login attempts, used for security monitoring and IP-based abuse prevention.
- Share activity — metadata about vault shares you create (who you shared with, when, and access status). Shared content is also encrypted.
- Billing information — if you subscribe to a paid plan, payment is processed by a third-party provider (Stripe). We do not store card numbers.
2. What We Cannot See
Your vault contents are encrypted client-side using AES-GCM with a key derived from your vault passphrase. This encryption happens entirely in your browser. As a result:
- We cannot read your vault entry titles, credentials, notes, or any content stored within entries. Entry titles and MFA methods are encrypted client-side before reaching our servers.
- We can see the names and types of your vault sections (e.g. "Banks", "Legal") and the number of entries per section. This structural metadata is stored unencrypted to enable navigation.
- We cannot recover your vault if you lose your passphrase. There is no server-side key escrow — with one narrow, consent-gated exception described in Section 4.
- Even in the event of a data breach, your vault contents are protected by your passphrase.
- Support staff cannot inspect, export, or recover vault contents on your behalf.
3. Structural Metadata
While vault entry contents and titles are encrypted client-side, certain structural metadata is stored unencrypted on our servers to enable the service to function:
- Section names and types — for example "Banks" or "Legal". These are visible to Fern & Echo.
- Entry counts — the number of entries per section.
- Timestamps — when entries and sections were created or last updated.
- Dependency relationships — numeric identifiers linking entries to each other (without labels or titles).
We store this metadata because it is required to render your vault structure, calculate your readiness score, and enable navigation before your vault is unlocked. This metadata does not include entry contents, credentials, or titles.
We intend to encrypt section names in a future release, further reducing the structural metadata visible to us.
Optional field usage analytics — if you opt in via vault settings, we additionally collect anonymized field usage patterns: which fields you fill when saving entries, recorded as true/false per field key. No field values are ever collected. This data is used solely to improve default form layouts. You can opt out at any time from vault settings.
Custom field label telemetry — when opted-in users add a custom field to an entry, the field's label (e.g. "User Name") is also collected so we can identify common labels across the user base and offer to surface them on the default form for everyone. The field's value is never sent to the server. Labels are stored anonymously (no user identifier) and are normalized for grouping. Same opt-out as above.
3. How We Use Your Information
- To authenticate you and maintain your session.
- To store and retrieve your encrypted vault blobs.
- To send transactional emails — account verification, password reset, share notifications (if enabled).
- To detect and block abuse — repeated failed logins, suspicious IPs.
- To process subscription billing through our payment provider.
We do not sell your data, run advertising, or share your information with third parties for marketing purposes.
4. Continuity Access & The Key Release Exception
Fern & Echo includes two levels of access that allow trusted people to step in when you are unavailable — whether for a medical emergency, extended travel, incapacitation, or after your death. We want to be completely transparent about how each level works and what we store.
Level 1 — Operational access (vault sharing)
You may share your vault with a trusted person — a partner, sibling, or close friend. They can view your
vault contents while you are available or unavailable. This uses a share key stored on our servers in
encrypted form. The mechanism is the same as standard vault sharing: we hold ciphertext we cannot read,
and access can be revoked by you at any time.
Level 2 — Full continuity access
You may designate a continuity contact — an attorney, executor, or trusted family member — who can take
full control of your vault when needed. This level requires a deliberate activation process and includes
a waiting period before access is granted.
The key release mechanism — our one exception to zero-knowledge
When a Level 2 continuity release is activated by a trusted person you have designated, the following
happens in sequence:
- The activation request is received and logged. You are notified immediately if possible.
- A waiting period begins — configured by you at the time of designation. During this window, you can cancel the release if you are able to.
- During this window only, a vault key is temporarily stored on our servers. This is the one moment we hold anything capable of opening your vault.
- When the waiting period ends, the key is sent directly to your designated continuity contact and deleted permanently from our servers. We do not retain it.
This is the only exception to our zero-knowledge architecture, and it requires your explicit prior consent to set up. Without designating a continuity contact and completing the key exchange process, no release can ever be triggered — by anyone, for any reason.
If you choose not to use Full continuity access, none of this applies to you. No key is ever created, no release can ever be triggered, and your vault remains mathematically inaccessible to Fern & Echo — permanently and by design. The zero-knowledge guarantee is unconditional for anyone who does not elect continuity access. This feature exists for people who want it. If you don't, nothing changes.
What we store as part of continuity setup
- The email address of your designated continuity contact
- The order in which you want your vault sections presented to them
- Your customized continuity playbook — a checklist of tasks, which may include personal notes you have written
This information is not encrypted with your vault key. It is stored as standard account metadata, similar to your name and email address. It does not contain sensitive financial, medical, or credential information.
What your continuity contact can access
Your continuity contact can only access your vault contents after the release process completes. Fern &
Echo cannot grant access on your behalf, override your designation, or provide access to any party not
explicitly designated by you. There is no backdoor outside this consent-gated process.
Resource library
The continuity playbook may link to guides in the Fern & Echo resource library. These are publicly
accessible pages covering common tasks — notifying banks, filing final tax returns, closing accounts.
They are not personalised or tied to your account data.
Why we built it this way
The temporary key window is a deliberate architectural tradeoff. A pure zero-knowledge system with no
release mechanism means your vault is permanently inaccessible to anyone if you cannot unlock it yourself.
We believe giving you the option to authorise a time-delayed release — with full transparency about when
and how a key exists on our servers — is more honest and more useful than pretending the problem does not
exist.
5. Data Retention
Your encrypted vault data and account information are retained for as long as your account is active. If you delete your account, your data is permanently removed from our systems. Access logs are retained for a rolling 90-day window for security purposes.
Unverified accounts — accounts where email verification has not been completed — are automatically deleted after 30 days. This is consistent with data minimization principles under GDPR and CCPA. To prevent deletion, simply verify your email address using the link sent at registration.
6. Cookies and Local Storage
We use session cookies strictly for authentication. We do not use tracking cookies or third-party
analytics. Your vault key is stored temporarily in sessionStorage
for the duration of your browser session and is never written to a cookie or sent to the server.
7. Third-Party Services
- Stripe — payment processing for paid plans. Subject to Stripe's own privacy policy.
- Email provider — transactional email delivery. Emails contain no vault content.
No analytics platforms, ad networks, or data brokers are used.
8. Your Rights
You may request a copy of your account data, correction of inaccurate information, or deletion of your account at any time. Because vault contents are encrypted and unreadable to us, any data export we provide will include the raw encrypted blobs. To exercise these rights, contact us at the address below.
9. Changes to This Policy
If we make material changes to this policy, we will notify you by email and by a notice on the dashboard prior to the change taking effect. We will always publish the updated policy with a clear effective date and a changelog entry. Continued use of the service after the effective date constitutes acceptance.
10. Contact
Questions about this policy or your data can be directed to us at [email protected].
To formally exercise your rights under GDPR or CCPA, use our privacy request form. We will respond within 30 days.
11. GDPR & CCPA
If you are located in the European Economic Area, United Kingdom, or California, you have additional rights regarding your personal data:
- The right to access, correct, or delete your account data at any time.
- The right to data portability — you may request an export of your account information.
- The right to object to or restrict processing of your data.
- California residents may request disclosure of any personal information shared with third parties for direct marketing purposes. We do not share data for this purpose.
To exercise any of these rights, email [email protected]. Because vault contents are client-side encrypted, any export will contain ciphertext only — we have no means to provide plaintext vault data.
12. Law Enforcement & Legal Requests
Fern & Echo is designed so that we cannot access your vault contents — not by policy, but by architecture. All vault data is encrypted client-side before it reaches our servers. We hold ciphertext we cannot read.
What we can provide in response to a valid legal request:
- Account metadata — email address, account creation date, subscription status, last login timestamp
- Audit log actions — events such as vault unlocked, entry created, export downloaded (no content)
- Share relationship records — who shared with whom, timestamps (no vault contents)
- IP addresses associated with failed login attempts only — we do not log IPs for successful vault access
What we cannot provide under any circumstances:
- Vault contents — entries, titles, URLs, notes, account numbers, or any encrypted field
- Vault encryption keys — these exist only in the user's browser session and are never transmitted to or stored on our servers, except during an active Level 2 continuity release window (see Section 4)
- Plaintext versions of any encrypted data
Note on continuity release windows: During an active Level 2 continuity release, a vault key is temporarily held on our servers for the duration of the waiting period. If a majority of designated confirmers confirm before the window closes, the key is sent to the continuity contact immediately and deleted — the waiting period does not need to expire. A valid legal request received during this window could compel us to produce that key before it is deleted. We will notify the account holder or their estate to the extent permitted by law. We do not pause, extend, or hold keys beyond the configured window under any circumstances — including in response to legal requests. Once the key is deleted, it is gone permanently. We have no mechanism to reconstruct it.
All legal requests must be directed to [email protected]. We review every request for legal sufficiency before responding. We will notify affected users of requests to the extent permitted by law.
We publish an annual transparency report summarizing the number and type of legal requests received. See our Transparency Report.
Policy Changelog
| Date | Change |
|---|---|
| 2026-06-28 | Initial policy published. |
| 2026-05-01 | Added executor setup & estate planning features section. |
| 2026-06-28 | Reframed executor access as continuity access. Added key release mechanism disclosure. Updated law enforcement section to reflect continuity release window. |