Who can read shared data in a local-first app?

A local-first app keeps a full copy of the shared data on each participating device. That is what lets it work offline, and it settles the first part of the access question: whoever holds a copy can read it.

The Ink & Switch essay on local-first software makes the consequence explicit. Centralised systems rely heavily on access control and permissions, but those concepts do not apply directly when every user has a copy. Any user who has a copy of some data cannot be prevented from locally modifying it, and others can only choose whether to accept those changes. The Keyhive notebook from the same lab puts it another way: unlike a cloud app that can keep data behind a web API, local-first runs a complete copy of the application at each replica.

So the useful question is not “who is allowed to read this?” but “which devices will this data reach?”

Local-first apps can still use servers for backup and for relaying changes between devices that are rarely online together. What those servers can read depends on what they receive.

• If changes travel to the server as plaintext, the server’s operator can read them.
• If devices encrypt end to end before syncing, the server only moves and stores bytes it cannot read. The local-first essay describes this, and Keyhive’s design calls it removing read access from sync servers altogether.

Encryption does not hide everything. A server that carries ciphertext still sees when it arrives and how large it is, and Keyhive notes a real tension here: sync protocols benefit from more metadata, while cryptographic protocols aim to minimise it. The article on whether encryption hides metadata goes further.

Keyhive observes that local-first applications today often rely on “security through obscurity”, treating a hard-to-guess document identifier as the key. Its example: by default, anyone who knows an Automerge document’s ID can write to it. That works only while the ID is shared with exactly the right people, access is all or nothing, and nobody ever needs to be removed. If the ID leaks, the document is open to anyone.

Choosing which data to sync is not the same as deciding who may receive it either. In Offline Protocol, a space is an existing MLS session or group, and setInterest scopes which documents a device replicates within a space. The shared state guide is explicit that this is not a substitute for membership authorization, and that different access boundaries need separate spaces.

With end-to-end encryption, the readers are the holders of the keys. In MLS, the IETF’s group messaging protocol (RFC 9420), a member is a client included in the group’s shared state, and so has access to the group’s secrets.

Removing someone changes what they can read from then on, not what they already have:

• In MLS, a Remove proposal followed by a Commit provides new entropy to every member except the removed one, so the new epoch’s secrets are not known to them, and removed users can no longer receive messages.
• Keyhive’s notebook notes that while future write access can be revoked, anyone who already has the data and the key can still read that data.

That is why a design that needs to share something with a smaller audience should put it in a separate group or scope, not in a document the wider group already holds. The article on how group encryption works explains the key changes behind this.

On a single device, the operating system separates apps. Android’s documentation says the system prevents other apps from reaching an app’s internal storage directories. That protects the data from other apps, not from a person using the unlocked phone, and not from backups.

Backups extend the reader list. Apple says iCloud Backup includes app data for the apps on the device, unless the app stores that data in iCloud Drive. A backup is one more copy, protected by whatever encryption and account security the backup service applies.

• List every place a copy of shared data can reach: devices, servers, relays, backups and exports.
• Encrypt end to end before data leaves the device if servers should not read it.
• Use one group or scope per audience, and keep data that needs a narrower audience out of wider documents.
• Treat removal as protecting future changes only. For sensitive content after a removal, start a new document in a new scope.
• Keep secrets out of anything that syncs to a wider audience than the secret needs.