Pairing Google is a verification checkpoint, not a data pull. The act of connecting the Google Account you already use every day is itself what gets recognised. ~Alter reads only your basic Google identity: no Gmail, no Drive, no YouTube, no calendar.
Coming soon
Pairing Google isn't live yet. This page documents what ~Alter will read once it is, published ahead of launch so you can see exactly what it will and won't touch before you ever pair it. The pairing button stays disabled until this connector goes live.
What pairing does not authorise
Pairing this connector is a read commitment, not delegation. Specifically, ~Alter cannot use this pairing to:
- •Read your Gmail, Drive, Calendar, Photos, or any other Google product.
- •Read your YouTube channel, subscriptions, watch history, or uploads.
- •Send anything from your Google Account or act on it in any way.
- •See your Google contacts, saved passwords, or payment methods.
- •Share your Google-derived identity with any third party without a separate consent row scoped to that recipient.
The OAuth or attestation scope we request is the minimum required to recognise the pattern described in What we read. Anything beyond that is structurally refused at the connector boundary, not promised by trust. How pairing works.
What we read
- Your Google account ID, name, and profile picture URL, exactly as the sign-in token carries them.
- Your email address and whether Google has verified it.
What we don't read
~Alter explicitly refuses these fields even when the OAuth scope or API permits them. Every refusal is enforced at the connector boundary, not by trust.
- Any Google API beyond the basic sign-in identity token. No YouTube Data API, no Gmail API, no Drive API, ever.
- Your Google contacts, calendar, files, or search or browsing history.
- Anything not present in the OpenID Connect identity token itself.
Where it lives
Evidence is stored in ~alter's pairing ledger keyed to your ~handle, encrypted at rest. The identity token Google issues is verified against Google's own published signing keys before anything in it is trusted, then discarded; only the resulting identity fields are kept.
How to revoke
Nothing to revoke yet, since Google cannot be paired. This is the revocation you will get when it goes live, published now so you can see the way out before you ever choose the way in. Revocation will be immediate. You will ask the AI client you paired through to revoke this connector, or revoke it from your consent surface over the same connection. Either path revokes the provider token, stops all further reads, and purges the derived signals this connector fed into your identity vector. An audit row records the revocation.
One thing is kept on purpose. The connector retains a record that this account was paired and when it was disconnected, so the same account cannot be unpaired and re-paired in quick succession to churn your identity vector. That cooldown record holds the raw profile snapshot until the window passes. It is never read into a new signal while disconnected, and it is not shared with anyone.
Prefer the command line? The CLI is the optional deeper path and revokes the same connector:
CLI (optional)
alter unpair googlePairing this connector does not enrol you in any matching, ranking, or matching surface. Every downstream use requires its own consent row. See the consent model.