Tradeoffs I chose
- No forward secrecy for album content. Members keep every epoch key so they can open old photos. Anyone who fully compromises a member's phone can open everything that member could.
- No automatic recovery after a compromise. There is no ratchet that heals over time. Recovering means removing the affected member, which starts a new epoch.
- Removal only protects the future. Miuchio deletes the album from a removed member's phone when it learns of the removal, but it cannot take back screenshots, copies saved outside the app, or keys and photos kept by a modified app.
- New members see the whole history. An invite delivers every earlier epoch key. There is no option to join without history.
- One admin per album, for now. Only the admin can invite, remove and start a new epoch. While the admin's phone is away, a removal cannot be completed and uploads to that album pause. Letting any member start the new epoch is what I'm working on next.
What a malicious server could still attempt
The server cannot decrypt photos or keys. It is still trusted with things encryption does not cover:
- Substitute a key at first contact. Pinning catches later changes, but the first key seen is trusted. Comparing safety numbers is the defence. See Trust and verification.
- Substitute a key during an invite. An invite does not check the invitee's key against an existing pin before delivering the album keys, even for a returning member, so a substituted key receives them. A later warning cannot take them back. See Trust and verification.
- Show members different versions of a key change. Members verify their own wrap, but not the admin's signed list of everyone who received the key.
- Hide, reorder or replay photo records. There is no signed list of an album's photos yet.
- Misreport who uploaded a photo. Uploader identity is recorded by the server, not signed by the uploader.
- Refuse service. It can delete data, withhold it or stop responding. Encryption does not provide availability.
What the server can see
| Information | Visible to the running server? | Notes |
|---|---|---|
| Photo contents, album titles, member names, profile photos | No | Encrypted on the phone |
| Your email address | At sign in | Passed to the email provider to send the code. The database stores only an HMAC |
| Which albums you are in, and your role | Yes | A database copy does not name you, but it shows which memberships belong to the same person. See Metadata and the social graph |
| Who signed an epoch change or a key delivery | Yes | Even a database copy shows it, by checking signatures against stored public keys |
| Number, size and timing of uploads | Yes | Sizes are exact; padding is not built |
| When membership and keys change | Yes | Default timestamps are stored rounded to the hour; revocations and key receipts are exact |
| Your network address and when you are connected | Yes | Inherent to talking to a server |
Work that is not finished
- Members cannot yet verify the admin's signature over a whole epoch change.
- There is no signed list of an album's photos.
- There is no backup and no multi-device support yet. The server will not accept a new identity key for an existing account, so a reinstalled app cannot take over that account's albums.
- Used one-time prekey private keys are not yet deleted from the phone.
- Encrypted file sizes are not padded.
- A person's memberships share one handle across albums. A separate handle per album is planned; see Metadata and the social graph.
- There is no post-quantum key agreement.
- The design and code have not had an independent security review.