Hi,

This issue also occurs on Windows 10 as of current version.
chrome://flags/#enable-experimental-web-platform-features does not seem to have any effect on the results.

Same error returned on different site using Web Bluetooth:
NotFoundError: Web Bluetooth API globally disabled.
undefined
-1

Brave version:
Version 1.18.75 Chromium: 87.0.4280.101

Works well on both Google Chrome and Microsoft Edge (new Chromium based version)

Same result on Android 10 (Brave 1.18.75)

same result windows 10
Brave Version 1.22.70 Chromium: 89.0.4389.105 (Official Build) (64-bit)

Also on macOS Big Sur

Brave | 1.24.84 Chromium: 90.0.4430.93 (Offizieller Build) (x86_64)
macOS Version 11.2.3 (Build 20D91)
JavaScript | V8 9.0.257.23

This is something we intentionally disabled (see brave/brave-core#114) for privacy reasons

@jumde @pes10k should we close this issue? or we could put behind a flag for folks wanting to use it

This is something we intentionally disabled (see brave/brave-core#114) for privacy reasons

Is there any way it can be enabled by the user?

Enabling brave://flags/#enable-experimental-web-platform-features or adding --enable-features=NewBLEWinImplementation to the command-line do not.

Thank you to folks involved in this thread. As you all have noticed, Brave has to date generally disabled non-standard Chrome features that come with significant privacy risks. Broadly, we've completely disabled these features (instead of making them controllable by flags, or otherwise limiting them) for a few reasons:

1. Easier (though not easy) to implement the "always disable" option. This is more important than it might first appear. There are lots of these, and time spent fighting with non-standard chrome additions is time not spent working on other privacy protections
2. More confidence that they wont be enabled out from underneath us. There are many ways of controlling if and when "uncommon" features Web Bluetooth are enabled (feature flags, origin trials, field trials, finch, etc), some of which can result in features getting enabled w/o code changes, or unintentionally during chromium rebases. The "always disable" option makes it less likely that features will get enabled w/o our intention
3. A general desire to not provide privacy footguns to users (i.e., even if there is a permission prompt, we don't want to ask or burden users with privacy-effecting questions, unless we think the feature being asked about is likely to be useful to a large number of users, in a large number of cases)

However, we recognize that there are some users (mostly advanced users) who would like to both use Brave, and use the privacy risky non-standard Chrome functions. Our plan (subject to change) here is to:

1. For new features in this category (non standard, privacy risking, powerful, etc), still ship default off, but maintain the ability for advanced users to enable through brave://flags where possible. i.e. prefer default off flags to global disabling where possible
2. For existing features in this category (Web Bluetooth, Native File API, many others) that are currently default off, go back and move them to default-off-flag-controlled when other Brave priorities allow. I don't have a specific timeline though, so I can't say much more that "we plan to get to it, but its still in the TODO queue and hasn't been assigned to anyone yet"

Anyway, TL;DR; we appreciate that this advanced functionality is useful, even if its privacy risky. We're moving from a "global disable" strategy to a "default-off-but-flags" strategy. We will apply this to new features like this in chromium going forward. We will revisit current features in this category in the medium term.

I appreciate thats likely not the answer everyone in this tread wanted, but I wanted to explain the "why" behind the current state of things, and our rough plan going forward.

In the meantime, i'm going to close this, since the broader issue of how to handle these features is already captured elsewhere, including #15637

Thank you all for the input and feedback!

I've labeled it wontfix but I dont mean we dont intend a better solution here, only that that solution won't be specific to Web Bluetooth on linux

Is there any way to enable it on MacOS Big Sur? I want to use the Bluetooth API

@atharvadeosthale not at the moment... you may subscribe to #15637 for more updates