Assume everything is compromised.

In plain English.

A company’s computers can be hacked without that automatically exposing the private content stored on them. The idea is to have your app lock the information before sending it, while keeping the ability to unlock it with you and the people you choose to share it with. The service can store and deliver the locked information without being able to open it on its own.

• What this protects: taking over the company’s storage or backend alone should not reveal your protected messages or records.
• What it does not protect: someone controlling an unlocked device or the software that reads your information may still see it. The service may also see details such as when you connect, and a breach can still interrupt access or delete stored files.
• What it asks of you: adding a device and recovering access need a trustworthy approval or recovery method. If every authorized device and recovery option is lost, customer support may be unable to restore the protected content.

The practical question is simple: who can unlock your information, and who can give someone else that ability? The rest of this article explores those choices through ChatZeee and Family OS.

The breach is not the end of the security model.

Imagine an attacker copies your application’s database and gains administrator access to the backend. They can inspect stored records, change account flags and watch requests arrive. What can they actually read?

The answer depends on decisions made long before the incident: where encryption happens, who controls the keys, how a new device gets access, and what customer support can recover. If the compromised service can retrieve everything needed to decrypt a record, encrypted storage alone does not preserve that record’s confidentiality against this attacker.

That is the question I bring to private application design: what does control of the service actually give someone? Keeping attackers out still matters. I also want a clear answer for the day those defenses fail.

This essay focuses on a specific goal: a storage or backend compromise should not, by itself, expose protected content while authorized clients, their keys and the client-release process remain trustworthy. “Assume everything” is a prompt to examine every dependency—not a claim that useful software can operate without trusting anything.

The founding commitment

Give the service the capabilities it needs to deliver the product. Keep content-decryption authority with the intended readers.

Two applications, two versions of the same problem.

In ChatZeee, my native iOS messaging work, the service needs to route messages and deliver attachments. Those jobs do not require it to read the conversations. The design puts message encryption and key use on authorized devices while the relay handles ciphertext.

That decision has a product cost: recovering an account cannot automatically mean recovering its message history. The recovery capability has to be designed and explained. ChatZeee is in iOS TestFlight beta; the documented implementation and evidence scope are linked below.

In Family OS, the problem is access to household information across trusted devices. Passkey authentication establishes account access, while the master key, encrypted records and device-approval flow govern access to content. The product has to make signing in, approving a device and unlocking a vault understandable as separate actions.

Family OS is in development. Its browser delivery model introduces another dependency: even well-encrypted records need trustworthy code when someone opens them. That constraint belongs in the design discussion from the start.

For both projects, the useful engineering question is concrete: can a server administrator give a new device usable content keys without an already authorized capability? The answer must come from the implementation and repeatable tests. The following sections explain the decisions behind that question.

Start with a better question.

“Can we keep attackers out?” still matters. But it is not enough. Ask what an attacker gains from each compromised component, and which additional secrets or permissions they would need to harm a user.

Define the boundary precisely: an attacker may control storage, the backend and ordinary administrator accounts, while authorized devices, content keys and the client-release process remain trustworthy. If those assumptions change, the promise changes too.

This table describes the design’s intended limits. The acceptance checks later in the article turn those expectations into questions an implementation must answer.

Access-control illustration, not a decryption-key design. View the full-size access flow.

This diagram answers an access question: should this person or device be allowed to reach a resource? Identity, device posture and context inform the decision; enforcement applies it; monitoring informs later decisions. Whether the service can decrypt that resource is a separate question. See NIST SP 800-207 for the access-control model.

Zero knowledge is an architectural decision.

An encrypted database and an end-to-end encrypted conversation protect different boundaries. Both can be valuable. To understand either one, follow the data to the point where it becomes readable and identify who can obtain that capability.

Here, a zero-knowledge service means the storage and backend systems lack independent decryption capability for specified private content, under the trusted-client and release assumptions above. It does not mean the provider learns nothing at all. A provider that controls accepted client updates may be able to introduce code that reads future plaintext; that release authority is a separate power that this backend-compromise promise does not eliminate.

Three terms, three jobs. Zero trust governs access decisions. Provider-blind content encryption limits who can decrypt specified content. Zero-knowledge proofs are a separate cryptographic technique for proving a statement without revealing the underlying secret. An access policy or proof does not automatically create the content boundary described here.

Keep the keys with the people.

Create and use content keys inside an authorized client. Encrypt before upload. Let the cloud store, synchronize and deliver encrypted data without independently possessing the capability to open it.

FIG. 01 / The content trust boundary. The cloud can be hostile. The client that handles plaintext must still be trustworthy. Recovery and device authorization must preserve the same boundary.

Data keys may be wrapped by a separate client-controlled key, with the encrypted envelopes stored alongside ciphertext. The service must not independently possess the capability to unwrap them. OWASP describes this separation; the important property is who can unwrap a key, not whether an encrypted copy exists on the server.

Multi-device access requires more than signing in. An existing trusted device or an explicit, user-held recovery capability must authorize the transfer of decryption keys to a new device. That authorization must bind to the new device’s cryptographic key. Successful identity verification by the server is not sufficient on its own; a compromised identity service can otherwise impersonate a new device, as RFC 9420 describes. A server-side account flag must not manufacture that authority.

Protect the integrity of changes as well as the secrecy of files. Verify who authorized an edit, a membership change or a key update. Treat old-but-valid data and silent key substitution as distinct problems, rather than assuming encrypted storage solves them.

What happens when someone adds a new phone?

Consider a person who still has an authorized phone and wants to add a second one. This is an illustrative enrollment flow, not a specification of either featured product’s complete protocol. It makes the authority question visible at each step.

1. Sign in on the new phone. Authentication establishes account access and lets the device request enrollment. It does not release content keys. A server-side “approved” flag is not sufficient evidence of cryptographic authorization.
2. Create the new device’s keys locally. The phone generates the key material required by the chosen protocol and submits its public enrollment information. Private material remains protected on that device.
3. Verify the requested device. The existing phone shows the pending enrollment. The user verifies the new device’s cryptographic identity through a suitable authenticated mechanism—for example, a protocol-defined QR exchange or key comparison. A friendly device name alone cannot establish that binding.
4. Authorize the actual key. Approval must bind the account, requested capability and new device key, with the protocol’s protections against substitution and replay. An attacker must not be able to swap in a different key after the person approves.
5. Transfer an encrypted capability. The trusted client prepares the key material the new device is authorized to receive, protected for that device through the chosen protocol. The service may relay or store the encrypted envelope without being able to unwrap it independently.
6. Unlock locally and record the change. The new phone verifies the authorization, unwraps the permitted material and decrypts locally. The product should make the newly authorized device visible and explain how to remove its future access.

Follow the same flow from the attacker’s side. In this hypothetical scenario, the attacker controls the backend and its account records, but not an authorized device, its keys or the client-release process. They can act as the account service, fabricate a pending-device record and mark it approved. Their goal is to turn those administrative powers into the ability to read private content.

The decisive step is key release. The attacker supplies a device key they control and asks for an envelope that device can unwrap. A trusted client must require independent authorization bound to that exact key and capability. A recognizable device name, a successful login or an “approved” database field cannot replace it. If changing a server flag is enough to obtain usable content keys, the boundary has failed.

An attacker does not need to break the encryption if they can trick a trusted device into sharing keys with them. That makes the approval screen part of the security design: it must let a person verify the intended device, rather than merely confirm a familiar label. If the person approves the attacker’s actual key, encryption may work exactly as designed while protecting content for the wrong reader.

A useful test observes the entire chain: the forged account state, the enrollment request, the client’s authorization decision and whether the requesting device can actually decrypt a synthetic record. A rejected API request is useful evidence, but it does not by itself establish that every key-release path is protected.

The cost is a more deliberate setup experience. The interface needs to explain why a second approval exists, what the user is approving and what happens if the old phone is unavailable. That last question leads directly to recovery; it cannot be solved by quietly handing decryption power back to the server.

Concept illustration: protection depends on trusted client code, authorized devices and sound key handling. It does not cover a compromised endpoint or malicious client update. View the full-size encryption illustration.

The browser is part of the threat model.

A web application usually receives its code from the same service it is trying to distrust. If that origin is compromised, replacement JavaScript may copy content before encryption or after decryption. Strong cryptography does not repair a hostile client. The W3C Web Cryptography security considerations explain why hostile scripts can expose keys or data.

This is why I treat release authority as part of the content boundary. A signature helps establish which authority approved a build; it does not establish that the build is harmless. Constrain signing authority, review sensitive dependencies and make changes verifiable. Two systems do not provide independent protection if the same administrator or recovery account controls both.

A key can be hard to steal and still be misused. In Web Crypto, marking a key “non-extractable” restricts exporting its key material through the API. It does not guarantee that hostile application code cannot use an accessible key for permitted decryption operations or read the resulting plaintext. The question is both “can this code export the key?” and “can this code ask the key to unlock something?” The Web Crypto key interface and its security considerations explain why these are different properties.

For Family OS, the practical question is who can replace the browser code that handles an unlocked vault. For native ChatZeee clients, it is who can ship an accepted update. Different delivery models create different controls, but both require an explicit answer.

Recovery without a universal backdoor.

Account access and data recovery are different powers. Resetting a password should not silently give the service the ability to decrypt an entire private history. A useful recovery design names the capability that restores access and the person or group that controls it. Customer support should be able to explain that design without becoming an undocumented route around it.

1. Another trusted device. A previously authorized device approves access and transfers the necessary capability.
2. An offline recovery key. The user keeps a recovery secret outside the primary service and verifies that it works.
3. A clearly disclosed recovery authority. A designated organization or user-selected group may hold recovery capability. State who holds it, whether they can act alone or require a threshold of participants, and which content they can recover. Any such authority becomes part of the trusted reader set. If the service provider can independently recover plaintext, that content falls outside the provider-blind guarantee; disclosure alone does not preserve it.

An honest trade-off

If every authorized device and every recovery capability is lost, protected data may be unrecoverable. Explain this during setup, help the user establish a workable recovery method, and let them verify it before an emergency. A privacy guarantee that people cannot recover from safely is an incomplete product experience.

Revocation governs future access. Removing a member can prevent access to new protected content after keys and membership state change. It cannot make someone forget plaintext or keys they already obtained.

Authentic does not always mean current. Suppose a household removes an old tablet. A malicious server later shows another device an older, correctly authenticated membership list that still includes it. Could that device encrypt new content for the removed tablet? The answer depends on the protocol and the state the client has retained; the mere fact that a list was valid once does not establish that it is valid now.

Review rollback and replay explicitly. Identify how clients authenticate membership changes, recognize older state and establish a trustworthy starting point after a reinstall or recovery. Specify what happens when a client cannot establish sufficiently current membership: whether it pauses the affected operation, requests verification or follows another documented policy. A warning after sensitive content has already been shared cannot undo that disclosure.

A hostile delivery service can also withhold updates altogether. RFC 9420 discusses suppression of updates and its effect on recovery after compromise. Encryption cannot force a server to deliver data; the product must explain what remains unavailable or uncertain.

Historical and future secrecy are different goals. Key rotation alone does not establish forward secrecy for old messages or recovery after an endpoint compromise. Those properties require protocol-specific key evolution, deletion and authenticated updates. MLS explains the distinction; citing that standard does not mean either featured product implements MLS.

Design every feature for the breach.

A message can be encrypted while its notification preview is readable. A document can stay in a protected vault while its extracted search text leaves it. An AI summary can reveal the substance of the record it describes.

I would review these paths alongside the main storage flow. A search index, thumbnail, notification, support bundle or summary needs a named reader and a defined lifetime, just as the original content does.

• Minimize what leaves the device. Collect only what the service needs. Identify what remains visible: depending on the system, IP addresses, connection times, ciphertext sizes, group membership or push-routing tokens. Not requiring an email address or phone number does not establish anonymity against correlation.
• Make every reader explicit. Give collaborators, integrations and AI agents narrow, understandable access.
• Keep private processing inside the boundary. Prefer local search and analysis. If selected plaintext is sent to an ordinary hosted AI service, that service becomes a reader for that request. State what leaves the client, who can access it, and how outputs and logs are handled. Consent or a no-training policy does not make that processing zero-knowledge.
• Test recovery and independent backups. An encrypted export is useful only with the keys and software required to restore it.
• Test the promise, not just the perimeter. Copy the database. Take over the backend. Try to enroll an unauthorized device. Verify what remains protected.

Follow one household document from beginning to end. Imagine someone adds a medical bill to a private vault. This is an illustrative design review, not a description of features already shipped in Family OS. The original file is only the beginning of the review.

1. Capture and upload. The trusted client reads the bill and encrypts it before upload. Check temporary files, original filenames and upload diagnostics: protected file contents should not quietly reappear in a log or unencrypted staging copy.
2. Preview and search. A thumbnail or extracted line of text can disclose the diagnosis as clearly as the PDF. Decide where these derivatives are created, which devices can read them and how stored copies are protected. Each copy needs the same explicit reader decision as the original.
3. Notify and share. A lock-screen preview or email saying what the bill contains creates another disclosure path. Show only the intended detail, and make clear whether sharing grants access to a particular document or a larger collection. Recipients can retain content they have already read.
4. Summarize with AI. If the person chooses a hosted service, identify the selected plaintext being sent, the service receiving it and the treatment of prompts, outputs and logs. A locally encrypted original does not make those remote copies private from their processor.
5. Back up, recover and get help. Trace encrypted exports, recovery envelopes, device backups and support attachments. Test restoration with synthetic data and identify who holds the necessary recovery capability. Ask whether any troubleshooting or account-reset route creates an undisclosed additional reader.
6. Delete or revoke. Explain which stored copies are removed, how long backups retain them and which prior recipients may still hold readable copies. Removing the primary record is not evidence that every derivative or export is gone.

This walkthrough changes the design question from “is the file encrypted?” to “where can its information become readable, for whom, and for how long?” It also gives product and support teams concrete decisions they can explain without discussing cryptographic algorithms.

Make the promise testable.

The following are proposed acceptance checks, not reported product test results. For a real release, attach each result to the tested revision, platform, setup and evidence. A source review, a passing test and an independent security assessment answer different questions.

Make each result inspectable. An evidence record should name the claim, tested revision and platform, attacker capabilities, synthetic setup, expected behavior, observed result and supporting artifact. Include the date, reviewer, unresolved limitations and a regression check. Use synthetic content and redact secrets from published artifacts.

Label the result honestly: proposed, executed—passed, executed—failed or inconclusive. A passing case supports the behavior observed under that setup. It does not establish that every alternate path is safe or replace protocol review. Source inspection, executed checks and an independent assessment should remain distinguishable in the evidence record. No new product test results are being claimed in this article.

Concept illustration: the protected boundary includes trusted client code, devices and recovery capabilities. Metadata and availability remain separate concerns. View the full-size trust-boundary illustration.

Three questions to take into your next design review.

Who can grant a new device decryption access? Follow the actual authorization and key-transfer path. Name the capability an attacker would still need after taking over the account service.

Who can recover the keys? Include support processes, organizational recovery, backups and any threshold of trusted participants. Every recovery authority belongs in the reader model.

Who controls the code that handles plaintext? Trace browser delivery, native releases, dependencies and update authorization. Key custody alone does not protect content from a hostile client.

Those questions turn a privacy promise into decisions a team can explain, build and test. They also reveal the product work: clearer device approval, understandable recovery, explicit AI permissions and honest behavior when a key is lost.

The future we should build

Private by construction. Not private by promise.

Make decryption authority a deliberate part of the product—and make its limits understandable to the people relying on it.

See how these questions appear in ChatZeee’s messaging architecture and Family OS’s household workflows.

Project evidence and status. ChatZeee’s case study records source and test-definition review through November 7, 2026, covering plaintext rejection, key wrapping and opaque push behavior; the product is in iOS TestFlight beta. Family OS’s case study records device-approval, record-decryption and first-device-bootstrap test definitions reviewed on November 4, 2026; the product is in development, and its suite and deployment were not rerun for that portfolio review. These records support the specific implementation discussion, not a claim of independent cryptographic certification. The enrollment and document walkthroughs, attacker scenarios and acceptance checks above are explanatory examples and proposed review work, not newly reported product test results or findings of vulnerabilities in either project.

Foundations & further reading

• OWASP Cryptographic Storage Cheat Sheet
• W3C Web Cryptography API
• RFC 9420: Messaging Layer Security

A foundational essay, not a complete cryptographic protocol. Product-specific threat modeling and independent review are essential.