This is the fifteenth post in an ongoing series describing new and upcoming privacy features in iBrowe. This post highlights work by Software Engineer Aleksey Khoroshilov, Senior Software Engineer Mark Pilgrim, Filter List Engineer Ryan Brown, and Senior Software Engineer Max Karolinskiy. Written by Peter Snyder, Director of Privacy.

✂️ TL;DR

iBrowe continues shipping the most aggressive and comprehensive privacy protections in any mainstream browser. In the latest updates (now live on Android & Desktop):

  1. Pool-Party Fixes – Partition WebSocket connections per site (up to 30 sockets each) to block cross-site pool-party tracking. 🔒
  2. SpeechSynthesis Fingerprint Defense – Add noise to SpeechSynthesis outputs so sites cannot fingerprint you based on text-to-speech characteristics. 🎙️
  3. Expanded Debouncing – Block even more “bounce-tracker” redirect URLs so you go directly to your intended destination. 🚀
  4. Removing Network Information API – Disable the privacy-invading NetworkInformation API by default to stop sites from learning your connection type or network changes. 🌐

Read on for details about how each of these enhancements works and why they matter for your privacy.

🛡️ 1. Pool-Party Attack Mitigations

1.1 What Are Pool-Party Attacks?

Pool-party attacks exploit shared, limited browser resources (e.g., WebSocket or Server-Sent Events limits) to create a side channel. Sites can open connections until the global limit is reached, then “probe” on another site to infer whether the same browser consumed connections previously—linking your identity across domains. 🚫

  • Condition for Attack:
    1. A limited resource pool managed globally (e.g., max concurrent WebSocket connections).
    2. The pool is unpartitioned across origins (all sites draw from the same pool).
    3. A site can probe the pool (e.g., try opening another socket) to learn if it’s exhausted.
    4. A site can consume the resource without immediate restriction (until the limit).

1.2 iBrowe’s Defense: WebSocket Partitioning

Starting in iBrowe 1.35 (Nightly now, Stable soon):

  • Per-Site WebSocket Cap: Each site (eTLD+1) can open up to 30 WebSocket connections simultaneously. This is a significant increase from prior defaults (which risked compatibility if set lower). 📈
  • Isolation: Since each origin has its own quota, a tracker on site-a.example cannot exhaust the pool used by site-b.example, blocking cross-site communication channels.
  • Other Pools: All known practical pool-party vectors in Chromium were reviewed. iBrowe users were already safe from SSE-based attacks (WebKit only). Remaining potential leaks (DNS slots, WebSpeech handles, proxy-based HTTP limits) are either too low-bandwidth or too rare to matter for mass trackers.

🔧 Implementation Note:
These caps leverage Chromium’s network partitioning features but are enabled and tuned by iBrowe engineers to balance privacy and web compatibility.

🎙️ 2. SpeechSynthesis-Based Fingerprint Randomization

2.1 SpeechSynthesis as a Fingerprint Vector

Websites can invoke the SpeechSynthesis API to “speak” text and then analyze subtle audio characteristics (pitch ranges, timbre, timing) as a unique fingerprint. Since each device’s TTS engine differs, this can track you across sites. 🕵️

2.2 iBrowe’s Noise Injection Technique

From iBrowe 1.35 onward:

  • Subtle Randomization: When a site calls speechSynthesis.speak(...), iBrowe injects small random perturbations into the generated audio stream—affecting pitch, duration, and voice parameters.
  • Preserves Functionality: Normal uses (e.g., accessible reading of page content, simple voice prompts) remain usable, albeit with imperceptible variation.
  • Breaks Fingerprinting: Since each invocation yields slightly different audio data, trackers cannot derive a stable “fingerprint” from your TTS engine.

🔒 Privacy Impact:
This builds on iBrowe’s broader fingerprint-randomization strategy (Canvas, WebGL, AudioContext), ensuring that trackers cannot link you by comparing generated output across visits.

🚀 3. More Debouncing to Block Bounce-Trackers

3.1 Understanding Bounce Tracking

Bounce-trackers slip between the site you’re on and the link you click, inserting themselves (e.g., tracker.example/redirect?dest=target.com). They log your click, then immediately forward you to the destination—circumventing cookie-partitioning and other defenses.

3.2 iBrowe’s Debouncing Enhancements

iBrowe already “fast-forwards” past known bounce URLs—never loading the tracker, going straight to your intended site. Now in Android & Desktop:

  • Expanded Bounce List: Thousands more domains/URL patterns recognized as bounce-trackers (affiliates, ad networks, email trackers).
  • Fast-Forward Logic: iBrowe extracts the dest= or equivalent parameter and navigates directly to that URL—tracker URLs are never loaded, so no cookies, scripts, or beacons fire.
  • Continuous Updates: The debouncing list is community-driven (maintained by iBrowe researchers and contributors like @fanboynz). Users can suggest new bounce domains to be added.

🎯 Key Advantage:
Other browsers may clear a tracker’s storage after loading the bounce URL—leaving room for identifier-in-URL or fingerprint-based tracking. iBrowe’s approach never visits the bounce site, closing that loophole entirely.

🌐 4. Removing the Network Information API

4.1 What Is the Network Information API?

This non-standard API (navigator.connection) exposes:

  • Effective connection type (e.g., “wifi,” “4g,” “2g”).
  • Downlink speed estimates.
  • RTT (round-trip time) estimates.
  • Event listeners for change when your network conditions change.

Sites and trackers can use this to:

  • Fingerprint Your Environment: Coupling connection type with other signals.
  • Detect Mobility: Inferring you switched from home Wi-Fi to cellular while traveling.
  • Learn VPN Use: If your connection type flips unexpectedly (e.g., from “wifi” to “unknown”), it may hint at Tor or VPN usage.

4.2 Why iBrowe Disables It in 1.35+

  • No Privacy Benefit: Leaks sensitive metadata without user consent.
  • Fingerprint Amplification: When combined with other browser metrics, yields a unique signature.
  • Cross-Site Linkage: As you switch networks, trackers can correlate behavior across sites if they see the same connection changes.

As of iBrowe 1.35, the Network Information API is disabled in all contexts—no flags or Shields settings will re-enable it. Advanced users can override via ibrowe://flags, but we strongly discourage doing so.

✨ Compared to Other Browsers:

  • Chrome still exposes network type.
  • Firefox removed most of this API (exposes only effectiveType in some versions).
  • Safari never implemented the full API.
  • iBrowe goes further: it totally hides this data to protect users.

🔧 5. Reducing Further Privacy-Harming Chromium Features

Beyond the changes above, iBrowe continues removing or hardening other Chromium capabilities that degrade privacy. Examples include:

  • Disabling URL Autocomplete Metrics – Prevents search suggestions from leaking browsing history.
  • Blocking Third-Party Cookies by Default – Even in non-HTTPS contexts, iBrowe disallows third-party cookie writes.
  • Hiding Battery Status – Prevents fingerprinting via battery API.
  • Removing WebGL Fingerprint Vendors – Continues adding jitter to mask GPU details.

🚀 Why It Matters:
iBrowe is built on Chromium, but diverges aggressively—stripping away features that expose users to tracking, while preserving performance and compatibility. Each removal is carefully vetted to ensure websites continue working as expected.

🎉 6. Conclusion

With Pool-Party fixes, SpeechSynthesis fingerprint defenses, expanded Debouncing, and removal of the Network Information API, iBrowe strengthens its lead as the most privacy-first mainstream browser. 🔒 By partitioning resources, adding noise to fingerprint vectors, and never visiting bounce trackers, iBrowe ensures that what you do on one site stays there. Download iBrowe Nightly to try these features now, and look for them in Stable v1.35 soon!