Browser Fingerprinting: Why Your Browser Fingerprint Is More Visible Than Your IP

1. IP Is Only the Outermost Layer

In cross-border AI coding and development tool scenarios, users sometimes run into a confusing situation: after switching to a network egress in a different region, an account is still quickly limited, challenged, or suspended. Many users then conclude that the IP is “not clean enough” and keep buying more expensive lines. But if you break down the detection process, IP is only the outermost threshold in risk evaluation. It is easy to observe and easy to replace. Behind the same egress, there may be hundreds or thousands of real users, and its “cleanliness” depends more on how heavily it is reused and its historical behavior than on price.

Once the connection path is established, signals from the client environment layer, network protocol layer, and interaction behavior layer are continuously collected. When combined, these signals can be more distinctive than the IP and are usually harder to change naturally over time. This article groups the detection items into 15 dimensions across three categories.

Environment Layer: 11 Dimensions Readable by the Client

1. Font and glyph coverage: By measuring text rendering widths, page scripts can infer whether Chinese font families, Japanese fonts, Korean fonts, and open-source CJK fonts are installed on the system.

2. Canvas rendering features: After drawing text and gradients with the same instructions and exporting the resulting pixels, the same GPU model and operating system version often produce a stable hash value. Differences in font rendering, anti-aliasing, and subpixel layout can also make the same text look slightly different across devices.

3. Renderer identity: Graphics interfaces can expose the GPU vendor, GPU model, underlying rendering software, and version information.

4. Graphics capability matrix: Parameter combinations such as supported extensions, maximum texture size, and anisotropic filtering levels across graphics interfaces can strongly distinguish device models.

5. Audio processing features: An offline audio context processes signals using fixed oscillators and dynamic compressors. Accumulating the output samples produces a value influenced by the underlying audio stack implementation and floating-point operation path, which is relatively stable.

6. Media devices and codec capabilities: The number and types of audio/video input and output devices, along with combinations of decodable video codec formats, can reflect the presence of cameras, microphones, and codec hardware.

7. Screen and display parameters: Resolution, device pixel ratio, color depth, available viewport, screen orientation, multi-touch support count, and display features such as dark mode, reduced motion, and color-gamut information.

8. Time zone signals: The current time zone offset, the IANA time zone identifier including city name, and historical offset records such as daylight saving time transitions.

9. Language and regional formats: Browser language and language priority, number and currency formats, first day of the week, time format, relative-time wording, and collation rules. Relative-time wording changes with the system language and region settings and produces a different result from simply changing the page language.

10. Speech input semantics: Which regional model the speech recognition interface is based on and which language tag it returns can reflect the system-level speech region configuration.

11. Hardware and runtime capabilities: CPU logical core count, device memory capacity tier, maximum touch points, battery status, and power-saving mode.

Transport Layer: 3 Dimensions

1. WebRTC address candidates: With default configuration, the real-time communication interface collects candidates across multiple address types, including local internal network addresses, public addresses obtained through session traversal utilities, and addresses obtained through relay services.

2. DNS resolution egress: If domain resolution and page access are completed through the local ISP and a remote network respectively, or if resolution uses an overseas public recursive service, the resolution path becomes disconnected from the egress location. This can slow down connections and also trigger inconsistency judgments.

3. Protocol stack and path features:

   • The order and combination of cipher suites, extensions, and elliptic curves in the TLS handshake can be mapped into a client fingerprint.
   • The HTTP/2 header field order, pseudo-header ordering, and SETTINGS parameters form another layer of features.
   • IPv6 egress addresses, TCP options and timestamps, and path MTU probing results together describe the network path.
   • The offset between the system clock and a standard time source can also be read.

Behavior Layer: 1 Additional Dimension

1. Interaction behavior: Timing intervals and distributions of keyboard/mouse events, scroll trajectories, input pauses, and page dwell paths. These features are not fixed values, but risk-control models can use them to distinguish “human operation” from “script operation.”

2. Why These Features Can Pinpoint a Device

• High-cardinality attributes produce high entropy when combined: The value spaces of different fingerprint dimensions vary widely. A time zone may have only dozens of possibilities, language combinations may number in the hundreds, and a graphics renderer identifier is affected by GPU model, driver version, and system version, giving it a much larger value space. Independent attributes are added according to Shannon entropy, and a few high-cardinality attributes can significantly increase the theoretical uniqueness of a device among millions of users.

• High stability and cross-site correlation: A fingerprint is not like a cookie, which is issued by a site and can be cleared. It is also not like an IP, which changes when the network changes. Clearing cache or using incognito mode usually does not change it, making it suitable as a long-term identifier across sites and sessions.

• Multiple snapshots amplify small differences: Risk-control services often do not make a conclusion from a single glance. They continuously collect multiple snapshots. If a supposed “California device” consistently shows East Asian time zone and language characteristics, that stability becomes the strongest evidence.

• Contradictory combinations are more damaging than a single feature: An overseas IP combined with a screen full of Simplified Chinese fonts, a Chinese system language, and a UTC+8 clock looks like a primary work machine in East Asia accessed through a tunnel. The platform may not be able to determine exactly where you are, but it can determine that “the egress and the endpoint are not the same environment.” Many risk-control models assign high weights to such self-contradictory combinations and may even trigger hard rules.

3. Build a Self-Check Page That Leaves Nothing on Disk

A self-check tool should be implemented entirely in the front end. Collection and scoring should all be completed in local browser memory, with no uploads, no cookies, and no local storage. The data should be destroyed when the page is closed. If egress information needs to be compared, a stateless interface can echo back the access-side time zone, language, and protocol features.

1. Example: Font Probing

<!-- Font width probe: compare the rendering width of candidate fonts against fallback fonts to determine whether fonts are installed -->
<span id="probe" aria-hidden="true" style="
  position:absolute; left:-9999px; top:0; visibility:hidden;
  font-size:72px; white-space:nowrap;">AaBbGg</span>
<script>
(() => {
  const probe = document.getElementById('probe');
  const FALLBACKS = ['monospace', 'sans-serif', 'serif'];
  // Candidate font families can be extended as needed; this is only a generic example.
  const CANDIDATES = ['SimSun', 'Microsoft YaHei', 'STHeiti',
    'PingFang SC', 'Songti SC', 'Noto Sans CJK SC', 'WenQuanYi Zen Hei'];
  const widthOf = (font) => {
    probe.style.font = `72px ${font}`;
    return probe.getBoundingClientRect().width;
  };
  // Results are stored in memory in a Map and released automatically after the page unloads.
  const installed = new Map();
  for (const fallback of FALLBACKS) {
    const base = widthOf(fallback);
    for (const family of CANDIDATES) {
      // If the candidate font is missing, the browser falls back to the fallback font and the width stays the same.
      const hit = widthOf(`"${family}", ${fallback}`) !== base;
      if (hit) installed.set(family, (installed.get(family) ?? 0) + 1);
    }
  }
  console.info('Detected fonts:', [...installed.keys()]);
})();
</script>

2. Scoring Model and Report Structure

/** Dimension configuration: weight is the weight, and tie marks “same-profile consistency” items. */
const DIMENSIONS = [
  { key: 'font', label: 'Font coverage', weight: 15, tie: true },
  { key: 'canvas', label: 'Canvas rendering', weight: 8 },
  { key: 'webgl', label: 'Renderer identity', weight: 8 },
  { key: 'webglCaps', label: 'Graphics capabilities', weight: 5 },
  { key: 'audio', label: 'Audio processing', weight: 8 },
  { key: 'media', label: 'Media and codecs', weight: 6 },
  { key: 'display', label: 'Display', weight: 5 },
  { key: 'timezone', label: 'Time zone', weight: 15, tie: true },
  { key: 'locale', label: 'Language and region', weight: 15, tie: true },
  { key: 'speech', label: 'Speech region', weight: 7, tie: true },
  { key: 'hardware', label: 'Hardware capabilities', weight: 8 },
  // Transport-layer dimensions usually require server-side echo or dedicated detection services and are not suitable for active probing on ordinary pages.
];
/**
 * Self-consistency score: does not aim to match a “standard device,” but measures internal consistency among devices in the same profile.
 * @param {Record<string, {value: unknown, stable: boolean}>} features Feature collection results for each dimension.
 * @param {Map<string, string>} [conflicts] Dimension conflict pairs: keys are sorted and joined with “+”.
 * @returns {{score: number, penalty: number, breakdown: object}} Score from 0 to 100; a lower score means better self-consistency.
 */
function scoreConsistency(features, conflicts = new Map()) {
  const breakdown = {};
  let base = 0, stable = 0, penalty = 0;
  for (const { key, weight, tie } of DIMENSIONS) {
    const f = features[key];
    if (!f) continue;
    // Dimensions bound to a profile count as real consistency signals only when they remain stable over the long term.
    const w = tie ? (f.stable ? weight : 0) : weight;
    base += w;
    if (f.stable) stable += w;
    const conflict = tie && conflicts.get(key);
    if (conflict) penalty += w * conflict.ratio; // Conflict ratio from 0 to 1.
    breakdown[key] = { weight: w, stable: f.stable, conflict: conflict ?? null };
  }
  const score = base
    ? Math.round(100 * (1 - stable / base) + Math.min(penalty, base))
    : null; // No score is given when there are no comparable dimensions, avoiding a “zero-information perfect score.”
  return { score, penalty, breakdown };
}

The report should contain four parts:

• Overview: self-consistency score, number of comparable dimensions, and number of conflict items.
• Dimension details: the value, stability, and whether each dimension matches the declared target profile.
• Transport-layer cross-check: whether the egress IP time zone, WebRTC public candidates, and DNS resolution path all point to the same region.
• Priority suggestions: improvement items sorted by “impact level × remediation cost.”

4. Align With a Real Profile, Not a Fake One

There is a common paradox here: over-disguise is more suspicious than exposure itself. An environment fabricated from scratch is often self-contradictory and falls into an extremely low-frequency combination in the population. Risk-control models do not need to know what a “real device” looks like. Discovering an inconsistent or abnormally frequent combination is enough to mark it as suspicious.

A reasonable approach is to govern around a fixed, self-consistent target profile so that all dimensions come from the same source.

Declared profile (US California)	Dimensions that need to be aligned
System language en-US	Browser language priority, regional formats, relative-time wording, speech recognition language, and Accept-Language priority in HTTP requests
System time zone America/Los_Angeles	Browser time zone offset, IANA time zone identifier, daylight saving time records, and synchronization between the system clock and a standard time source
Western-priority local environment	Installation status of Chinese fonts, Japanese/Korean fonts, and open-source CJK fonts
Egress path in the same region as the IP	Domain resolution egress and real-time communication public candidate addresses
Real endpoint	Graphics renderer, audio processing results, display parameters, hardware capabilities, and protocol handshake fingerprint

Even after unification, periodic review is still necessary. Endpoint system updates may introduce new fonts, remote network switching may change the resolution egress, and GPU driver upgrades may refresh the renderer identifier.

5. Actionable Remediation Directions

Process the issues in the order of “hard conflicts first, soft features later.” This gives the best return on effort.

1. First, handle hard conflicts in the transport layer

   • Real-time communication: In applications where real-time communication is genuinely needed, disable unnecessary media permissions, or use organization-wide real-time communication infrastructure policies to block non-proxy candidates, preventing internal-network and public addresses from being exposed at the same time.
   • Domain resolution: Complete resolution through encrypted DNS transport, or configure split-resolution rules based on network egress, so that the resolution path is consistent with the egress.
   • IPv6: If direct IPv6 can bypass the remote network, disable IPv6 or include it in the proxy path.
   • Clock: Calibrate the system time and reduce the offset from a standard time source.

2. Then handle client-side soft features

   • Fonts and language: On desktop systems, use the system language and region settings rather than changing only the browser language. A browser restart is usually required for the change to take effect.
   • Time zone: Prefer system-level time zone configuration and confirm that the browser reads the system value rather than a forced value from a startup parameter.
   • Rendering and audio: These involve low-level hardware implementation. Rewriting return values through scripts is not recommended. Individual users can enable fingerprint-protection features in the browser to reduce the details that can be read.
   • Local configuration: Unify privacy and security settings, but do not enable rare parameter combinations just to appear “unique.”

3. Finally, govern behavior features

   • Interaction rhythm: Keep operation timing close to human behavior and avoid mechanical calls with fixed polling intervals.
   • Cache and storage: Regularly clear cookies, cache, and local storage.
   • Extensions: Keep extensions minimal or consistent to reduce additional features.

6. Common Troubleshooting Mistakes

• Mistake 1: A fast speed test means a clean IP. Bandwidth, latency, and egress quality are different things. The first one has little to do with risk control.
• Mistake 2: Only looking at IP geolocation. Determining whether an address belongs to a data center or residential network often depends on multiple signals such as reverse DNS records, open ports, and historical access patterns.
• Mistake 3: Assuming one change solves everything forever. Client environments drift with system updates, driver upgrades, and network changes, so periodic review is necessary.
• Mistake 4: Blaming all anomalies on fingerprints. Device fingerprints are only one part of the evaluation. Call frequency, request patterns, and account history also participate. An account being restricted is usually related to violating the relevant platform’s terms of service. This article does not provide evasion methods for any platform.

7. Engineering the Self-Check Workflow

Checking each item manually can easily miss things. It is better to turn the self-check workflow into a repeatable, continuously monitored engineering process:

1. Baseline collection: Periodically collect dimension values on the target-profile endpoint and generate baseline snapshots.
2. Difference comparison: Collect snapshots before and after deployment or updates, compare them item by item, and focus on fonts, time zone, language, renderer, and resolution egress.
3. Continuous monitoring: On cloud platforms, snapshot results can be stored in object storage for retention, and logging services and monitoring alerts can set threshold notifications for changes in key dimensions.
4. Issue reproduction: Introduce or output a versioned trace identifier in the self-check page to make it easier to compare differences in the same dimension across multiple endpoints.
5. Closed-loop fixes: Include remediation items in the configuration management process to prevent drift caused by manual changes that are not maintained afterward.

8. Conclusion

Whether an account can remain stable in the long term depends on whether the entire chain is self-consistent, not merely on whether an IP is “clean.” Details that look irrelevant, such as fonts, time zone, language, rendering, and network egress, are exactly the consistency evidence most valued by risk-control models. Rather than continuously paying for a “clean IP,” it is better to first perform a complete 15-dimension environment check: identify which dimensions contradict each other, which are harmless personalized differences, and then address them one by one according to priority. Understanding these technical principles clearly also helps developers protect their digital privacy more consciously.