Encryption is only meaningful against a specific threat model. Here is who SilentSuite protects you from (the server, the host, the network, us) and who it cannot (a compromised device, a leaked password, metadata at the server).
SilentSuite is an open-source, end-to-end encrypted alternative to Google Calendar, Contacts, and Tasks, built on the Etebase protocol. Encryption is only meaningful if you know what it is defending against. This post is the threat model: a plain-language list of who SilentSuite protects you from, and who it does not. No product is secure in the abstract. It is secure against specific attackers, under specific assumptions, and honest about the rest.
We would rather you understand the boundary than assume a guarantee we cannot make. If a part of this looks like an admission, it is. A threat model that only lists wins is marketing, not security.
What is a threat model, and why does it matter?
A threat model answers three questions: what are you protecting, who might want it, and what can you actually do about each of them. SilentSuite protects the contents of your calendar, address book, and task lists. The interesting attackers are the server operator (us), the hosting provider, a network observer, and anyone who gets hold of one of your devices. SilentSuite handles some of those completely and others not at all. The point of this page is to draw that line clearly.
The short version: SilentSuite uses zero-knowledge, client-side encryption, so the contents of your data are protected against everyone on the server side. What it cannot protect is anything that happens before encryption (on your own device) or the metadata that the server legitimately needs to do its job.
Who does SilentSuite protect you against?
These are the attackers the encryption is designed to defeat. In each of these cases, the contents of your events, contacts, and tasks stay unreadable.
SilentSuite, the company
We run the hosted servers, and we cannot read your data. Your calendar events, contact cards, and tasks are encrypted on your device with data keys that the server cannot unwrap. Your password protects the key material, but it is not sent to us and it is not used as a bulk data key. The server stores ciphertext. This is what zero-knowledge means in practice: a lawful request to SilentSuite produces encrypted blobs and account metadata, not the plaintext of your schedule. We designed it this way on purpose, so that trusting us is not a requirement.
The hosting provider and anyone with the disks
SilentSuite is EU-hosted, and the hosting provider sees the same thing we do: ciphertext. If someone seized the physical disks, imaged the database, or compromised the host operating system after the fact, they would get encrypted data without the keys to open it. The encryption does not care whether the database is breached, leaked, or lawfully copied. The contents stay sealed.
A passive network observer
Traffic between your device and the server is encrypted in transit with TLS, and the payload inside is already end-to-end encrypted on top of that. Someone watching the network sees that you are talking to a SilentSuite server and roughly how much data moves, but not the contents. (Note the limit: they see that sync is happening. More on metadata below.)
A future SilentSuite that changes its mind
Business models change and companies get acquired. The protection here is structural, not a promise. The server is open source under AGPL-3.0, your data exports to standard .ics and .vcf files, and you can self-host the whole thing. If a future SilentSuite ever became untrustworthy, the encryption would still hold and you could walk away with your data and run the server yourself.
| Attacker | Sees your event/contact/task contents? |
|---|---|
| SilentSuite (the company) | No |
| Hosting provider / disk seizure | No |
| Database breach or leak | No |
| Passive network observer | No |
| Lawful access request to the host | No (ciphertext only) |
| A compromised device of yours | Yes |
| Someone who knows your password | Yes |
| Metadata analysis (existence, timing) | Partial (see below) |
Who can SilentSuite not protect you against?
This is the part most privacy products skip. End-to-end encryption draws a line at your device. Everything on the wrong side of that line is outside what the cryptography can do.
A compromised device
Encryption protects data in transit and at rest on the server. It does not protect a device that is already in someone else's control. If your phone or laptop has malware, a keylogger, or a stalker with your unlock code, the attacker sees your calendar the same way you do, because the data is decrypted there for you to use. No sync product can fix a compromised endpoint. For maximum privacy, we recommend running SilentSuite on GrapheneOS for phones and Linux for desktops or laptops. Stock Google Android, Windows, iOS, and macOS add more vendor services, telemetry, cloud hooks, and opaque system components around the place where your data is decrypted, so the endpoint story is weaker. Device hygiene (full-disk encryption, a strong unlock, keeping the OS updated, and installing as little as possible) is on you, and it matters more than any server-side guarantee.
Anyone who has your password
Your password derives the keys that decrypt your data. That is the property that keeps us out, and it is also the property that means a weak or reused password is the whole ballgame. If an attacker learns your password, they can decrypt your data, because at that point they can do exactly what you do. Use a long, unique password, store it in a password manager, and do not reuse it. SilentSuite cannot reset your password into your data for you, which is the honest cost of zero-knowledge: there is no back door for us, which also means there is no recovery hatch we can open on your behalf.
A malicious or buggy client
The encryption happens in the client software. If you run a malicious build of an app, or a browser extension that scrapes the page after decryption, the data is exposed at the point of use. This is why the clients are open source and why you should install them from sources you trust. The threat model assumes the client you run is the client we published.
Metadata at the server
This is the most important limit to understand. The contents of your items are encrypted, but the server is not blind. To route sync, resolve conflicts, and bill accounts, the server can see that collections exist, roughly how many items are in them, and when they were last changed. The server does not see what an event says, but it can see that an account had activity at a particular time. We cover exactly which fields are encrypted and which are visible in a companion post, what Etebase actually encrypts. If your threat model includes an adversary who can correlate timing and volume of sync activity, that adversary learns something, even though they never learn content.
How does this compare to a normal calendar service?
The honest framing is that SilentSuite removes an entire category of attacker that mainstream calendars leave wide open, and is upfront about the categories that remain.
| Threat | Google Calendar | SilentSuite |
|---|---|---|
| Provider reads your events | Yes | No |
| Server breach exposes contents | Yes | No |
| Lawful access yields plaintext | Yes | No |
| Compromised device exposes contents | Yes | Yes |
| Metadata visible to server | Yes (plus contents) | Partial (no contents) |
Google Calendar processes every event in plaintext, so the provider, a breach, and a lawful request all reach your actual schedule. SilentSuite closes those three. What neither closes is your own device and, to a lesser degree, metadata. The difference is that with SilentSuite the metadata is all an attacker on the server side gets, instead of the full record.
What this means for how you should use SilentSuite
The threat model points to a short list of things that are actually in your hands, because the server-side risks are already handled:
- Pick a strong, unique password. It is the root of your encryption keys. There is no us-side recovery, which is the point.
- Use the strongest endpoint you can. For maximum privacy, use GrapheneOS on mobile and Linux on desktop. On stock Google Android, Windows, iOS, or macOS, assume the operating system and vendor cloud layer are a larger part of your threat model.
- Keep your devices clean. Full-disk encryption, a real lock screen, current updates, and a small trusted app set protect the one place your data is decrypted.
- Install clients from sources you trust. The apps are open source so the encryption can be inspected, not just claimed.
- Know what metadata is. If timing and volume of sync activity are part of your threat model, read the companion post on what Etebase encrypts.
SilentSuite's hosted plan is “From €3/mo,” or you can self-host the AGPL-3.0 server and remove us from the trust equation entirely. Either way the encryption model is the same, and so is this threat model.
Security is a set of trade-offs, not a checkbox. SilentSuite makes a specific one: the contents of your personal information are protected against the server, the host, the network, and us, at the cost of putting password strength and device hygiene squarely in your hands. That is a trade we think is worth making, and one we would rather state plainly than paper over.
Get started with SilentSuite, or read what Etebase actually encrypts for the field-by-field detail behind this model.
Interested in private sync?
SilentSuite is available now. Sign up and start syncing your calendar, contacts, and tasks with end-to-end encryption.
Get started for free