The End of Fingerprinting As We Know It: How Browser Privacy Protections Are Reshaping Bot Detection

For years, the internet played fast and loose with your privacy. Browser vendors prioritized flashy features and cross-platform compatibility over protecting user data. Many browsers allowed audio, video, and other web APIs to access direct hardware properties and, therefore, create fingerprinting surfaces that many bot management vendors (including DataDome) have used to detect browser inconsistencies.

But the web has suffered many attacks over the last years, encouraging vendors to issue new kinds of protections to the user, alongside dedicated mods that allow users to enable/disable protections, features, and modify fingerprints. 

Apple, Mozilla, and Brave are now racing to lock down the very APIs that made fingerprinting possible. The result? The cat-and-mouse game between privacy advocates and security vendors just entered a whole new phase.

Safari

Safari “Advanced Fingerprinting Protection”

Starting with iOS 26, Safari will enable Advanced Fingerprinting Protection by default for all browsing sessions.

Apple elevates the iPhone experience with iOS 26

What does Advanced Fingerprinting Protection alter?

• Storage APIs (LocalStorage, IndexedDB, Cache API, SessionStorage, and Blob URLs): To prevent cross-site tracking, these APIs are now partitioned. This means data stored by one website cannot be accessed by another.
• Canvas, WebGL, and WebAudio APIs: To combat fingerprinting, Safari injects noise into the data returned by these APIs. For instance, properties like AudioContext.sampleRate would all fall back to generic values like 48,000 instead of showing the real value.
• Screen properties: When tested, we’ve noticed differences in values for two similar tests, with one being Safari Tahoe (MacOS 26), and the second being the previous version. Properties like document.clientHeight and window.innerHeight were altered while browsers had the same effective height.
  • While testing, we detected the following properties to be randomized:
  • window.inner{Width|Height}
  • screen.avail{Width|Height}
  • window.outer{Width|Height}

Safari “Lockdown Mode”

Lockdown Mode is an optional, extreme protection that’s designed for the very few individuals who, because of who they are or what they do, might be personally targeted by some of the most sophisticated digital threats. Most people are never targeted by attacks of this nature.

When Lockdown Mode is enabled, your device won’t function like it typically does. To reduce the attack surface that potentially could be exploited by highly targeted mercenary spyware, certain apps, websites, and features are strictly limited for security and some experiences might not be available at all.

https://support.apple.com/en-us/105120

From our early research, this mode deactivates certain Web APIs in Safari:

• Audio
• WASM
• GamePad
• WebRTC

Firefox

When Resist Fingerprinting settings are enabled in Firefox Advanced Preferences (the Configuration Editor about:config page), it can help prevent websites from uniquely identifying you by limiting the information they can gather about your device.

https://support.mozilla.org/en-US/kb/resist-fingerprinting

What does Resist Fingerprinting alter?

• • AudioContext.sampleRate: fixed to 44100
  • HardwareConcurrency: fixed
  • DateTimezone: fixed to UTC (value is 0 )
  • InstalledFonts: seems to add/remove fonts
  • Screen properties modified
    • window.inner{Width|Height}
    • screen.avail{Width|Height}
    • window.outer{Width|Height}
    • screen.orientation
    • screen.colorDepth 
  • Web APIs removed: during my tests, I’ve found values to be different between instances with and without resistFingerprinting set. I’ve checked manually for what these Web APIs could be, and I’ve found:
    • Web APIs that are deleted by resistFingerprinting
      • ImageDecoder
      • VideoDecoder
      • AudioEncoder
      • VideoColorSpace
      • VideoEncoder
      • AudioDecoder
      • AudioData
      • EncodedVideoChunk
      • VideoFrame
      • EncodedAudioChunk
      • ImageTrackList
      • ImageTrack
  • Speech voices: all seem removed

• WebGL

• • ext.UNMASKED_RENDERER_WEBGL: fixed to Mozilla
• Worth noting: Other Web APIs affected
  • CSS Media Queries
    • screen query: seems inconsistent with screen real size
    • @media
      • device-aspect-ratio: fixed to unsupported
      • device-screen: fixed to unsupported

Brave

Brave applies randomization-based defense to its browsers by slightly adjusting canvas and audio values to create a unique fingerprint every time.

Their protection has three levels:

• Off: no fingerprinting protection
• Standard: which adds small amounts of randomness to various Web APIs with maximum compatibility
• Maximum: which adds several layers of protection but may break support on some websites

What does Brave Defense alter?

• Canvas, WebGL, and WebAudio APIs: a full list can be found here https://brave.com/privacy-updates/4-fingerprinting-defenses-2.0/#farbling

Not everyone is fighting for privacy

We’ve seen how some vendors have made fingerprinting-defense a selling point of their strategy, but not all are heading in that direction.

Google Chrome, with ~70% of browser market share—once against fingerprinting in Google Ads as can be seen in this archive from May 2021—has taken the opposite road in 2025 by removing all mention of fingerprinting in the current page, with their February 2025 Platforms policy update not mentioning fingerprinting at all.

Google, being Chromium’s main contributor, is also in a position to shape the technical capabilities available to all Chromium-based browsers, which includes Microsoft Edge, Opera, Brave, and numerous others. This influence extends beyond policy statements to the actual APIs and features that make fingerprinting either easier or harder to implement.

While some Chromium-based browsers like Brave have added their own anti-fingerprinting protections on top of the base Chromium code, the underlying architecture and default behaviors are still largely determined by Google’s development priorities.

What’s the impact of these privacy measures on bot detection?

The anti-fingerprinting measures deployed by major browser vendors confirm a significant industry trend: traditional client-side fingerprinting, used to establish distinctive user identity and fight against malicious actors, is becoming increasingly unreliable and low-entropy.

The consequence is the degradation of data quality derived from these specific browser surfaces. This leads to:

• Data from previously distinctive identifiers now appears generic or randomized across different users, making it harder to differentiate a sophisticated bot using a privacy-enhanced browser from a legitimate human user.
• Attempting to track automated malicious entities across multiple sessions using these altered fingerprinting surfaces is now harder.

How DataDome remains effective

While these measures introduce a new difficulty, it’s important to note that the affected data does not degrade DataDome’s bot detection:

1. Data derived from these manipulated APIs is reclassified from a high-confidence identifier to a low-entropy signal. Its utility shifts from providing distinctive identity certainty to identifying patterns of deviation or anomaly within a normalized baseline.
2. Our continued focus on behavioral analytics (mouse movements, clicks) and server-side telemetry (IP reputation, header analysis) provides resilient detection vectors that are functionally immune to client-side API restrictions.
3. Beyond the more obvious device and browser characteristics that are being actively hardened against fingerprinting, such as screen resolution, GPU details, and font lists, a significant number of other Web APIs remain valuable signals for device identification. We continuously investigate new and old Web APIs to find new fingerprinting surfaces that could reveal malicious bots and coordinated attacks.

The bot detection vendors that will thrive in this new landscape are the ones that never put all their eggs in the fingerprinting basket in the first place. As browser privacy protections become more aggressive, our research team continues to explore emerging Web APIs, refine behavioral models, and identify new patterns that separate automated attacks from legitimate users—all while respecting the privacy boundaries browsers are establishing.