This is the eighteenth post in an ongoing series describing new and upcoming privacy features in iBrowe. This post highlights work by Privacy PM & Engineer Shivan Kaul Sahib, and was written by Shivan Kaul Sahib and Senior Director of Privacy Peter Snyder.

📋 Summary

iBrowe now offers De-AMP, a powerful feature that ensures you never land on a Google-hosted AMP page—you go straight to the publisher’s original URL. ⚡ AMP (Accelerated Mobile Pages) compromises privacy, security, and user experience while strengthening Google’s control of the Web. With De-AMP, iBrowe rewrites known AMP links and intercepts AMP loads—redirecting you to the true article before any Google AMP code executes. This reduces data replay, accelerates loading, and keeps your browsing private. De-AMP is live in Nightly and Beta, and ships by default in iBrowe 1.38 on Desktop and Android (iOS coming soon).

🔍 1. What Is AMP and Why It’s Harmful

1.1 AMP Overview

  • AMP (Accelerated Mobile Pages) is a Google-driven subset of HTML that serves publisher articles from Google’s servers (e.g., google.com/amp/…), even when the original content belongs to another site like nytimes.com.
  • On mobile search results, Google prefetches AMP pages in the background, then delivers them on click—making you believe you’re on the publisher’s site when you’re really on Google’s copy. 📲

1.2 Privacy Concerns

  • Tracking Scope: AMP gives Google a broader view of what you read. Every article click on an AMP URL logs your behavior to Google—unlike direct visits, where only the publisher and any included trackers record your actions.
  • Forced Publisher Integration: Publishers lose autonomy when they rely on AMP to avoid search-rank penalties. Google punishes non-AMP sites, coercing them to embed AMP code and link back to google.com. This further centralizes user data under Google’s domain.

1.3 Security & Usability Issues

  • Security Boundary Confusion: Users assume they’re interacting with the publisher’s domain (e.g., nytimes.com), when in fact the URL bar shows google.com/amp/.... This breaks the browser’s trust model: security and privacy boundaries become unclear. 🔒
  • False Performance Claims: While AMP advertises faster loads via Google’s infrastructure, internal disclosures show AMP only improves median performance—popular sites often load faster with their own optimization strategies. Users sometimes pay for ad-free browsers just to sidestep AMP. 🚀

1.4 Web Monopolization

  • Google’s Control: AMP pushes more of the Web onto Google’s servers and proprietary format. Publishers cede control over ad delivery, analytics, and content structure. AMP is one piece of Google’s broader “Privacy Sandbox” and “Web Bundles” strategies that further lock users into Google’s ecosystem. 🌐

🚀 2. How De-AMP Protects Your Browsing

De-AMP employs a three-pronged defense against AMP pages:

2.1 Link Rewriting: Avoid AMP from the Start

  • In-Page URL Rewrites: When you load a page that contains AMP links (e.g., Google Search results), iBrowe rewrites those URLs to point to the publisher’s canonical version instead of the Google AMP proxy. 🔄
    • Example:
      • Original: <a href="http://nytimes.com/article">
      • Rewritten: <a href="https://nytimes.com/article">
  • Seamless Integration: Sites continue functioning as normal—no broken links—yet you bypass Google’s AMP servers entirely.

2.2 In-Flight Fetch Interception: Catch AMP Before Rendering

  • AMP Detection: Even if a link wasn’t rewritten (e.g., from social media or older pages), iBrowe inspects fetched pages for <html amp> or the amphtml URL meta tag.
  • Automatic Redirection: Upon recognizing an AMP document during fetch (before any scripts or images load), iBrowe halts the load and immediately redirects to the original publisher URL extracted from the AMP metadata.
    • Prevents: Any execution of Google’s AMP JavaScript, images, or personalization. Your network requests go straight to the content owner, dramatically reducing Google’s telemetry.

2.3 Future Debounce Extension: Skipping AMP Redirects

  • Upcoming (v1.40): De-AMP will integrate with iBrowe’s existing debouncing logic—detecting known AMP redirect patterns (e.g., amp/s/…) and skipping to the publisher URL even before the request starts. ⏭️
  • Benefit: Complete elimination of AMP redirects, even when link rewriting isn’t possible (e.g., in embedded iframes or obfuscated share links).

⚙️ 3. Enabling, Disabling, and Compatibility

3.1 Enabled by Default

  • Nightly & Beta: De-AMP is active out of the box. If it doesn’t appear, restart iBrowe.
  • Stable v1.38+: De-AMP ships enabled on Desktop & Android; iOS release follows.

3.2 User Controls

  • Disable De-AMP: For those who need to access raw AMP pages (e.g., developers testing AMP sites), navigate to ibrowe://settings/shields and toggle De-AMP off. 🔧

3.3 Site Compatibility

  • De-AMP strives to preserve publisher features (comments, paywalls, interactive embeds). If any site breaks due to aggressive AMP avoidance, contact the iBrowe community: we’ll fine-tune the rewriting or interception rules.

🌐 4. The Broader Context: AMP 2.0 and Beyond

4.1 AMP 2.0 (Signed Exchange & WebBundles)

  • Signed Exchange (SXG): Embed publisher content in cryptographically signed bundles served by Google. Unlike AMP, SXG content can appear to come from the publisher’s domain even when served by a third party.
  • WebBundles: A format that packages HTML, CSS, JS, and other resources into a single binary. Google envisions bundling entire websites into .wbn files on their servers, then distributing them—again under Google’s control.

Risks:

  • Users lose visibility into the true content origin.
  • Privacy-enhancing tools (like ad blockers) cannot easily inspect or filter deeply nested bundles.
  • Google’s “Privacy Sandbox” incentives will push publishers to adopt these proprietary formats to maintain search visibility, further centralizing control.

4.2 iBrowe’s Stance

  • Oppose Encroachment: iBrowe actively voices concerns in W3C and other standards bodies, advocating for user-first protocols that preserve origin transparency.
  • Future De-SXG & De-WebBundle: Once AMP 2.0-like formats emerge at scale, iBrowe will develop “De-SXG” and bundle-inspection tools, automatically rewriting or intercepting those requests to serve the publisher’s true origin content.

🎉 5. Conclusion

De-AMP in iBrowe 1.38 puts you back in control—no more Google AMP shortcuts. By rewriting known AMP links, intercepting in-flight AMP fetches, and soon integrating with debouncing, iBrowe guarantees you see the publisher’s original page, not Google’s proxy. 🌟 This enhances your privacy, boosts security, and helps keep the Web decentralized. Update to iBrowe 1.38 (or try Nightly/Beta) and enjoy direct, privacy-respecting browsing—free from AMP’s hidden redirects.