Memory & control

Source/event record · Guide · prepared 19 September 2026

A privacy promise is only as good as the six screens a user can control

A repeatable audit turns a broad privacy policy into observable choices about microphones, training, memory, retention, export and deletion.

Prepared for local review · Site publication: not set · 507 words

Companion apps invite unusually intimate disclosure, so a policy-page skim is not enough. The useful question is whether a person can find, understand and reverse the product’s important data choices. This audit records what the interface actually permits without pretending that a visible toggle proves what happens on a server.

Inspect six control surfaces

Start with microphone permission, model-improvement or training choice, saved memory, chat retention, data export and account deletion. For each, record the path from the home screen, the default state, the wording shown before consent, and whether the choice can be reversed. Apple’s privacy guidance says permission should be requested when a feature needs it, while Google Play’s user-data policy calls for clear disclosure, consent and account deletion. Those are useful baselines, not certifications of any particular app.

Separate three kinds of evidence

Label each finding interface, documentation or inference. A screenshot of a disabled microphone permission is interface evidence. A retention period in a privacy notice is documentation. The belief that deleting a memory also removes training copies is an inference unless the provider says so. This separation prevents a polished settings page from carrying more evidentiary weight than it deserves. Also note platform, app version, region and date; controls can differ across all four.

Run a reversible test

Use a harmless hypothetical fact, such as “my test drink is cedar tea.” Save it only if the product offers an explicit memory control. Ask what is remembered in a new conversation, correct the fact, then disable memory and repeat. Do not enter real health, financial, workplace or relationship details. Record outputs, but score only observable behavior: control found, state changed, correction reflected, and deletion route explained. A single successful trial does not establish reliability.

Use a compact scorecard

  • Findable: reached in two minutes without search or support.
  • Specific: explains the data and purpose, not merely “personalization.”
  • Granular: one choice does not bundle unrelated uses.
  • Reversible: the user can change course later.
  • Verifiable: the app reports the resulting state.

Mark unknown rather than awarding zero when evidence is absent. The ICO’s privacy-by-design guidance asks organizations to limit personal information to what is necessary throughout a lifecycle; an outside audit cannot confirm compliance, but it can expose where users lack practical agency.

Make one decision from the result

Suppose training is optional but its switch is buried, memory can be edited, export arrives as readable text, and deletion gives no completion estimate. A cautious user might disable training, keep only low-sensitivity memories, test the export, and ask support for the deletion timeline before subscribing. The audit earns its keep by changing a bounded decision. It should not manufacture one privacy score that hides different priorities or imply that a clean interface verifies back-end behavior.

Keep the result proportional

The output should be a dated control map, not a declaration that an app is “private.” Pair it with the policy-reading guide for contractual claims and the data-minimization diary for day-to-day behavior. Controls deserve credit when they are clear; uncertainty deserves a label when they are not.

Sources & reading trail