don't sign in with google (the smart ape, 2026)

X thread by the-smart-ape (the_smart_ape) walking through what happens when a Google account vanishes overnight, why "sign in with Google is more secure than passwords" is wrong, and where SSO is actually fine. The structural argument: clicking "Sign in with Google" is not creating an account — it's telling the app "Google will vouch for me." When Google stops vouching, every dependent service stops working in the same instant. The cascading-loss case study sets the stakes; the architectural and attack-surface arguments justify the recommendation.

The friend's three-year SaaS

A founder gets one email: "your account has been suspended for violation of our policies." No reference number, no human, no appeal path. Eight years of Gmail, gone. Drive, YouTube, Play Store purchases, gone. The three-year SaaS itself, gone — because the founder had stacked every operational tool on "sign in with Google":

Notion — three years of product specs, customer notes, contracts, financial forecasts.
Figma — design system, brand assets, every mockup.
Linear — roadmap, every bug, every customer ticket.
Vercel — production deployment tied to a GitHub account whose recovery email was the dead Gmail. He can see the site is up; he can't touch it.
Stripe — dashboard auth went through Google. He can't refund, can't even read his own MRR.

He still doesn't know what he did wrong. Google never told him.

The framing the thread leans on: there is no contract, no SLA, no court. There is a form, the form is read by a model, the model says no.

The named precedent

Andrew Spinks, developer of Terraria, lost his account in January 2021. 15 years on Gmail, no explanation. He got it back — but only after publicly cancelling the Stadia port of his game and the story going viral. The normal appeal process did nothing. The implicit claim is that this is the rule, not the exception: the appeal process isn't designed to work for individuals without media leverage.

The architectural argument

The "SSO is more secure than passwords" pitch compares one half of the picture (the password) to a system (password manager + per-site email alias + hardware 2FA key). Done properly, the latter wins on every axis except convenience. SSO trades distributed risk for concentrated risk: statistically the expected loss is the same, but emotionally and operationally it isn't even close — losing 1/20 of your stack hurts; losing 20/20 ends the business. See sso-concentration-risk for the umbrella concept.

The Truffle Security domain-takeover flaw (January 2025)

A startup dies. Its domain hits the open market. Someone buys it for $12, spins up Google Workspace on the same domain, recreates alice@deadstartup, bob@deadstartup. Then they walk into the dead company's Slack, Notion, Zoom, ChatGPT by clicking "Sign in with Google" — because the SaaS apps only check the email and Google's domain claim, neither of which changed.

Google's first response was to close the report as "won't fix," classified as fraud-and-abuse rather than an OAuth bug. They only reopened it after the researchers' Shmoocon talk was accepted and the story went viral. Final bounty: $1,337. The thread's framing: a meme bounty for an industry-scale flaw is also a signal about the team's architectural priorities. See google-oauth-domain-takeover.

Post-password-reset attack vectors

The "I have 2FA, I'm fine" story is wrong because the modern attack class doesn't go through the password flow at all.

Multilogin / refresh-token replay. Late 2023 researchers found an undocumented Google OAuth endpoint called multilogin that, given a refresh token, regenerates fresh session cookies. By 2024, ten-plus malware families (Lumma, Rhadamanthys, others) had integrated it. They steal the refresh token from Chrome, regenerate cookies, and keep the session alive after the victim resets their password. The only real fix is to revoke every active session and every third-party OAuth grant manually from the Google security page. Almost nobody does this because nobody knows that's what they need to do.

Consent phishing. The attacker doesn't try to authenticate as you. They put up a real Google consent screen — actual google.com domain, valid cert, your account already logged in — and ask you to grant their malicious app a permission like "read your email" or "manage your drive." You tap Allow. Now they have a Google-signed token with exactly that permission, valid for months. Password didn't help. 2FA didn't help. You were never asked to authenticate; you were asked to authorize. Completely different mechanism.

Industry numbers cited. Token theft was 31% of Microsoft 365 breaches in 2025. In March 2025 attackers pivoted device-code phishing to Google. In August 2025 the Salesloft/Drift breach harvested OAuth tokens for Salesforce and Google Workspace integrations at scale. See oauth-token-theft.

The button is a tracker

The "Sign in with Google" button isn't an image — it's a Google-hosted script. Any page carrying it loads code from Google's servers, so Google sees the page load, the referrer, the user agent, and, if you're already logged into Google in another tab, exactly who you are. You don't have to click it. Just loading the page is enough.

The Apple contrast

"Sign in with Apple" solves a different (and additional) problem with Hide My Email — each app gets a unique forwarding alias. Google has no equivalent. Your real, primary email goes to every app, forever — and that primary email is the master key to every password reset you will ever do.

The actual rule

Not "never use SSO" — "if losing access to this service for 30 days would damage your work or your money, do not use SSO." Sort by recovery damage, not by which button is more convenient. Concrete steps the thread closes with:

Audit. Open myaccount.google.com/connections, revoke everything unrecognized or unused in six months.
Separate. Anything money- or work-touching (Stripe, domain registrar, cloud provider, accounting, Slack) gets a real account, real password, real 2FA. No Google.
Alias. Stop giving the real email to every app. Proton, Fastmail, SimpleLogin, Apple's relay all generate per-app aliases. Burn the leaked one and move on.
Break the recovery chain. None of the password manager, cloud, or domain-registrar recovery emails should point to Gmail. Gmail dying tomorrow should not orphan everything else.
Pre-mortem. Sit for ten minutes: if your Google account vanished tonight, what would you lose?

Cross-references

sso-concentration-risk — the umbrella concept; distributed risk traded for concentrated risk.
google-oauth-domain-takeover — the Truffle Security finding.
oauth-token-theft — multilogin and consent phishing as attack vectors.
bitwarden / marius-bitwarden-not-recommended — adjacent concrete-recommendation territory for password managers.
long-lived-keys — refresh tokens as long-lived credentials whose revocation surface most users never touch.
supply-chain-security — adjacent class of "the platform you depend on can betray you" risks.
the-smart-ape — author entity.

Captured 2026-05-19 from smart-ape-dont-sign-in-with-google.