Web Bluetooth is present or absent as the claimed desktop platform requires
navigator.bluetooth is present on a build claiming Chrome on Windows or macOS desktop, and ABSENT on one claiming Chrome on Linux: Chromium leaves WebBluetooth at "experimental" on Linux and kWebBluetooth is disabled by default, so genuine Chrome for Linux never defines it (measured against genuine Chrome 154). The row declines on a non-Chromium engine, or where no desktop OS is claimed.
What a detector infers
navigator.bluetooth is part of Chrome's desktop surface on Windows and macOS (and not on Linux, where the feature stays experimental), and it is provided by the platform layer rather than by JavaScript — the object's methods are native bindings onto a real Bluetooth stack.
That makes its absence informative in a specific situation: a browser presenting a desktop persona while actually running in a container or on a stripped-down host often has no Bluetooth stack for the browser to bind to, so the API quietly disappears while the identity keeps claiming a platform that ships it.
The check is one presence test against the OS the user agent claims, and it is one of the surfaces a spoof most often forgets because nothing about a fingerprint profile suggests it. Two honest limits keep it at warn rather than critical, and both are stated in the row itself: enterprise policy can disable Web Bluetooth outright, and a build can be compiled without it as a deliberate choice.
Neither is automation, and neither is visible to a page — so the row reports a contradiction rather than convicting of one.
How to resolve it
On a Windows or macOS claim, run the build where the Bluetooth stack is reachable, or stop claiming a desktop OS whose Chrome ships the API. On a Linux claim the opposite applies: stop force-enabling WebBluetooth.
That switch is the right fix for a Linux host serving a Windows or macOS persona, where the API would otherwise go missing, but it has to be keyed on the platform the page is TOLD it is rather than the host it runs on, or a Linux identity ends up carrying an API real Linux Chrome lacks and answering getAvailability() false. Defining navigator.bluetooth from page script does not close either direction: the object's shape and native-binding behaviour are read too.
Read in the wild by
CloakBrowser issues
A stealth-browser tracker raises Bluetooth availability as a platform-coherence surface that goes missing under containerised Linux while a desktop persona is presented.
CloakHQ/CloakBrowser #162 (navigator.bluetooth vs claimed platform)
CloakHQ/CloakBrowser#162Every attribution traces to a published artifact. See the sources and their limits.
Nearby checks in Capability surfaces
- The platform theme resolves the CSS system colours coherently
system-colors-vs-platformThe CSS system-colour keywords — Highlight, HighlightText, Canvas, CanvasText, ButtonFace, ButtonText, GrayText and their newer siblings… - The user-agent stylesheet resolves identically in a fresh realm
default-style-values-vs-realmEvery browser ships a user-agent stylesheet: the rules that make a heading bold and a button look like a button before any site CSS exists. - The permission descriptors this build accepts are the platform's, not a lookup table's
permission-name-support-setThe Permissions specification deliberately fixes no list of names. - Form-factor-gated APIs match the form factor the client hints claim
platform-gated-apis-vs-form-factorSome Web APIs are not compiled for every platform, so their presence is a fact about the binary rather than about the user agent. - The WebAuthn surface is as complete as the claimed platform's browser ships it
webauthn-surface-vs-platformWebAuthn reaches further down the stack than most web APIs: PublicKeyCredential is not a self-contained JavaScript object but the front door… - The deprecated and modern storage-quota APIs report the same origin quota
legacy-quota-surface-agreementnavigator.webkitTemporaryStorage.queryUsageAndQuota and navigator.storage.estimate() describe the same thing — this origin's storage quota… - The Storage Buckets API reports the same origin quota as navigator.storage
storage-buckets-quota-agreementThere are three ways to ask this origin how much storage it may use, and they all describe one number. navigator.storage.estimate() is the… - The origin private file system works if it is exposed
opfs-surface-vs-platformThe Origin Private File System is the newest of this origin's several storage doors, and a persona reaches it last if at all — the same…
Clearcote is a browser built for fingerprint coherence
It is a Chromium fork, maintained by the same people who wrote this reference. It ships as a compiled browser rather than as a stealth script injected into someone else's — which is a description of how it is built, and is not an argument about how it behaves on this check.
This audit takes no position on how Clearcote scores on Capability surfaces checks, on this one, or anywhere else. It has no baseline corpus of other people's fingerprints to rank you against and no vendor scoreboard — nearly every check is self-referential, asking one browser the same question through two independent APIs and reporting whether both answers can be true at once. It runs identically on any browser, including ours. Run it on yours and read the result yourself.
See the other checks in Capability surfaces — the family bluetooth-availability-vs-platform belongs to.