Privacy · Threat model
Who can reach your data — and who can't.
A privacy promise without a threat model is marketing. Here is a concrete account of which attacks Endearist is designed to defend against, which it may mitigate — and which are outside our control.
Endearist has not launched. This describes the intended design, not a service you can test today. End-to-end encrypted sync over storage you run yourself — a local or shared folder, or a WebDAV server — is planned for v1. Google Drive as a destination is not decided yet. Managed sync on Endearist Cloud is planned for after v1, as part of the Pro Cloud subscription only.
What we actively protect against
Us
This is the most important category. Even if you fully trust us today, you shouldn't have to depend on us remaining trustworthy forever. The planned local-first design keeps content on your device rather than on a central content server.
Planned sync over your own storage would encrypt content with AES-256-GCM before it leaves your device. The proposed Endearist Cloud service is planned only for after v1. In that design, a server would see opaque bytes, not contact names or notes. The key would be derived on your device and would not be sent to us.
Adding a second device should not change that model. Pairing is intended to use an existing trusted device or your recovery code, not a server-side copy of the key.
Third-party trackers
On this website: no Google Analytics, no Facebook Pixel, no Hotjar, no embedded social buttons. We use a self-hosted Plausible instance that collects no personal data and no cookies — only anonymous page views.
In the app: no third-party SDKs transmitting usage behavior without your consent. The proposed telemetry policy is opt-in; a public release must verify the default. No Amplitude, no Mixpanel, no Segment.
Employees and internal access
The planned app has no central content server. Support should not need access to contact content. As with any support request, content you deliberately paste into a message can still reach us.
What we mitigate but can't fully prevent
Government actors with court orders
If an authority comes to us with a valid legal order, we would have to disclose data we hold. Under the planned local-first model, that could include account data and, if you choose the future managed service, encrypted sync packages. The planned encryption means we should not hold a key to decrypt your content.
What we don't guarantee: protection against authorities with access to your physical device. If your unlocked device is in the hands of a law enforcement agency, that is outside our technical control. Device full-disk encryption (FileVault, BitLocker, iOS Secure Enclave) is your first line of defense in that scenario.
Compromised sync services
If a planned user-controlled storage backend is compromised, an attacker could obtain encrypted packages. The intended encryption would protect their contents, but not metadata such as timestamps and file sizes. Google Drive as a direct destination is undecided; iCloud is not a planned sync destination.
AI requests you choose to run
AI is intended as a separate data path, not a loophole in local-first storage. The app is designed to work without AI. A planned AI action would send only the context needed for that task: directly to the provider configured with your own key, or through a future managed service. It should not upload your whole relationship database.
The honest limit: if you ask an external AI provider to process a message draft, journal excerpt, or contact note, that selected text leaves your device for that request. Treat AI actions as deliberate sharing, not as invisible background sync.
For flows where a server-side AI call is not necessary, we prefer a prompt-bridge pattern: Endearist prepares the prompt locally, shows you exactly what will be sent, and lets you copy it into your own AI tool. In that path, the generated prompt leaves your device only if you deliberately paste it somewhere else.
What we honestly can't protect against
Physical device access by an attacker
If someone holds your unlocked device with Endearist open, they see your data. That's not a failure of our app — it's physics. We plan an optional app lock via PIN or biometrics for exactly this case. But we will never claim to protect you against an attacker with physical device access and sufficient time.
Screenshots by an attacker who controls your device
Screenshot protection: planned for v1; not offered on Windows. Platform-specific protection is not a guarantee against malware or a person controlling the device.
The vendored app measurement does not confirm an encrypted local database. It records an unencrypted SQLite file; an app lock does not encrypt that file. Protect your device and backups independently.
Forgotten passphrases with no recovery path
Under the planned model, if you lose your passphrase, recovery code, and every trusted device, you could permanently lose access to encrypted sync data. A server-side recovery key would weaken the intended end-to-end encryption. Keep an independent local backup; its protection depends on how you store it.