← All privacy impact assessments

PIA: Keeping the group's calendar and your phone's calendar in step

This extends The calendar already on your phone (the "Other calendars" tool). That assessment covered copying ONE event out, and bringing ONE picked entry in. This one covers keeping them in step automatically, in either direction or both, and it is a separate assessment because it changes four things the first one relied on:

  1. It remembers what it wrote, so that it can change and remove it later.
  2. It reads the phone's calendar whenever the app is open on the group, not only on a screen the member opened to read it.
  3. It brings entries in without a per-entry choice — the member chooses a whole calendar once.
  4. It needs full calendar access on iOS, not the write-only access the "Add to my calendar" button uses.

Status: Built. Written before the code, as a precondition of building it (exposure draft s 38(3)), and checked against the implementation. This revision also sets out, before it is built, the same arrangement running on a group's shared wall display rather than a single member's own phone, built in October 2026 for the "in" direction only. Written: 25 September 2026 · Last revised: 2 October 2026 Nothing here is legal advice. Children's Code citations are to the exposure draft.

1. Purpose and scope

People asked for the one-at-a-time copying to become a standing arrangement: "put everything the group plans into my calendar, and put my kids' sport calendar into the group". Two switches, each off until a member turns it on, each on this phone only, each for one group:

Still device-only, and that is the design decision that matters most. Everything still goes through the calendar store on the phone. There is no server-side synchronisation, no Google or Apple account permission, no subscription link, and no new table in our database. The arrangement lives on one phone: another phone of the same member does nothing until they turn it on there, and nothing happens while the app is closed.

Out of scope, named so nobody assumes it was overlooked: a subscription feed, anything server-side, sync while the app is not open, and syncing reminders or tasks. Each is a different design and needs its own assessment.

The same "bring in entries from my calendars" switch, running on a group's shared wall display (built, "in" only). A group can set up a spare tablet as a wall screen for the house — a separate assessment covers that device on its own terms. What's built here is narrow: while that tablet is acting as the group's wall, it can bring in whatever's on the tablet's own calendars — iCloud, Google, Exchange, and any calendar a person subscribed the tablet to, such as a school's term dates — the same way a member's own phone already can, using the same switch, the same picker, and every rule already described in this document.

Three things are different about running it on a wall rather than a phone, and each is covered in the sections below: who is doing it (§4) — the adult setting up the wall, not whoever happens to be standing near it later; how often it runs (§3) — continuously, because the wall is always open, rather than only when a member happens to have the app in front of them; and which direction is built — only entries coming in from the tablet's own calendars onto the group's. Whether the wall should also be able to put the group's own events onto one of the tablet's calendars, the way the "show group events in my calendar" switch does on a phone, hasn't been decided, and isn't built. If it is, this document is revised again before it ships.

2. Data involved

Kind Whose Children's? Sensitive? Free text?
Each group event's title, time and place, written into the phone's "GroupApp" calendar The group's Yes, where an event is about a child Possibly Yes
The list of the phone's calendars — names, and the account each belongs to — to let the member pick The member's own No The account names can say where a person works No
The title, time and place of every entry in a calendar the member picked The member's own, and anybody named in their entries Possibly Possibly — a calendar can contain a diagnosis in a title Yes
A map, kept on the phone, from a group event to the phone entry it became, and from a phone entry to the group event it became, plus a short fingerprint of each so the app can tell when something changed The member's own No No — identifiers and fingerprints only, never a title No

Deliberately not read, and not written: a calendar entry's notes, its attendees and its organiser are never read; a group event's notes and who it is assigned to are never written out. The map on the phone holds no titles, no times and no places: a fingerprint cannot be turned back into the words it was made from. Nothing is counted, and nothing summarises how busy anybody is.

Strictly necessary (s 38(2)(b)): the out direction needs the group event's own fields, which the member can already read; the in direction needs title and time because those are the event, and the place only if the member leaves "include the place" on. The map is what makes "keep up to date" possible at all — without it the app could only ever add, never correct or remove.

3. Flows and locations

Data Device Our database Anywhere else
Group events written out Into the "GroupApp · group" calendar on the phone Unchanged The account that calendar lives in. On Android the app creates it as a calendar on the phone only. On iOS it is created in the same account as the phone's default calendar — often iCloud — so Apple holds a copy and the member's other Apple devices show it. The switch says which account it went to
Entries read from a picked calendar Read on the phone Written as ordinary group events, assigned to the member Wherever those calendars already are
The map A file in the app's private storage on this phone Never sent —
The list of calendars Read on the phone to draw the picker Never sent —

The boundary crossings, stated slowly. Out: every group event title leaves the app's protection and becomes an entry in a calendar account. In a Device-only group, whose titles are encrypted so our servers cannot read them, that is every title at once, continually — the switch says so in plain words before it turns on, and the member has to confirm. In: every entry in the calendars a member picks becomes readable by every member of the group, including entries added to that calendar later.

Group time survives in both directions, exactly as it does for the single-event copy: events go out as the instant the group's wall-clock time resolves to, entries come in converted into the group's own time zone, and an all-day entry keeps the calendar date the phone shows it on.

When it runs: when the app comes to the foreground on a group with a switch on, and shortly after the group's calendar changes while the app is open. Never on a timer, never in the background. On the wall: a wall display stays in the foreground on its one group for as long as it's acting as the wall, so this runs continuously rather than only when someone happens to be looking at the screen — still never in the background, and still nothing while the wall is stopped or showing anything other than this group.

4. Legal basis and consents

No new consent purpose, for the same reason as the first assessment: nothing here goes to us or to any provider of ours. The out direction writes to the member's own calendar; the in direction writes to their own group, which is the same act as typing the entries in, done by a switch they turned on and can turn off. The operating system's calendar permission remains the real gate, and on iOS this feature needs full access, which the priming sheet says before the system dialog is reached.

What makes it fair (s 38(2)(c)): each switch is off until turned on, each explains what it will do in the words above, the in direction shows the member exactly what will appear on the group's calendar — every entry, by title — before it is turned on, and the tool screen says what is on for this group whenever the member looks.

The privacy policy's section on the device calendar is revised before this ships, and its version moves so the change is dated: it now says the app can keep a calendar on the phone matching the group's calendar, that it keeps a record on the phone of what it wrote so it can correct it, and that a member can have entries from calendars they choose appear on their group's calendar automatically.

Whose act turning this on, for a wall, is. As built, the switch is turned on AT THE WALL: in the setup the wall runs once just after it is paired, or later from the wall's own settings. Both ask for the wall's PIN first — the PIN an adult has just set from their phone — and both show the same preview of what will appear before anything comes in. So the act is that of whoever knows the PIN, which in practice is the adult setting the wall up; the PIN identifies nobody, and this document does not claim it does. The tablet's operating system asks for calendar permission at that moment (or already holds it, if an adult granted it earlier while signed in on the tablet) and treats it as a permission for that installation of the app on that device, so it keeps applying afterwards whoever is standing at the wall. Each event the wall brings in is created by the group's wall account and given to nobody, so it reads as the group's; on the wall itself it says which of the tablet's calendars it came from. That label is worked out on the tablet from its own record of what it brought in and is not stored with the event, so a member's phone shows no source.

5. Risks and mitigations

Risk Who is harmed Mitigation Structural or conventional? Residual
5.1 A member turns on "in" for a calendar, and months later an entry they never thought about — a counselling appointment, an interview — appears on the group's calendar. The member, and anybody named in the entry The member picks calendars, not "all of them"; the picker lists each calendar with its account. Before turning on, a preview lists every entry that will appear, by title. The switch's own description says future entries in those calendars will appear too. Notes, attendees and organisers are never read. "Include the place" can be turned off. Conventional — copy and interface, pinned by tests. Accepted, and the most important one here. The first assessment's protection was that every entry was picked by hand. This one trades that for a choice made once per calendar, and a preview that covers only what is there today.
5.2 A member's calendar is shared into a group, and the member later loses track of the arrangement. The member The tool's home shows, per group, which switches are on and which calendars are being brought in. Signing out removes the phone's GroupApp calendars. Conventional Accepted.
5.3 A Device-only group's titles, which our servers cannot read, are written in the clear into Google or iCloud — all of them, and every new one. The group The out switch in a Device-only group shows the warning and requires a confirmation before it turns on. We do not refuse it, for the reason the first assessment gave: a group that chose Device-only did so to bind us. Conventional — copy, pinned against softening. Accepted, and sharper than the single-copy case: one confirmation now covers every future title, not one.
5.4 The out calendar lands in an employer's account. The member and their family On Android the app creates a phone-only calendar. On iOS it uses a calendar on the phone only if one is available, otherwise the default calendar's account, and the switch names that account afterwards, so the member can see where it went and turn it off. Conventional Accepted — if the phone's default calendar is a work account, the group's events are in it until the member notices.
5.5 Something goes wrong and the app deletes things it should not — in the member's calendar, or on the group's calendar. The member, the group The app only ever changes or deletes things it made: phone entries inside its own "GroupApp" calendar, and group events it brought in (recorded in the map). It never edits or deletes an entry in any other phone calendar, and never touches a group event somebody else made. A failed read is never mistaken for "everything was deleted" — the whole run stops. A calendar that has disappeared from the phone (an account removed) does not cause its entries to be removed from the group. Structural in the code's shape; conventional in that nothing outside the code prevents a future version doing more. Pinned by tests. Accepted.
5.6 An echo: the group's events go out to the phone, get picked as an "in" calendar, and come back in doubled — or another group's GroupApp calendar is brought into this group, which would copy one group's calendar into another. The member, both groups Every calendar whose name starts "GroupApp · " is left out of the picker and never read for "in". The app also never writes back out an event it brought in. Conventional, pinned by a test. Accepted — a member who renames a GroupApp calendar on their phone could defeat the name check; the app also excludes calendars it created by their recorded identifier, which renaming does not change.
5.7 Somebody in the group edits or deletes an event that was brought in, and the phone quietly undoes it. The group A group member's edit stands until the entry itself changes on the phone; only then is the phone's version written. A group event somebody deleted is not brought back. Conventional Accepted — an edit made in the group is overwritten if the member later changes the same entry on their phone.
5.8 Two phones of the same member both run the arrangement and double everything. The member, the group Before creating anything, each phone looks for a matching event already there (same title, same start) and adopts it rather than creating another. Conventional Accepted — a matching fingerprint is a heuristic; two genuinely different entries with the same title and start collapse into one.
5.9 The map on the phone is itself a record of the arrangement. The member It holds identifiers and fingerprints only, sits in the app's private storage, and is removed with the out calendar when the member turns the switch off. Structural by absence — no titles are stored. Accepted.
5.10 Because a wall stays in the foreground, it reads the tablet's calendars far more often than a phone ever would, so a change made on any of the tablet's own calendar accounts reaches the group sooner — and anything that shouldn't have been on a picked calendar reaches the group sooner too. The group; anybody named in an entry The same preview and the same picked-calendars-only rule apply; nothing about running continuously widens what can be read, only how soon a change is noticed. Conventional Accepted — the trade this document already accepts in §5.1 simply happens faster on a wall.
5.11 The tablet's operating system keeps the calendar permission given during the wall's setup for as long as the app is installed, whoever is standing at the wall later, and there's no sign-in on the wall to point to as "who agreed to this" — only the PIN, which identifies nobody. The adult who set it up; the group Said plainly during setup, at the moment the permission is actually granted, by the adult actually granting it; the permission can be removed in the tablet's own settings at any time, and turning the switch off removes what the app itself wrote Conventional Accepted — this is how the tablet's operating system treats the permission, not a choice this feature makes.

6. Structural versus conventional

Enforced by the platform: whether the app can touch the calendar at all (the operating system's permission, revocable in the phone's settings); that nothing runs while the app is closed (the app has no background calendar task on either platform).

Structural in a small way, by absence: no table, nothing sent to us about a calendar, no titles in the phone's map.

Conventional — held by the code and tests, named because a reader would otherwise assume something stronger: adults only; the Device-only confirmation; the GroupApp-calendar exclusion from "in"; only touching what the app made; the preview before "in" turns on; a failed read stopping the whole run. The same posture on a wall: the switch is turned on only after the wall's PIN is entered; the preview is still shown; the continuous reading described in §5.10 changes nothing about what's read or how, only how often.

7. Best interests of the child

Neither switch is offered to a child account. The first assessment offered the single-event copy out to children because it discloses nothing new and puts a child's own events where they look. A standing arrangement is different in two ways: out needs full calendar access on iOS, which the first assessment already declined to ask a child for; and in is the smoothest possible path from my private diary to something every adult in my group can read, which the Code's concern with designs that make disclosure the easy action is about. "Add to my calendar" on a single event is unchanged and still offered to everyone.

On a wall: a child's entries can still reach the group's calendar this way, exactly as they can from an adult's own phone, if the calendar they're on is one the adult chose to bring in — a school's term dates, for instance. Setting up a wall at all is itself adult-only, the same condition as everything else about that device; a child standing near the finished wall cannot turn this switch on or change its calendars without the wall's PIN.

8. Residual risk we accept

  1. An entry a member never thought about can reach their group (§5.1), because the choice is made once per calendar rather than once per entry.
  2. A Device-only group's titles can flow into Google or iCloud continually (§5.3), on one confirmation.
  3. On iOS the out calendar is usually in an account, not on the phone alone (§5.4).
  4. Adults only is a condition in the interface and nothing else.
  5. A group edit can be overwritten by a later change on the member's phone (§5.7).
  6. Only the group open in the app is kept up to date. A member in several groups sees another group's calendar catch up when they next open that group.
  7. The window is bounded: events from a week ago to twelve weeks ahead go out, entries from now to twelve weeks ahead come in, and a phone entry longer than two weeks that runs past that window can be missed on Android, where the calendar is read by containment. Past entries are left as they are.
  8. Running on a wall reads the tablet's calendars far more often than a phone would (§5.10), because the wall stays open continuously rather than being opened and closed.
  9. The tablet keeps the calendar permission given at the wall's setup, whoever is standing there later (§5.11) — a property of how the tablet's own operating system treats the permission, not something this feature decides.

9. Review trigger

Re-read this document when any of these stops being true: anything read from a calendar is sent to our servers or a model; sync runs while the app is closed; a calendar other than the member's picked ones is read for "in"; either switch is offered to a child account; the app edits or deletes a phone entry outside its own calendar; the map starts holding titles or times; anything about a member's calendar is counted or summarised. Also re-read before a wall display is given the "show group events in my calendar" (out) direction, or if the shared wall display it runs on is itself redesigned.

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 the collection is strictly necessary §2
(c) lawful and fair collection §4
(d) best interests of the child §7
(e) compliance with the Code and the Act §4, §6
(f) risk of harm to, and impact on, children §5, §7, §8

s 38(3): written before the code. s 39: listed on our published register.

11. Sources

Primary — law. Privacy Act 1988 (Cth), Australian Privacy Principles 1, 3, 5, 6 and 8 (APP 8 not engaged: nothing about a member's calendar reaches us or any recipient of ours). Children's Online Privacy Code exposure draft, ss 10, 13, 20, 33, 38, 39.

Primary — platform documentation. Expo's calendar module documentation for the SDK version this app is on — creating and deleting a calendar, creating, updating and deleting an event, and the difference in how iOS and Android answer a date-range query. Apple's and Android's own documentation on calendar permissions.

In-repo. The first assessment, docs/pia/device-calendars.md, whose §5 and §9 this document answers; lib/deviceCalendar.ts, lib/calendarSyncPlan.ts and lib/calendarSync.ts. The wall extension is set out in docs/shared_display_plan.md, and is covered on its own terms — everything about the display except its calendar — in a shared display in the house.