Access layer
Everyday Access, the Secure Vault, and Secondary Access are intended to expose distinct sets of information.
Technical architecture
A system organized around
controlled visibility.
This conceptual architecture records the current design direction: local critical paths, separate access states, narrow backend responsibility, and explicit recovery tradeoffs.
System boundary
The device is the primary security boundary.
Protected operations are intended to happen locally. Network features should remain outside the critical path and receive only the minimum information their function requires.
Architecture target / guided sequenceLocal control. A changed representation. Limited service scope.
Optional local ruleDEVICE CONTEXT
Access-state controllerPROTECTEDSelected on device
Secure Vault
PRIVATE NOTE
Readable only inside this trust zone8F 2C A1 7D 9B 44
Optional encrypted material
8F 2C A1 7D 9B 44
Stored or processed without a readable representationNo reverse controlThe service-side model contains no key or decrypt action.
Outside intended readable scope
- Vault content
- Key material
- Local context rules
Stage 01 / 07A rule begins on the device.
Optional context is intended to be evaluated locally rather than becoming a service-side activity record.
Conceptual architecture · mobile product in developmentFrom tap to key
What happens when you use the app.
Pick an action to see where the keys are, what leaves your phone and what Liberty Lock can see. These are design targets for a product in development, not an audited implementation.
Design target
Add an item to the vault
You save a password, phrase, journal entry, photo or document.
- Where’s the key?
- Created and kept on this phone, protected by the platform where supported.
- What leaves the phone?
- Nothing. The item is encrypted and stored on the phone.
- What can Liberty Lock see?
- Nothing about the item.
Four layers
From visible state to service boundary.
Protection layer
Protected content is planned to use local encryption and platform-supported key protection. Specific algorithms remain design targets until implementation evidence exists.
Control layer
Prepared actions and optional context rules are intended to change state on the device.
Service layer
Accounts and optional encrypted backups are intended to remain separate from readable protected content. Restoring a backup needs the recovery kit, which Liberty Lock never holds.
Tradeoffs
Security properties create product costs.
Recovery versus confidentiality
If the company could always recover a key, the company could also become a path to protected content. The planned model keeps recovery with you through a printed recovery kit, which means a lost kit can’t be replaced. The final model will be documented before launch.
Automation versus context collection
Location rules (coming later) are useful only if they don’t create a new record of where you go. Local evaluation is the design target. A proposed Panic Mode would deliberately share location with contacts you choose, so it is treated as a separate, opt-in feature.
Speed versus assurance
Prepared state changes must feel immediate, but no numeric performance claim will be published until supported-device testing exists.