Brave browser freezes in Web Audio API test

Consider the following test URL:

https://linxin2020.github.io/hls_live/js_performance.html

Disclaimer: I do not own that page, but it serves as a good test case.

The page in question is making some calls to the Web Audio API and measures the response time. In my tests, it returns in 10-30ms on Firefox and Chrome (both on Windows) whilst Brave (again on Windows, desktop) it returns in about 20-30s.

On my laptop, it spins up fans and will soon hang the browser for the above duration. On my high-end desktop, it also freezes the thread, for pretty much the same amount of time.

So the device seems to not matter that much, Brave is about a 1000-2000x slower compared to other browsers in running this script.

I don’t know anything about the underlying cause for this, but given that it’s so Brave-specific, I can speculate that this may be extra code running in Brave to counter fingerprinting? Because indeed, Web Audio scripts similar to this are used in fingerprinting libraries.

I’m all for combating fingerprinting, but that should not be an excuse to completely freeze the user’s browser. Fingerprinting libs are sometimes used in ecommerce sites to combat fraud, especially when payments are involved. I don’t care to debate whether they should do this, I’m just stating it as an observation. Consequently, this means that when a consumer visits such ecommerce website in Brave, it fully locks up, whilst it doesn’t in other browsers. A consumer isn’t likely to understand why this happens, hence I hope this can be looked at.

@8809c3564743f120339b,
Thanks for reaching out. So for me, this page actually won’t load at all when I try and run it in Brave. My assumption was that one of the Shields protections was preventing it from running, but even with Shields down the page appears to lock/freeze.

Reaching out to our web compatibility team to take a look at this.

I wonder if you waited long enough :slight_smile: Sometimes after a while Brave will show a pop-up “the browser is not responding”, allowing the user to keep waiting or cancel the navigation.

Correct that this isolated test script fails irrespective of shield status. In other contexts, Brave shields up may block this code from running if the script it is part of is known to fingerprint the user.

Yes I did wait long enough for the error prompt to appear. I’ve posted this in the necessary internal channels — hope to have more information for you soon.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.