← Back to Home Local Authority Principle →

Local Authority vs Cloud Dependence

Why centralized cloud-first architecture fails vulnerable users, and how local-authority design preserves user agency under degraded or adversarial conditions.

Cloud-first architecture is the dominant pattern in modern software. It offers real benefits: synchronized state across devices, no data loss from device failure, and reduced development complexity. For most users in most conditions, it works.

But for users in degraded or adversarial conditions — no reliable connectivity, confiscated devices, coercive institutions, crisis states — cloud dependence is not a feature. It is a structural vulnerability. The more a system depends on continuous cloud connectivity to function, the more completely it fails when that connectivity is unavailable or unsafe.

What Cloud Dependence Looks Like in Practice

Cloud-dependent systems share a set of identifiable failure modes:

Authentication gate: The user cannot access anything — including data they created — without a successful server round-trip to verify credentials
Read-only fallback at best: When offline, users might see stale cached data, but cannot create, update, or meaningfully interact with their records
No local copy: The canonical data lives on the server; the local device is just a view layer
Sync as a black box: Conflict resolution happens on the server, invisibly to the user
Your outage is their lockout: When the service is down, users lose access entirely, even to their own records
Third-party key custody: Encryption (if present) uses keys the service controls, meaning the service can decrypt and is compelled to disclose

What Local Authority Looks Like in Practice

Local-authority design inverts these properties:

Offline operation is the baseline: The app works without a network connection for all critical functions
Data is owned by the device: The canonical copy lives locally; the server is a sync target, not the source of truth
Sync is transparent: When conflicts occur, the user is shown what conflicted and asked to resolve it
Authentication is local where possible: Device-level auth (PIN, passphrase, biometric) grants access to locally stored data without server verification
Export is always available: Users can retrieve their full data at any time without connectivity or support
User holds the key: Sensitive content is encrypted with user-controlled keys; the server holds only encrypted blobs

Side-by-Side Comparison

Scenario	Cloud-Dependent Response	Local-Authority Response
Network unavailable	User is locked out; app shows error	App functions normally; syncs when connectivity returns
Service outage	Complete data inaccessibility	Local data remains accessible; sync resumes when service restores
Device confiscated	Adversary can log in via web; data fully exposed	Local encryption requires device credentials; remote session revocable
Legal data request	Service must disclose server-held plaintext data	Server holds only encrypted blobs; keys not held by service
User wants to leave service	Export depends on service remaining operational	Export is available at any time from local device
Connectivity is intermittent	Partial operations; risk of data corruption or loss	All operations complete locally; sync handles eventual consistency
Coercive actor has physical access	Device acts as authenticated session; all cloud data accessible	Local wipe removes local data; no live session to exploit

Why Cloud-First Persists Despite These Failures

Cloud-first architecture is not adopted maliciously. It has genuine advantages that make it the default choice for most development teams:

Development speed: Building against a centralized API is simpler than managing local-first state and conflict resolution
Multi-device sync: Users expect data to be available across devices; cloud-first makes this trivial
No device loss risk: If a device is destroyed, cloud-stored data survives
Business model alignment: Server-held data enables analytics, monetization, and retention features
Team capacity: Conflict-free replicated data types (CRDTs) and local-first architectures require specialized expertise most teams do not have

These are real trade-offs. Protective Computing does not argue for eliminating cloud architecture. It argues for recognizing when cloud dependence creates structural risk for vulnerable users, and designing against that risk deliberately.

Designing for Local Authority: Practical Steps

Step 1: Map the Critical Path

Identify the minimum set of actions the user must be able to perform to achieve their core goal. This is the set of functions that must work offline, on a degraded device, without cloud connectivity.

Step 2: Identify Cloud Dependencies on the Critical Path

For each action on the critical path, determine whether it currently requires a network call. Authentication, data reads, data writes, and validation steps are common cloud dependencies.

Step 3: Remove or Defer Each Dependency

Dependency removal strategies

Authentication: Cache a local session token after first authentication; validate locally until token expires
Data reads: Cache records locally on first fetch; serve from cache when offline
Data writes: Queue writes locally; sync to server when connectivity returns
Validation: Run validation logic locally; re-validate against server when connected
Feature flags: Cache flag state; fall back to safe defaults when offline

Step 4: Make Sync Transparent

When the user comes back online, show them what changed, what conflicted, and what was discarded. Do not silently resolve conflicts in ways that could cause data loss.

Step 5: Test the Offline Path

Test every critical path with the network disabled. If anything breaks, it is not yet a local-authority design.

The Offline-First Architecture Pattern

For sensitive applications, the full expression of local authority is an offline-first architecture: data lives on the device first; the server is a sync peer, not the primary. This is detailed in the Offline-First Health Architecture page.

Related Resources

Local Authority principle deep-dive
Offline-First Health Architecture
Designing for Coercion Resistance — How local authority intersects with coercion threat models
Protective Computing Audit Checklist
Protective Computing Specification v1.0

Protective Computing — back to home