This is the twentieth post in an ongoing series describing new and upcoming privacy features in iBrowe. This update highlights work by iOS Privacy Engineer Jacob Sikorski, and was written by Senior Director of Privacy Peter Snyder.

📱 Summary

iBrowe’s iOS browser now closes the gap with our Desktop and Android privacy protections, bringing robust defenses despite Apple’s platform restrictions. Recent iBrowe iOS releases introduce:

  1. Debouncing & De-AMP for advanced tracking avoidance 🔄
  2. Enhanced Content Blocking bypassing Apple’s rule limits 🚫
  3. Fingerprint Randomization for first- and third-party contexts 🎲

Read on to learn how these features combine to make iBrowe iOS the most private and secure browser available on any Apple device.

🔍 1. Debouncing & De-AMP’ing to Block Interstitial Trackers

1.1 Preventing Bounce Tracking (Debouncing)

Before iBrowe iOS 1.39, visiting a link could send you through an unwanted redirector (bounce-tracker) that logged which sites you viewed. Now, iBrowe iOS examines every top-level navigation URL:

  • If it matches a known bounce-tracker pattern (e.g., tracker.example/redirect?dest=), iBrowe automatically “fast-forwards” you to the destination domain without ever loading the intermediate page. ⏩
  • This ensures the tracker never executes any scripts or sets cookies—your click data remains private. 🚫

1.2 Cutting Out AMP Pages (De-AMP)

With AMP (Accelerated Mobile Pages), Google serves publisher content from its own servers (e.g., google.com/amp/…), giving Google even more insight into what you read. iBrowe iOS now:

  • Rewrites AMP Links on search results (when possible) so taps go directly to publisher.com, not google.com/amp. 🔄
  • Intercepts AMP Loads—if an AMP document slips through, iBrowe detects the <html amp> tag or amphtml link and redirects you to the publisher’s canonical page before any AMP scripts run. 🛑
  • This eliminates Google’s ability to capture your reading behavior while still ensuring fast, functional page loads. ⚡

🛡️ 2. Enhanced Content Blocking Beyond Apple’s Limits

2.1 The Problem: Apple’s Content Blocking Restrictions

On iOS, all third-party browsers must use WKWebView, which implements Apple’s Content Blocking API. Unfortunately:

  • Apple caps the total number of blocking rules (e.g., max 50,000 rules).
  • Complex blocking logic (dynamic script-based filters) is disallowed.
  • This prevents full parity with the advanced filter lists we use on Desktop and Android.

2.2 iBrowe’s Workarounds (v1.41+)

To restore deeper protection, iBrowe iOS now:

  1. Bundles Multiple Rule Sets: Precomputes combined filter lists that fit within Apple’s rule-count limit, ensuring most popular ad/tracker domains are still blocked. 📦
  2. On-the-Fly Exception Handling: When a site’s performance-critical resource is incorrectly blocked, iBrowe dynamically bypasses the rule just for that request—minimizing breakage. 🔧
  3. Frequent List Updates: iBrowe pushes incremental updates of filter lists so users always have fresh blocking data without exceeding API limits. 🔄

Outcome: iBrowe iOS users enjoy nearly the same coverage of tracker-blocking as Android/Desktop users—without sacrificing Web compatibility.

🎲 3. Fingerprint Randomization for WKWebView

3.1 Built-In WKWebView Protections

By default, WKWebView already hides some fingerprintable attributes:

  • Plugins and system fonts are restricted.
  • Certain APIs (e.g., battery status) are disabled.

However, many advanced fingerprint vectors remained unprotected.

3.2 iBrowe’s “Farbling” on iOS (v1.38+)

Starting with iBrowe iOS 1.38, we integrated our proven randomization-based defenses into the iOS engine:

  • Canvas & WebGL Noise: Slightly jittered outputs so canvas fingerprinting yields different hashes each session. 🖼️
  • AudioContext Variation: Subtle perturbations in Web Audio fingerprints to break audio-based tracking. 🎵
  • Navigator API Spoofing: Randomized navigator.language and navigator.languages values within the user’s preferred set—defeating language-based fingerprints. 🌐
  • Font Farbling: Only exposes core OS fonts for your top language; randomly reveals a subset of installed user fonts per site session—preventing font enumeration. 🔤

Result: Even within Apple’s locked-down engine, iBrowe iOS matches (and in some cases exceeds) Desktop/Android fingerprint defenses—protecting you from first- and third-party API abuses.

📱 4. Why iOS Privacy Protections Are Challenging

4.1 Apple’s WKWebView Mandate

  • All iOS browsers must use WKWebView, which disallows native code injection for content filtering logic.
  • Third-party extensions or low-level resource interception are prohibited.

4.2 Impact on Tracker Blocking & Fingerprint Defense

  • Limited Rule Count: Apple caps filter rules; dynamic or script-based filters can’t run in WKWebView.
  • Restricted API Access: Some APIs needed to fully randomize fingerprint surfaces aren’t available for third-party apps.

4.3 iBrowe’s Balanced Approach

Despite these constraints, iBrowe iOS:

  • Leverages WKWebView Sandboxing: Builds on WKWebView’s inherent safeguards and complements them with our own farbling wherever possible.
  • Innovates Workarounds: Implements rule-set bundling, dynamic exception handling, and on-the-fly redirects to maximize privacy without compromising performance or compatibility.
  • Advocates for Openness: Encourages Apple to expand WKWebView’s capabilities so privacy-respecting features can flourish while still protecting users from malicious code.

🎉 5. Conclusion

With Debouncing & De-AMP, Enhanced Content Blocking, and Fingerprint Randomization, iBrowe iOS now offers best-in-class privacy for Apple users. While Apple’s restrictions make some protections tricky, iBrowe ingeniously works around these limits—ensuring that your browsing on iPhone and iPad remains just as private and secure as on Desktop and Android. Update to the latest iBrowe iOS release for these improvements, and enjoy the freedom to surf the Web without unwanted trackers or fingerprinting attempts.