Liberty LockExplore product
Liberty Lock
PrivacyTerms
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.

Conceptual architecture sequence showing local input, access-state selection, a protected object changing from readable text into a cipher representation, a controlled boundary crossing, limited service scope, and information that never crosses.
Architecture target / guided sequenceLocal control. A changed representation. Limited service scope.
Trust zone A · local deviceUser device
Optional local ruleDEVICE CONTEXT
Access-state controllerPROTECTEDSelected on device
Protected Vault
PRIVATE NOTE
Readable only inside this trust zone
Planned key protectionPLATFORM DEPENDENT
Device edgeControlled boundary
8F  2C  A1  7D  9B  44
Encrypted material only where an optional feature requires it
Limited zone B · externalService scope
Optional encrypted material
8F  2C  A1  7D  9B  44
Stored or processed without a readable representation

No 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 development
Four layers

From visible state to service boundary.

01

Access layer

Everyday, protected, and secondary access are intended to expose distinct sets of information.

02

Protection layer

Protected content is planned to use local encryption and platform-supported key protection. Specific algorithms remain design targets until implementation evidence exists.

03

Control layer

Prepared actions and optional context rules are intended to change state on the device.

04

Service layer

Accounts, subscriptions, and optional encrypted backup are intended to remain separate from readable protected content.

Tradeoffs

Security properties create product costs.

Recovery versus confidentiality

If the company can always recover a key, the company may also become a path to protected content. The final recovery model must make that tradeoff explicit.

Automation versus context collection

Context-aware behavior is useful only if it does not create a new record of sensitive location or behavior. Local evaluation is the design target.

Speed versus assurance

Prepared state changes must feel immediate, but no numeric performance claim will be published until supported-device testing exists.

Related

Read the security posture.

See which statements are current facts, design targets, and deliberately omitted claims.

Security posture