Two paths diverged in a wood. One was worn smooth by years of easy traffic. The other asked more of you. More effort, more intention, more thought. Most travelers took the first and forgot there was ever a choice.
In technology, the easier path is usually the one someone else built, optimized for their interests, and made frictionless enough that you stop asking questions. The harder path: a standalone email address, a strong password, no single sign-on shortcut takes more effort. It also keeps the blast radius yours.
A Proton Mail post went viral last week. 14 million views. The message: “Don’t Sign In With Google.” Simple. Emphatic. Repeated seven times for effect.
DON'T SIGN IN WITH GOOGLE
DON'T SIGN IN WITH GOOGLE
DON'T SIGN IN WITH GOOGLE
DON'T SIGN IN WITH GOOGLE
DON'T SIGN IN WITH GOOGLE
DON'T SIGN IN WITH GOOGLE
DON'T SIGN IN WITH GOOGLE— Proton Mail (@ProtonMail) May 15, 2026
The reaction was predictable. Half the replies agreed. The other half asked why. Proton’s follow-up cited two reasons: bad opsec, and Google’s data collection model.
Both points are valid. But they’re two separate problems, and conflating them obscures what’s actually at stake. One is a problem with identity federation broadly. The other is specific to Google.
Let me separate them out.
This Isn’t New. We Just Forgot.
When Gmail launched in 2004, the backlash was immediate. An advertising company scanning your email to serve targeted ads? Privacy advocates called it a line crossed. I wrote about it at the time. The concerns were real.
Two decades later, nobody talks about it. Gmail has over 1.8 billion users. The concern didn’t go away — it got normalized. We traded privacy for convenience so gradually that most users don’t remember there was ever a debate.
Sign In With Google followed the same arc. It launched as a convenience feature. It became the default. The privacy implications got lost in the frictionless experience.
The Proton Mail post is a reminder that the debate was always there. We just stopped having it.
Problem 1: The Blast Radius of Federated Identity
Federated identity lets you authenticate to one service using credentials from another. Sign in with Google, Sign in with Microsoft, Sign in with Apple. The IDP (Identity Provider) vouches for you so the app doesn’t have to manage your credentials directly.
It’s genuinely useful. One set of credentials, many services. Less password sprawl. Faster onboarding.
The risk is structural.
When your Google account is compromised by phishing, credential stuffing, account takeover, the attacker doesn’t just get your Gmail. They inherit access to every service you authenticated with using that account. The blast radius expands automatically.
It applies to any identity provider used as an SSO anchor. Sign in with Microsoft: same blast radius. Sign in with Okta: same blast radius. Sign in with Apple: same blast radius. The blast radius problem is a property of federation itself, not of any particular provider.
Using a single identity as the key to many doors means a stolen key opens all of them.
The mitigation is isolation. Scope your tokens. Monitor federation events. Don’t chain high-value services to a single IdP without compensating controls. For enterprises, this is a foundational identity architecture question. For individuals, it means being deliberate about which services you trust your Google or Microsoft account to vouch for.
Problem 2: The Google-Specific Problem
Here’s where the providers diverge.
Google’s core business is advertising. It is one of the most profitable advertising platforms in history precisely because it knows more about user behavior than almost anyone else. Every interaction with Google’s services — search, Gmail, YouTube, Maps — feeds a behavioral profile that gets monetized through targeted advertising.
Sign In With Google extends that surface area. Every time you use it, Google logs which service you authenticated with, when, and how often. This gets added to your Web and App Activity data. It’s not a bug. It’s the product.
Microsoft is in a fundamentally different business. Its revenue comes from enterprise software, cloud infrastructure, and productivity tools. Microsoft has invested heavily in privacy controls and compliance certifications precisely because its enterprise customers demand it. The business model doesn’t depend on harvesting consumer behavioral data.
Apple goes further. Sign in with Apple doesn’t share your email address with third-party apps — it generates a randomized relay address. Apple’s business model is hardware and services, not advertising.
The point isn’t that Microsoft and Apple are saints. The point is that when the business model is advertising, every data point has value. When it isn’t, the calculus is different. Google is by far the dominant consumer and prosumer federation platform — which makes the distinction worth understanding.
What To Actually Do
Not all identity providers are equal on privacy
If you’re going to use federated login, the provider matters. Here’s how the major platforms stack up:
Apple Best consumer option. Generates a randomized relay email per app, no cross-app tracking, hardware and services business model with no advertising profile.
GitHub Developer-focused, no advertising business, minimal data collection. Good for technical tools and developer accounts.
Microsoft Enterprise business model, strong privacy commitments, no consumer ad profiling. Better than Google, not as clean as Apple.
LinkedIn Owned by Microsoft, but runs its own ad platform. Builds a behavioral profile for LinkedIn advertising. Mixed.
Google Advertising business model. Every sign-in extends your behavioral profile. Use with deliberate caution.
Facebook/Meta Avoid. Cross-app and cross-site tracking is core to their business model. Sign in with Facebook is one of the worst choices from a privacy standpoint.
For individuals
Be deliberate about what you connect to your Google account. High-value services such as financial, healthcare, anything with sensitive personal data deserve standalone credentials. If you use SSO, prefer providers whose business model isn’t built on your behavioral data. Apple is the best consumer option. GitHub is solid for developer tools. A password manager makes standalone credentials practical for everything else.
For enterprises
Identity federation without governance is a liability. Enforce IdP isolation for sensitive systems. Scope OAuth tokens. Audit which applications are federated to which providers. Monitor for anomalous federation events. The question isn’t whether to use federation — it’s whether you’ve built the security layer around it that the risk requires.
Federated vs. Non-Federated: The Security and Privacy Tradeoffs
Neither approach is universally better. The right choice depends on what you’re optimizing for. Here’s how they compare across the dimensions that actually matter:
| Feature | Federated / SSO (Google, Microsoft, Apple, etc.) |
Non-Federated (Username + Password / Passkey) |
|---|---|---|
| Blast Radius | ⚠️ High. One compromised IdP account exposes every service linked to it. |
✅ Contained. A breach on one site doesn’t affect others. |
| Privacy / Tracking | ⚠️ Varies by provider. Google logs every sign-in for ad profiling. Microsoft and Apple do not. |
✅ No third party knows when or where you log in. |
| Authentication Security | ✅ Strong. Most IdPs enforce 2FA, anomaly detection, and passkeys. |
⚠️ Depends on implementation. Weak passwords remain a risk without 2FA. |
| Account Recovery | ✅ Typically handled by the IdP with robust recovery flows. |
⚠️ Varies. You own recovery but also own the risk if you lose access. |
| Third-Party Dependency | ⚠️ If the IdP goes down, changes policy, or suspends your account — you lose access everywhere. |
✅ No dependency. You own your credentials. |
| Consent Scope Creep | ⚠️ Federation often requests access beyond what’s needed — contacts, calendar, profile data. |
✅ The site gets only what you explicitly provide. |
| Convenience | ✅ One click. No passwords to manage. |
⚠️ Requires a password manager and deliberate setup. Worth it. |
The Convenience Trap
The pattern repeats. Gmail launched with privacy concerns that got normalized. Sign In With Google launched and became the default. Every time, the convenience wins in the short term and the privacy implications get deferred.
The Proton Mail post went viral because it said something plainly that a lot of people already sensed but hadn’t articulated. Don’t outsource your authentication to a company whose business model is your data.
That’s not anti-Google. It’s just accurate.
The blast radius problem is real, and it applies to everyone. The data model problem is specific, and it applies to Google. Both deserve attention. Conflating them just makes the conversation harder.