pkalogiros / AudioMass

Free full-featured web-based audio & waveform editing tool
1.95k stars 226 forks source link

No audio in Brave Browser #10

Open SephReed opened 4 years ago

SephReed commented 4 years ago

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 commented 4 years ago

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

pkalogiros commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

I think we can trace the issue here - https://github.com/brave/brave-browser/issues/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 commented 4 years ago

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