Why some security features can’t be turned off

Private.Ki is built around one idea: secure communication should be the default, not a setting you have to remember to enable. Because of that, some security features are intentionally not optional. If we allowed users (or attackers) to disable them, Private.Ki would become vulnerable to mistakes, "downgrade" attacks, and inconsistent security guarantees.

Below are the most common examples and why we enforce them.

Encryption and signing for internal emails can’t be disabled

When you email another Private.Ki user (with an @private.ki address), encryption is always on.

You don’t have to press the Encrypt button, and you can’t deselect it. The message content and attachments are encrypted end-to-end with the recipient’s public key, and the message is digitally signed by the sender. This is enforced for every internal email, and you don't need to take care of it.

We do this so that both sender and recipient can rely on a simple rule: Internal email is always private and always authentic. If we made this optional, users could accidentally send sensitive content in plaintext. It would also make it easier for attackers to trick users into sending unencrypted messages or strip security controls in certain situations.

Encryption for Messenger/Chat can’t be disabled

The same principle applies to private chats, either inside or outside of Private.Ki:

Messages on our messenger are always encrypted.

There is no "unencrypted mode" and no setting to turn signing off.

This keeps chat consistent, prevents mistakes, and removes the possibility of "downgrade" scenarios where one side expects encryption but the other side is sending plaintext.

Receiving encrypted emails from outside is automatically protected

If someone outside Private.Ki sends you an email that is already PGP-encrypted, we encrypt it a second time while it is stored on our servers. You won’t notice any difference when reading it, but this extra layer strengthens privacy at rest and helps prevent cross-user correlation in storage.

This behavior is automatic and cannot be disabled.

Metadata protection inside Private.Ki is not optional

Metadata (such as subject, sender, dates, message IDs, and similar fields) is encrypted for storage. This is part of our privacy model and is not a toggle.

There is one practical exception: We must know which Private.Ki mailbox a message belongs to, so the recipient address is available for routing. The sender is stored encrypted so that stored data does not directly reveal who is communicating with whom.

For external email sent over SMTP, standard headers must exist during transport. SMTP requires fields like From, To, Date, Subject, and Message-ID to deliver the email. There is no technical way to transmit external email without that metadata being present on the wire. This limitation applies only during transport. In storage, we encrypt metadata as described above.

Why we enforce these defaults

We enforce certain security features because security is only reliable when it is predictable.

If encryption and signing could be turned off, users would have to constantly verify that the right settings are enabled for every message. That creates the same failure mode we see in legacy systems: privacy becomes an optional checkbox that gets missed at the exact wrong moment.

Enforcing these protections also prevents attackers from pushing users into weaker configurations and keeps internal communication consistent across devices and clients.