PIA: Sign in with Google, and Sign in with Apple

Amended 22 October 2026, before release: staged sign-up. The server still requires an authorised email address to create an account, whether by password, emailed code, Google or Apple. An Apple Hide My Email relay address must itself be authorised while the gate is closed. The duplicate Gmail-inbox rule, NULL-email refusal and 7-day unconfirmed-account cleanup still apply. Only the founder may later open the database gate; after that, prior email authorisation will not be needed. A new account does not itself join a group.

Status: Built, awaiting console prerequisites. The design below was written before the code, as a precondition of building it (exposure draft s 38(3)), and the code now matches it: the sign-in module, the two buttons, the privacy policy amendment and the account-section disclosure this document describes are all in place. What is NOT yet true is that either button works on a real device — the Apple Developer capability, the three Google OAuth client ids, and the two Supabase provider settings are owner-only steps nobody else can complete (see the public prerequisites list a reader of this document does not need, and the operator's own checklist for it), and §8's residual risk 4 — the identity-linking rule — remains unverified until somebody tries it on a test project. Read this document as describing what SHIPPED, not what has been exercised. Written: 15 September 2026 · Last revised: 31 October 2026 (Google nonce, §5.8) · 22 October 2026 (staged sign-up, before release) · 15 September 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

Two more buttons on the sign-up and sign-in screens: Sign in with Google and Sign in with Apple. Tapping one opens the platform's own sheet — Apple's system sheet on an iPhone, Google's account chooser — the person picks an account, and the phone hands us a short-lived signed token saying who they are. We give that token to our authentication service, which checks the provider's signature and either finds the matching account or creates one. No password is created, and no web page opens.

The point is a shorter door, not a different app. Everything on the other side of it — invite-only, groups, the child-account rules, what a member can see — is unchanged.

In scope: the two buttons, what each provider learns, what we receive and store, how the invite-only rule survives them, and what happens when a person already has a password account at the same address.

Out of scope, and covered elsewhere: whether sign-up should stop being invite-only at all — that is a separate question with consequences for several assessments in this register, and this design deliberately does not touch it. Also out of scope: any use of a provider beyond identity. We ask for nothing but who the person is; a person's Google calendar, contacts, files and photos are not requested, and the separate assessment of calendar integration in this register describes a design that reaches a calendar through the phone rather than through a provider account.

2. Data involved

Kind	Whose	Children's?	Sensitive?	Free text?
The provider's subject identifier — an opaque, stable id for this person at this app	The member's own	Only where a child account is created this way; see §5.4	No	No
The email address the provider asserts, and whether the provider says it has verified it	The member's own	Same	No	No
A display name, offered by the provider at the first sign-in only	The member's own	Same	No	Yes — a name is whatever a person typed into their provider account
The signed identity token itself	The member's own	Same	No	No — a fixed structure
The fact that this person signed in to this app, and when	The member's own, held by the provider	Same	No	No

Strictly necessary (s 38(2)(b)), item by item. The subject identifier is what lets the same person come back to the same account; without it the button cannot work at all. The email address is what the invite list is written in — it is the whole of how we know this person was invited. The display name is not strictly necessary, which is why it is used only to pre-fill a profile that has no name yet, only at first sign-in, and is never written over a name the person chose themselves. The token is verified and discarded.

Apple hands over the address and the name once, ever. Apple's documentation is explicit that the scopes an app asks for are returned only at the first authorisation for that person; every later sign-in returns the identifier and nothing else. That is a privacy design of Apple's and we do not work around it: the address is kept on the account record from the first sign-in, and a person who wants to change their display name later changes it in the app, not by signing in again.

Not collected, and could have been:

No provider access token, no refresh token, and no permission beyond identity. We ask for who the person is and nothing else. There is no standing permission on their provider account that we could use later, and nothing of that kind for us to lose if our own systems were breached.
No profile picture from either provider. A member's display photo stays something they upload.
No contacts, calendar, files, or any other provider data.
No password. A person who uses these buttons has no password with us to be guessed, reused or leaked.

3. Flows and locations

Data	Device	Our database (Sydney)	The provider	Region
The account chooser and the sheet	Runs on the device, drawn by the operating system or by the provider's own component	—	Google or Apple authenticates the person and issues the token	The provider's own
The signed token	Created on the device, handed straight to our authentication service	Verified against the provider's published keys; never stored	Issued by the provider, which knows it issued it	Sydney, for the verification
Subject identifier and email address	—	Stored on the authentication records for the account	The provider already holds both	Sydney
Display name at first sign-in	—	Written to the member's profile only where it is empty	—	Sydney
Anything about a group, a child, a task, a photograph, a message	Stays exactly where it is today	Unchanged	Nothing reaches Google or Apple	—

What the provider learns is the sign-in itself. Google or Apple knows that an account of theirs was used to sign in to this app, and when, and — as with any request made to them — the device's network address. They learn nothing else: not the group, not who else is in it, not that there is a child in it, not a single thing anybody has written in the app. This is the same information a provider holds about every app that uses its sign-in, and it is the honest cost of the feature.

Direction matters under the cross-border rules. We are not sending personal information overseas here; we are receiving it. The provider discloses to us; we disclose nothing back. The one thing that travels outward is the request the person's own device makes to their own provider, which is that provider authenticating its own user.

Nothing new is logged. We record outcomes, not tokens and not addresses, for the reason that applies everywhere in this app: a line in a log is data an erasure cannot reach.

4. Legal basis and consents

No new consent purpose, and the reason is the test we apply to every other switch. A consent in this app gates something that sends a member's or a group's information somewhere it would not otherwise go — a baby's day to a model, a group's mail to a mail provider overseas, a member's assistant conversations to a tracing tool. None of that happens here. The person's act of choosing the button is itself the disclosure, made by them, to a company they already hold an account with, about an authentication that company is performing. There is no standing flow to withdraw, nothing that lapses, and nothing a twelve-month re-consent would be asking about. A purpose with nothing behind it would be consent theatre: a switch that, turned off, changes nothing.

The existing terms acceptance carries it, though the two doors show it differently. On the sign-up screen a person ticks the same checkbox a password sign-up already requires, before the sheet opens — an explicit act, identical to the password path. The sign-in screen has no checkbox at all, so a tap there is not "exactly as a person typing a password does": it carries a caption naming the Terms and Privacy Policy, visible before the sheet opens, and the tap itself is what the app treats as the moment of agreeing for anyone whose first-ever sign-in happens to land on that screen. Both are a genuine, visible act before any account is created; only the sign-up screen's is a tick a person can see themselves make. Either way the same dated record is written, as an act, with the version of the wording current at the time.

The privacy policy must be amended before either button is shown to anybody. It currently describes account data as an email address, a display name, a user id and a terms timestamp, collected when a person signs up. It does not name Google or Apple as sources of that information, does not say that an identity provider learns the person signed in, does not say that no other provider data is requested, and does not mention that Google's own sign-in component sends a device identifier and usage data to Google for Google's analytics (§5.5). All four have to be there, with the policy's own version number moved so the change is a dated one. Building the buttons before that ships would put a collection in front of members that the policy they have already agreed to does not describe. This is a precondition, not a follow-up.

Fair and lawful means (s 38(2)(c)): the person chooses the provider, sees their own account chooser, and can back out of it. We do not pre-select a provider, we do not hide the email option behind them, and nothing is collected until they have picked an account.

Where Apple's own store rules bear on it, stated precisely. Guideline 4.8 of the App Store Review Guidelines does not name Sign in with Apple. It says that an app using a third-party or social login service to set up or authenticate a person's primary account must also offer an equivalent login service that limits collection to name and email address, lets a person keep their email address private, and does not collect interactions with the app for advertising without consent. It then lists exceptions, the first of which is an app that exclusively uses the company's own account system — which is the exception this app relies on today, with nothing but email and password. Adding Google gives that exception up. Sign in with Apple is the obvious service meeting the three features, which is why the two are designed and shipped together on iOS rather than one being added and the other deferred.

Worth noting for the third of those features: we do not collect interactions with this app for advertising at all, by anybody, and never have.

5. Risks and mitigations

Risk	Who is harmed	Mitigation	Structural or conventional?	Residual
5.1 Somebody who has taken over a member's Google or Apple account signs in as them and reads that member's group.	The member, and everyone else in their group	Two things. First, this route already exists: whoever controls a person's mailbox can reset a password today, so the button shortens an existing path rather than opening a new one — and because we link only on an address the provider says it has verified (§5.2), the provider identity always carries the same address a password reset would have gone to. Second, a stranger signing in on a new device does not get the group's sealed content: photographs, chat messages and a member's own assistant history are encrypted under keys held by that group's own devices, and a new device has to be admitted by an existing member before it can read any of it.	Structural for the sealed half — a key the new device does not hold. Structural for the linking rule. The comparison with the password model is reasoning, not a control.	Accepted. The unsealed half — task titles, calendar times, who is in the group — is readable immediately. We hold no second factor of our own, on either door.
5.2 A member who already has a password account taps Google with the same address, and either gets a second, empty account or has their existing account joined to an identity that is not theirs.	The member	We join an incoming provider identity to an existing account only where the address matches exactly and the provider asserts it has verified that address. Where the provider does not assert verification, we neither join nor create: the sign-in is refused with a sentence telling the person to use their password. Where the addresses differ, no joining is even considered — a different address is a different person as far as the invite list is concerned.	Structural at the authentication layer, but it depends on configuration as well as code: the joining behaviour is a setting on our authentication service, and a change to that setting would change the rule without changing a line of ours. §6 says so, and §9 makes it a review trigger.	A person whose provider will not assert a verified address cannot use the button at all, and is told to use their password. And one fact behind this row is unverified: our authentication service's own documentation says automatic joining "requires unique, verified emails to prevent account takeover attacks", but we could not find a published statement of the exact rule it applies. Before either button is shown to anybody, the behaviour is to be confirmed by trying it on a test account rather than assumed from the sentence above.
5.3 A person chooses Apple's Hide My Email (amended 22 October 2026, before release).	That person	While the gate is closed, the server requires an authorised email address whichever door presented it, so an Apple Hide My Email relay address must itself be authorised; the sign-in screen says so and names the relay address. Only the founder may later open the database gate; after that, prior email authorisation will not be needed and a relay address makes an ordinary account.	The refusal is structural (the account-creation trigger). The explanation is conventional — copy.	Accepted. While closed, someone who wants to keep their address from us needs their relay address authorised first. In both phases recovery depends on Apple's forwarding, and invitations by email, a guardian's invitation and the group inbox match the relay address.
5.4 A child with their own provider account uses one of the buttons.	The child, and the guardian relying on the link	A child account's guardian link is keyed to the address the guardian was invited under. Where the provider presents that same address, the link forms exactly as it would have — the trigger that writes it reads the verified address from the authentication record and matches without regard to capitalisation, so a differently-capitalised address is not a problem. Where the provider presents a different address — a second account the phone happens to be signed into, or an Apple relay — the invite list refuses account creation outright, so no unlinked child account can come into existence. There is no separate sign-up screen to keep the buttons off. A child invited by a guardian signs up through the exact same screen as anybody else, with the same ordinary invite code — nothing on that screen can tell an adult's sign-up from a child's, and the buttons therefore render for both.	The refusal of a different address is structural. There is no "adults only" mitigation for the buttons at all — see §6 and §8.2, which this finding corrected.	Accepted. A child who reaches the ordinary sign-up screen with their own invited address can use a button exactly as an adult can, and we accept that because the account which results is a correct child account with its guardian link intact — the same outcome a password sign-up already produces.
5.5 The provider's own software on the phone reports something to the provider that is not part of signing in.	The member	None that we control, and it is worth being exact rather than reassuring. Google's sign-in component for iOS carries Apple's required privacy manifest, and in it Google declares that the component collects a device identifier and usage data for analytics purposes, linked to the person — alongside name, email address, phone number, user id and coarse location for app functionality. It declares that none of it is used for tracking across other companies' apps. So the honest statement is not "it sends nothing": it is that Google's own declaration says an identifier and some usage data go to Google for Google's analytics, and that no advertising tracking is declared. Apple's sheet is drawn by iOS itself. We add no measurement of our own to either path and we ask for nothing beyond identity.	None. The declaration is Google's, and it is the most authoritative thing available.	Accepted, and it belongs in the privacy policy rather than only here — see §4. Anything more precise than the declaration (which endpoints, how often, what exactly is in "usage data") is unverified: we have not inspected the component's network traffic and make no claim about it.
5.6 A phone is signed into a provider account belonging to somebody else in the family, and the wrong account is picked.	Whoever owns the account that was picked	The account chooser shows which account is about to be used, which is more than a remembered password does. On the sign-up path the invite list is the backstop: an uninvited address creates nothing.	The backstop is structural. Reading the chooser is the person's own.	Accepted. On a shared device a person can create an account under an address that is invited but is not theirs — no different from a shared device with a saved password.
5.7 A provider's display name overwrites the name a member chose for themselves in the app, or a meaningless one is invented for them.	The member, and everyone who has to recognise them in the group	The name is taken only when creating a profile that has none, only at first sign-in, and never on a later one. There is a second half to this: where no name is supplied, two places in the app today fall back to the part of the email address before the "@" — which for an Apple relay address is a random string of letters and digits, presented to a group as somebody's name. Either the address is a relay, in which case the sign-up is refused anyway (§5.3), or the fallback has to be told not to do that.	Conventional — conditions in the sign-in and group-joining code, to be pinned by a test.	None material once the fallback is fixed; recorded here so that it is fixed rather than discovered by a group looking at a stranger's name.
5.8 A token issued for a different app is replayed at ours.	The member whose token it was	The authentication service verifies the signature, the issuer and the audience — a token minted for another app fails the audience check — and, where the provider supports one, the request carries a nonce so a captured token cannot be reused. Amended 31 October 2026: that nonce was true for Apple only. Google requests carried no nonce on either platform, and every iPhone Google sign-in was refused, because Google's iPhone component puts its own nonce in every token and the authentication service refuses a token with a nonce the request didn't send. From the next iPhone build, the iPhone app sends its own nonce with Google, as it does with Apple. Android's Google tokens carry no nonce, so Android sends none. An iPhone that hasn't installed that build can sign in with Google only while the authentication service's nonce check is switched off for Google. That is a short stop-gap: Apple's check stays on throughout, the Google check goes back on once every active iPhone has the new build, and any period it was off is recorded here with its dates.	Structural — verification happens before an account exists.	Accepted for Google on Android, and on an older iPhone while the stop-gap lasts: a valid Google token for our app, captured within its hour of life, could be exchanged for a session. It cannot be forged or taken from another app.
5.9 The screen tells a person their address is not on the invite list, which confirms whether a given address is invited.	Whoever is on the list	Unchanged by this feature: the same message already appears on the email sign-up path, and the underlying check has always been callable.	Not a new exposure	Accepted, as it already is. It says whether an address was invited; it says nothing about which group, or by whom. (Amended 22 October 2026, before release.) While the gate is closed this stays true. The Gmail spelling check (`provider_email_conflict`) now answers only a fixed word, never a stored spelling, and the duplicate-inbox refusal names no address.
5.10 A real invited member is refused because the invite list compared their address as a literal string, when one large provider — Gmail — does not: it ignores dots in the part before the "@", ignores anything after a "+", and always shows the account its own original spelling, whichever of those the person typed when they were invited. The first person this happened to was refused entirely, and — had the refusal not caught it — would have had a SECOND, empty account created for the identical inbox, because the authentication service only ever joins an incoming identity to an existing account on an exact match.	Anybody invited under a Gmail address whose spelling later differs from what Google's own sign-in presents	The invite list now recognises the handful of spelling differences Gmail itself ignores — dots, a "+" suffix, and its second domain name — and nothing else: every other provider's address is still compared exactly, because dots are meaningful there. Recognising the SAME inbox under two spellings makes a second, genuine risk reachable that did not exist while every comparison was literal: the invite list can now say yes to an address the authentication service would still treat as a stranger and try to create a new account for. So account creation itself now separately refuses an address that resolves to the SAME inbox as an existing account under a DIFFERENT spelling, naming both spellings in the refusal, rather than allowing a second account to be created. A person is told to sign in with their password using the spelling already on file.	Structural — a database rule that runs on every account creation, including our own elevated access, with no exemption.	Accepted. The one cost is a person who is refused a second account having to go find their original spelling rather than being silently joined to it — joining automatically was rejected as a separate, larger design question this feature does not answer (§5.2's own residual risk about how the authentication service's joining rule actually behaves). A check offered to the app BEFORE it asks the authentication service to sign somebody in can say which spelling is on file, so the refusal names it rather than reading as a bare failure; that check answers only for an address that is genuinely on the invite list, in keeping with §5.9 above. And that check is itself a small, deliberate disclosure worth stating plainly: for an address that IS on the invite list, it tells the caller that an account already exists there AND its exact spelling — more than §5.9's plain yes/no ever revealed about an invited address, though nothing at all about one that is not invited. Accepted because the caller, to be asking the question at all, must already be attempting to sign in as that person (holding a token the provider issued for that identity) — this is not a new way for a stranger to learn whether somebody has an account, only a more specific answer to a question the invite-only check already answered in part. If more than one existing account happens to share a normalised address (§6's own note on why `allowed_emails` carries no uniqueness guarantee), the check declines to name either rather than guess — never widening what it reveals beyond a single, genuine match.

6. Structural versus conventional

Structural — something other than good intentions enforces it:

Invite-only survives the new doors untouched (amended 22 October 2026, before release: while the database gate is closed; only the founder may later open it, after which prior email authorisation will not be needed). A trigger on account creation refuses any address that is not on the invite list, and it does not care which provider presented it, whether a password was involved, or what is doing the writing — it refuses our own elevated access too, deliberately, because an exemption would be a hole in the only thing enforcing the property. Nothing about these buttons required that trigger to change, and nothing about them may.
A forged or foreign token creates nothing. Signature, issuer and audience are checked against the provider's published keys before any account exists.
A relay address, or any other address that differs from the invited one, cannot produce an unlinked child account while the gate is closed, because it cannot produce an account at all unless that address is itself authorised (amended 22 October 2026, before release). After the founder opens the gate it produces an ordinary account with no guardian link, which can't found or join a group without an adult birth month or a confirmed guardian link.
The guardian link is written from the verified address, not from anything the client sends, and matches without regard to capitalisation — so the invited address is the key, however the person typed it or the provider spelled it.
A new device does not inherit a group's sealed content. Photographs, chat messages and a member's own assistant history are encrypted under keys held by that group's own devices; a device that has not been admitted reads none of it, whichever door it signed in through.
A second account for an inbox that already has one is refused, whatever spelling reached it. Once the invite list recognises a Gmail spelling difference as the same inbox (§5.10), account creation itself separately refuses a differently-spelled duplicate — a database rule, not a screen, and it runs on every writer including our own elevated access.
- The invite list itself does not guarantee one entry per address, so this refusal is written to stay safe under more than one match rather than to assume it can never happen. Where more than one invite-list entry, or more than one existing account, shares a normalised address — which can happen only from state that predates this design, since the refusal above stops a NEW second account from ever being created going forward — nothing guesses which one is "the" match. The account-creation refusal still refuses (it does not need to know which existing spelling to name to know a duplicate exists), and the two places that would otherwise have to pick one — the spelling-disclosure check in §5.10 and the equivalent check that carries a guardian's invitation forward to a child's own account — both decline to answer rather than attribute to the wrong person.

Configuration, which is neither of the two and should not be mistaken for the first:

The joining rule is partly a setting on our authentication service, not only a decision in our code. The service joins an incoming provider identity to an existing account when the provider asserts the address is verified; that behaviour can be changed in a console without touching anything in the app. It is written down here for that reason, and §9 makes a change to it a trigger to re-read this document.

Conventional — held by copy, by a condition in the code, or by a test:

"Adults only" is not a property of this feature. There is no session at the sign-in screen, so the app cannot know who is about to tap — and, checked against the actual sign-up flow rather than assumed, there is no SEPARATE sign-up screen a guardian's invitation opens for the buttons to be kept off of in the first place: a child invited via invite_child reaches the same ordinary sign-up screen as an adult, with the same ordinary invite code. An earlier draft of this document described the buttons as absent from a child's sign-up path; that was wrong, and is corrected here rather than left standing. What actually decided against a stronger mitigation is §7's argument, not a screen: an "is this address a child's" check would be a new disclosure about a child to an unauthenticated caller, which is a worse outcome than the buttons simply rendering identically for everybody.
The Apple relay explanation is copy, and copy is where a promise goes stale. It is rendered from one place and pinned by a test, like every other claim in this app that a member reads.
The display-name rule (§5.7) is a condition in the sign-in path.
Asking for nothing beyond identity is a decision in the code. Nothing outside it prevents a future change from asking for more, which is exactly why §9 names it.

7. Best interests of the child

Children are affected here mostly by not getting the feature, so the reasoning has to be about what withholding it costs them and about what happens when they get it anyway.

What a child gains: nothing directly. Where a child does sign in with a provider under their invited address, the account they get is the same child account, with the same guardian link and the same restrictions as one created with a password.
What it costs them: a child who has a provider account and reaches for the familiar button may be refused — because their phone is signed into a school-managed account with a different address, or because they chose Apple's Hide My Email — and a refusal at a sign-in screen is not a moment a young person is well placed to work out. The mitigation is the wording, and it is necessarily general rather than specific: the client cannot know, before an account exists, who invited a given address or what that address even is once a provider has hidden it, so the message can say only that this app is invite-only and to "ask your group organiser" — a role, not a name — rather than naming either address or a specific adult.
The safer design not chosen: refusing the buttons for anybody whose invited address carries a child invitation. That would need a way to ask, before sign-in, whether a given address is a child's — a new thing our systems would disclose about a child to anybody able to type the address. Publishing that a particular address belongs to a child, to a caller who has not signed in, is a worse outcome than the confusion it would prevent.
Where the interests of child and parent diverge: barely at all here. A guardian's convenience in signing up faster costs their dependant nothing; the guardian link is written from the same verified address either way.
What a child is told: nothing new. This feature adds no record about a child and changes nothing on the page that tells a child what the adults around them can see.

This is not an argument about the under-16 rule. Restricting which screens carry a button does nothing for the app's position under that rule, and our own standing correction is that an age-restricted experience carries no meaningful weight there. It is not cited here as if it did.

8. Residual risk we accept

A person who wants Apple's private relay cannot use Sign in with Apple with us, for as long as the app is invite-only and an invitation is written as an email address. That is us defeating a privacy feature of Apple's in order to keep a privacy property of our own, and it is a real trade rather than an oversight. We state it on the screen at the moment it bites.
There is no "adults only" mitigation for these buttons, at all. A first draft of this document described one — the buttons kept off a guardian-invitation sign-up screen — and that screen does not exist: a child invited via invite_child signs up through the ordinary sign-up screen, exactly as an adult does, with an ordinary invite code. Nothing refuses a child here beyond what already refuses anybody with an uninvited or unverified address. We accept this because the account a child gets by that route is a correct child account with its guardian link intact — the same outcome a password sign-up already produces — and because the alternative (asking, before sign-in, whether a given address is a child's) would disclose to any caller that a given address belongs to a child, which §7 argues is the worse outcome.
Google's sign-in component sends a device identifier and usage data to Google for Google's own analytics, by Google's own declaration (§5.5). We cannot turn that off, it is the price of using the component, and it is a thing a member should be told about in the policy rather than left to find. Anything more precise than the declaration is unverified and is not claimed.
We could not confirm, from published documentation, the exact rule our authentication service applies when joining a provider identity to an existing account (§5.2). It is to be established by test before either button ships, and if it turns out to join on an address the provider has not verified, this design does not proceed as written.
A takeover of a member's provider account is a route into the unsealed half of their group's records. It is not a new route — the mailbox already resets the password — but it is a shorter one, and we hold no second factor of our own on either door.
Part of the joining rule lives in a console setting, so somebody with access to that console could change who can join an existing account without any change to the code or to this document. Written down here so that it is at least visible.
We cannot revoke a provider identity from our side except by deleting the account. There is no "unlink Google" screen in this design. A member who wants that today deletes their account.
The client's email_verified check (§5.2) has not met a real device. The code treats a missing claim as unverified and refuses rather than joins — Apple's own documentation says this claim is sent, as a string, but nothing here has read one from an actual sign-in on an actual phone. If it turns out Apple omits the claim in some legitimate case this design has not anticipated, the symptom is a real person refused with "we could not confirm that address", and the fix is in the code, not the trigger.
The check that names the existing spelling (§5.10) is advisory, not the boundary, and can fail silently to a plainer message. If it cannot be reached, a genuine duplicate is still refused — that refusal is the database rule from §6, not this check — but the person sees a generic failure instead of a sentence naming their existing spelling. Accepted because the alternative, blocking sign-in whenever this one advisory check cannot be reached, would take the button away over a message-quality problem rather than a security one. And Gmail's own rules for what it ignores are a fact about Gmail today; if Gmail ever changes them, the two spellings this app treats as one inbox would need re-deriving from Gmail's own current documentation rather than assumed to still hold.

9. Review trigger

Re-read this document when any of these stops being true:

We ask either provider for anything beyond identity — a calendar, contacts, a profile photo, anything.
The joining behaviour on our authentication service changes, or is configured to join on an address the provider has not verified.
A third identity provider is added, or one of these two is offered on a platform where it is not offered today.
A child account is offered one of these buttons deliberately, or the invitation sign-up path starts carrying them.
The Apple relay refusal is replaced by anything that accepts a relay address — which would mean the invite list is no longer written in email addresses, and several arguments in this register would need re-reading with it.
We gain a second factor, or any other authentication method.
Invite-only ends. (This is one of the two register-wide triggers, and it bites harder here than almost anywhere: several paragraphs above lean on the fact that every account was vouched for.)
Gmail changes which spelling differences it ignores, or a second provider needs the same treatment — the handful of rules §5.10 relies on would need re-deriving from that provider's own current documentation rather than assumed to still hold.

10. Checklist against exposure draft s 38(2)

s 38(2)	Requires	Answered in
(a)	the nature, scope, context, flow and purposes of the handling of children's personal information	§§1–3
(b)	why the collection is strictly necessary	§2 — item by item; the subject identifier and the address are the feature, the display name is not and is bounded accordingly
(c)	lawful and fair collection	§4
(d)	consistency with the best interests of the child	§7
(e)	how we comply with the Code and the Act	§4, §6
(f)	risk of harm to, and impact on, children	§5.4, §7, §8

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

11. Sources

Primary — law and regulator. Privacy Act 1988 (Cth), Australian Privacy Principles 1 (open and transparent management, which is why §4 makes the policy amendment a precondition), 3 and 5 (collection and notification), 6 (use and disclosure) and 8 (cross-border disclosure — engaged only in the direction §3 describes). The Children's Online Privacy Code exposure draft, ss 13, 14(3)(b), 15–17, 20, 23, 38, 39; section numbers may move on registration.

Primary — platform rules and provider documentation. Apple's App Store Review Guidelines, guideline 4.8 ("Login Services"), read from Apple's published guidelines rather than a summary — §4 quotes its structure rather than paraphrasing it, because the exception the app relies on today is in the same section. Apple's developer documentation on Sign in with Apple and on communicating through its private email relay service — how a person chooses between sharing and hiding their address at first authorisation, what an app receives when they hide it, the relay address domains, and Apple's notice that new addresses move to a second domain while existing ones keep working. Apple's documentation for the sign-in component used here, which states that the requested scopes are returned only at a person's first sign-in and are absent from every later one. Google's published privacy manifest for its iOS sign-in library, which is the source for everything §5.5 says about what that component collects and for what purpose. Supabase's authentication documentation for signing in with a native identity token — the parameter list, including the nonce, was taken from the installed library's own type declarations, because the published reference page did not render completely — and its documentation on identity linking, which states that automatic linking "requires unique, verified emails to prevent account takeover attacks" but which we could not get to state the exact rule; §5.2 records that as unverified and makes confirming it a precondition.

In-repo. The migration 20260808150000_enforce_email_allowlist.sql — the trigger on account creation that is the whole of invite-only, and its own note on why a client check is not the boundary. supabase/migrations/20260907233008_child_schema.sql — the guardian link written from the verified address at profile creation. The migration 20260916001000_gmail_address_normalisation.sql — §5.10's Gmail-aware address comparison and the duplicate-account refusal it made necessary. app/auth/signup.tsx and app/auth/login.tsx — the current doors. lib/providerSignIn.ts — the check that names the existing spelling before either button asks the authentication service to sign somebody in. constants/legalTexts.ts — the privacy policy §4 requires amending, and its version constant. lib/consents.ts — the closed list of consent purposes §4 declines to add to. Google's own published description of how Gmail addresses are delivered — dots and anything after a "+" are ignored, and google addresses may also be reached at a second domain name — which is the entire factual basis for §5.10 and nothing more than that. Our own written rules: Invite-Only Is Enforced In The Database, A Birth Month Is A ROW, "Child" Is Two Ages, And The Guardian Invariant Is A Trigger, A Consent Is An ACT, Encryption Is Two Tiers, Privacy Copy Is Tested For What It Must NOT Say, Gmail Addresses Are Compared As Google Compares Them.