← All privacy impact assessments

PIA: Telling existing members what changed in the privacy policy

Status: Built on 30 September 2026, the same day this assessment was written; not yet released. Written: 30 September 2026 · Last revised: 12 October 2026 Nothing here is legal advice. Children's Code citations are to the exposure draft; section numbers may move on registration (due 10 Dec 2026).

Revised 12 October 2026, before implementation. For the v3.5 release, a brief guide to new features follows a successful tap on OK. It is a separate page within the same sheet, after the acknowledgement is saved. It thanks adults who continue testing and points them to features they can try. It asks for no new agreement, sends no data, records no further answer and can be closed at once. It does not appear if the acknowledgement fails or the notice is dismissed. The guide is tied to this release's policy version, so a later policy notice cannot replay stale feature claims. The existing adult-only and personal-device limits also apply. If the app closes between the successful acknowledgement and the guide, the guide may not reappear; this is acceptable for a helpful introduction that does not gate a feature or convey a required disclosure.

Revised 10 October 2026. A newer app may use the record to enable a faster typed-assistant route that sends a direct adult request to TypeSafe for verification. The server checks that the member saw that policy version. Closing the notice keeps the ordinary assistant available; it does not amount to withdrawing assistant or overseas-processing consent. The new data flow is assessed separately in the faster commands assessment.

As built, 30 September 2026. This notice was built and merged the same day this assessment was written, matching the design below with no deviation we found. It has not reached any member yet: it takes effect once our next database release ships and a member's app has updated to the version built alongside it. Until then, a member who joined before a policy change still has no way to find out about it, as this assessment's own opening paragraph describes.

1. Purpose and scope

When our privacy policy changes, a member who joined before the change has had no way to find out: the app asked them to read the policy once, at sign-up, and never again. This feature shows an adult member a short list of what changed, once per version, with a way to read the full policy, and remembers that they have seen it so it does not show again.

It is a notice, not a request for agreement. Tapping OK records that the member has seen it. The ordinary assistant remains available to somebody who closes it without tapping OK; the faster typed-command route is not used until they acknowledge the updated disclosure. They are shown the notice again the next time the app starts.

Out of scope: the policy's own wording (it is assessed where each change is made), and the separate Children's Privacy Policy, which has its own version and is not covered by this notice.

2. Data involved

Kind Whose Children's? Sensitive? Free text?
privacy_policy_acknowledgements: the member, the policy version (for example v1.19-2026-09-30), and when they tapped OK The member's own No — the notice is shown only to adult accounts No No: the version is written by the app, never typed

Not collected: whether the member opened the full policy, how long the sheet was open, whether they closed it without tapping OK, and anything about other members. None of those would help anybody, and each would be a record of how a person reads.

3. Flows and locations

Data Device Supabase (Sydney, ap-southeast-2) GCP Model provider Region
Acknowledgement Written when the member taps OK; read when the app starts Stored as plain rows, readable only by that member through member access The assistant server checks the version before using the faster route — Australia

4. Legal basis and consents

None. This is deliberately not recorded on the consent ledger: that ledger is the record of consent acts, each of which is somebody agreeing to something, and an acknowledgement of a notice is not that. Writing it there would put something that is not a consent into the one table whose value is that every row is one. The policy's account-data paragraph names the record.

5. Risks and mitigations

Risk Who is harmed Mitigation Structural or conventional? Residual
Other members of a group learn when someone last opened the app, from the time they acknowledged a change The member The record is in its own table readable only by its owner, not on the account row co-members can read Structural (row-level security, no group predicate) None
A member is nagged, or a notice is read as a demand to agree The member Shown once per version; closing it is always possible; the wording says it asks for nothing; a failed check shows nothing rather than guessing Conventional (copy test refuses "agree", "accept", "consent") Low
The record is edited to suggest someone saw a version they did not The member No update or delete permission for any member; the database sets the time; a member can write only their own row Structural (grants and row-level security) A member can still record a version string of their own choosing for themselves; from the faster-command release, a forged current version could activate that route on a capable client

6. Structural versus conventional

11. Sources