From be5dd529e91d394d84b405a81e33774763e1662b Mon Sep 17 00:00:00 2001 From: thePR0M3TH3AN <53631862+PR0M3TH3AN@users.noreply.github.com> Date: Tue, 4 Aug 2026 11:59:13 -0400 Subject: [PATCH] =?UTF-8?q?Record=20the=20Google=20rail's=20scoping=20and?= =?UTF-8?q?=20blast=20radius=20in=20=C2=A7CO3.3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Per-client-ID app-data silo makes the rail per-site; cross-site portability is the capsule account's job. A host's dead Google project locks out ungraduated users in practice while every account survives on relays -- the phrase card is load-bearing. Shared ecosystem client ID behind a bitlogin.network relay hub considered and rejected: a chokepoint plus federated credential readability is worse than the silo. Note the sensitive-scope verification review hosts should expect. Co-Authored-By: Claude Fable 5 --- docs/centralized-onramps.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/docs/centralized-onramps.md b/docs/centralized-onramps.md index 3537987..146d3c3 100644 --- a/docs/centralized-onramps.md +++ b/docs/centralized-onramps.md @@ -136,6 +136,24 @@ Password rotation while Google-managed is the graduation step (CO6 step 2): the Drive copy simply goes stale and dead, and the rotate screen says so before the user commits. +**Scoping and blast radius (recorded 2026-08-04).** Drive app data is siloed +per OAuth client ID, so the Google rail is a per-site (or per-site-family) +convenience: a credential stored via Site A's client ID is invisible to +Site B, whose "Continue with Google" would offer to create a NEW account. +Cross-site portability is the underlying capsule account's job — password or +phrase work on every BitLogin site. If a HOST'S Google project is banned or +deleted, no Nostr account is lost (capsules live on public relays), but +ungraduated users are locked out in practice: their credential file sits in +their own Drive, readable only through an app bearing the dead client ID. +Graduated users lose nothing but a button. This is why the Tier B2 phrase +card is load-bearing, not decorative. A shared ecosystem-wide client ID +behind a static relay hub on bitlogin.network was considered and rejected: +it would make one domain and one Google project a chokepoint for every +deployment, and a shared client ID lets any federated site read the user's +credential file — worse centralization than the per-site silo it would fix. +`drive.appdata` is a Google "sensitive" scope: hosts should expect Google's +app-verification review before serving more than ~100 users. + ## CO3.2 Architecture B — OAuth as the password manager (recommended) The insight: a BitLogin account requires a high-entropy password, but the