Protected Spaces
Overview
Protected Spaces are Shared Spaces built for the highest-risk data. They require coordinated approval from multiple participating Safes before protected content opens.
Use a Protected Space when one Safe opening the data alone is too much risk. The Space can still be shared across Safes, but access depends on the configured protection policy instead of a single participant acting alone.
Why Protected Spaces Matter
Most systems protect data with one account, one password, or one device. If that one point is compromised, the data is exposed.
Protected Spaces change that model. A Protected Space can require multiple independent Safes to participate before the protected data opens. That makes it useful for:
- family or estate material that needs shared custody,
- sensitive business records,
- operational plans that no one person should be able to open alone,
- high-risk users who need protection against coercion, device theft, or compromise of one Safe.
How It Works
- A Safe owner creates a new Space and chooses the protected option.
- The creation wizard collects the participating Safe Receive Addresses.
- UnoLock sends protected Space setup messages to the participant Safes.
- Participants approve the protected Space.
- When the Space is opened later, the required Safes coordinate approval before protected content opens.
The Safe clients control the protected Space state and message format. The server moves encrypted control data and encrypted Space data, but it does not receive plaintext records, plaintext files, plaintext user metadata, or the keys needed to read them.
Creation Rules
- A Protected Space is created as protected from the start.
- Existing Spaces are not converted into Protected Spaces.
- The protected setup flow handles participant selection.
- Protected Spaces use the Space management UI, not the normal message composer.
- Protected Spaces do not support Space backups.
Security Model
- Multi-Safe approval: opening protected content requires the configured approval policy.
- Independent Safes: participants keep their own Safes.
- Client authority: the clients enforce the protected Space workflow and cryptographic material.
- Zero-knowledge storage: user data and user metadata remain client encrypted.
- Compromise resistance: compromise of one Safe or one server does not automatically expose a protected Space that requires other Safes.
What Protected Spaces Are Not
- They are not a public group chat.
- They are not a file-sharing directory.
- They do not create a directory where other users can find your Safe.
- They do not let the server read the protected Space.
- They do not replace access keys for one-Safe access control.
When to Use Shared vs Protected
Use a normal Shared Space when collaboration is the goal and each participant can open the Space normally.
Use a Protected Space when the shared data is sensitive enough that opening it requires coordinated approval from more than one Safe.
FAQs
Can I protect an existing Space later?
No. Create the Space as protected from the start.
Can a Protected Space be backed up?
No. Protected Spaces do not support Space backups.
Can the server open a Protected Space?
No. The server stores and transfers encrypted data. The clients control the keys and approval flow.
Does a Protected Space share the rest of my Safe?
No. Only the protected Space participates in the protected workflow.