Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No audio in Brave Browser #10

Open
SephReed opened this issue May 28, 2020 · 5 comments
Open

No audio in Brave Browser #10

SephReed opened this issue May 28, 2020 · 5 comments

Comments

@SephReed
Copy link

Sorry I don't have greater detail. I just wasn't getting any audio, and I suspect it's because I use a non-standard browser.

@pkalogiros
Copy link
Owner

Brave's vision can potentially save the web from itself.
I 'll do my best to fix this during this weekend. Cheers!

@pkalogiros
Copy link
Owner

This is very interesting. It is not happening locally, but it is happening on the audiomass website. I am wondering if during minification some line of code is omitted. Currently this is my top priority. Thanks

@pkalogiros
Copy link
Owner

pkalogiros commented Jun 21, 2020

This appears to be a bug in Brave.

Multiple calls to audiobuffer.getChannelData (chanel_index); seem to slowly reduce the overall strength of the signal. You can call it once, before the signal starts deteriorating. Here's an example...

                var chan = this.buffer.getChannelData(0);
                console.log(0, chan[20000] );
                chan = this.buffer.getChannelData(0);
                console.log(1, chan[20000] );
                chan = this.buffer.getChannelData(0);
                console.log(2, chan[20000] );
                chan = this.buffer.getChannelData(0);
                console.log(3, chan[20000] );
                chan = this.buffer.getChannelData(0);
                console.log(4, chan[20000] );
                chan = this.buffer.getChannelData(0);
                console.log(5, chan[20000] );
                chan = this.buffer.getChannelData(0);
                console.log(6, chan[20000] );
                chan = this.buffer.getChannelData(0);
                console.log(7, chan[20000] );
                chan = this.buffer.getChannelData(0);
                console.log(8, chan[20000] );
                chan = this.buffer.getChannelData(0);
                console.log(9, chan[20000] );
                chan = this.buffer.getChannelData(0);
                console.log(10, chan[20000] );

0 -0.0016706869937479496
1 -0.0016629432793706656
2 -0.0016552354209125042
3 -0.0016475633019581437
4 -0.0016399266896769404
5 -0.0016323255840688944
6 -0.00162475963588804
7 -0.0016172287287190557
8 -0.0016097327461466193
9 -0.0016022715717554092
10 -0.0015948449727147818

You can see the signal slowly reduce, and if it keeps running it will actually become negative, as if everytime calling getChannelData it loses strength.

This only happens in brave and DOES NOT happen in localhost, so I am inclined to believe it's a bug!

@pkalogiros
Copy link
Owner

pkalogiros commented Jun 21, 2020

I think we can trace the issue here - brave/brave-browser#9187

default protection: Farble output volume by [0,-.01] under eTLD+1 session seed
max protection: randomly generate low amplitude white noise under eTLD+1 session seed (with max amplitude / volume being 1% of max representable volume).

It appears to be a mechanism for obfuscating browser fingerprinting. It results in getChannelData and related functions to slowly lose signal strength on each call (but the signal fluctuations are reproducible and move towards the same vector, so I am not sure exactly what it aims to do but this area is not my forte)

here is the value after 10 calls, between reloads
Screen Shot 2020-06-20 at 11 42 49 PM

Should the fluctuations be random and not reproducible between reloads?

Anyway.... Since we cannot access audio buffers, modify them, and write them back without the risk of destructive signal changes on each iteration, this means that unfortunately Brave is a poor choice for anything related to audio production on the web.

This is unfortunate, because I whole heartedly support Brendan's vision, use Brave daily and expect it to blow in popularity any time soon. I would highly urge the Brave developers and security researchers to reexamine these consequences, at least for the getChannelData function.
buffer.getChannelData should return the same values every time it is being called in the same session.
It should not be affected by CPU usage, browser version, phases of the moon or anything else.
Assuming a non-intrusive random seed is added to prevent fingerprinting, it should be added once (to the underlying buffer) and not on every call.

Am I getting this wrong?

@SephReed
Copy link
Author

This seems accurate. Have you put in an issue with the brave browser git?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants