Network Info API Fingerprinting: Connection Identity

Introduction

Modern web browsers expose connection details through the Network Information API (navigator.connection). This API was originally designed to help web developers deliver content more efficiently. For example, a website might serve lower-resolution images to users on slower connections, or defer non-critical resources when bandwidth is limited. Properties like effectiveType, rtt (round-trip time), downlink (bandwidth estimate), and type (connection type) all contribute to these adaptive decisions.

While this functionality improves the browsing experience, it also introduces a significant fingerprinting surface. Every time your browser reports its connection characteristics, it shares information about your network environment, your ISP, and potentially even your geographic location. These details, when combined with other browser signals, create a more specific profile that can be used to identify and track users across browsing sessions without their knowledge or consent.

BotBrowser provides coordinated protection for navigator.connection properties, so the values reported by the browser can follow the loaded fingerprint profile instead of exposing the host network environment.

Why Network Information Matters for Privacy

Network connection data poses a privacy challenge because the values are dynamic. Unlike static browser properties such as screen resolution or installed fonts, network metrics change over time. The patterns created by these changing values can still contribute to tracking, especially when combined with other browser signals.

Here is why network information raises privacy concerns for researchers, testers, and anyone who values their online privacy:

• Geographic exposure: Connection latency values correlate with physical distance to servers. If your browser consistently reports low latency to servers in one region and high latency to servers in another, this pattern reveals your approximate location, even without IP geolocation data.
• ISP and connection type profiling: Different internet service providers and connection technologies produce characteristic network signatures. A fiber optic connection produces measurably different latency and bandwidth patterns compared to a cellular data connection or a satellite link. These differences help narrow down your identity.
• Proxy and VPN exposure: When you connect through a proxy or VPN, the navigator.connection values may not align with the expected network behavior for the proxy's exit location. This mismatch between your reported connection data and your apparent IP address can reveal that you are using a proxy, undermining the privacy that the proxy was meant to provide.
• Session correlation: Although individual network readings fluctuate, the statistical distribution of your connection values over time forms a recognizable pattern. This pattern can be used to link separate browsing sessions back to the same user.

The saveData property, which indicates whether a user has enabled a data-saving preference, adds another dimension to this fingerprint. Only a small percentage of users enable this feature, making it a distinctive identifier on its own.

Research from INRIA found that network information, when combined with timing analysis, could improve cross-session user identification accuracy by up to 8% compared to fingerprinting without network data. The API requires no permissions and operates silently in the background, making it particularly concerning from a privacy perspective.

Understanding the Network Information API

What Properties Are Exposed

The Network Information API makes several properties available through navigator.connection:

• effectiveType: Classifies the connection as slow-2g, 2g, 3g, or 4g based on observed performance metrics.
• rtt: An estimate of round-trip time, expressed in milliseconds.
• downlink: An estimate of downstream bandwidth in megabits per second, rounded to the nearest 25 Kbps.
• type: The underlying connection technology, such as wifi, cellular, ethernet, or unknown.
• saveData: A boolean indicating whether the user has requested reduced data usage.

Why Standard Privacy Tools Fall Short

Understanding why common approaches do not adequately address network fingerprinting helps explain why BotBrowser takes a different approach.

VPNs and proxy servers change your visible IP address, but they do not modify the values reported by navigator.connection. Your browser continues to measure and report real network conditions. In many cases, the added routing overhead of a VPN actually makes the network fingerprint more distinctive by creating an unusual combination of high latency with an IP address that suggests a nearby location.

Private browsing modes do not define a separate network policy. The navigator.connection API still follows the browser's active configuration.

Browser extensions can attempt to override navigator.connection properties, but they face fundamental consistency challenges. Setting static override values creates a network profile that never changes, which is itself unusual. More importantly, extensions operate at a layer above the browser engine, which means other APIs and internal browser mechanisms may still report the actual network state, creating contradictions that are easy to identify.

Blocking the API entirely is also problematic. If navigator.connection is missing or returns unexpected values, that absence itself becomes a distinguishing signal. Very few legitimate browser configurations lack this API entirely.

These limitations exist because network information is deeply integrated into the browser engine. Effective protection requires control at the same level where the values originate.

How BotBrowser Protects Your Network Identity

BotBrowser coordinates the values reported through navigator.connection from the start of the session. This keeps direct property reads and change notifications aligned with the selected profile and policy.

Profile-Based Network Protection

Every BotBrowser fingerprint profile includes realistic network information values captured from real device configurations. When you load a profile, the browser automatically applies these values:

chrome --bot-profile="path/to/profile.enc" \
       --user-data-dir="$(mktemp -d)"

The profile contains appropriate rtt, downlink, effectiveType, type, and saveData values that are internally consistent and realistic for the type of connection the profile represents. This means you do not need to manually configure individual network properties. The profile handles all of them together, maintaining the relationships between values that a real browser would exhibit.

Explicit Network Info Override

For scenarios where you need explicit control over network information reporting, BotBrowser provides the --bot-network-info-override flag:

chrome --bot-profile="path/to/profile.enc" \
       --bot-network-info-override \
       --user-data-dir="$(mktemp -d)"

When this flag is enabled, the browser reports network information values exclusively from the profile rather than measuring the actual network connection. This also controls the corresponding Client Hints headers (RTT, Downlink, ECT, Save-Data), ensuring consistency between JavaScript API values and HTTP header values. The override applies to all properties and prevents real network state changes from leaking through the API during your session.

Consistent Protection When Using Proxies

One of the most important use cases for network information protection is maintaining consistency when browsing through a proxy. BotBrowser ensures that the navigator.connection values align with the expected network characteristics for the proxy's location:

chrome --bot-profile="path/to/profile.enc" \
       --proxy-server="http://us-proxy:8080" \
       --bot-network-info-override \
       --user-data-dir="$(mktemp -d)"

When a profile is configured with network values appropriate for the proxy's geographic region, the entire browsing identity remains coherent. The reported connection characteristics match what would be expected for a user in that location, eliminating the mismatches that traditionally expose proxy usage.

Change Event Management

On a standard browser, the navigator.connection object fires a change event whenever network conditions shift. These transitions can reveal information about your actual environment, for example, switching from Wi-Fi to cellular data. BotBrowser manages the change event to match the profile's expected network stability, ensuring that real changes in your host network do not leak through during a session.

Configuration Examples

How the Override Policy Is Resolved

--bot-network-info-override is a policy switch, not a request to freeze every network number forever. BotBrowser resolves it in a predictable order:

1. With no override, the browser uses its native network estimator. The page sees measured values with normal browser rounding and privacy buckets.
2. With profile, the loaded profile supplies a baseline for network fields. The browser still applies the legal range, rounding, and per-host variation.
3. With a JSON object, only named fields are overridden. Unnamed fields use the profile baseline when available, or the native measured value otherwise.

For example, this changes latency while retaining the profile's connection type and data-saving preference:

chrome --bot-profile="path/to/profile.enc" \
       '--bot-network-info-override={"rtt":150}' \
       --user-data-dir="$(mktemp -d)"

Values in a profile or custom object are baselines. rtt and downlink are normalized with the browser's usual limits, privacy buckets, and small host-dependent multiplier. Two origins can therefore receive different legal values from one baseline, and two browser processes need not produce the same exact number. A constant unrounded value on every site would be unusual in its own right.

The resolved policy is applied to each browser context created by Playwright, Puppeteer, or another supported automation API. Pages, workers, and requests inside that context use the same resolved identity. A new context can use its own profile or policy without changing an existing context. The JavaScript API and the related RTT, Downlink, ECT, and Save-Data Client Hints use the same result, keeping page-visible and request-visible views aligned. This does not change a proxy's real speed or server-side measurements.

Invalid input is non-fatal. An unsupported policy, wrong value type, malformed JSON, or empty policy is ignored, and BotBrowser continues with measured native values. Other profile fields and sibling contexts remain usable. Check launch diagnostics when troubleshooting, then correct the policy instead of treating fallback values as a custom override.

Basic CLI Usage

# Profile-based network info protection
chrome --bot-profile="path/to/profile.enc" \
       --user-data-dir="$(mktemp -d)"

# With explicit network info override for full control
chrome --bot-profile="path/to/profile.enc" \
       --bot-network-info-override \
       --user-data-dir="$(mktemp -d)"

Playwright Integration

const { chromium } = require('playwright-core');

(async () => {
  const browser = await chromium.launch({
    executablePath: 'path/to/botbrowser/chrome',
    args: [
      '--bot-profile=path/to/profile.enc',
      '--bot-network-info-override',
    ],
    headless: true,
  });

  const context = await browser.newContext({ viewport: null });
  const page = await context.newPage();

  const networkInfo = await page.evaluate(() => {
    const conn = navigator.connection;
    return {
      effectiveType: conn.effectiveType,
      rtt: conn.rtt,
      downlink: conn.downlink,
      type: conn.type,
      saveData: conn.saveData,
    };
  });

  console.log('Network info:', networkInfo);
  await browser.close();
})();

Puppeteer Integration

const puppeteer = require('puppeteer-core');

(async () => {
  const browser = await puppeteer.launch({
    executablePath: 'path/to/botbrowser/chrome',
    args: [
      '--bot-profile=path/to/profile.enc',
      '--bot-network-info-override',
    ],
    headless: true,
    defaultViewport: null,
  });

  const page = await browser.newPage();
  await page.goto('about:blank');

  const connInfo = await page.evaluate(() => ({
    effectiveType: navigator.connection.effectiveType,
    rtt: navigator.connection.rtt,
    downlink: navigator.connection.downlink,
  }));

  console.log('Connection info:', connInfo);
  await browser.close();
})();

Full Identity Consistency

For complete fingerprint protection, combine network info control with other identity settings to create a fully consistent browsing profile:

chrome --bot-profile="path/to/profile.enc" \
       --proxy-server="socks5://user:pass@us-proxy:1080" \
       --bot-network-info-override \
       --bot-timezone="America/New_York" \
       --bot-locale="en-US" \
       --user-data-dir="$(mktemp -d)"

This configuration keeps your timezone, locale, network information, and IP address aligned with the same geographic context.

Verification

After launching BotBrowser with a profile, you can verify that network information protection is working correctly:

const conn = navigator.connection;
console.log('effectiveType:', conn.effectiveType);
console.log('downlink:', conn.downlink, 'Mbps');
console.log('rtt:', conn.rtt, 'ms');
console.log('type:', conn.type);
console.log('saveData:', conn.saveData);

// Verify values remain stable over time
setTimeout(() => {
  console.log('After 5s - rtt:', conn.rtt, 'downlink:', conn.downlink);
}, 5000);

What to check:

1. effectiveType is appropriate for the profile's network class (4g for broadband connections, 3g for slower connections)
2. rtt value is consistent with the proxy location (lower values for nearby servers, higher values for distant ones)
3. downlink is realistic for the connection type represented by the profile
4. Values remain stable during the session with no unexpected changes
5. saveData matches the profile's configuration
6. Fingerprint testing tools report no anomalies or inconsistencies

Best Practices

1. Always use --bot-network-info-override when using proxies. This is the most important recommendation. Without the override, real network measurements can leak through and contradict the expected characteristics for the proxy's location, potentially undermining your privacy setup.

2. Match network values to geography. Choose profiles with network values that are realistic for the proxy location you are using. A profile configured for a broadband connection should have latency values that make sense for the geographic region of your proxy server.

3. Use profiles captured from real devices. BotBrowser profiles include network information values from actual device captures, ensuring that the values are realistic and internally consistent. This is far more reliable than manually specifying individual network parameters.

4. Combine network protection with other fingerprint controls. Network information is most effective as a fingerprint signal when combined with other data points. Similarly, network information protection is most effective when combined with BotBrowser's other fingerprint controls, including timezone, locale, and WebRTC protection.

5. Verify your configuration before starting important sessions. Use the verification script above to confirm that all network values are being reported correctly and remain stable over time.

Frequently Asked Questions

Is the Network Information API available on all browsers?

No. The full API with all properties is available in Chrome, Edge, and Opera. Firefox has limited support, and Safari does not support it at all. BotBrowser profiles account for the target browser's level of API support, so the fingerprint remains consistent with the browser brand being emulated.

Does BotBrowser also control the Client Hints headers related to network info?

Yes. When --bot-network-info-override is enabled, BotBrowser controls both the JavaScript API values and the corresponding Client Hints HTTP headers (RTT, Downlink, ECT, Save-Data). This ensures consistency between what the page can read via JavaScript and what the server sees in request headers.

Can websites measure real network latency through other APIs?

Yes. The Resource Timing API (performance.getEntriesByType('resource')) can measure actual request latency. BotBrowser's timing controls through --bot-time-scale help maintain consistency between navigator.connection values and observable request timing, providing an additional layer of fingerprint protection.

Does the saveData property matter for fingerprinting?

Yes. Only a small percentage of users enable data-saving mode, which makes it a distinctive signal when present. BotBrowser profiles set saveData to match the target device configuration. For most desktop profiles, this is set to false, reflecting typical usage patterns.

How does BotBrowser handle network state changes during a session?

BotBrowser manages the change event on navigator.connection so that real network transitions on the host machine do not leak through to the web page. The reported network state remains consistent with the loaded profile throughout the entire session, regardless of what happens on the actual network.

Does this protect against server-side latency measurement?

No. Server-side latency measurement, where the server measures the round-trip time of its own requests, operates outside the browser and cannot be controlled by any client-side tool. BotBrowser's network info protection controls the client-side API values. For network-level consistency, use an appropriate proxy server that provides realistic latency characteristics for the target geographic region.

Can I set custom network info values without a profile?

The --bot-network-info-override flag works in conjunction with a loaded profile. The profile provides the specific values to report. If you need different network characteristics, use a different profile that matches your desired configuration, or combine your current profile with an appropriate proxy setup.

Summary

A practical review checklist

Before approving a deployment, check the policy at the same scope at which the browser will run. Confirm that the intended profile is loaded, that the context received the expected override value, and that the proxy route is the route authorized for the workflow. Then inspect a page-level result through the normal application path. A small diagnostic page can display the connection type, effective type, and data-saving preference without recording the page's private content.

Compare a native run and an override run with the same browser release, profile, viewport, route, and application state. Change only the policy value. The purpose of the comparison is to confirm that the selected fields change together and that unrelated controls remain stable. It is not a promise that every origin receives one fixed number, because browser scheduling and host conditions still vary.

When a value is unexpected, check the configuration in this order: profile selection, JSON syntax, field names, context creation timing, and proxy routing. A malformed policy is ignored and returns the browser to measured values, so a page that looks unchanged is not evidence that the browser stopped. A separate context is the cleanest way to test a new policy. Reusing a live context can mix the new question with an already established page state.

Keep the review record limited to configuration and visible outcomes. Do not copy page text, credentials, or private request data into a shared report. This gives operators enough information to reproduce a decision while respecting the data policy for the browsing session.

The Network Information API exposes connection characteristics that can contribute to a browser fingerprint. BotBrowser uses profiles and the --bot-network-info-override flag to keep reported values consistent with the selected browsing context. The JavaScript API and related Client Hints can therefore describe the same policy while the proxy still handles real network routing. See the features page for related controls. For adjacent topics, see proxy configuration, DNS leak prevention, and timezone and locale configuration.