← All privacy impact assessments

PIA: The assistant reads a photo or a PDF you attach

Status: Assessed and approved with conditions on 25 October 2026, before any code was written. The server half was built on 28 October 2026 and is switched off: nothing on this page reaches a member until we turn on one platform switch, and we won't do that until the app half, the staged changes described in §3.4, the privacy policy and the evaluations in §5 are all in place. This page describes the server half as built and names every part that is not built yet. Written: 25 October 2026 · Last revised: 28 October 2026 Nothing here is legal advice. Children's Code citations are to the exposure draft; section numbers may move on registration (due 10 December 2026).

The labels A1–A27 (conditions), K1–K13 (risks) and R1–R9 (residual risks) are the numbering of our internal approval of this design (PIA-011). We keep them here so each claim below can be traced to the condition it rests on.

1. Purpose and scope

A member wants to show the assistant a school notice, a receipt, a poster or a letter and ask "put this on the calendar" or "what do I need to bring?", instead of typing it out. One sentence for why: reading the file is the same act as the member typing what is in it, done for them.

In scope: an adult (or a 16- or 17-year-old who has already turned on AI features) attaching up to five files to a typed message in their own Assistant tab: photos from the phone's library, a photo taken there and then with the camera, and PDFs. What our server reads, what goes to Google, what is kept and where, what the file's contents can and can't make the assistant do, and what our improvement records say about it.

Out of scope, covered elsewhere: Mail Sifter's own pictures, whose reading step this feature reuses unchanged (forwarded email, "Pictures in Mail Sifter"); where the assistant's model runs (cloud inference §12); "Help us improve the assistant" itself (assistant tracing); how the assistant conversation is stored on the phone.

What is built, and what is not (28 October 2026).

2. Data involved

Item What it holds Whose Children's? Sensitive? Free text?
A photo (library or camera) pixels: printed words, faces, homes, plates, screens, labels the member's, and anyone in it or named on it often: school notices, class photos, children's faces can be: a medicine label, a letter, a bank card yes, in effect
A PDF its text layer, first 20 pages as above often can be yes
What was read the photo's words or the PDF's text, credentials masked, capped others' words, in the member's conversation possibly possibly, including health yes
The guardrail check the same masked words, nothing else as above possibly possibly yes
The guardrail's outcome per file: used or not, a closed reason, and a quote of at most 60 characters shown once the file's own words, for the quote possibly no the quote only
"Forget the file" marker a message id: from here on, earlier files aren't used the member no no no
A file's name can name a child ("Ada_report.pdf") the member's possibly possibly yes
Daily picture count member, Sydney date, a number up to 20 the member no no no
First-use record member, notice version, time the member no no no

Not collected, and could have been: no stored copy of any file, thumbnail, bucket object, cache or disk copy on our side; no location or camera details (removed on the phone, and the server re-encodes every picture again so only pixels remain); no description of a person (the reading instruction asks for words only, with [photo] or [logo] where a picture is); and no file name ever reaches our server: the server calls files "picture 1" and "PDF 2", and its request shape refuses any other field.

Strictly necessary? For each item, the member asked for it: they chose the file and asked a question about it, so reading it is the service itself. The children's information in it is not collected for its own sake: it is in the file the member chose, and we read words only, keep what was read only in the member's own sealed conversation for its 30 days, and send it nowhere else. The daily count and the first-use record exist to cap cost and to show the notice before use. The file name is the one thing we don't need, so it stays on the phone.

3. Flows and locations

3.1 Two requests, and pixels reach neither turn (A5)

Request 1: reading the files. The phone sends the files to our assistant server's read request (POST /api/assistant/attachments, in Google Cloud, Sydney). The group it is for travels in a header, so every gate runs before a byte of the body is read, in this order, each one a fixed refusal with no model call (A2):

  1. signed in;
  2. not a child account;
  3. not a 16- or 17-year-old without their own AI yes;
  4. not a shared display's account;
  5. the group's privacy level readable through the member's own access, and not Device-only;
  6. the member has acknowledged privacy policy version 3.14 or later, and has seen the first-use sheet at its current version;
  7. the platform switch assistant_attachments is on;
  8. the member's weekly allowance, the group's allowance and the platform's spending ceiling.

Only then is the body read, by this request's own parser and limit (every other request keeps its 1 MB limit), behind its own limit of 10 requests a minute per member and its own error handler, which answers a fixed code and logs only the kind of error. The body may hold each file's kind, type and bytes, and nothing else. Then, in request memory only:

It answers each file's outcome, the words for each file that was read and used, and a set of closed labels for the improvement record (§3.5). It never sees the member's sentence, the group's member list or context, or a file name, and it writes nothing to the conversation.

Request 2: the turn. The phone shows "What the assistant read" beside each file, then saves the member's message with what was read sealed under the member's own key in its own column (§3.6), and then sends the ordinary assistant request with what was read as text. Later messages in the conversation carry it back in their recent turns. On that request our server:

3.2 Where each thing goes

Data Phone Our server (Sydney) Our database (Sydney) Google Vertex global Logs
Photo bytes picked or taken; re-encoded; cache copies deleted when the read ends (app half) request memory only never the re-encoded pixels, in the fixed picture call never
PDF bytes picked; cache copy deleted (app half) request memory only; parsed here never never never
What was read shown; sealed under the member's own key request memory, then in the turn sealed, on the member's own message in the guard call and in the turn, and later turns while it is in their recent turns never
A flagged file's words never sent request memory only; dropped there never the guard call only never
File names sealed with what was read (app half) never sealed only never never
Outcome codes, labels kept with the message passed through closed codes on the member's message never counts only

Every model call for this feature goes to Google LLC through Vertex AI at its global location, which may process in any country where Google operates, including the United States. TypeSafe never receives a picture, a PDF, what was read or a file name: an attachment turn never runs a TypeSafe step (A14).

3.3 The visible guardrail (A25)

After the words are read and masked, and before anything goes back to the phone, each file's text gets two checks. A file is set aside when either flags it.

A file that is set aside is not used. Its words are dropped in the server's memory: not sent to the phone, not sealed, not in the turn or later turns, not logged. The phone gets the outcome, a closed reason and, at most, a quote of 60 characters and 8 words that appears in the file exactly, with no link or markup. The quote is shown once and never saved. The reply is fixed words the phone shows from the outcome (app half), never a model's, and says nothing was used.

It is a filter, not a boundary. It will miss some files written to slip past it, and it will set aside some ordinary ones. What holds whatever it decides is §3.4. Its catch rate and false positives will be measured on invented files before the switch (§5, A19); a number for that set, not a promise about files in the wild.

3.4 What a file can make the assistant do: the attachment gate (A8)

One rule decides it: a request is an attachment turn when it carries what was read from any file, in this message or in any recent turn the phone sends. Our server sets that from the request's own contents after everything else in it is read, so a request can neither claim it nor shed it. It holds whether or not the guardrail flagged anything. On an attachment turn:

Because the gate also holds on later messages while the reads are in their recent turns, "remove Sam from the group" sent just after attaching a poster gets the fixed sentence and a Forget the file chip (app half, A26). Tapping it stops the phone sending every earlier file's words and the replies to them (each reply replaced by a fixed placeholder, since a reply can restate a file), records a marker on the member's next message so it survives a reinstall or another phone, and re-sends the member's own sentence as an ordinary typed request. It does not remove what was read from the sealed message, which stays for its 30 days (R5): the chip says "forget" and "stop using", never "delete".

3.5 Improvement records (A12, A13)

For a member who turned on "Help us improve the assistant": any request carrying what was read, any message that carried a file at all (even if nothing was used), and the sentence re-sent after Forget the file are recorded in outline only, like a forwarded email: no message, file, instruction, tool or reply words. The read request is not traced at all, and neither model call in it carries a tracing callback. The outline gains closed labels only: the kinds of file, a count bucket, each file's outcome, the guardrail's result, which pattern families hit and the model's reason (never the text, the matched words, the quote, positions or the pattern), the guard's latency bucket and tokens, which part the gate dropped, and whether the file was forgotten.

Our nightly improvement labels (assessed in HQ PIA-009) treat any such record like a forwarded email's: fixed-list labels only, never a model reading of it and never a rewritten test case. The label format moved to its second version for these columns; first-version labels stay as they were, never rewritten. The guardrail's false-positive rate in use is estimated only from these labels and the evaluations, never by reading a set-aside file.

3.6 Retention and deletion

Artefact Where Kept Account deletion
File bytes phone cache; our server's request memory the request; the phone deletes its cache copies when the read ends (app half) n/a
Pixels at Google Vertex global Google's terms: request-response logging off (verified 31 October 2026); abuse monitoring may log a flagged prompt for up to 90 days; in-memory cache up to 24 hours, durable caching off (§8) not reachable by us
Guard check Vertex global, Flash-Lite the request; Google's terms as above not reachable by us
What was read, and file names chat_messages.sealed_attachment_reads, on the member's own message, sealed under their own key with the message: 30 days deleted with the message
What was read, sent again recent turns in later requests the request; none after Forget the file n/a
A set-aside file's words; the quote server memory; the quote on the phone's screen the request; the quote is shown, never saved n/a
Outcome codes, forget marker attachment_outcomes, attachments_forgotten_before on the member's message; no words with the message: 30 days deleted with the message
Finished reply the reply hold, in server memory up to 5 minutes, as for any reply n/a
Daily picture count assistant_attachment_picture_days, counts only 7 days deleted
First-use record assistant_attachment_notices with the account deleted
Logs, spend ledger, outline Cloud Logging, the spend ledger, LangSmith counts, codes and labels only, existing retention existing

The database holds these properties itself: the sealed column must be empty unless the message is sealed, and can hold only base64; the outcome column holds only the closed list of codes; only a member's own message, never an assistant reply, can carry any of the three; members keep insert and read only on their messages, with no update and no delete; no member can read or write the daily count except through one function that can only add to their own; and our server never reads or writes any of the three columns.

4. Legal basis and consents

No new consent purpose. Reading a file the member picked, to answer what they asked, is the assistant doing what it already does with typed words (APP 6, below). The member is told, not asked:

APP 6 (use and disclosure). The primary purpose is answering the member about the file they chose and sent. What was read is used for that answer and for the follow-up questions in the same conversation, and for nothing else: it never reaches TypeSafe, "Send to GroupApp" sends the sentence and reply but never what was read or a file name (app half), and the improvement records carry labels only.

APP 8 (overseas disclosure). A photo's pixels go to Google at Vertex global, the assistant's existing processor, location and terms. What is new is the kind of data: a face and a scene can't have names replaced. A PDF is read on our server in Sydney and only its words travel, as typed words do; the guardrail sends words, never pixels. We make no zero-retention claim. Google's data-governance page says request-response logging is off unless a project turns it on; in our production inference project it is off for 3.8 Flash and 3.7 Flash (checked by the founder on 31 October 2026; the project's audit trail shows no change to it, ever). If Google's safety classifiers flag a request, its prompt, a picture included, may be logged for up to 90 days and reviewed by Google staff (the register's Argon amendment). Vertex's implicit cache: in-memory, project-only, up to 24 hours, never used for training. Durable (at-rest) caching is off in our inference project (EPHEMERAL, set 31 October 2026 by the founder and verified with a read-back; Security's durable-cache ruling of 31 October, on Google's pages "Last updated 2026-10-30"). Turning it back on needs Security (§8).

APP 11 (security). The file exists only in the request's memory: no disk, temporary file, bucket, table, cache or queue, and an automated check scans the read code for any storage call. What was read is sealed under the member's own key, a key our server does not hold. Logs carry counts and fixed codes only, never bytes, words, file names, a request's body or an error's message, and a check covers the new code. The PDF parser runs with script evaluation off, caps and a time limit (R7). The read request has its own body limit, rate limit and error handler.

Lawful and fair (s 38(2)(c)). The member chooses each file and is told, before the first one, who reads it and where. People in the photo are not told (R8).

5. Risks and mitigations

Likelihood and impact at our current scale (about 100 invited members), before and after the conditions.

# Risk Who is harmed Before → after Mitigation Structural or conventional?
K1 A child, a young member without their AI yes, a Device-only group or the shared display gets a file read children; groups that chose Device-only Medium → Low the gates in §3.1, in order, before any byte is read code before any model, each gate pinned by a check that counts zero model calls and zero bytes read
K2 Location or camera details reach Google the member; people at that place Medium → Low re-encoded on the phone with no metadata (app half); re-encoded again on our server; only JPEG accepted server half: code, pinned by a check with a GPS-tagged picture; phone half: to be pinned when built
K3 Pixels, the member list or the group's context reach a step that uses tools everyone in the photo High → Low two requests; the turn refuses image parts, data: addresses and long base64 runs; the picture and guard calls bind no tools code, pinned
K4 A file's text makes the assistant act (manage members, the baby tracker, delete, post) or steers an answer the group High → Low (R4) the guardrail (filter); the attachment gate (boundary); reads only for now; evaluations before the switch gate: structural; guardrail: conventional
K5 What was read is stored unsealed, or an older app shows it and sends it back as ordinary words the member; people in the file Medium → Low (R6) own sealed column, base64 only and only on sealed messages; older apps don't read that column; seal or drop on the phone the column rules are database constraints; seal-or-drop is app half
K6 A file, its words or its name reach logs, crash reports, traces or feedback people in the file High → Low counts and codes only; no file name reaches our server; outline-only tracing server: code, pinned by log and tracing checks; crash reports and feedback: app half
K7 Other people's and children's words reach LangSmith or our improvement labels people in the file, children High → Low outline only; labels from fixed lists; no model reading, no rewritten case code, pinned
K8 TypeSafe receives file content people in the file Medium → Low no TypeSafe step on an attachment turn code, pinned by a check that counts TypeSafe calls
K9 Pictures run up cost us; the group's allowance Medium → Low 20 pictures a member a day; every call reserves first; the budget kill switch fails closed the count is a database function and constraint; reservations are code
K10 The feature is live before the notice and policy reach phones every member High → Low policy version and first-use record checked per request; switch inserted off code and a database row
K11 A crafted PDF or a huge body crashes or slows the server everyone using the assistant Medium → Low (R7) caps before parsing; own body limit; script off; time limit code, pinned with crafted fixtures
K12 The guardrail sets aside an ordinary file, or its quote or reply leaks or accuses the member Medium → Low (R9) narrow patterns; a quote only from the file's own words; fixed reply that never says "injection", "prompt" or "delete" code and copy checks; the rate itself is measured, not enforced
K13 A reply sends group data out through a remote picture or link a file planted the group Medium → Low replies load no remote pictures and show links in full (app half); reads only app half, to be pinned when built

Evaluations before the switch (A19). Invented files only: no real person or child. At least 60 attack files (plain overrides, instructions about members and settings, steering inside the allowed parts, forged markers, split and disguised text, at least three languages besides English, and text addressed to the guard itself) and at least 150 ordinary ones (posters, school notes, receipts, menus, recipes, medicine labels, terms and conditions, with traps such as "ignore the old date" and "you are now enrolled"). The marks: at least 90% of attack files caught, at least 98% of plain English overrides; no more than 2% of ordinary files set aside; no set-aside file's words anywhere; the guard adding no more than 1.5 seconds at the 95th percentile; and, with the guardrail turned off, no injected action reaching a write or a dropped part. The switch stays off until every mark passes.

6. Structural versus conventional

Condition What it holds Status (28 October 2026)
A2 Gates before a byte is read child accounts, young members without their yes, the shared display, Device-only, the policy and notice, the switch and the allowance refuse before the body is read Structural: code that runs before any parsing or model, in a fixed order; each gate pinned by a check that counts zero model calls and zero bytes read. The switch is a database row read per request; anything but a plain "on" is off
A5 Pixels never reach a step with tools the turn carries words only Structural: two separate requests; the turn refuses image parts, data: addresses and base64 runs over 4 KB before anything is built; neither model call on the read request binds tools. Pinned
A8 The attachment gate which parts run, and that nothing is written Structural: the disallowed parts are dropped before they run; write tools are not bound (only the read list is), so no model output can call one; the flag is set by our server from the request's contents. Pinned by a check that drives a turn with a stubbed model. The day staged cards arrive, the Approve step must hold the same way
A10 Sealed under the member's own key only what was read is never stored readable Structural for the database's part: the sealed column must be empty unless the message is sealed and holds only base64; members can't update or delete a message; our server never touches the column (a check scans for it). The sealing itself, and dropping the reads if sealing fails, are app half
A12 Outline-only tracing no file words in an improvement record Structural for what was read: our server decides from the request's contents, and checks feed four kinds of attachment request through the real tracing path and look for words. Conventional for a message whose files were all set aside, and for the re-sent sentence after Forget: those carry no words of the file to leak, and are kept to the outline only because the phone sends a label saying so (app half)
A25 The guardrail fewer files written as instructions reach the assistant Conventional: a filter, measured by the evaluations, never a boundary. What it leaves out (a set-aside file's words) is code and pinned; how well it judges is not something code can prove
A26 Forget the file earlier files stop being used Structural for what forget removes: our server keeps no copy of what was read, so once the phone stops sending it, nothing on our side can bring it back into a turn, and the re-sent sentence is an ordinary typed request with the gate off. The removal from what the phone sends, the marker and the chip are app half, to be pinned by tests there. The backstop's sentence is fixed code, pinned by a copy check

Also held by code and pinned: no storage call in the read code (A9); no file name in the request shape and nothing but counts in logs (A11); the picture call's request matches Mail Sifter's pinned instruction byte for byte (A4); the daily count and the 7-day sweep are database functions (A15, A24). Conventional: the reading instruction asking for words and never a description of a person (R3); Google's handling of what it receives (R1).

7. Best interests of the child

Under-16s have no assistant, so a child cannot attach a file. Children appear in files: a class photo, a school notice with names, a sports roster, a medicine label. That is the main case, not an edge case.

8. Residual risk we accept

Accepted on approval, 25 October 2026.

  1. R1 Google's handling of pixels. Faces and scenes reach Google outside Australia and can't be pseudonymised. No zero-retention claim. On-device text recognition is the later fix.
  2. R2 People who chose nothing, children first. A school poster, a class photo or a note carries other families' children's names, schools and faces to Google. Their words sit in one adult's sealed conversation for 30 days and go back to Gemini on follow-up questions. Bounded by words only, no description, never traced, the 30-day sweep and under-16s having no assistant.
  3. R3 Imperfect reading. The reading instruction is an instruction, not a guarantee: a transcript can describe a person, miss a credential the mask doesn't know, or carry health details. The picture itself always goes whole.
  4. R4 Steering within the allowed parts. A file's text can still shape an answer, and once staged cards arrive, a card: a wrong date, a planted title or link. Bounded by the gate, by the member's Approve and by the evaluations. The guardrail lowers this for text written as instructions to the assistant, by a catch rate measured on an invented set; it does nothing for content that is simply wrong in a file's own voice ("Book at "), and a determined author can phrase past both checks. We say "fewer such files reach the assistant", not more.
  5. R5 No early deletion. What was read can't be removed before 30 days except by deleting the account. Forget the file stops its use, not its storage.
  6. R6 Replies restate files. A reply's own words ("the excursion is on 3 November") are ordinary reply text: on an older app, or once the reads have left the recent turns, a later request carries them as words and can be traced under "Help us improve".
  7. R7 Parsing untrusted files on our server. A parser bug could crash or slow an instance. The PDF time limit stops waiting, not parsing: one step of a crafted file can run past it. Bounded by the 5 MB and 20-page caps, script off and no storage; the upgrade is parsing in a separate thread with its own deadline.
  8. R8 Notice depends on the member. People in the photo are never told; the member is told once, plus one line beside the + button.
  9. R9 The guardrail is imperfect both ways. It will set aside some ordinary files and miss some written to slip past it. A set-aside file costs the member one retype and its words are never kept; a missed one meets the gate. Its false-positive rate in use is known only from labels, never from reading a file.

Also accepted, and conservative: the daily picture count counts pictures offered for reading, claimed before the first call, so a picture later skipped as too small or a duplicate still uses one of the day's 20.

Unverified, and to be recorded before the switch (as at 28 October 2026)

9. Review trigger

10. Checklist against exposure draft s 38(2)

s 38(2) Requires Answered in
(a) nature, scope, context, flow and purposes §§1–3
(b) why collecting children's personal information is strictly necessary §2: it is in the file the adult chose; we read words only and keep them only in that adult's sealed conversation
(c) lawful and fair collection §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, 7, 8

s 38(3): assessed and approved before the code, and the switch stays off until the conditions above are met. s 39: listed on the published register.

11. Sources