← All privacy impact assessments
Privacy impact assessments
This is the register. One file per assessment, an index below, and a rule in
AGENTS.md → A Feature That Touches Group Data Gets A PIA First that says
when a new one is owed.
Nothing in this directory is legal advice. It is the app's own reasoning about its own design, written down so that it can be checked, argued with, and handed to a lawyer as a draft rather than a blank page. The legal brief is parked by owner decision until the app has been tested with families we know (issue #330); these documents are what that brief will be built from.
Sources: the primary texts these assessments cite are kept in docs/sources/, with a verification log.
What a PIA is here
A short, specific document that answers: what this feature collects, whose it is, where it goes, what could go wrong, what stops it going wrong, and — where children are involved — why the design is in their best interests. It is written before the code, against the design, and revised when the design changes.
It is not a form to be filled in. A PIA that says "risk: data breach; mitigation: RLS" has cost time and bought nothing. The part that earns its place is the column headed structural vs conventional: whether a property is enforced by the database, a key, or a trigger — or by somebody remembering to keep the copy right. Both are legitimate answers. Confusing one for the other is what a PIA is for.
When one is required
Standing rule: any feature that creates, reads or moves group data, or is likely to be accessed by children, gets a PIA before code.
The draft Children's Online Privacy Code makes this a gate rather than paperwork: s 38(3) of the exposure draft requires the assessment before a new service or feature likely to be accessed by children is provided, and s 39 requires the register to be published. The Code's own examples of covered services name "applications that track early childhood development" and "family photo sharing applications" (s 5, Note 1) — two modules of this app, verbatim — so the question of whether it reaches us has a boring answer.
In practice that means a PIA is owed for:
- a new surface that stores anything a member types, photographs, or records about a person;
- anything that sends group data to a model, a provider, or another group;
- anything that changes who inside a group can see what;
- any change to the child-safe variant, the guardian invariant, or the age bands;
- any feature whose absence is currently load-bearing in the ban self-assessment — a recommender, a ranked or endless feed, anything that shows a member how others engaged with what they posted, disappearing content, discovery, or a cross-group surface.
That third-to-last item became the whole position on 2026-09-08. The app is outside the under-16 rule because it has no recommender feature and no logged-in feature, so a feature that reinstates one is not a PIA topic — it is a change of legal status. Read the self-assessment's §10 before building anything that displays a count, a tick, a heart, a reaction, a "seen by", or a ranking of the household's own content.
A PIA is not owed for a refactor that moves no data, a copy change that makes an existing claim narrower, or a bug fix. When in doubt, the cheap version is the honest one: open the template, fill in the first three sections, and if nothing in them is interesting, say so in four lines and move on.
Where the register is published
The repository is private, so a file in docs/pia/ does not satisfy "published online"
(exposure draft s 39). The register is published on the public site — a subdomain of
brendanpatch.com on Firebase Hosting — as part of WS17 of the privacy programme. That site
does not exist yet. Until it does, this directory is the register and the publication
obligation is outstanding; the obligation itself does not bite until the Code is registered,
which is due 10 December 2026.
Published means published: an assessment in here is written on the assumption that a member of the public, a parent, or the OAIC will read it. Nothing goes in that could not be shown to all three. Where an assessment records a residual risk the owner has accepted, it says so in those words rather than leaving the reader to infer it from a silence.
The register
| Assessment | Feature | Status | Written | Last reviewed |
|---|---|---|---|---|
2026-09-ban-self-assessment.md |
Whether GroupApp is an age-restricted social media platform (Online Safety Act s 63C) | Current — pre-child-accounts | 2026-09-07 | 2026-09-08 — position: not an age-restricted platform, because it has neither a recommender feature nor a logged-in feature (Rules s 4A), so the purpose question is never reached. The three feedback features (chat read receipts, photo likes, message reactions) were removed for every member on 2026-09-08 to settle it there. The recommender reading is recorded as arguable and is now the principal residual risk; the §7A stocktake is retained as evidence and no longer gates child accounts |
child-accounts.md |
Child accounts, the guardian invariant and the child-safe variant (#282 §4) | Built (WS8, 2026-09-08) — revised against the code; residuals in §11 | 2026-09-07 | 2026-09-08 — WS8 shipped 20260908043933: children_allowed, invite_child, the guardian invariant as a trigger, restrictive policies for the variant, guardian consent and child assent in the ledger, server-side refusals. §5.2 says which rows are structural, which are conventional, and which two (baby tracker, public reviews) are NOT built and stand as residual risk. WS9 (2026-09-08, issue #220) shipped the child-directed privacy policy Code s 23 asks for (CHILD_PRIVACY_POLICY); §9's terms row and §12A's s 23 / s 23(6) lines now read Met |
cross-group-events.md |
Cross-group RSVP invitations and event groups (#331) | Built — Steps A, B and §8 | 2026-09-07 | 2026-09-09 — §8 re-assessed as built: the event-group photo wall and the copy flow shipped with WS12, each of the owner's three conditions marked structural or conventional. 2026-09-08 — WS6 built (§1A) and WS7 built (§1B). §1B records the owner withdrawing the draft's deletion timer before it was built: a group that deletes itself is the 4A(6) time-limited limb, so an event group ARCHIVES and is kept until a host admin deletes it. Also: the kinds are standing/event, 29 restrictive policies plus triggers where a SECURITY DEFINER writer would walk past one, and the SECURITY-DEFINER gap stated rather than closed outside the baby domain |
intentions.md |
Intentions, beneficiaries and the motivation layer (#342) | Built — WS22 shipped 2026-09-08 (#342) | 2026-09-08 | 2026-09-09 — status moved to built; the assessment was written before the code and revised against it the same day. 2026-09-08 — the first feature that asks a member to record why they are doing something and who for, so the interesting risks are crowding out and guilt rather than access control. Nothing in it is counted, scored or ranked, which is also what keeps it clear of the features step |
ceremonies.md |
Ceremonies — a shared, model-read family-meeting thread with children in it (#344, WS23) | Built — WS23 shipped 2026-09-08 (#344; #347 and #353) | 2026-09-08 | 2026-09-09 — status moved to built; the outcomes a ceremony records now land through WS22's own claim, thanks and intention actions (#353). 2026-09-08 — the two modes disclose differently (in thread the facilitator receives everyone's free text; in person it receives only its own script and the tapped outcomes, and the conversation never touches a server); thread messages are deleted seven days after close by a sweep shipping in the same PR, and only structured outcomes carry forward — the grievance-archive answer |
baby-tracker.md |
Baby tracker, as it ships today | Retrospective | 2026-09-07 | 2026-09-07 |
photo-wall.md |
Group photo wall, as it ships today | Revised — WS12 built | 2026-09-07 | 2026-09-09 — photographs, captions and album names sealed on the device (#223); an event group admits a photo row only where encrypted = true; a report goes to that group's admins rather than to us, because we can no longer look at the photograph; copies carry provenance and a durable removal tombstone. The plaintext-at-rest finding is narrowed to the history the job has not reached, and the claim in the app is dated for that reason |
Status means:
- Draft — gates X — the feature is not built. The assessment is the precondition, and the workstream it names must not start until this document has been reviewed by the owner. What it describes is a design, not a description of the app; every mechanism in it is marked planned.
- Retrospective — written after the fact, against the code as it stands. Honest about being late. Its value is the baseline it sets for the next change to that surface.
- Current — a live assessment of the app as it is, expected to be re-run on the trigger it names.
Reviewing one
Every assessment carries a review trigger rather than a review date, because a calendar reminder for a feature nobody has touched is noise and a feature that changed last week does not wait for the quarter. A trigger is a specific event: this table gains a column, this surface starts sending data somewhere new, this absence stops being true.
Two triggers apply to every assessment in here and are not repeated in each one:
- The Children's Online Privacy Code is registered (due 10 December 2026). Every citation in this directory is to the exposure draft; section numbers may move and the drafting may change. On registration, every assessment is re-read against the registered instrument.
- The app stops being invite-only. Today
enforce_email_allowlist_on_signupmeans every account was created by a person who was vouched for by an existing member. Several arguments in here lean on that. Opening sign-up (#282 §2) invalidates them and every assessment is re-run.
Conventions
- Cite the primary source, not a summary of it, and say when you could not reach the primary source. The ban self-assessment does exactly that about one page that would not load.
- Say "planned" about anything planned, in the sentence that describes it, not in a footnote.
- Mark anything unverified as unverified rather than asserting it.
- Prefer a specific residual risk that has been accepted over a general mitigation that has not been built.