← All privacy impact assessments

PIA: Trips and stays, a shared form for a group's holiday

Members of a group type in a holiday's details: where and when, the places they're staying, how they're travelling, any booking references they want to keep, and who's going. Everyone in the group sees the same trip, and it updates on every phone as someone changes it. Nothing is fetched or imported. The tool stays hidden until the privacy policy that describes it (version 3.15) is the one in the app. Approved with conditions by the founder on 28 October 2026.

What a trip holds, and what it never asks for

A trip has a name, and may have a destination, start and end dates (a day, no time) and notes. A stay has a name, and may have an address, check-in and check-out dates and a booking reference. A leg of travel has a mode (flight, train, bus, car, boat or other), and may have where it leaves from and goes to, when it leaves and arrives (as typed, such as "Fri 6:05 am"), the flight or service ("QF 43") and a booking reference. "Who's going" lists members of the group who are people, children included. Members without their own sign-in (profiles), anyone outside the group, and babies go in the notes; the database refuses a profile or the wall as a traveller. Each piece of text has a length limit the database enforces, and a trip holds at most 30 stays and 30 legs.

There is no field for a passport, visa, licence or other identity-document number or image, a date of birth, nationality, a frequent-flyer number, seat or meal preferences, health or dietary notes, payment or card details, prices, attachments, photos, or links fetched or previewed. Notes and addresses are free text, so a member could type one of these; the form says who can see the notes and asks people to keep passport and card numbers out. We don't scan for numbers: it would be wrong too often and would suggest a guarantee we can't give.

Who sees it

Every active member of the group, children included, can see, add, change and delete its trips, as with the calendar. A member who joins later sees the trips already there. Shared displays (the group's wall) and profiles (members without their own sign-in) see nothing: the database refuses them every read, not only every write. Someone not in the group, a member who has left or been removed, and anyone signed out read nothing.

Where it's kept

Trips are stored as ordinary text in our database in Sydney, at every privacy level, including Device-only groups and groups that have turned on encryption with a Group Password. The Group Password protects chat and photos only, so trips are never encrypted on the phones. Members' phones hold the trips in memory only, never saved to the phone's storage, and clear them when the member switches group, leaves the group, signs out or closes the app.

What never reads it

The assistant doesn't read or write trips. Nor do the daily brief, Add by talking, Mail Sifter, usage counts, Arrange by use or the improvement traces. Trips aren't shown on Home, aren't written to the phone's own calendar, and aren't shared with any other group. The Schedule view described below is the only additional reader.

Nothing about a trip sends a notification, a badge or an email, with one exception: the chat notice before booking references are cleared (below). Tapping "Open in maps" under a stay's address hands that address to the phone's maps app, on that tap only; nothing is looked up in advance, and there is no map, place search or link preview in the app.

Dated trips and stays in Schedule (5 November 2026)

A trip with start and end dates, and a stay with check-in and check-out dates, also appears in Day, Week and Month in the group's Schedule. Both dates are included. A single date range is one item, with the existing continuation words and multi-day rendering. The trip keeps its own name; the stay keeps its name. The people listed as going appear where events show people. Tapping opens the trip, where its dates and details can be changed. Travel legs remain in Trips: their departure and arrival descriptions are free text, not calendar dates or reliable times.

This changes where existing readers see the dates, not who can read them. Schedule reads through the same signed-in, group-scoped Trips loader and the same database row rules. Every active person in the group can see a trip, including children and members not listed as going. There is no per-traveller or privacy-level restriction. Walls and profiles remain refused by the restrictive person-only database policy; incomplete two-step sign-ins and removed sign-ins remain refused. Schedule's existing people filters can narrow the display; they never grant access.

The Schedule items are derived in memory inside that screen only. No event rows, new tables, phone-storage copies or server copies are written. The shared Schedule store remains unchanged. The derived items never enter Home, the wall, the assistant or its model context, Add by talking, the daily brief, notifications, calendar export or device-calendar sync. Addresses, booking references and notes are not included in the derived items. The existing in-memory Trips cache and its group-switch, sign-out and foreground rules continue to apply.

The accepted residual is that a member can now notice a trip's name, dates and travellers while looking at Schedule without opening Trips first. Those members already have access to exactly that information in Trips. Keeping the derivation inside the screen, with checks for excluded consumers, protects against a later change accidentally extending this to a broader audience. The database holds the reader boundary; the screen and its tests hold the consumer boundary.

Booking references are cleared 30 days after the trip

A booking reference and a surname can be enough to change or cancel a booking, and everyone in the group can see one. So booking references are cleared automatically 30 days after a trip ends (counted from the trip's start date if it has no end), in Sydney time. A trip with no dates at all has no end to count from, so its references are cleared 12 months after the trip was last changed, with nothing added. The rest of the trip stays until someone in the group deletes it.

A week before, the group gets one notice in its chat: “Booking references for ‘Summer at the coast’ will be cleared on Fri 9 Jan. If you need them, copy them somewhere else before then.” It names the trip and the date and nothing else: no reference, address, place or person. It is sent only if the trip still holds a reference, once for that date, by our database rather than any member or model, and like every notice of its kind it is never a push, a badge or an unread count, and is never read aloud. It is shown in the chat on members' phones, never on a shared display. References are never cleared without a notice for that trip's current clearing date having been sent at least a week earlier, so a trip added, given a reference, or moved too late for a week's notice is cleared a week after the notice. If the trip's dates move, earlier or later, so its clearing date changes, one fresh notice names the new date, again with at least a week to go. Once a trip's references are cleared, a reference typed in afterwards gets a notice of its own and a week before it is cleared too. The notice stays in the chat under the chat's own retention; it names a trip, never what was cleared.

Leaving, deletion and export

A member who leaves or is removed comes off every "who's going" list at once, by the database's own rule; the trips and anything they wrote stay with the group. Deleting a trip deletes its stays, travel and who's going straight away. Deleting a group deletes its trips. Deleting an account deletes the trips of a group the person was alone in; in a shared group their trips stay, no longer naming them as the one who added them, and they come off every "who's going" list. Backups follow the policy's 90-day rule. Download my data includes the trips, stays, travel and who's going of every group the member is in.

Risks we accept

Risk What reduces it What's left
Someone in the group (a later joiner, a teenager, a member about to be removed) uses a booking reference to change or cancel a booking References are optional, the field says who can see it, and they are cleared 30 days after the trip Everyone in the group can read a reference until then
A passport, licence or card number is typed into notes or an address No field asks for one; the notes say not to; length limits We don't scan free text, so it can still happen
Whereabouts and an empty home reach people outside the group Nothing is shown on a shared display (the clearing notice reaches the wall's copy of the chat but is never drawn), nothing reaches the assistant, notifications, the phone's calendar or a link preview Trips are ordinary text on our servers, like the calendar, readable by our database operators under our access rules
A future feature (the assistant, importing from email, counts, or a wider Schedule consumer) starts reading trips Each of those needs this assessment revised first, and a test fails if the assistant's server names a trips table The check catches names, not intentions

Structural versus conventional

Held by the database: the grants and per-group row rules on all four tables; a shared display or profile refused every read and write; two-step sign-in and a removed sign-in refused, as on every table; a traveller must be an active member who is a person (never the wall or a profile), and leaves with their membership; a stay, leg or traveller can't point at another group's trip; the length limits, the mode list, the date order and the 30-item limits; the nightly job that writes the notice and clears references, which no member, the app or our own server's keys can call; the client can't set the clearing date or write the notice.

Held by our code and its tests: the form's help lines; "Open in maps" only on a tap; the tool hidden until policy 3.15; the phone's copy cleared on switching group, leaving and sign-out; and "no AI reader", which is a test that fails if the assistant's server names a trips table or the notice, not a database rule.

Best interests of the child

A child can see where their group is going and when, and can help plan it, which is in their interest; they are already in the calendar their group sees. The added exposure is a stay's address and a booking reference, both inside the group. Trips never reach the assistant, so the rules for under-16s and AI are untouched; they are never shown on the wall, and never reach a notification or the phone's calendar; booking references expire; and a 13 to 17-year-old who leaves the group comes off every "who's going" list at once. The Child Privacy Policy's "Who can see it" gains "the trips".

Sources