← All privacy impact assessments
PIA: Connecting a phone to encrypted group content
Status: Written and reviewed before implementation, then checked against the implementation. Explicit approval by an owner or admin after comparing the phone's safety phrase, bound setup links and a scheduled retention job are implemented. Local automated checks cover the access boundaries; phone interactions still need checks in use. The feature has not yet been released. Written: 23 September 2026 · Last revised: 19 October 2026
Amendment, 19 October 2026. The Group Password the amendment below now leads with is dormant until the separated-key rollout reaches a group — and that is true of every group, not only the ones that already encrypt: it needs the platform-wide rollout to be on and every active member to have a phone that can read the separated keys. It is not that a group must hold a separated key version first; setting the password is what creates one. This flow is unchanged by that, and deliberately so: what is dormant is setting a password, not using one. A group that cannot set a password yet therefore simply has none, and a phone waiting for that group's key is shown only the ask to have the phone connected — the same path, and the same screen, as a group that never set a password, with no mention of one it has never had. A group that already holds a Group Password keeps opening a new phone with it however the rollout stands, because that is a read of a password that exists. See the assessment of the change itself, whose 19 October correction records what is hidden while a group waits.
Amendment, 18 October 2026. A group now decides whether its chat and photos are encrypted at all, and the group's recovery phrase is no longer the safety net this assessment points at. From the app update released after 18 October 2026, a new group's chat and photos are stored as ordinary text, and an owner or admin turns encryption on by setting a Group Password that opens every version of the group's key archive — so a member's new phone reaches the group's whole history with the password alone. That changes what the notice described below offers first. Wherever a phone is waiting for the group's key, the notice now leads with opening the content with the Group Password, and asking somebody to connect the phone comes second: the password is the one way back that needs nobody else to be awake, holding their phone, or still in the group. Both are offered together — the ask is not withdrawn, and the notice does not try to work out in advance whether this person can use a password, because it cannot: it knows a phone is waiting, not whether the group ever set one or how old the member is. Who may actually use it is decided on the screen the first option opens, and that screen is where the limits live: a child's account, or a member whose age we do not hold, is told the content will arrive once somebody else in the group opens the app, and is never shown a password field; a group that never set a Group Password is shown only the ask, with no mention of a password it has never had. The phrase path stays for groups that saved one, and everything else here — the approval by an owner or admin, the four-word safety phrase, the bound setup links, the retention of a request — is unchanged. A group with encryption off has nothing for this flow to connect a phone to: its chat and photos are readable to any active member's phone from the start. See the assessment of that change.
Amendment, 30 September 2026. Separating the key our server may use from the key it must never hold was built the same day it was assessed and describes one automatic path this assessment's review triggers name: if no member helps a waiting phone within 24 hours, our server may give it the key for tasks and calendar only, with a notice in the group's chat and a push that any member can use to stop or revoke it. That path is built but has not been released, and even once it is, it only runs for a group whose admin has separately turned it on — never by default. Chat and photos stay available only through the member approval described here, whatever a group's choice on that switch. That assessment carries the threat model; nothing here changes until that path is both released and switched on for a group. Amendment, 3 October 2026. The QR code and camera step are gone: many phones in a group have no way to scan a code, so the option protected almost nobody. A waiting phone now shows its own four-word safety phrase and asks its owner to get an owner or admin to share the key. Each owner and admin sees one card per request in their Assistant, showing the same phrase (read from the server's record of the requesting phone) and the sentence "If the person you are sharing the key with knows this phrase you can safely share the key with them", with a Share key button. Share key runs the same request-bound approval as before, with the same database checks. Plain members are no longer asked. Comparing the phrase is a check the two people make, by voice or in person; the app cannot tell whether they did. Amendment, 14 October 2026. Two of this assessment's review triggers, silent automatic grants and older-version archive sharing, are now exercised, and the key architecture assessment §3.7 assesses them, written before the code. Once an owner or admin of a group taps "Share this group's earlier messages with everyone", members' phones automatically send the group's earlier keys to every person's phone that already holds the current key, with no further tap. This flow is unchanged: approval and setup links still send the current key only, and a phone connected this way receives the earlier keys afterwards, once it holds the current key and its person has been told. Nothing here makes an unrecognised phone a recipient: a phone must already hold the current key and have shown it with that key's token. Keys made before phones could check them have nothing to check a copy against, so the admin's tap is the vouch for them, made with the same trust as their admin role. The limit stated in §8 still applies, and the key architecture assessment states one more: in a group not yet on the newer key arrangement, a breach of our assistant server could use the whole-key copy kept there to make a phone look like one that holds the key, and so receive the group's earlier keys.
Amendment, 15 October 2026: content a phone can't open, and an open request in the chat. Written before the code, and revised the same day before release after the first version was tried on a test phone. When a phone can't open some of a group's content, it now shows only what it can. A list leaves out an item whose main words it can't open: a task, a photo, a shopping item, a forwarded email, or a note in the baby log. An item whose title it can read stays, and its detail screen says which part, such as the notes or the place, isn't available. Messages it can't open are folded into one short line, such as "3 messages aren't available on this phone". Each screen that leaves something out says so at the top: "Some content isn't available on this phone." That notice says what to do next. A screen never says there is nothing there when it has left something out. A part this phone can't open can't be edited on it, so saving never writes over it.
The next step depends on who can help, and since 18 October 2026 the first offer is the one that depends on nobody: wherever a phone is waiting for the group's key, the notice leads with opening the content with the Group Password on this phone. It offers that to anyone who reaches it, because the notice cannot know whether the group has a password or how old the reader is; the screen it opens applies both limits, and tells a member who cannot use a password what will happen instead. Everything in this paragraph is offered as well, beneath it, and remains the whole of what a member is offered where no password can be used. The notice names up to two of the group's owners and admins whose phones can connect this one ("Ask Alex or Sam to connect this phone"), and offers Ask to connect, which files the same request described here, with the same limits. If the person's own other phone can connect it, the notice says to open the app there instead, under Settings → Devices, which is the existing way a member adds their own phone. If no phone can help, it offers the group's recovery phrase, but only when a saved phrase covers the current content; otherwise it says to contact us. While the list of who can help is still loading, or can't be read, the notice still offers Ask to connect and never says that nobody can help. When a phone holds the current key and only older content is unavailable, it says so, and offers an owner or admin the existing way to share older messages; it makes no promise that older content will arrive. The request a phone makes by itself is still made only once per key, and the notice says it was made automatically. A person can ask again after cancelling, because this time they asked. A shared display never shows the notice and never asks.
The card an owner or admin sees now asks them to have the person read out the four words shown on their new phone, and to continue only if they match; its button reads "Connect Sam's phone", and after it is tapped the card says "Connection approved", because the new phone still has to open what it was given.
Naming who can help discloses nothing new: members already see each other's names and roles. Whether a named person's phone can connect this one is worked out on the phone from records it already reads.
While a request is open, each owner and admin of the group also sees one line about it at the top of the group chat, on a phone that can connect the other: "Sam wants to connect a new phone to Sandbox Household". Tapping it opens the same card as their Assistant, so a helper who never opens the Assistant still sees it. The line is not a stored message. Each owner's or admin's phone draws it from the request record it can already read, and it goes when the phone is connected, the request is cancelled or expires, or that person puts the card aside. Other members, children included, never see it, so nobody new learns who is waiting, and who is asked is unchanged: a child's request still goes to the group's owners and admins. Showing the line only to owners and admins is our app's choice, not a database rule; as before, the database lets any member whose phone holds the current key read a request's metadata. No new information is collected, and nothing new is sent to a model or in a push.
Nothing here is legal advice. This assessment describes the handling of information and the risks we accept for this feature; it does not determine compliance with future law.
1. Purpose and scope
A person already in a group can ask another member to connect their phone to the group's encrypted content. This fixes a situation where a longstanding member cannot use chat because their phone was registered after the group's encryption key was first created.
The person asks from chat; their phone shows its four-word safety phrase. Every owner and admin of the group receives an action card showing that phrase and explicitly shares the key, or chooses to send a short-lived setup link. The words are generated by the app, not an AI model. Access includes messages, photos and other content protected by the shared key version; it is not restricted to chat. This does not add a person to a group or expand the content they are entitled to through membership.
2. Information involved and necessity
| Information | Whose and why needed | Children and sensitivity |
|---|---|---|
| Group, account and device identifiers | Binds a request and grant to the intended member's phone | May identify a child member; no new health information |
| Key version, request state and expiry | Prevents stale, duplicate or expired grants | Operational access metadata |
| Approving account/device and grant method | Attributes the security action and supports checking it | A member's act, not engagement with posted content |
| Encrypted device wrap | Gives the intended device the group's key without sending plaintext to the server | Protects potentially sensitive group content |
| Setup token hash and encrypted offer | Authorizes a short-lived redemption for one account/device | Sensitive capability metadata; the token itself is not stored server-side |
| Private dismissal | Lets a helper put a card aside | Visible only to that helper |
No new free-text field, contact list, phone number, message body or photo is collected. Existing roster names and fixed device platform labels are resolved on the phone. No viewed/ignored counts or named read receipts are collected or displayed.
3. Flows and locations
Request metadata, token hashes and encrypted device wraps are stored with the group's existing records in the Australian database. Private device keys remain on the phones. The helping phone encrypts the group key for the requesting phone; the database can validate the authorized destination but cannot decrypt the wrap or prove that it contains the correct key.
The action card lives on the Assistant screen as a deterministic interface. Neither its keys, setup token nor request details are sent to an AI model. The same actions are available outside the Assistant screen so access does not depend on AI availability, consent or age restrictions.
A generic push notification may pass through existing overseas push infrastructure. It contains identifiers and fixed operational copy, never a key, token, device name or encrypted message.
The helper may explicitly open the system share sheet to send a setup link through another service. That service can see the link, the group name in its accompanying message when available, and the fact of sharing. The link contains a random token in its fragment, not the group key or recovery phrase. It is useful only to the bound account and device. The public landing page is static and does not redeem the token or store keys.
Pending requests expire after 24 hours; setup offers after at most 15 minutes. Ended records are scheduled for deletion after seven days by the included daily sweep. Delivered requests that were never acknowledged expire after seven days and then follow the same deletion schedule. Account/group deletion removes associated new records. These jobs must be deployed with the feature before it is available to members.
4. Permission and user choice
The request is initiated by its member. The helper's explicit approval authorizes the transfer; a model cannot make that decision. A setup link is sent only through a share sheet the helper chooses to use. No new standing consent purpose is created: these are individual operations to restore access under existing group membership. Cancelling an unfulfilled request invalidates its offers. Access already received cannot be recalled by deleting a request; removal and key rotation govern future access.
5. Risks and mitigations
| Risk | Mitigation | Remaining limitation |
|---|---|---|
| A stolen account or compromised directory presents an attacker's device as a member's phone | Explicit approval by an owner or admin, who is shown the requesting phone's safety phrase to compare with the requester; immutable device identity, pin checks, active membership and revocation checks | The phrase comparison is a convention between two people: the app cannot see whether they compared it, and approval still trusts the account/directory. It is not independently verified identity or key transparency |
| A forwarded or intercepted link enables another phone | Bind to account, device, group and version; random token, expiry, one-time redemption | The delivery provider can see the link; an attacker also controlling the bound account/device has stronger access |
| Two helpers or a retry corrupt access | Transactional request handling and append-only wraps preserve one winning grant | A malformed ciphertext from an authorized helper cannot be verified cryptographically by the database |
| A removed member or stale device receives a key | Recheck membership, device revocation and current version at the atomic grant boundary | Content a device already received cannot be taken back |
| A person is told setup succeeded although it failed | Distinguish delivery from recipient-confirmed local opening; preserve retryable errors | The database trusts the recipient's completion assertion |
| A child is excluded because they have no Assistant tab | Provide the same access controls in chat/Devices without an AI call | Another usable device or recovery backup is still required |
| An owner or admin sees in the chat who is waiting for the key | Shown only to the people already asked through their Assistant, drawn from the request itself and gone when it ends; no stored message, no count, no record of who looked | Other members whose phones hold the key can still read request metadata through the database, as before; the app does not show it to them |
| Requests become a way to nag or observe others | Deduplicate and rate-limit requests; one notification per delivery identity; private dismissal, no viewed/ignored reporting | A requested security operation still creates a short-lived operational record |
6. Structural and application safeguards
Database privileges, row security and guarded transactional operations enforce membership, request ownership, destination, version, expiry, one-time redemption, private dismissal and append-only grant behavior. Existing cryptography makes a device wrap openable by its target private key, not by another member merely holding a URL.
The app enforces actual local key readiness, pin checks, recipient decryption before showing connected, separation from models, log redaction, and which members are shown a card (owners and admins). Showing a card only to owners and admins is an app convention: the database still decides who may approve. These require behavioral tests and review; they are not database guarantees.
7. Children
Restoring a child's access to their existing household helps them participate without asking them to manage encryption terminology. The device gets no additional membership rights. Requests contain the minimum account/device identifiers needed for the operation and no child birth date or health information. Children have a route that does not invoke an AI assistant. Helpers are told that approval opens the group's encrypted content, which may include personal information about children as well as adults.
Mandatory in-person verification would provide a stronger identity check but would prevent remote recovery and perpetuate the reported exclusion. Comparing the safety phrase in person remains possible, and we accept the ordinary account-approval tradeoff explicitly.
8. Residual risk accepted by this design
Ordinary approval relies on account authentication and the device directory. A fooled helper can authorize an attacker's device; we do not claim WhatsApp-style key transparency. A group member who already holds the key can disclose it outside this flow. No cryptographic system can withdraw content already opened on a device. A setup link is a convenient delivery mechanism, not additional protection against an operator who controls the directory. Historical versions not included in a grant may remain unreadable, and losing every usable device and recovery backup can permanently lose access. Since 14 October 2026 a group can turn on sharing of its earlier keys (see the amendment above), which narrows the last two points for that group; an earlier key no admin's phone holds can still stay unreadable for a member who never had it.
9. Review triggers
Review before adding silent automatic grants, server-side decryption, older-version archive sharing (both exercised on 14 October 2026 and assessed in the key architecture assessment, §3.7; review again before either widens beyond what that section describes), model access, new notification contents, cloud key backup, a different token transport, or a broader request audience. Review again if implementation cannot enforce a boundary stated here, and when the retention job and application are ready to release.
10. Sources and design evidence
The existing encryption and device-admission design is described in docs/encryption_plan.md.
The implementation specification is docs/chat-access-implementation-plan.md. Existing
cryptographic operations are in lib/crypto/keyring.ts, lib/crypto/groupKeys.ts and
lib/crypto/attestation.ts. The related attention-routing assessment is
Targeted notices. No new statutory interpretation is made here.