Storage Encryption Boundaries for Local AI

Direct answer

A storage-encryption review begins by naming what is stored and what protection is claimed. App-private storage, Android file-based encryption, a database abstraction, and an application-managed ciphertext file are not interchangeable. Android notes that internal app storage is restricted by the app sandbox, while sensitive data in external storage may need application encryption; device encryption describes a different threat boundary. Android Keystore can protect key material from extraction and constrain its uses, but it does not encrypt every file automatically. ANDROID-PRIVACY-01 and PRIVACY-01 support an evidence-led boundary inventory, not a claim that Cove data is currently encrypted.\n\nLimit this topic to persistent application data at rest: transcripts, generated results, settings that reveal activity, and derived indexes that actually exist. Exports are a separate handoff, requiring their own format, recipient, and encryption analysis. Cloud backup and device migration are separate lifecycle routes to inspect, not a reason to conflate file encryption with data leaving the device. A phrase such as encrypted at rest should specify which database pages, files, temporary copies, backup copies, keys, and device states are covered.\n\nBuild a data-location map from observable code paths. Record directory or database, private versus shared storage, readers, temporary files, and backup inclusion. Do not call an app-private directory end-to-end encryption: the sandbox is an access-control boundary, not a cryptographic threat model. Equally, do not infer an application encryption layer just because Android applies device encryption. State what was verified from manifest configuration, storage APIs, cryptographic calls, and restore behavior.\n\nIf app-managed encryption exists, document key creation, alias, authorized purposes, authentication requirements, rotation or invalidation, and behavior when the key cannot be used. Keystore guidance explains that key material may be non-exportable and operations restricted, but properties depend on configuration and device. Test missing, invalidated, and inaccessible keys without deleting unrelated data. Never store secret key bytes beside ciphertext and call that protection. Use official Android cryptography guidance for algorithm choices; this page is not an implementation recipe for Cove.\n\nTest lifecycle states that change access: foreground use, process recreation, screen lock, reboot, credential unlock where applicable, app update, backup, restore to the same device, restore to another device, and app-data removal. Outcomes depend on Android version, storage configuration, and backup policy. A file protected while locked may be readable after unlock; a key may not survive reinstall or migration. Do not claim hardware-backed keys unless the implementation verifies that property rather than assuming every device has it.\n\nInspect actual files and requests using synthetic content. Check database journals, write-ahead logs, thumbnails, temporary plaintext, caches, crash reports, and debug exports in addition to the primary table. Confirm backup exclusions match policy and that restore does not silently bring back deleted records or stale consent. A single encrypted-looking database file is not evidence for every copy, backup, or transient buffer. Keep production content out of test fixtures.\n\nThe final evidence should name build, Android version, data inventory, manifest and backup settings, key events, tested locked and unlocked states, restore results, and exclusions. Phrase conclusions narrowly, such as which data class used an observed mechanism in this build. Do not promise absolute device security, resistance to a compromised operating system, or universal encryption. Keep exports, model files, diagnostics, and remote services out of the claim unless separately tested. This precision makes privacy language auditable and prevents one successful crypto test becoming a broad product guarantee.

A user reviews saved AI notes after migrating phones

A user stores private transcripts and derived search records, enables system backup, and migrates to another phone. The product team must determine which records return, whether keys remain usable, and whether an older backup can reverse a deletion or consent change.

Decision

Inventory data and key lifecycle separately, test configured backup paths, and scope encryption statements to the exact files and states observed.

Expected outcome

The review distinguishes sandbox access, device encryption, app-managed ciphertext, backups, and exports without promising universal protection.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Storage location inventory
• Platform configuration
• Locked and restored device tests

A privacy claim needs a data inventory and traffic evidence. A local-model label by itself is not proof.

Implementation workflow

1. Inventory persistent and temporary data. Trace databases, files, journals, thumbnails, caches, plaintext temporaries, and derived indexes to storage locations, readers, retention paths, and cleanup code.
2. Write the precise protection statement. For each data class distinguish sandbox access control, platform encryption, app-managed encryption, backup behavior, and explicit export, citing the evidence.
3. Inspect key ownership and failure behavior. If encryption exists, record Keystore alias, authorized operations, authentication policy, rotation, invalidation, and recovery when the key is unavailable or lost.
4. Exercise lock, restart, update, and restore. Use synthetic records across process death, reboot, device lock and unlock, app update, backup restore, reinstall, and migration states in scope.
5. Verify deletion and user disclosure. Delete selected records, inspect derived copies and restored state, then align user-facing privacy wording with evidence, exclusions, and failure outcomes.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• Each encryption statement names the data classes, copies, key assumptions, and device states it covers.
• Backup, restore, key-loss, and deletion outcomes are documented without equating app-private storage with app-managed encryption.
• Exports and remote paths are excluded unless separately reviewed, and no absolute security or universal-device claim appears.

Decision table

Failure patterns to prevent

• Using “encrypted” without scope
• Ignoring exports and backups

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Android privacy and security
• Android Keystore system
• Android cryptography guidance
• Android sensitive data in external storage

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions