Most companies talk about privacy the same way they talk about quality or customer service: as a value they hold, expressed through a policy document that sits, unread, in a footer link. We think that approach has quietly failed the people it was supposed to protect. A promise is only as strong as the willingness of the company behind it to keep it, and we did not want to ask people to simply trust that we would. So instead of building a product and writing a privacy policy to describe it afterward, we started from the opposite direction: we asked what a system would have to look like structurally in order to make certain privacy violations impossible, not just discouraged.
This is what we mean when we talk about how Chrysaor approaches personal privacy. It is not a single feature. It is a set of decisions made at the architecture level, before a single line of interface was designed, that shape everything the product can and cannot do with your information.
We Start From Architecture, Not Policy
A privacy policy tells you what a company says it will do with your data. Architecture determines what the system is actually capable of doing in the first place. Those are very different guarantees, and the difference matters enormously. A policy can change with a new executive team, a new owner, or a new legal pressure. A structural limitation does not bend the same way. If a system is built so that it never holds the key to decrypt your messages, no policy change can suddenly grant it that access, because the capability was never built in.
We build with that principle first. Before we ask what a feature should do, we ask what it needs to know to do it, and we design the system so that anything beyond that minimum is not just discouraged but structurally unavailable.
Data Minimization Is a Default, Not a Setting
Many services treat privacy as something you opt into: a toggle buried in a settings menu that most people never find, let alone change. We think that backwards. The strongest, most private configuration should be what everyone gets automatically, without needing to know it exists or go looking for it.
In practice, this means we ask a simple question before collecting anything: does this feature genuinely need this piece of information to work? If the answer is no, we do not build a place to store it. This is a deliberate constraint, not an oversight. Every field we do not collect is one less thing that can ever be lost, leaked, subpoenaed, or sold.
Encryption Is the Foundation, Not an Add-On
Email was never originally designed with strong encryption as its default state, and much of the email industry still reflects that history. We are building around a different assumption: that the content of your communications should be unreadable to anyone except the people you are actually communicating with, including us. Encryption at rest and in transit is table stakes. What we are building toward is a model where your messages are protected end to end, so that even in a scenario where our systems were compromised or compelled, there is nothing readable to hand over.
Transparency Over Reassurance
We would rather tell you specifically what our systems cannot do than offer you a general reassurance that we take your privacy seriously. “Trust us” is not a security model. A specific, verifiable limitation is. As we build out Chrysaor, we intend to be explicit about the architectural choices behind the product, not just the values behind the company, because a claim you can inspect is worth more than a claim you can only take on faith.
Full Functionality, Not a Trade-Off
One of the most common excuses for weak privacy is the idea that strong protection has to come at the cost of usability. We reject that framing. Privacy and a genuinely good product experience are not opposing goals that require balancing. They are both outcomes of the same underlying discipline: building deliberately, rather than defaulting to collecting everything simply because it is technically possible. Our goal is an email experience that feels modern and effortless, precisely because the privacy protections are built into the foundation rather than layered on top as friction.
What This Means for You, Practically
- You should not have to read a lengthy policy to understand your privacy. The strongest protections should already be the default the moment you start using the product.
- Your data should not outlive its purpose. Information collected for one reason should not sit indefinitely on the chance it becomes useful for something else later.
- Our ability to access your content should be limited by design, not just by promise. That is the difference between privacy you have to trust and privacy you can rely on.
This Is the Beginning, Not the Finished Product
We are early in the Chrysaor journey, and we do not want to overstate where we are. What we can commit to is the discipline behind how we are building: architecture first, minimization by default, encryption as a foundation rather than a feature, and transparency about the specific choices behind the product rather than vague reassurance. In the months ahead, we will continue sharing the details of how these principles show up in the product itself.
To follow along as we build secure email around exactly these principles, visit the Chrysaor home page and stay with us as the next steps roll out.
Frequently Asked Questions
What does “privacy by architecture” mean at Chrysaor?
It means privacy protections are built into the structure of the system itself, rather than promised through a policy. If a system is built so it cannot access certain data in the first place, that limitation does not depend on trust or enforcement to hold.
Does Chrysaor collect data by default?
Chrysaor is built around data minimization as a default, not an optional setting. The guiding principle is to collect only what a specific feature genuinely needs to function, rather than gathering broadly and deciding what to do with it later.
How does encryption fit into Chrysaor’s approach?
Encryption is treated as a foundation of the product rather than an add-on feature. The goal is an email experience where message content is protected end to end, so that even Chrysaor cannot read it.
Does strong privacy mean a harder to use product?
No. Chrysaor treats privacy and usability as compatible goals rather than a trade-off, aiming for an email experience that feels modern and effortless because privacy protections are built into the foundation rather than added as friction later.