← All privacy impact assessments
PIA: Keeping an assistant answer for a phone that lost the connection
Status: Assessed before the code, 20 October 2026; implementation authorised the same day. Nothing is kept for a member until they have seen the privacy policy version that describes it. Written: 20 October 2026 · Last revised: 20 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).
1. Purpose and scope
When a member asks the assistant something, the answer can take 10 to 25 seconds. If they lock the phone or switch to another app while they wait, the phone drops the connection. Our server still finishes the work. It creates the task, logs the feed or moves the event, but the answer never reaches the phone. The member is told the answer was lost, asked to check Tasks and Calendar, and may send the request again. That second send can repeat a change the first one already made, such as a second feed in a baby's log or a second task.
This change has our assistant server keep each finished answer in its memory for a few minutes, so the phone can collect it when the member comes back. One sentence for why: an answer that was already written should reach the person who asked, instead of being lost and repeated.
In scope: answers to requests typed or dictated into a member's own Assistant tab. Out of scope: the shared display's Ask page and spoken requests (its accounts and the voice door are not offered the hold); what the assistant does to answer (unchanged, and covered by cloud inference and faster assistant commands); and the conversation record on the phone, which stays encrypted under the member's own key exactly as now.
2. Data involved
| Kind | Whose | Children's? | Sensitive? | Free text? |
|---|---|---|---|---|
| The answer the server would have sent: its words, what it changed (for example "Added ‘Book the vet’ to Tasks"), any card awaiting Approve, and pointers to the views it shows | The member who asked; can name other members | Can describe a child, for example a feed just logged | Can carry health details, as any answer about a baby or a medicine can | Yes: the answer's words are written by a model from the member's request |
| Which account asked, and the random id the phone gave the request | The member | No | No | No |
Nothing new is collected. The server writes this answer today and sends it straight away; the change is that it also keeps it for a few minutes. Not kept: the member's question, the group's records, the earlier conversation, anything another member wrote, or anything for a request that ended with a refusal or an error.
Strictly necessary? The answer is what the member asked for, and it exists only in the server's memory once the connection is gone. Keeping it briefly is the only way to give it to them without running the request again.
3. Flows and locations
| Data | Phone | Our assistant server (Google Cloud, Sydney) | Our database | Logs |
|---|---|---|---|---|
| The finished answer | Collected once, then saved to the member's conversation, encrypted on the phone under their own key, as now | Held in the running server's memory only. It can be collected for five minutes; then it is refused, and erased at the server's next request or when the server stops | Never written | Never written |
| That a held answer was collected or expired | Nothing | Nothing | Nothing | A log line with codes and counts, no words, no account or group id |
How the phone collects it. If the connection drops at any point, the phone asks once for the answer to its own request. It names a random id it made for that request alone, never the message's own id, so an Approve is covered too. If the server is still working on it, the request waits up to a minute for it. The server hands it over only to the same signed-in account that asked, once, then deletes its copy. If two requests to collect arrive together, only one receives it. If the server instance that held it has restarted, or a different instance answers, there is nothing to collect and the member is told the answer was lost, as now.
Memory only. A held answer is never written to our database, a disk, a cache shared between servers, or a log. When the server restarts, every held answer is gone. One server keeps at most 500 at a time; when it is full, the oldest goes first.
Five minutes is when collection stops, not a timer we rely on. Our server is given processor time only while it is handling a request, so a timer set for five minutes may not run on time. The server therefore records when each answer expires, refuses to hand one over after that, and erases every expired answer at the start of each request it handles. An idle server can keep an expired answer in memory until its next request or until it stops; nobody can collect it in that time.
Every streamed answer is held, not just lost ones. The server cannot tell whether the phone received what it sent, so each answer stays collectable for the full five minutes whether or not it is ever collected. We considered having the phone confirm receipt so the copy could go at once. We did not choose it: it adds a request to every turn to shorten a hold that ends within minutes anyway.
Nothing crosses a border. The answer was written in our server's memory in Sydney and stays there.
4. Legal basis and consents
No new consent purpose. The hold applies only where the assistant already runs: an adult, or a 16- or 17-year-old who has said yes to AI features themselves, in a group that is not Device-only. Child accounts have no assistant, and nothing changes for them.
Our privacy policy currently says our servers can never open a member's conversation with the assistant, because it is stored under the member's own key. That remains true of the stored conversation. But a held answer is a readable copy of part of that conversation, kept by our server after the request. The policy has to say so before the hold exists. We propose this sentence:
If your phone loses the connection while the assistant is answering — for example because you locked it or switched apps — our assistant server keeps that answer in its memory so your phone can collect it within five minutes when you come back. After that it can no longer be collected, and it is erased the next time our server handles a request, or when the server stops. It is never saved to our database or our logs, and only your account can collect it, once.
As with other changes of this kind, the server would hold answers only for members who have acknowledged the policy version containing that sentence. Anyone else's answers are not kept.
5. Risks and mitigations
| Risk | Who is harmed | Mitigation | Structural or conventional? | Residual |
|---|---|---|---|---|
| Someone else collects a member's answer, for example a person who learns the request's id | The member, anyone the answer names | Collection requires the same signed-in account that asked, checked on our server; the id is random and never shown | Code on our server; a test pins the account check | None known |
| Someone signed in on the same phone after a switch of account collects the earlier person's answer | The first member | The account check above; the phone asks with the account that is signed in now | Code | None known |
| A held answer is kept longer than we say, or written somewhere lasting | The member, anyone named | An expiry time checked before any answer is handed out, expired answers erased at the start of every request, a cap on how many answers a server holds, and copies removed on collection; no code writes held answers to the database or logs | Conventional: tests check the expiry, the erasing, collecting once when two requests arrive together, and that the route's log lines carry no answer fields | Accepted (§8) |
| A person asks for their data to be erased while an answer is held | The member | The copy can't be collected after five minutes and was never stored | Time-bound | Accepted (§8) |
| A held answer about a baby, such as a feed or medicine just logged, is readable on our server for minutes | The baby, the parent | Held only for the parent who asked, only in memory, only for minutes, and never for a child account | Code and time-bound | Accepted (§8) |
| The shared display, seen by the whole group, collects a private answer | A member | The shared display's accounts are not offered the hold | Code on our server, by account type | None known |
6. Structural versus conventional
Structural: collection is refused on our server unless the signed-in account matches the account that asked. The shared display's accounts, child accounts, Device-only groups and members who have not acknowledged the describing policy version get no hold, because the server checks each before it keeps anything. A server restart discards everything held.
Conventional: that held answers live only in memory and are never logged (no code writes them; a test scans the route's log lines); the five-minute limit and the cap (an expiry time checked on collection, erasing at every request, and a size limit, pinned by tests); that only the Assistant tab collects (a phone-side choice); and the policy sentence (copy, pinned by tests on the policy text).
Not built, and why: we could encrypt each held answer to the member's own phones so the server could not read its own copy afterwards. The server wrote the answer in readable form moments earlier, so this would protect only the few minutes after. We judged it not worth the extra moving parts. We will reconsider it if the hold time grows.
7. Best interests of the child
A child's own account has no assistant, so the hold never keeps a child's own request or answer. A parent's answer can describe a child, most often a feed, a nappy or a medicine just logged. Without the hold, the parent is told the answer was lost and may log it again, leaving the child's record with a feed or a dose that never happened. That is a worse outcome for the child than a few minutes of a copy in our server's memory. We chose the hold for that reason. We kept it as short as a locked phone needs, and only the parent who asked can collect it.
8. Residual risk we accept
- A readable copy of part of a private conversation sits on our server for five minutes, and on an idle server possibly until its next request or until it stops. It can't be collected after five minutes. This is the first time a member's own assistant conversation has a copy outside their key after the request ends. It is held in memory only, never saved, and handed only to them. The policy says so before it happens.
- Every streamed answer is held, collected or not, because the server cannot know which ones arrived.
- An erasure request during those minutes does not reach the held copy; it expires on its own.
- The hold can still miss. If the member comes back after five minutes, or a different server answers, the answer is lost as it is today.
9. Review trigger
We re-read this assessment if held answers are kept anywhere but a running server's memory, if the hold grows past five minutes, if anything other than the asking account can collect one, if the shared display or spoken requests gain the hold, or if held answers are used for anything other than returning them to the person who asked.
10. Checklist against exposure draft s 38(2) (verified 2026-09-08)
| s 38(2) | Requires | Answered in |
|---|---|---|
| (a) | nature, scope, context, flow and purposes | §§1–3 |
| (b) | why collection is strictly necessary | §2 |
| (c) | lawful and fair means | §4 |
| (d) | best interests of the child | §7 |
| (e) | how we comply with the Code and the Act | §§4, 6 |
| (f) | risk of harm to children | §5 |
11. Sources
- The finding: three answers our server finished were lost on phones on 11 and 18 October 2026. On a simulator, a connection cut after the first progress line reads as a stream that ended without its answer. Pinned by
lib/__tests__/agentApi.test.ts. - The phone's handling of a lost answer and its report:
lib/agentApi.ts. The server's streamed answer:agent-server/src/server.ts. - What the policy says today about the assistant conversation:
constants/legalTexts.tsandconstants/privacyPromises.ts. - Sibling assessments: Cloud inference, Faster assistant commands, Knowing when someone has finished dictating.