PIA: A group decides whether its chat and photos are encrypted, and holds the password that opens them

Amended 1 November 2026 — Device-only retired (privacy-levels §3E). A Device-only group that moves to Standard keeps its chat-and-photo setting and its Group Password as they are. Before our server is given a copy of its key, an owner's or admin's phone makes a new key, which joins the password's archive as any new key does; the keys it used while Device-only are never given to our server.

Status: Draft, written on 18 October 2026 before any of the code. It assesses one change: from the app update released after 18 October 2026, a new group's chat and photos are stored as ordinary text in our Australian database, and an owner or admin turns encryption on by setting a Group Password that opens the group's whole key archive. Everyday records — tasks, the calendar, shopping, meal plans, the baby tracker's words, ceremonies, games, the daily brief and each member's own plan — are already ordinary text and are assessed separately; this change does not touch them, nor each member's own conversation with the assistant, nor email forwarded to a group, nor the cards the assistant raises. Written: 18 October 2026 · Last revised: 19 October 2026 (§3.4, §3.5: the question on Home; §3.6: the password check; the correction below: the feature is dormant for every group until the separated-key rollout reaches it) Nothing here is legal advice. Children's Code citations are to the exposure draft; section numbers may move on registration (due 10 Dec 2026).

The claim to be careful with, stated before anything else. After this change, the honest sentence about a group's conversation and its photographs has an "if" in it. A group that has turned encryption on has chat and photos that nobody but its phones can open, including us. A group that has not — which is every group made after this update, until somebody chooses otherwise — has chat and photos that sit in our database in readable form, protected by the rules in that database, by encryption in transit, by encrypted disks and backups, and by our rule that nobody here reads a group's content. No copy anywhere may say chat and photos are encrypted without saying "when your group turns it on", and none may say we cannot read them when a group has not turned it on. The privacy policy, the promise register and the Privacy screen move in the same release as the code.

Correction, 19 October 2026 — until the separated-key rollout reaches a group, this change offers that group nothing, and that is now what the app says. A Group Password is sealed under the separated keys assessed in the key architecture, and that arrangement is not switched on yet. Two things must both be true before any group can set a password: the platform-wide key_scheme_v2 rollout is on, and every active member has a phone running a build that can read the separated keys. Until both are true, no group can set a Group Password — not only the groups that already encrypt; every group, including one made today. It is not that a group must first hold a separated key version: setting the password is what creates one. It is that nothing can create one while the rollout is off, or while a member's phone could not read the result.

So a group in that position is now offered nothing at all, rather than offered something that fails when it is used:

no "Set a Group Password", and no password step when a group is made;
no question on Home — neither for a group that already encrypts nor for a creator who asked to be reminded;
no password check (§3.6);
no "turn encryption off" either. A dormant feature must never leave switching protection off as the only button that works.
In Manage group → Keys the group reads one sentence that names the real reason instead: that Group Passwords are not available for it yet and nothing changes for now, or — when the rollout is on and only some phones are behind — that the members whose phones need updating are what is blocking it, named if this phone already holds their names and "some members" if it does not. No refusal blames a member's phone when the rollout is the blocker, and none blames the rollout when the phones are. Where the check itself could not be finished — the phone is offline, a read failed — the row says it is checking, and claims nothing either way.

Nothing about a group changes while it waits. A group that already encrypts keeps reading everything on the phones it has; a group that is off stays off and readable to its own members; and a group that already holds a Group Password can still see it and still type it on a new phone, because reading a password that exists is not a change to anything.

This also narrows §3.1's audit correction below. A group that is not ready is now refused before any key is advanced, so an attempt that cannot succeed no longer leaves the group on a fresh key version it gained for nothing, and the refusal names the rollout or the phones rather than offering "upgrade" guidance no member can act on.

1. Purpose and scope

Why: so that a family can read its own conversation and its own photographs on any phone, on the first day, and so that a group that wants them protected from us can have that too, with one thing to remember instead of a key ceremony.

The design before this change gave every group the second without ever offering the first. Chat and photos were encrypted under a key that lived only on the group's phones, which is strong, and the costs were paid by people who had not chosen them:

A new phone sees locked bubbles until another member's phone connects it, and a group whose only key-holding phone is lost or wiped loses its conversation and its photographs for good, unless somebody wrote down a twelve-word phrase.
Nobody chose it. A group that would rather have its photographs recoverable than private from us had no way to say so, and a group with a real reason to want them private had nothing stronger than the arrangement everyone else got by default.
It is now the only thing a key protects. Since the everyday records went back to ordinary text, chat and photos are the last content under a key on a phone, so "is this group's content encrypted?" can be one question with one answer a member can see and change.

The change makes it a choice, with the password as the way to hold the key. Setting one wraps every version of the group's key archive, so a member's fresh phone with only the password reaches every message and every photograph the group has, not just the newest ones.

In scope: group chat messages and the quotes replies carry; photographs on the group's photo wall with their captions, album names and comments; the Group Password itself, the wrapped copies of the group's keys it opens, and the copy of the password the group's own key seals so that an unlocked phone can show it; the switch that says whether a group encrypts; and the copies of the group's keys written automatically for members' registered phones.

Out of scope, and covered elsewhere: everyday records, which are already ordinary text; each member's own conversation with the assistant, under that member's own key; email forwarded to a group, encrypted on arrival to the group's inbox key; the cards the assistant and the inbox raise; the split between the key our assistant server may hold and the key it may not; and how a phone is connected to a group's key by another member, which this change leaves in place.

2. Data involved

Kind	Whose	Children's?	Sensitive?	Free text?
The Group Password, typed by an owner or admin, held only in the phone's memory while it is used and by whatever password manager the member saves it in. A member known to be 18 or over can also have it shown on screen, copied, shared, or displayed as a square code for another phone to read	the group's	no — it is a secret, not a record about a person	yes: it opens everything the group has encrypted	typed, so it can contain anything, including a name
A copy of the password sealed under the group's own current key (`groups.sealed_group_password`), so an unlocked phone can show it to an adult or re-wrap after a key change	the group's	no	as above, to anyone who already holds the group's key	no
`group_password_wraps` — one row per group, password generation and key version: the group's key for that version, wrapped under a key derived from the password, with the derivation's salt and cost settings	the group's	no	as above, to anyone who knows the password	no
`groups.chat_photo_encryption` (`on` / `off`) and `groups.password_generation`	the group's	no	no — a setting and a number	no
Copies of the group's keys written for members' registered phones, so a phone that is already in the group opens content without anybody typing the password	each member's	a child's phone is one of these	the content they open is	no
The derived key cached on the phone in the platform's secure store, per group and generation, so a member is not asked again	that member's	a child's phone holds one once an adult has unlocked for it	as above	no
Chat messages, photographs, captions, album names and comments — stored encrypted or as ordinary text depending on the group's switch	the group's	very often: a family photo wall is mostly children	yes: photographs of children, conversations about health, school and money	yes

Strict necessity (s 38(2)(b)). Nothing new about a person is collected. The password, its wraps and the switch are about a group's key, not about its members; the only new personal information in the feature is the ordinary fact of which phone a copy of a key was written for, which the app already records for every key it distributes. What changes for the content already collected is the form it is stored in, and therefore who else could read it.

Not collected, and could have been. We do not collect the password, a hash of it, a hint, a record of who typed it or how many attempts failed, or anything that would let us test a guess. There is no reset: a group that forgets its password and loses every phone that holds the key cannot be helped by us, and the copy says so before the password is set.

3. Flows and locations

Data	Device	Our database (Sydney)	Our assistant server (Sydney)	Model provider	Region
The password, as it is typed	typed and used on the phone; derivation runs there	never sent	never sent	never	Australia
The wrapped key rows and the sealed copy of the password	made on the phone	stored, readable only to active members of that group	no key for them	—	Australia
Chat and photos in a group that has not turned encryption on	written and read as ordinary text	stored as ordinary text; disks and backups encrypted	reads them with the asking member's own access, inside that member's request	only what a member sends to the assistant, as before	Australia
Chat and photos in a group that has	encrypted on the phone before they are sent	ciphertext	holds no key for them	never	Australia
A copy of a group's key written for another member's phone	made by a phone that holds the key, locked to the receiving phone	stored as the group's other key copies are	—	—	Australia
The line that tells the group encryption was turned on, changed or turned off	—	written by our database itself, in the same step as the change, into the group's own chat where every member reads it	—	—	Australia
Logs	—	—	outcomes, not words, and never the password	—	—

3.1 Setting a password, in order

An owner or admin who is not a child account, on a phone that holds the group's key (or is making it, at group creation), types the password twice, or once with autofill.
The phone checks it against the rules in §5 and refuses a password that fails them.
The phone derives a key from the password and a fresh random salt, wraps every version of the group's key archive it holds, seals the password under a checked scheme-2 Tier 1 key, and writes all of it in one step with the switch set to on. Either all of it lands or none of it does.
The same phone then writes a copy of the group's keys for every registered, un-revoked phone of every active member, so no other member types anything. §8 records what that trusts. Since 20 October 2026 (B1) "registered, un-revoked" also means "added by a live sign-in that hasn't been removed": a phone row can only be added by our server binding it to the sign-in that adds it, a removed sign-in can add none, and removing a phone ends its sign-in, so it can read no copy, archive row or sealed password afterwards. Phones added before binding stay unbound and are still wrapped for until they are removed; removing one signs the member's other sign-ins out.

Audit correction, 18 October 2026: a legacy scheme-1 root can have a server copy, so it must never seal a Group Password. Setting a password first uses the existing verified rotation flow to reach scheme 2; if the rollout or the group's phones are not ready, the operation is refused and the refusal names which of the two it was. The existing key_scheme_v2 platform flag remains an operator-controlled prerequisite; setting a password never enables it. A group whose registered phones cannot read scheme 2 cannot publish a password archive, and neither can any other group while the rollout is off. Corrected 19 October 2026: the readiness check now runs before any rotation, so a group that cannot succeed is refused with no key advanced and no archive row written — where an earlier build advanced the group's ordinary legacy key first and only then reported that it could not go on. An existing password sealed under a legacy root remains usable for old history but cannot wrap another root, even through a cached derived key. An eligible admin visit rotates an already-exposed current root once and asks for a different password; replacing it preserves the historical recovery archive until the replacement is saved. A new password cannot undo copies of old passwords, roots or content already obtained by a server or device.

3.2 Opening with the password on a new phone

A member signs in on a new phone, which holds no key. The password is typed, or read with the camera from the square code another phone in the group is showing; either way it is used on the phone and never sent. The phone reads the rows for the group's live password generation, derives the key from it, and opens every version it finds — so the group's whole history opens, not only what was sent since. It then writes its own copy for itself, caches the derived key in the platform's secure store for that group and generation, and tells the group in the usual key notice. A wrong password opens nothing and changes nothing: there is no record of the attempt, because there is nothing a server could check it against.

3.3 Changing the password, and turning encryption off

Changing it writes the new generation's rows and deletes the previous generation's in the same step. A replacement must cover every version in the previous archive. A phone missing historical roots first recovers them with the existing sealed password through the ordinary verified unlock flow; if it cannot, the change is refused and directs the admin to a phone that can read the older history. Generation and coverage checks run under the same database lock as replacement and archive extension, so a concurrent repair cannot lose its recovery route. The old password no longer opens the live archive after replacement; previously copied wraps are not revoked. Turning encryption off sets the switch back: new messages and new photographs are stored as ordinary text from then on, while everything already encrypted stays encrypted and stays readable on the phones that hold the key. We do not rewrite a group's older photographs into readable form when it turns encryption off, and §8 records what that means for a member who expects otherwise.

3.4 The groups that already encrypt

Eleven groups hold encrypted chat and photos today. The change switches them to on with no password, so every phone reads exactly what it reads now, and their owners and admins are shown one choice: set a Group Password, or turn encryption off. The choice waits on their Home screen as well as in Manage group until they make it, because without a password a member's new phone still depends on another phone in the group. Subject to the correction above: while the separated-key rollout has not reached the group, neither half of that choice is offered to anybody — not the password and not turning encryption off — and the group simply keeps reading what it reads today. "Ask me later" puts it away on that phone for two days, and then it comes back. Nothing of theirs is re-encrypted, moved or made unreadable, and nobody is locked out while they decide.

3.5 Being asked again

When a group is made, its creator has three answers to "Encrypt chat and photos?": encrypt them, no thanks, or ask me later. The question itself only appears when the group could actually act on it (the correction above): while the separated-key rollout has not reached the group, the step is skipped in silence and the group is simply made with encryption off, which is every new group's starting point anyway — a question whose only honest answer is "not yet" is not worth asking. The last two both leave encryption off. "Ask me later" brings the same question back to that one person on Home two days later, with "Ask me later" and "No thanks" beside it again; "No thanks" ends it. A group that is simply off is never reminded, by anyone, because off is every new group's starting point and a standing nudge to undo it would sit over every new group's Home.

Whether, and when, to ask again is kept on that phone only: no row is written, nothing is sent to our servers, and nobody else in the group can tell that the question was put off. A different phone, or the same phone after the app's data is cleared, simply asks the legacy question again or, for a group that is off, never asks — which is the safe direction in each case. Only owners and admins are ever asked, never a shared display, and never in an event group, whose encryption cannot be changed.

3.6 Checking the password is still known

A password with no reset is only useful while somebody remembers it, and the first person to find out it is forgotten is the member whose new phone needs it. So, now and then, the app asks an owner or admin of a group that has a Group Password to type it — rarely: a month after their phone first sees the password, then every six months after each right answer. "Ask me later" asks again in two days; "I've forgotten it" opens Manage group, where they can see or change it, and starts the schedule again. Changing the password starts it again too.

What is typed never leaves the phone. The phone already holds the group's key, opens the password with it, compares the two and keeps neither; the screen says so beside the field. Nothing records that a check happened, was skipped or was answered wrongly, except the phone's own note of when to ask next, which is device-local in the same way as §3.5. Only the people who may already see the password are asked: owners and admins known to be 18 or over, on a phone holding the key. A child account, a member whose age the phone has not read, an ordinary member, a shared display and an event group are never asked. A password filled in by a password manager passes the check, which is the intended outcome: the point is that the group can still get at it, not that it is memorised.

4. Legal basis and consents

No new consent purpose. The consent purposes the app relies on keep their meaning; nothing new is disclosed to anyone, and nothing new reaches a model. This is an APP 11 question — what reasonable steps we take to protect what we hold — and a question of what a member is told.
A group-level choice made by one person for everybody. An owner or admin turns encryption on or off for the whole group, and the group is told: our database writes a line into the group's own chat in the same step as the change, naming who made it and which way it went, so the telling cannot be skipped by a screen that forgot. The line carries no part of the password and nothing about the content it covers. That is the same shape as the privacy level, and it is recorded here because it is a choice about other people's conversations and photographs, including children's. It is not presented anywhere as a consent, because it is not one.
The default is the less protective one, and we say so. A new group starts with chat and photos as ordinary text. Our standing principle is a useful feature with a clear disclosure and a real choice; here the useful default is chosen for every new group, the choice is one tap away in Manage group, and §8 accepts the consequence rather than presenting the default as neutral.
Members are told, once, in the product. The privacy policy moves a version in the same release, with this change named in the list every member is shown once, and the promise register changes with it: it stops saying chat and photos are encrypted and starts saying they are encrypted when a group has turned it on.
Children. A child account can read and write in a group exactly as before and is never given the password. The child-facing privacy page makes no claim about chat or photo encryption, so it does not change; §7 is the reasoning about what the change costs a child.

5. Risks and mitigations

The four rules a password must pass, which this assessment proposes and §8 accepts the limits of: at least 10 characters; made of at least five different characters, so that a long repetition is not mistaken for a long password; not one of a small built-in list of about sixty common passwords, compared in lower case and again with punctuation and trailing digits removed, so a familiar password with a year on the end is refused as well; and it must not contain the group's name, compared without regard to case or spaces. Two edges of that last rule are worth stating rather than leaving to be discovered: it is skipped for a group whose name is shorter than three characters, because almost any password contains a two-letter string, and the common-password list holds whole passwords rather than forbidden words, so a password that merely contains an ordinary word is accepted. Nothing a member types is sent anywhere to be checked: all four rules run on the phone. A Suggest a strong one button offers a generated password, and a weak/okay/strong line describes what was typed without refusing it.

Risk	Who is harmed	Mitigation	Structural or conventional?	Residual
Somebody who obtains a copy of our database guesses a group's password offline and opens every message and photograph the group ever encrypted	every member of that group, and every child in its photographs	the four rules above, enforced on the phone before a password is accepted; the key is derived with a deliberately slow, memory-hard function (Argon2id, 19 MiB, two passes) over a per-group salt, so each guess costs real time and memory; the Suggest a strong one button	conventional: the rules are code on a phone, and the cost function is a structural slowdown, not a barrier	a determined guesser beats a weak password. Ten characters that pass our list are not a strong secret, and the derivation cost is the same for a weak password as a strong one. §8 accepts this in those words
A group never turns encryption on, and a copy of our database yields its conversation and its family photographs in readable form	every member; every child photographed	per-group rules inside the database rather than in application code; private file storage with short-lived links; encrypted disks and backups with our own backup key held outside our cloud providers; our rule that nobody here reads a group's content	structural as to who may read; conventional as to anybody with legitimate access	the words and the pictures themselves. This is the risk the default accepts
A member known to be an adult views the password and passes it on — writes it in the chat of another group, or gives it to somebody who has left	every member	only a member whose account is known not to be a child, on a phone that already holds the key, sees View, Copy, Share or the code; everyone else never sees it; changing the password takes one transaction and ends the old one	structural as to who the app shows it to; conventional as to what an adult then does	an adult can always hand the password on. That is what a shared password is; the change screen is the answer, and the copy says so
A phone is wrapped for automatically, so a phone that should not have the key gets it without anybody comparing safety words	every member	only registered, un-revoked phones of active members are wrapped for, and that list is itself protected per group inside the database; a removed member's phones are revoked and are not wrapped for; every copy is recorded in the group's Key history	structural as to the list the wrapping reads; conventional as to the absence of a human check	the approval ceremony is skipped for phones already in the group. Anyone who can get a phone onto that list before the password is set receives the key with it
A child's new phone cannot be opened by the child, because the child may not be given the password	the child	any member's phone that already holds the key wraps for every registered phone of every active member, so a child's new phone is served the next time an adult's phone does that; the child sees the same "not on this phone yet" explanation as anybody else	conventional (it is code and a human being available)	a child waits on an adult. §7 says why that trade was made
A key change made on an ordinary member's phone leaves that new key out of the password archive, so the password would not open the newest content	a member setting up a new phone during the gap	every phone already in the group keeps reading, because its own copies of the key are untouched; the gap is detected and shown on the group's Keys screen; the next owner or admin to open that screen fills it automatically, with nothing typed and no password needed	structural as to the refusal (the same owner-or-admin rule as everywhere else); the detection and the repair are conventional — code and its tests	the gap lasts until an owner or admin opens the app. A member who sets up a new phone inside that window opens everything except the newest versions, and no notice goes out while it is open
A group turns encryption off and assumes its older photographs are now readable everywhere	that group	the copy at the switch says, beside the option, that older photographs and messages stay as they are and stay readable only on the phones that hold the key	conventional, test-pinned (the sentence is in the copy module and the copy test reads it)	older content stays unreadable to a phone that never held the key. We do not rewrite it
Opening a phone with the Group Password is not announced as that. It is recorded as a phone being given the group's key, and in a group that saved a twelve-word recovery phrase years ago the line names the phrase instead	every member of such a group, who would be reading that history to notice a phone nobody expected	the act is still recorded, still names the member and the phone, and still appears in the group's own history of key events, so no unlock is silent; what is missing is a line that says which secret was used	conventional — it is which description the notice code reaches first	a member reading that history cannot tell a Group Password unlock from the other ways a phone is given the key, and in a group with a saved phrase the words name the wrong secret. We have not corrected it in this change
Somebody actively running our servers serves a phone the wrong rows, or withholds them	the group	out of scope by design, as it is for the rest of the key architecture: we do not claim protection against a server that lies to phones	neither — it is a stated limit	stated, in this document and in the policy
Copy somewhere says chat and photos are encrypted, without the "when your group turns it on"	every member reading it	one copy module carries every sentence this feature shows; the promise register and the policy move in the same release; the scan that refuses overclaiming privacy copy runs over that module; a copy test refuses a claim of end-to-end encryption and refuses saying we cannot read chat when a group has encryption off	conventional, test-pinned	a surface nobody added to the scan. The release lists what it changed
The password is shown on a screen, as words or as a square code, where somebody else in the room reads it or photographs it	every member of the group	it is shown only to a member known to be 18 or over, on a phone that already holds the key, and only after they ask for it; the code is taken off the screen after five minutes so it is not left sitting there; the copy beside it says plainly that anyone who has it can read the group's chat and photos on a new phone	structural as to who may ask for it; conventional as to the room they are standing in	a password on a screen can be read or photographed by anyone who can see it, and a code scanned inside those five minutes keeps working afterwards — the five minutes clears the screen, it does not expire the secret
The password is typed into the wrong box, or kept where it can be read — a note on a fridge, a message in the group's own chat	the group	autofill is offered, so the phone's own password manager is the easy path; the copy asks for it to be saved in a password manager and never suggests the group's chat	conventional	a password manager nobody uses. We cannot see this and would not know

6. Structural versus conventional

Structural

The server holds nothing that opens a group's encrypted chat or photos. It holds the key wrapped under a password it never receives, and a copy of the password sealed under the group's own key, which it also never receives. Both are useless without something a phone has.
Only the active members of a group can read its rows, enforced per group inside the database: the wrap rows, the sealed password, the switch, and the content itself. There is no permission for anybody else, and no public role on any of them.
Only an owner or admin, who is not a child account and is an active member, can set, change or turn off — checked inside the database function that does it, not only in the app.
A password change is one transaction. The new generation's rows land and the previous generation's are deleted together; a half-done change cannot leave two live passwords.
The rows cannot be edited or deleted by anybody from a phone, and only an owner or admin who is not a child account can add one, at the group's live generation. There is no permission to update a row in place or to remove one. An earlier design let any member of the group add a row for a key version their own phone held; that was changed before the feature shipped, and the paragraph after this list says why.
The group is told, by the database, in the same step as the change. The line that says encryption was turned on, changed or turned off is written inside the same transaction as the switch itself, so a group cannot be moved quietly: there is no path that changes the setting and separately decides whether to mention it. It names who did it and which way it went, and nothing else.
A phone that does not hold a key cannot be wrapped for by a stranger: the list of phones a wrap may be written for is the group's own registered devices, protected per group.
Where the content lives when encryption is off is protected by the same per-group rules as everything else a group writes, and photographs by private storage with short-lived links.

Why only an owner or admin may add to the archive. The first design of this rule let any member add a row for a key version their own phone could prove it held. Checking that design before it shipped found that the proof was one the member could write for themselves — the record that says "this phone holds that key" is one an ordinary member may create — so any member of the group could place a row of their own choosing in the archive. It would not disclose anything: a row that was not made with the real password cannot open anything, and a phone that tries it rejects the row twice over. What it could do is take the slot. Each key version has exactly one place in the archive, so a member who filled a version's slot with junk would leave the honest copy with nowhere to go, and that version of the group's conversation and photographs would stop opening by password for everybody — repairable only by an owner or admin setting the password again. The rule is now the same one that guards every other part of this feature: an owner or admin who is not a child account, and nobody else. The attempt that found this is kept as a test, written the way the member would do it rather than the way the fixture did.

Conventional, and pinned by automated checks where we can

The password rules. They run on the phone, in one tested function. A future change could weaken them, and nothing in the database would notice; the derivation cost would not change either way. This is the single most important line in this document: the rules are the only thing standing between a group and a guessable password.
Who is shown the password. The database decides who may read the sealed copy at all; which members see View, Copy and Share is the app's own rule about child accounts, pinned by tests.
The honesty of the copy, including the "when your group turns it on" qualifier everywhere, the refusal to claim end-to-end encryption, and the sentence at the off switch about older content.
"We don't read your group's content." For a group with encryption off, this and the access rules are what stand between us and its conversation and photographs.
The automatic wrapping skipping the approval ceremony. It is code, with tests.

7. Best interests of the child

Children are plainly involved: a family photo wall is mostly photographs of children, a group's chat is about them, and a child aged 13 to 17 can hold an account and post in both.

What it gives a child. Their family can see their own photographs on whichever phone they are holding, including a parent who has just replaced a phone, a grandparent added last week, or a carer in a second home. The failure this removes is not theoretical: a locked photo wall on a new phone is the most common way a family loses access to its own pictures of its children, and a family that cannot see its photographs in this app keeps them somewhere with no access rules at all. A group that wants its children's photographs kept from us can now say so, which it could not before, and the group's whole history opens on a child's new phone instead of starting blank.
What it costs a child. For a group that does not turn encryption on — the default — a copy of our database yields photographs of children and conversations about them in readable form, where before it yielded ciphertext. Children do not make this choice and are not asked. The benefit of the default is taken mostly by the adults, who get a working photo wall on every phone; the cost sits with the child, whose picture is the thing in the clear.
A child is never given the password, and that is a decision with two sides. It protects the group: a child's phone, which is likelier to be shared, watched or taken, cannot leak a secret it was never given. It costs the child independence: their new phone waits for an adult's phone to wrap for it, and they cannot restore their own access the way an adult can. We chose the protection, consistent with the rule that under-18s are not given the group's secret.
The safer design, and why it was not chosen. The obvious alternative is encryption on by default for every new group, with a password required at creation. It was considered and not chosen: it puts a key ceremony in front of every family in the first five minutes, it makes a forgotten password a permanent loss of a family's photographs of its children, and it recreates exactly the lock-out the previous design was abandoned for. The middle course — on by default for groups with a child in them — was also considered and not chosen, because the group's shape changes after it is made, and a design whose protection silently appears and disappears as members join is one nobody can reason about. If that trade should be made the other way, this is the document to say so in, before the code lands.
Where the child's interest and the parent's diverge, the parent's won in the default and the child's won in who holds the password. Both are open to disagreement.
What a child is told. The child-facing page already says that everyone in their group can see the chat, the tasks, the calendar and the photos, and that our rule is that nobody who works on the app reads them. That stays true and does not change for this feature. The page has never told a child that chat or photos are encrypted, so there is no claim to withdraw.

8. Residual risk we accept

The password rules are the only defence against a weak password. The derivation is slow and memory-hard, and that is all it is; it does not make a guessable password safe. A group whose admin types ten characters that happen to pass our list, and whose encrypted content is later taken with a copy of our database, can be opened offline by somebody patient. We accept this because the alternative — six words made by the app — was tried and asks more of an ordinary parent than they will carry.
A new group's chat and photographs are readable to anybody who can read our database, until somebody turns encryption on. That is the default, it is chosen for every new group, and what protects those words and pictures is access control and our own rule, not cryptography.
A member known to be an adult can read the password and pass it on. We show it so that a family can get back in; we cannot control where it then goes. Changing it is one screen away.
Phones already registered to a group are wrapped for automatically, with no approval ceremony. This is the choice that makes "turn it on" painless for everybody else in the group, and it means the protection is only as good as the group's own list of phones at that moment. Since B1 (20 October 2026) that list holds only phones added by a live sign-in that hasn't been removed, so a phone its member removed cannot put itself back on it; a phone added before binding is on it until it is removed.
Older photographs and messages stay encrypted after a group turns encryption off, so a phone that never held the key still cannot read them. There is no pass that rewrites them, and we are not building one in this change.
We cannot help a group that forgets its password and loses every phone holding the key. There is no reset, by design, and the content is gone.
A child's new phone depends on an adult's phone, because a child is never given the password.
A key change made on a phone that is not an owner's or an admin's leaves a gap in the password archive until an owner or admin next opens the app. The gap is detected and shown on the Keys screen and then repaired without anybody typing a password, but while it is open a member setting up a new phone opens everything except the newest versions, and no notice goes out to say so. We accept it because the alternative — letting any member add to the archive — is the design §6 explains we withdrew, and because every phone already in the group reads normally throughout.
Somebody actively running our servers, changing what they serve to phones, is outside what this design protects against, as it is for the rest of the key architecture.
Opening a phone with the Group Password is not announced as a Group Password unlock. The act is recorded in the group's history of key events, with the right member and phone named, so it is not silent; but it reads as a phone being given the key, and in a group that saved a twelve-word recovery phrase it reads as that phrase being used. Giving the act a line of its own is left to a later change.
A copy of our database made while a group had encryption off keeps holding readable chat and photographs after the group turns encryption on, and our own backups keep older copies for up to 90 days.
The group's switch is one person's decision for everybody. The group is told in its chat, by the database, in the same step as the change — but it is told, not asked, and no other member has to agree.

9. Review trigger

Anybody proposes a server-side reset, hint, recovery code or escrow for the Group Password — the absence of all of those is what this document's first structural claim rests on.
The password rules change, or the key derivation's cost settings change.
Encryption stops being off by default for a new group, or becomes conditional on the group's members.
A pass is proposed that rewrites older photographs or messages into readable form when a group turns encryption off.
Anybody proposes showing the password to a member who is not known to be 18 or over, or to a shared display.
The automatic wrapping to registered phones is widened — to another member's unregistered phone, or across groups.
The notice that tells a group encryption moved stops being written by the database in the same step as the change, or stops appearing in the group's chat.
A breach, or any evidence that a group's password reached us or appeared in a log.
The Children's Code is registered, or sign-up stops being invite-only.

10. Checklist against exposure draft s 38(2)

s 38(2)	Requires	Answered in
(a)	the nature, scope, context, flow and purposes of the handling of children's personal information	§§1–3
(b)	why the collection is strictly necessary	§2 — nothing new about a person is collected
(c)	how the collection is lawful and fair	§4
(d)	whether the handling is consistent with the best interests of the child, with reasoning	§7
(e)	how the entity complies with this Code and the Act	§§4 and 6
(f)	the risk of harm to children	§§5 and 7

s 38(3): this assessment was written before the change was built. s 39: it is listed on the published register.

11. Sources

The assessments this builds on: docs/pia/content-encryption-v3.md (the everyday records that are already ordinary text), docs/pia/key-architecture-v2.md (the root key per group version, the Tier 1 / Tier 2 split, the key notices and the automatic sharing of a group's earlier keys), and docs/pia/chat-access.md (how a phone is connected to a group's key today).
The assessments this amends: docs/pia/photo-wall.md, docs/pia/privacy-levels.md, docs/pia/child-accounts.md.
The design this assesses, and the decision behind it: docs/decisions/2026-10-18-group-password-is-the-on-switch.md, which supersedes docs/decisions/2026-10-13-group-history-and-key-recovery.md §(b), and docs/group_password_and_key_recovery_plan.md.
The switch, the table and the two database functions named here are created by the migration for this change under supabase/migrations/; the per-group access rules are the row-level security policies defined with them.
The key derivation and its cost settings: lib/crypto/recovery.ts (RECOVERY_ARGON2); the password archive, the unlock and the automatic wrapping: lib/crypto/keyring.ts; the password rules: lib/groupPasswordRules.ts, with lib/__tests__/groupPasswordRules.test.ts.
Every user-facing sentence in this feature: constants/groupPassword.ts, with lib/__tests__/groupPasswordCopy.test.ts; the promise register and the privacy policy that move with it: constants/privacyPromises.ts and constants/legalTexts.ts, with the copy tests under lib/__tests__/.
Our own written rule that nobody here reads group content in production, and the register in which a permitted query against a member table is recorded, both kept with our engineering rules.