← All privacy impact assessments

PIA: Direct group invitations

Status: Email invitations are implemented and reviewed locally; release and production dispatcher setup remain separate operational steps. Phone-number invitations are deferred and are not part of this implementation or its data collection. Written: 23 September 2026 · Last revised: 14 October 2026. This is our assessment of our design, not legal advice. References to the Children's Online Privacy Code are to its exposure draft; the final instrument may differ.

Amendment, 14 October 2026, written before the code. Joining a group now also means seeing its earlier messages and photos, once that group has turned on sharing its earlier keys (the key architecture assessment, §3.7). The invitation says so before the person chooses Join, and their Join records that they were told; our database sends their phones no earlier key until it has that record, or until they acknowledge it later in the app. When the invitee is a child, the adult admin sending the invitation acknowledges it for them when sending, and our database refuses that acknowledgement from someone who is a child; the child's own Join never counts as it. Joining still gives no phone a key by itself.

Amendment, 20 October 2026 (epic 001 D1). Everyone who joins a group joins as a member. An invitation no longer offers to make someone an administrator: the sender isn't asked, the invitation says nothing about a role, and Join always admits a member, including for an invitation sent before this change that offered more. An owner or administrator can make someone an administrator from Members after they join. No new data is collected; the stored role on an older invitation is kept as it was and no longer decides anything.

1. Purpose and scope

An adult administrator can invite someone who already has a GroupApp account into a group, using that person's confirmed email address. The person sees the invitation on My Groups and chooses Join or Ignore. Joining grants membership; it does not by itself give an unrecognised phone access to encrypted messages or photographs.

The design includes a generic push notification, short-lived administrator history and controls to stop direct invitations or their notifications. It does not create accounts, upload contacts, search a public directory, send invitation emails or texts, or let a child invite someone. Existing invite codes remain separate.

2. Data and necessity

Data About whom Why it is needed Children's data?
Submitted email Intended recipient, potentially a person without an account Exact server-side lookup; unmatched values are not retained as invitation history Possibly
Group, sender and recipient identifiers, offered role and expiry Sender and recipient Bind one offer to one account, enforce access and settle it once Possibly
Group name and inviter display name Group and sender Let the recipient recognise the offer before admitting themselves A group name can contain a child's name or sensitive information
Masked contact, decision and timestamps Sender and recipient Let administrators distinguish invitations and know whether admission occurred Possibly
Rate counters, delivery job and provider receipt Sender/recipient/device Bound abuse, retry failed delivery and avoid repeated notifications Possibly

The child invitation data is limited to what identifies and authorises a membership offer and records its outcome. A phone number is not necessary for a child to receive an invitation: their existing confirmed email works. We therefore do not add child phone collection in this release. No new birth dates, location, contacts, message content, open/view history or model input are collected. No custom invitation message is allowed.

Email addresses are structured inputs with strict length/shape checks. Group and display names remain existing free text; a member may have put personal or sensitive information in them. The feature does not infer a sensitive category, but those names can reveal one.

3. Flows, access and retention

Authenticated lookup and invitation records stay in the existing Australian database. Stored contact and invitation metadata are access-controlled server-readable data, not end-to-end encrypted. The app must not describe this feature as having the encryption of group chat. Only exact submitted details are looked up, using confirmed identity records. The result is bound to an account and confirmed-email version; a change of address invalidates the offer.

Before joining, the recipient receives only the group name/type, inviter name, offered role and validity period. They cannot read the roster, group photo, chat or any group content. Only active adult group administrators see outgoing history. It includes explicit Joined or Ignored outcomes, never whether the person opened or viewed the invitation. The recipient is told that visibility beside the choice. Ordinary group members cannot read the history.

Push uses the existing Expo/Apple/Google delivery services. Its words are generic and its data contains only an opaque invitation identifier and navigation destination. It includes no group name, contact details, inviter name, secret or message content. These services process delivery outside our Australian database boundary. A receipt is not evidence that a person read anything.

Phone lookup, phone registration and SMS verification are outside this release. They require separate provider and privacy assessment before implementation. No phone numbers or OTPs are collected. Submitted email addresses and user identifiers must not reach application logs, crash-report context or model prompts. These are application rules backed by tests.

Pending invitations expire after seven days. Ended invitations are removed after thirty days by a scheduled database job. Email-binding records last while needed for the account and are removed with it. Quota records and delivery records have separately bounded retention. Deletion of the account or group reaches its invitation jobs and related records. Our cleanup cannot erase records a recipient saw, a push already handed to another provider, a screenshot or a provider's own legitimate operational records. Backup restoration follows the existing erasure procedure.

4. Choice and fair handling

The sender chooses the individual offer, and the recipient chooses whether to join. Sending is not permission to add someone silently or to share group encryption keys with their device. Ignore closes the offer and allows a brief undo, provided nobody has since cancelled it and it remains valid. Repeated sends are limited; an ignored offer cannot immediately be reissued.

Account settings let the recipient stop new direct invitations, cancelling pending offers, or turn off invitation push notifications. Their choice is not exposed to a sender as a block. We do not infer consent to marketing or expand an existing model-processing permission. No new standing AI-consent purpose is involved.

Current guardian and child-account protections remain required for a child joining. The child is told in plain words that administrators can see Join or Ignore. No new authority is given to a guardian to read the child's unrelated invitation inbox.

5. Risks and controls

Risk Implemented control Kind Residual
Someone uses invitations to discover who holds an account Exact lookup, generic refusal, no returned profile, adult-admin gate, transactional quotas Database/function checks A successful invitation still reveals reachability
A mistyped email identifies the wrong account Confirmed email, immutable account binding, invalidation on address change, explicit recipient choice Database rules Control of an inbox is not proof of real-world identity
A group name exposes private circumstances before consent Minimal invite-only projection; no photo, roster or content Database read boundary Names can themselves disclose family or sensitive information
A recipient feels pressure because Ignore is visible Clear notice at the choice, bounded history, no seen/read data or response ranking Copy plus database scope/retention Administrators can remember or photograph the decision
An unwanted sender repeatedly interrupts somebody Sender/group quotas, Ignore cooldown, recipient disable control, no automatic reminder Database and dispatch checks Multiple groups/accounts can still attempt harassment
Two phones race and produce unintended admission or privilege Atomic first valid transition, immutable offered role, current eligibility checks, duplicate constraints Database Account compromise still enables acts as that account
A child is admitted without a guardian or gains administrator powers Active guardian and group eligibility required, under-18 member role forced Existing triggers and new RPC checks Age and guardian declarations retain their existing limitations
A push opens another account's invitation or old group data Fresh authenticated invite read; no implicit group switch Database plus client routing A generic push may remain on a shared phone

6. Structural versus conventional

The structural controls are table privileges, recipient/admin read boundaries, unique pending offers, immutable bindings, atomic membership changes, guardian triggers and server expiry/quota checks. The shipped migration has adversarial tests against a second authenticated account. A confirmed email is an account fact, not proof of a person's real-world identity.

Generic notification words, minimal request payloads, no sensitive logging, accessible buttons, correct routing and truthful UI are application conventions. Automated tests should catch a regression, but tests are not a database guarantee. Retention has a tested deletion path and the migration creates the scheduled sweep. Production delivery remains disabled until an operator supplies the explicit Vault/cron dispatcher setup; merging code does not send a notification.

Implementation evidence and limits

20260923231501_direct_group_invitations implements the email binding, guarded creation and response RPCs, outgoing-history projection, privacy-minimised export and cascading deletion paths. It also creates durable per-token notification jobs, accepted-ticket ledger entries and retention sweeps. The client obtains each received offer freshly after a generic notification and does not persist the inbox across accounts. The isolated database gate exercised invitation authorization, contact and authority changes, expiry after locks, child/event eligibility, ignore/cancellation races, delivery claims, opt-out and token reassignment; client and transport tests cover account guards, preference failures and generic ticket classification.

This is local implementation evidence, not a claim that Expo, Apple or Google delivered a message, that another person did not photograph a visible outcome, or that production Vault values have been configured. Physical-device delivery and the operator setup are checks in use after release.

7. Children and the service's existing assessment

A child can deliberately accept a family/group invitation without passing a code around. They gain a clear choice, but the visible Ignore outcome costs some privacy from administrators. The least-disclosure alternative would keep Ignore private and show only that the invitation ended. The accepted design instead identifies the decision so administrators can manage the offer; it does not show opens, response speed or engagement statistics. That trade is stated at the point of choice and the history is bounded.

Adult-only sending, guardian-required membership and keeping optional child phone numbers out of this release reduce harm. They do not establish an exemption from social-media rules. This cross-group feature and its visible decision re-examine the existing assessment's review triggers. Our design reasoning is that an admission decision authorises membership, like an organisational RSVP, rather than reports consumption of posted material. It carries no user message, read indicator, score or aggregate describing somebody's responsiveness. This is our interpretation, not a regulator's determination. Public discovery, a custom invitation post, views, acceptance rates or response rankings would require a new assessment.

8. Residual risks and limits

We accept that exact invitation success can disclose account reachability, group names can disclose context, administrators can remember an ignored offer, and inboxes can be shared or compromised. These limits are narrower than a public directory or automatic membership and are disclosed rather than claimed away. A person's explicit Join is still needed, and encryption-device approval remains separate.

We make no guaranteed push, exactly-once delivery or immediate provider-erasure claim. Push transport is simulated in automated tests; physical-device delivery remains a check in use.

9. Review triggers

Reassess if what joining means for a group's earlier messages changes, or if signup or phone invitations are added, a new provider or processing location is used, phone becomes a login credential, discovery or bulk contacts are introduced, message text is added, Ignore becomes private/public to a different audience, or retention/role/guardian/encryption boundaries change. The phone deferral remains tracked in the deferred-phone issue.

10. Coverage of the draft assessment requirements

Nature, purpose and flows are in sections 1–3; necessity of each child's data item is in section 2; choice and fair handling are in section 4; best interests and competing interests are in section 7; specific safeguards and their limits are in sections 5–6; harms and remaining risks are in sections 5 and 8. This is implementation evidence for the public register, not a statement that the draft Code is already in force or that legal compliance is proved.

11. Sources