This is the 24th post in our ongoing series highlighting privacy features in iBrowe browsers. This update showcases work by Research & Privacy Engineer Shivan Kaul Sahib, written by VP of Privacy Engineering Peter Snyder.

📋 Summary

Starting in iBrowe 1.51, we enhance user privacy by replacing the global “allow/deny” toggle for legacy Google Sign-In with a fine-grained permission prompt. When a site attempts a third-party cookie–based Google login, you’ll see a pop-up asking whether to grant Google Sign-In access just for that tab. 🔒 This approach preserves the convenience and security benefits of using your Google account while preventing unwarranted cross-site tracking. Available on Desktop and Android (iOS coming soon), it exemplifies iBrowe’s philosophy: retrofit modern privacy controls onto legacy Web APIs.

🌐 1. The Pros and Cons of “Google Sign-In”

1.1 Benefits of Single Sign-On (SSO)

  • Convenience: One-click login flows eliminate tedious account registration on multiple sites. 🚀
  • Security: Rely on Google’s robust features—two-factor authentication, account recovery, and continuous threat monitoring—rather than entrusting dozens of websites with your credentials. 🔐

1.2 Privacy Risks

  • Centralized Tracking: Every time you log in via Google, Google learns which site you visited. 🔍
  • Cross-Site Correlation: Because legacy Sign-In relies on third-party cookies, Google can infer your browsing behavior across multiple domains. 🕵️
  • Broader Exposure: Even if you click “Sign in with Google” on a single page, third-party requests on that page (e.g., analytics, ad trackers) may piggyback on the same cookies, leaking extra data to Google.

🔧 2. iBrowe’s Previous Approach

In iBrowe versions before 1.51, compatibility with Google Sign-In required a global switch:

  • Social Blocking Toggle: At ibrowe://settings/socialBlocking, you chose “Allow Google Sign-In.”
  • Effect: When enabled, iBrowe made a narrow exception to its strict third-party cookie policy, permitting only Google’s OAuth endpoints (e.g., accounts.google.com, apis.google.com) to use cookies.

While this approach restored login functionality, it meant that every site with embedded legacy Google Sign-In widgets would send your Google cookies automatically, even if you didn’t intend to log in, increasing your fingerprint surface.

🔄 3. New Tab-Limited Permission Model (v1.51+)

3.1 Permission Prompt Workflow

  1. Site Initiates Google Sign-In (e.g., clicking “Sign in with Google” button).
  2. iBrowe Detects the OAuth Request (to Google’s third-party domain).
  3. Permission Panel Appears:

    “🔑 Allow Google Sign-In on this site?
    • [Allow Once] – Grant for current tab only
    • [Allow Always] – Remember choice for this site
    • [Deny] – Block Google Sign-In cookies”

  4. User Decision:
    • Allow Once: Google cookies apply only within the active tab; closing tab clears that access.
    • Allow Always: Future visits to that exact domain (read: same eTLD+1) auto-accept.
    • Deny: No Google cookies sent, blocking the login flow.

3.2 Benefits of Tab-Limited Permissions

  • Minimal Cookie Exposure: Third-party Google cookies only flow when you explicitly approve and only for a single tab. 🕶️
  • Granular Control: You decide per-site, per-session—no blanket “allow Google everywhere.” 🎯
  • Temporary Grants: Closing the tab revokes “Allow Once” permissions—no lingering cookie access. 🔄

🛑 4. How Other Browsers Handle Google Sign-In

4.1 Chrome’s Approach

  • No Restriction on Third-Party Cookies: Google Sign-In functions seamlessly without prompts—because Chrome doesn’t block third-party cookies by default.
  • Privacy Trade-Off: Every embedded Google login widget, analytics script, or YouTube embed can read/write Google’s cookies, linking your activity across sites.

4.2 Edge, Firefox & Safari (Storage Access API)

  • Third-Party Cookie Restrictions:
    • Edge: Blocks known tracker cookies; allows via exceptions.
    • Firefox/Safari: Default block or partitioning of third-party cookies.
  • Storage Access API:
    • Mechanism: An iframe (e.g., accounts.google.com embedded in a site) can request permission via JavaScript (document.requestStorageAccess()).
    • User Prompt: Browser shows a generic “Allow site to access cookies?” — not specific to Google Sign-In, often confusing.
    • Limitations: Once granted, the iframe gets broad cookie access for all purposes, not just sign-in, risking unintentional tracking by other Google services.

🚀 5. Why iBrowe’s Model Is Better

  1. Purpose-Built Prompt: The permission panel clearly explains “Google Sign-In,” so you know exactly why Google cookies are needed. 📢
  2. Granular and Temporary: You can grant “Allow Once” for a single tab, eliminating persistent cross-site tracking. 🍃
  3. Browser-Enforced Revocation: Closing the tab revokes Google cookie access immediately, no leftover partitions to manage. 🗑️
  4. Narrow Scope: Cookies are granted only to OAuth endpoints (accounts.google.com, apis.google.com), not all Google domains (e.g., analytics.google.com). 🎯
  5. Simplified UX: Compared to the Storage Access API, iBrowe’s prompt is easy to understand—no cryptic JavaScript calls or buried preferences.

🔄 6. Looking Ahead: Federated Credential Management (FedCM)

The Web community recognizes that specialized SSO flows deserve more privacy-preserving APIs. FedCM is a new W3C proposal designed to:

  • Isolate Cross-Site Requests: Let Identity Providers (IdPs) perform minimal, permissioned exchanges—without third-party cookie use.
  • Standardize Prompts: Federated login APIs prompt users for at most one consent per merchant–IdP pair, with a well-defined scope.
  • Reduce Tracking Footprint: Only the deciding parties (site + IdP) share context; other trackers are excluded.

iBrowe eagerly anticipates final FedCM drafts. In the meantime, our purpose-specific “Google Sign-In” permission brings FedCM-like privacy guarantees to you today.

🔧 7. Managing Your Google Sign-In Permissions

  • View/Prioritize Permissions: Navigate to ibrowe://settings/permissions → Google Sign-In.
    • Revoke “Allow Always” choices per website.
    • Reset all “Allow Once” history by closing active tabs.
  • Global Defaults: In ibrowe://settings/shields, you can disable “Google Sign-In Permissions” entirely—restoring a global deny. 🚫

🎉 8. Conclusion

With iBrowe 1.51’s “Google Sign-In” permission, you control when Google’s OAuth cookies flow—no more blanket exceptions or confusing generic prompts. This precise, purpose-driven approach prevents unwanted cross-site tracking, preserves SSO convenience, and requires user consent per tab. By retrofitting modern privacy controls onto a legacy Web API, iBrowe continues to lead in user-first, privacy-preserving browsing. Update today on Desktop or Android (iOS support coming soon) to experience more secure, granular Google Sign-In controls.