How Much Can Websites Really Detect About Brave Users?

People install Brave because they want websites to know less about them. That expectation is reasonable. Brave blocks ads and trackers by default, restricts cross-site storage, modifies fingerprintable APIs, and has spent years building defenses that stock Chromium does not provide.

Then a website runs this:

const isBrave = await navigator.brave?.isBrave?.();

Or reads this request header:

Sec-CH-UA: "Brave";v="153", "Not_A Brand";v="8",
  "Chromium";v="153"

Or asks JavaScript for the visitor’s default timezone:

Intl.DateTimeFormat().resolvedOptions().timeZone;

The result might be Europe/Zurich, America/New_York, or Asia/Tokyo.

None of those observations makes Brave a bad privacy browser. They do expose an important distinction that gets lost in browser marketing: privacy protection does not mean making the browser invisible.

As of September 22, 2026, the current stable desktop release is Brave 1.95.104, based on Chromium 153. This article focuses mainly on Brave’s Chromium-based desktop and Android versions. Brave on iOS runs on Apple’s WebKit stack, does not support User-Agent Client Hints, and has different technical constraints.

So, how much can an ordinary website actually learn about a Brave user?

The short answer is: quite a bit about the browser environment, but much less stable identifying information than it would receive from an unprotected Chromium browser.

A first-party website can generally determine that the browser is Brave. It can learn the Chromium major version, operating-system family, exact IANA timezone, language information, viewport dimensions, and broad hardware characteristics. With User-Agent Client Hints, it can request additional details such as platform version, architecture, and bitness.

At the same time, Brave blocks many third-party tracking scripts before they execute, partitions storage, and deliberately modifies signals such as canvas output, Web Audio output, screen characteristics, CPU count, memory estimates, font availability, WebGL extensions, and GPU identification.

That combination is where Brave’s privacy model gets interesting.

Brave is detectable, and that is intentional

There are at least three direct, current mechanisms for detecting Brave on a normal website:

• The Brave brand in User-Agent Client Hints
• The navigator.brave.isBrave() JavaScript API
• Brave-specific generic GPU strings exposed by its WebGL protections

Brave’s own documentation is unusually direct about the first two. Hiding the fact that someone uses Brave is not a general privacy goal.

That decision deserves more attention than either side of the usual debate gives it.

Browser identification is not the same as identifying a person. Knowing that a visitor uses Brave 153 places them in a group. It does not reveal their name, account, browsing history, or a persistent browser identifier.

Still, reducing a visitor from “some Chromium user” to “a Brave user” narrows the anonymity set. It also gives websites an easy condition they can incorporate into analytics, fraud scoring, content decisions, or browser-specific blocking.

Brave accepts that trade-off, while maintaining compatibility exceptions for sites that break or discriminate against Brave users.

Why the traditional User-Agent string often looks like Chrome

On desktop and Android, Brave uses a Chrome-compatible User-Agent request header. A current macOS string looks roughly like this:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/153.0.0.0 Safari/537.36

There is no Brave token.

This is deliberate. User-Agent strings have accumulated decades of compatibility baggage. Websites frequently parse them using brittle regular expressions and assumptions about token order. Adding a new browser token can result in unsupported-browser pages, incorrect downloads, or entire applications refusing to load.

The string is also reduced. It exposes the Chromium major version but replaces the minor and patch components with zeros. On macOS, the operating-system token is frozen at 10_15_7, even on much newer systems.

At first glance, Brave therefore looks like Chrome to traditional server-side User-Agent parsers.

That does not mean the browser is trying to remain indistinguishable from Chrome everywhere.

Sec-CH-UA says Brave explicitly

Chromium’s replacement for much of the old User-Agent machinery is User-Agent Client Hints, commonly shortened to UA-CH.

On an ordinary secure request, Brave can send low-entropy hints such as:

Sec-CH-UA: "Brave";v="153", "Not_A Brand";v="8",
  "Chromium";v="153"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "macOS"

The first value is the important one:

"Brave";v="153"

It tells the server that Brave is one of the browser’s brands. The version is the Chromium-aligned major version, not the Brave application version 1.95.104.

"Chromium";v="153" describes the shared browser engine lineage.

"Not_A Brand";v="8" is an intentionally fake GREASE brand. It exists to discourage developers from assuming that the first item is always the real browser or that every brand will be recognized. The spelling, version, and ordering can change.

Do not parse Sec-CH-UA with a fixed substring position. Treat it as a structured list of brands:

function hasBrand(name) {
  return (
    navigator.userAgentData?.brands?.some(
      ({ brand }) => brand === name,
    ) ?? false
  );
}

console.log(hasBrand("Brave"));

Unlike many higher-entropy Client Hints, Sec-CH-UA is normally sent without a server first opting in through Accept-CH. JavaScript can obtain the equivalent low-entropy list from navigator.userAgentData.brands.

This produces an interesting split:

• The legacy User-Agent string prioritizes Chrome compatibility.
• The newer Client Hints interface identifies Brave directly.

That is not an accidental failure to hide. It is Brave’s documented design.

JavaScript can ask Brave directly

Brave also exposes a browser-specific API:

async function detectBrave() {
  const brandMatch =
    navigator.userAgentData?.brands?.some(
      ({ brand }) => brand === "Brave",
    ) ?? false;

  let apiMatch = false;

  try {
    apiMatch = Boolean(await navigator.brave?.isBrave?.());
  } catch {
    apiMatch = false;
  }

  return { brandMatch, apiMatch };
}

console.log(await detectBrave());

navigator.brave.isBrave() returns a promise resolving to true in Brave. This is not a standard Web API. It is an intentional Brave extension implemented in the browser’s Blink integration.

A website might use it to:

• Offer installation instructions for another Brave component
• Avoid presenting a “download Brave” banner to existing users
• Diagnose browser-specific compatibility problems
• Measure Brave usage more accurately
• Apply a workaround for a known Brave interaction

It can also be used less constructively, such as placing Brave users into a separate risk bucket or denying them access.

Brave maintains compatibility exceptions where this API and its Client Hints identity may be hidden because a site breaks or discriminates against Brave. Users can also apply a custom content-filter rule to suppress navigator.brave for a particular domain.

The ordinary behavior remains clear: a website is allowed to know that the visitor uses Brave.

Brave’s GPU protection is another detectable marker

There is now a third, less obvious signal.

Older Brave releases allowed WebGL’s debugging extension to expose detailed GPU strings such as an Apple M-series model, an NVIDIA GPU, an AMD adapter, or an ANGLE renderer and driver combination.

Brave addressed this in versions 1.92 and 1.93. With fingerprinting protection enabled, current Brave desktop and Android builds replace the WebGL unmasked vendor and renderer with a generic value:

function getWebGlIdentity() {
  const canvas = document.createElement("canvas");
  const gl = canvas.getContext("webgl");

  if (!gl) {
    return null;
  }

  const debug = gl.getExtension("WEBGL_debug_renderer_info");

  if (!debug) {
    return null;
  }

  return {
    vendor: gl.getParameter(debug.UNMASKED_VENDOR_WEBGL),
    renderer: gl.getParameter(debug.UNMASKED_RENDERER_WEBGL),
  };
}

console.log(getWebGlIdentity());

Under current default protection, those unmasked fields can return Brave instead of the real GPU vendor and model.

From a fingerprinting perspective, this is a very good trade. Replacing thousands of possible hardware and driver combinations with one common value removes a large amount of entropy.

From a browser-identification perspective, it is another Brave marker.

That distinction matters. A value can make the browser family easier to identify while making the individual device much harder to identify. Calling both effects a “privacy leak” would be technically sloppy.

Brave reveals the default IANA timezone

The timezone case is more difficult to dismiss as mere browser branding.

A normal website can run:

const options =
  Intl.DateTimeFormat().resolvedOptions();

console.log({
  locale: options.locale,
  timeZone: options.timeZone,
  calendar: options.calendar,
  numberingSystem: options.numberingSystem,
});

On current Brave, timeZone can contain the runtime’s default IANA timezone identifier:

Europe/Zurich
Europe/Vienna
America/New_York
Asia/Tokyo
America/Buenos_Aires

This is not just a UTC offset.

As of the current Brave release, the browser does not generally replace this value with UTC, randomize it per site, or reduce it to a generic numeric offset. Brave’s public fingerprinting test matrix does not list timezone as a protected surface, and an open Brave issue continues to track the fact that the real zone is observable.

A September 2026 diagnostic report in Brave’s issue tracker also recorded the browser returning America/Buenos_Aires alongside the current Brave 153 Client Hints data.

An IANA timezone contains more information than an offset

Consider these two values:

UTC+1

Europe/Zurich

UTC+1 describes an offset at a moment in time. Many countries and regions can share that offset.

Europe/Zurich identifies a named set of civil-time rules. It carries information about daylight-saving transitions, historical changes, and the region whose timezone database entry is being used.

The same distinction applies to:

UTC-5

and:

America/New_York

New York is not always UTC-5. During daylight-saving time it uses UTC-4. Other regions may currently share one of those offsets while following different transition rules.

This is why websites and calendar applications prefer an IANA identifier. It allows them to schedule a recurring event at 9:00 AM local time across future daylight-saving changes. A numeric offset alone cannot reliably do that.

That legitimate use is also what makes the value more informative for fingerprinting.

A timezone is a regional clue, not proof of location

Europe/Zurich does not prove that someone is physically in Zurich. The user could be:

• Elsewhere in Switzerland
• Traveling with an unchanged system timezone
• Using a remote desktop
• Running a virtual machine
• Manually overriding the system timezone
• Using a VPN whose endpoint does not match the device timezone

A website also cannot derive a street address or GPS position from Intl.DateTimeFormat.

Precise geolocation remains separately permission-gated.

Timezone should instead be understood as a regional signal. Its significance depends heavily on the zone.

America/New_York covers a large population across multiple states and areas. It is a relatively broad clue.

Europe/Vienna, Europe/Zurich, and Asia/Tokyo are more strongly associated with particular countries or small groups of jurisdictions. For users in smaller countries or distinctive timezone regions, the identifier can narrow the likely area more substantially.

The value becomes more useful when combined with other signals:

• IP-derived country or region
• Browser language
• Locale and formatting preferences
• Operating-system family and version
• Keyboard and font availability
• Screen and device characteristics
• Browser brand and major version

A timezone and IP address that agree can increase confidence in a geographic inference. A mismatch can suggest travel, a VPN, remote access, or a misconfigured clock. It should not automatically be treated as evidence of fraud.

Why Brave may be reluctant to mask it

It is tempting to say Brave should return UTC or a representative city for each current offset. Technically, neither solution is free.

Returning UTC would change how existing applications display dates unless every application explicitly asked for another zone.

Replacing Europe/Zurich with another zone that currently has the same offset can create incorrect results when daylight-saving rules diverge. It can also change historical date calculations.

Permission-gating the value would be cleaner in privacy terms, but it would introduce prompts and break the long-standing assumption that local date formatting works without permission.

Brave could theoretically apply different policies in first-party and third-party contexts, reduce the value only when used for passive inspection, or introduce an explicit site permission. Each option has compatibility and implementation consequences.

The criticism is still fair: exact timezone identifiers are stable, geographically meaningful fingerprint inputs, and current Brave leaves them available. The reason is not that timezone masking is obviously impossible. The reason is that a correct replacement has to preserve calendaring behavior, daylight-saving rules, and existing application expectations.

What else can a website observe?

The following table summarizes important surfaces on current Chromium-based Brave releases with default fingerprinting protection enabled.

Signal	How a site obtains it	Current Brave treatment	Privacy significance
Brave identity	Sec-CH-UA, navigator.userAgentData.brands, navigator.brave.isBrave()	Intentionally exposed, with site-specific compatibility exceptions	Identifies the browser family, not the user
Chromium major version	User-Agent and Client Hints	Exposed	Useful for compatibility and fingerprint classification
OS family	Sec-CH-UA-Platform, navigator.userAgentData.platform	Exposed	Broad platform signal
OS version	High-entropy Client Hints	Available when requested on supported builds	Can narrow the device population
CPU architecture and bitness	High-entropy Client Hints	Available when requested	Can distinguish ARM, x86, 32-bit, and 64-bit environments
IANA timezone	Intl.DateTimeFormat().resolvedOptions().timeZone	Exposed unchanged	Stable regional and fingerprinting signal
IP address	Normal network connection	Not hidden by ordinary Brave browsing	Strong network and approximate-location signal
WebGL GPU vendor and renderer	WEBGL_debug_renderer_info	Replaced with generic Brave values by default	Exact hardware hidden, browser becomes more obvious
WebGPU adapter descriptors	GPUAdapter.info	Vendor, architecture, device, and description scrubbed	Removes direct GPU identification
WebGL extension list	getSupportedExtensions()	Randomized per site and session	Reduces stable GPU and driver fingerprints
Canvas and Web Audio output	Canvas and audio readback APIs	Farbled	Poisons hashes that expect stable output
Screen characteristics	screen, CSS media queries	Several screen-size surfaces are modified	Reduces stable display fingerprints
Viewport dimensions	innerWidth, innerHeight, layout APIs	Generally available for page layout	Dynamic but still useful as a supporting signal
CPU count	navigator.hardwareConcurrency	Farbled	Preserves performance hints while reducing stability
Memory class	navigator.deviceMemory	Farbled or reduced	Broad hardware-capability signal
Fonts	Font probing and text measurement	Availability is restricted or randomized	Reduces installed-font fingerprinting
Language preferences	Headers and navigator properties	Partially reduced or modified	Still useful for localization and regional inference
Browser capabilities	Feature detection	Available	Reveals engine generation and enabled features

The exact result can change if the user lowers Shields, disables fingerprinting protection for a site, installs extensions, changes browser flags, or uses a platform where Brave has fewer implementation controls.

High-entropy Client Hints deserve more scrutiny

Low-entropy Client Hints include the browser brands, mobile status, and platform. More detailed fields are available through the high-entropy interface:

async function getDetailedUaData() {
  const uaData = navigator.userAgentData;

  if (!uaData?.getHighEntropyValues) {
    return null;
  }

  return uaData.getHighEntropyValues([
    "architecture",
    "bitness",
    "fullVersionList",
    "model",
    "platformVersion",
  ]);
}

console.log(await getDetailedUaData());

A supported Brave build may return an object containing data such as:

{
  architecture: "arm",
  bitness: "64",
  mobile: false,
  platform: "macOS",
  platformVersion: "27.0.0",
  brands: [
    { brand: "Brave", version: "153" },
    { brand: "Not_A Brand", version: "8" },
    { brand: "Chromium", version: "153" }
  ]
}

Returned values vary by platform, browser policy, and Chromium version. “High entropy” is not a promise that every field will contain maximum detail. The browser remains free to reduce or omit data.

Servers can request corresponding HTTP headers through Accept-CH, including:

Accept-CH: Sec-CH-UA-Arch, Sec-CH-UA-Bitness,
  Sec-CH-UA-Platform-Version

The browser can then send those hints on subsequent requests.

Client Hints are an improvement over broadcasting every detail in every User-Agent string. They make granular information structured and, for higher-entropy fields, request-driven.

They do not make the information harmless.

For developers, the right rule is simple: request only the fields the application actually needs. Architecture may be justified on a native-software download page. It is hard to justify on a blog, documentation site, or ordinary account dashboard.

Display and window information cannot simply disappear

Websites need the viewport size to perform layout. CSS media queries, responsive images, canvas sizing, and virtualized interfaces all depend on display-related information.

A page can observe values such as:

const display = {
  screenWidth: screen.width,
  screenHeight: screen.height,
  availableWidth: screen.availWidth,
  availableHeight: screen.availHeight,
  colorDepth: screen.colorDepth,
  pixelRatio: devicePixelRatio,
  viewportWidth: innerWidth,
  viewportHeight: innerHeight,
};

console.log(display);

Brave modifies several screen-size surfaces to make them less reliable for fingerprinting. The viewport still has to correspond closely enough to the actual page area for layout to work.

This is a recurring pattern in browser privacy engineering. A value does not need to be perfectly accurate to support benign use, but changing it too aggressively can produce visible breakage.

The useful privacy question is therefore not, “Can a website read a number?” It is, “Does the website receive a stable, sufficiently precise value that helps link this browser across contexts?”

Memory and processor APIs reveal broad hardware classes

Two common examples are:

console.log(navigator.hardwareConcurrency);
console.log(navigator.deviceMemory);

hardwareConcurrency exists so applications can choose a sensible number of workers. deviceMemory helps a site avoid delivering an unnecessarily expensive experience to a low-memory device.

Both can also classify hardware.

A high-end ARM Mac, an older dual-core laptop, and an inexpensive Android phone may produce different combinations. Brave farbles these values so they remain useful as rough performance hints without consistently exposing the true machine configuration.

This is a stronger defense than simply reducing every device to the same hard-coded value. A universal value is easy for scripts to detect, can break workload tuning, and may itself identify the browser’s privacy mode.

GPU information has improved substantially

GPU information used to be one of Brave’s clearest remaining fingerprinting weaknesses.

The 2026 WebGL and WebGPU changes materially improved that situation:

• WebGL unmasked vendor and renderer strings are replaced with generic values.
• WebGPU adapter descriptors are emptied.
• WebGL supported-extension lists are randomized.
• Existing canvas and WebGL rendering farbling remains active.

For current WebGPU code, GPUAdapter.info is the relevant interface:

async function inspectWebGpu() {
  if (!navigator.gpu) {
    return null;
  }

  const adapter = await navigator.gpu.requestAdapter();

  if (!adapter) {
    return null;
  }

  return {
    info: adapter.info,
    features: [...adapter.features],
    limits: adapter.limits,
  };
}

console.log(await inspectWebGpu());

Older examples using requestAdapterInfo() are outdated for the current API.

In Brave, direct fields such as vendor, architecture, device, and description are scrubbed. WebGPU features and limits still have to describe what the implementation can support. Those capability sets may reveal a broad GPU class even when the model name is gone.

Brave has discussed further protection for WebGPU’s supported capabilities. Proposed or planned work should not be confused with shipped behavior. The currently shipped improvement is the removal of direct adapter identification.

Fingerprinting is not one thing

A lot of privacy writing collapses several distinct concepts into “tracking.” That makes technical discussions harder than they need to be.

Browser identification

Browser identification answers:

Is this Brave, Chrome, Safari, or Firefox?

Sec-CH-UA and navigator.brave.isBrave() do this directly.

It classifies software. By itself, it does not distinguish one Brave user from another.

Device fingerprinting

Device fingerprinting combines browser and environment characteristics into a representation of the client.

Possible inputs include:

timezone
+
browser brand and version
+
OS and platform version
+
architecture
+
language and locale
+
screen and viewport characteristics
+
GPU capabilities
+
CPU and memory hints
+
font behavior
+
browser-specific APIs

Some values may be shared by millions of devices. The combination can be more distinctive than any individual input.

A fingerprint does not have to be globally unique to be useful. It can help a site recognize a returning visitor with some probability or divide traffic into smaller groups.

Geographic inference

Geographic inference estimates where the user may be.

An IP address is usually much more informative than a timezone. Language and locale can add supporting evidence. An IANA timezone can narrow the possibilities, particularly in geographically distinctive regions.

None of those signals necessarily proves the user’s physical location.

Tracking

Tracking is the act of linking activity across time, pages, accounts, or websites.

A fingerprint is one possible tracking mechanism. Cookies, URL identifiers, login accounts, redirect parameters, and server-side identifiers are others.

Brave’s tracker blocking and storage partitioning attack tracking at several layers. Even if a first-party page can read the timezone, a blocked third-party script cannot collect anything because it never executes.

Personal identification

Personal identification connects browser activity to a real person.

A website can do that trivially after the user logs in, provides an email address, completes a purchase, or submits identifying information. A timezone is not personal identification.

This distinction is why “Brave exposes my timezone” and “Brave tells websites who I am” are not equivalent claims.

What Brave’s privacy model is actually trying to do

Brave does not attempt to make every API return nothing.

Its architecture combines several defenses:

• Block known ads and trackers at the network layer
• Block or partition third-party storage
• Remove known tracking parameters from URLs
• Limit referrer information
• Partition network state
• Modify or remove especially identifying API results
• Randomize fingerprint inputs using farbling
• Preserve enough API behavior for normal sites to work

Farbling is particularly important.

Instead of forcing every Brave installation to return the same value, Brave derives modifications from a seed associated with the site, session, and storage area. A value remains consistent enough for a page to function during that context, but can differ for another site or a later session.

That design attacks fingerprint stability.

Suppose a fingerprinting library hashes 20 attributes together. If even one important input changes when the user restarts the browser or visits from another site context, the final hash changes too. Brave does not have to make every attribute invisible to disrupt that fingerprint.

This is also why finding an unmodified property does not automatically prove the entire protection has failed. The relevant question is whether the complete collection remains stable and linkable.

Older Brave documentation refers to a separate Strict fingerprinting mode. Brave retired that mode beginning with version 1.64. Current articles should not tell users to enable a legacy Strict setting that no longer exists.

The unresolved tension: privacy versus compatibility

Brave’s most defensible disclosures are those needed for interoperability.

A site may reasonably need to know:

• Whether a browser supports a feature
• Whether it is running on a mobile form factor
• Which installer architecture to offer
• Which timezone rules to use for a calendar
• How large the viewport is
• Roughly how much parallel work the device can handle

The harder question is whether each use case needs the most precise available value.

Does a documentation site need the exact operating-system version? Probably not.

Does an event calendar need a real IANA timezone? Often, yes.

Does a 3D application need GPU features and limits? Yes.

Does it need a human-readable GPU model and driver string? Usually not.

Does a website need to know the browser is Brave? Sometimes useful, but feature detection is generally more robust.

Brave’s 2026 GPU changes are a good example of the model working as intended. WebGL and WebGPU remain usable, but highly identifying strings are removed. The site gets capabilities without receiving the exact device name.

Timezone remains a harder case because the precise identifier is itself the capability calendar software wants.

Browser identity is mostly a policy decision. Brave wants to be measurable, supportable, and compatible as its own browser. It also wants the ability to suppress that identity when sites misuse it.

Those goals are reasonable. They are not the same as maximizing indistinguishability.

What developers should do with this information

The fact that Brave can be detected does not mean application code should branch on it.

Prefer feature detection:

if ("gpu" in navigator) {
  // Offer a WebGPU path.
}

if ("showOpenFilePicker" in window) {
  // Offer the File System Access integration.
}

Avoid logic like this:

if (isBrave) {
  disableFeature();
}

A Brave user may have Shields lowered. A Chrome user may have restrictive extensions. Enterprise policies can alter both browsers. Browser identity is a weak proxy for actual capability.

If you collect timezone information, collect it because the product needs timezone semantics:

const timeZone =
  Intl.DateTimeFormat().resolvedOptions().timeZone;

Good uses include:

• Scheduling events
• Displaying account activity in local civil time
• Calculating recurring reminders
• Selecting an initial timezone in a user-editable form

Poor uses include silently adding the timezone to an unnecessary device fingerprint.

For systems that genuinely need a durable timezone, an explicit account setting is often better than repeatedly inferring it from the device. Users travel, use remote machines, and change system settings.

Treat high-entropy Client Hints the same way. Request architecture on a download page if you need to choose between ARM64 and x86-64 binaries. Do not request it across every route merely because the API exists.

Fraud and abuse systems also need to account for privacy browsers. Farbled CPU counts, generalized GPU details, blocked storage, or a mismatch between IP and timezone are not proof of automation or malicious behavior. Privacy protection can look like environmental inconsistency to systems trained exclusively on stock browsers.

Finally, remember the first-party boundary. Brave is strongest against the web’s background machinery: third-party trackers, cross-site storage, fingerprinting scripts, tracking parameters, and stable hardware identifiers. It does not prevent a site the user intentionally visits from seeing everything necessary to serve that page.

Privacy is not binary

Brave is a strong privacy-focused browser precisely because it does more than change a preference or install an ad-blocking extension. Its protections operate in the network stack, storage model, rendering APIs, JavaScript environment, and Chromium integration.

The browser still reveals meaningful information.

A website can identify Brave through Client Hints and JavaScript. The new generic WebGL strings may identify Brave while hiding the underlying GPU. High-entropy Client Hints can provide platform details. The exact IANA timezone remains available and can contribute to regional inference and fingerprinting.

Those facts do not cancel out Brave’s protections.

They show what modern browser privacy actually looks like: reducing stable, unnecessary identifying information while keeping enough of the web platform intact for applications to work.

Brave’s decision to expose its own identity is debatable, but transparent and intentional. Its timezone behavior is a more surprising limitation and a reasonable target for further privacy work. Its recent GPU changes show that the project is willing to revisit exposed surfaces when a useful, compatible mitigation becomes practical.

For developers, the useful lesson is not that Brave is undetectable. It is that Brave changes the economics and reliability of tracking.

A website can learn that a visitor uses Brave. It can learn their timezone, platform class, viewport, and a collection of capabilities. What it has a much harder time obtaining is a precise, stable hardware profile that works unchanged across sites and sessions.

That is not perfect invisibility. It is still a meaningful privacy improvement.

Sources

• Brave: Release Notes
• Brave GitHub Wiki: Detecting Brave (for Websites)
• Brave GitHub Wiki: User Agents
• Brave GitHub Wiki: Fingerprinting Protections
• Brave QA: Fingerprinting Farbling Tests
• Brave Privacy Updates: Brave improves protections against GPU fingerprinting
• Brave Privacy Updates: Brave browser simplifies its fingerprinting protections
• Brave GitHub Issue #35646: Brave still exposes too much fingerprintable information
• Brave GitHub Issue #58773: CF checks failed
• Brave source code: navigator.brave.isBrave()
• WICG: User-Agent Client Hints specification
• MDN: Sec-CH-UA header
• MDN: Intl.DateTimeFormat.prototype.resolvedOptions()
• MDN: WEBGL_debug_renderer_info
• MDN: GPUAdapterInfo
• Brave: Privacy Protection and Security Features
• Author's Website