The device-API family is present or absent as a unit
Either all four device APIs present, or the check is N/A because the siblings are not all there (severity: warn).
What a detector infers
Web Bluetooth, WebUSB, WebSerial and WebHID are one family on Chromium desktop - the same secure-context gating, the same desktop platforms, shipped and maintained together. So the question worth asking is not whether Web Bluetooth is present, but whether it is missing while its siblings are present, which no released build of Chrome produces on its own.
Measured across four configurations on one machine: stock Chrome, Playwright bundled Chromium, and Chrome launched with the usual automation arguments all expose all four; SeleniumBase UC mode exposes WebUSB, WebSerial and WebHID but no Web Bluetooth at all - not navigator.bluetooth, not the Bluetooth interface, not BluetoothDevice. The cause is in its own launcher source, which appends Bluetooth, WebBluetooth and UnifiedWebBluetooth to --disable-features on every launch.
The command-line switch is invisible to a page; the hole it leaves in the API surface is not. The check requires all three siblings to be present before it says anything, so browsers that ship none of the family (Firefox, Safari) are N/A rather than failing, and Brave is excluded outright because it disables Web Bluetooth by default as a stock privacy feature.
How to resolve it
Web Bluetooth is not optional within this family on Chromium desktop. Passing Bluetooth/WebBluetooth/UnifiedWebBluetooth to --disable-features removes the namespace and both interface objects while leaving WebUSB, WebSerial and WebHID untouched - a shape no released Chrome produces. To avoid Bluetooth prompts, deny the permission instead of removing the feature from the surface.
Nearby checks in Capability surfaces
- Web Share is present or absent as the claimed platform's Chrome ships it
web-share-vs-osnavigator.share is present or absent depending on the platform the Chrome binary was built for. - C:/ parses the way the claimed OS's Chromium parses it
url-drive-letter-vs-osChromium's URL library contains a Windows-only rule: a string that begins with a drive letter, such as 'C:/x', is treated as a file path and… - The system colour palette belongs to the claimed OS
system-colors-vs-osWindows and Linux Chrome resolve the CSS system colours and their built-in form-control styles differently, and some of the differences are… - hrefTranslate is present under the Google Chrome brand
href-translate-vs-brandHTMLAnchorElement.prototype.hrefTranslate is a runtime-enabled feature that Chrome only switches on when its translation service is… - A build claiming Chrome carries the Privacy Sandbox surface Chrome ships
privacy-sandbox-vs-chrome-claimTopics, Protected Audience, Shared Storage and Fenced Frames all shipped to Chrome stable in 115 and are present by default on desktop. - Firefox resistFingerprinting announces itself when enabled
firefox-resist-fingerprinting-identifiableFirefox's privacy.resistFingerprinting substitutes CONSTANTS rather than randomness, and a constant is itself a fingerprint. - The CSS feature surface is identical in a fresh realm
css-surface-vs-realmWhich CSS properties, values and selectors an engine understands is decided when the browser is compiled. - Device-level media features are identical in a fresh realm
media-surface-vs-realmMedia features are answered by the layout engine rather than by the JavaScript properties that describe the same machine, which is what…
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 device-api-family-coherence belongs to.