The problem is that farbling takes time. getChannelData is supposed to be fast but we need to iterate through all the data points. There might be many samples that needs to be processed per second in multiple channels.

The research/design issue is if we should change behaviour on such pages. If we do not do any change, users will likely do. Maybe it will change the wrapping and turn AudioBuffering off, maybe they will uninstall the extension. What is the acceptable solution?

I am also thinking on introducing fast but unreliable little lies. We currently do modify all samples. But we can make things faster if we modify only a fraction of samples. Then, the fingerprinter could correlate to the correct value over multiple visits. If the fingerprinter does not invest time into this behaviour, the fingerprint differs. (Currently, ) I think that such behaviour should not be default.

I tried to visit ebay.com with 0.7.1, Recommended level and observed:

1. The page loaded but did not respond to any clicks.
2. The extension popup did not load the page-level data (so that only the global settings header was visible).
3. I went to global options, JS Shield configuration, entered ebay.com and disabled the audio buffer group.
4. I needed to close the ebay.com tab.
5. I opened a new tab with ebay.com.
6. The page was operational, popup worked as expected.

So in this case, the audio wrappers are definitely the problem. But we need to face several issues:

1. Should we make popup responsible on such pages?
2. Should we modify wrappers behaviour if we detect that something the wrapping consumes to much CPU?
3. For any modification, we need to decide what should be the default behaviour.

I am going to modify the issue title.

Another example is ib.moneta.cz that also performs audio fingerprinting. I am inclined to deactivate Audio fingerprinting farbling by default until we have another solution.

We discussed this issues on the meeting https://lists.nongnu.org/archive/html/js-shield/2022-04/msg00012.html and decided to move the protection to Strict for 0.10. We also received a bug report https://github.com/polcak/jsrestrictor/issues/182. I tried to investigate further and learnt the following:

https://audiofingerprint.openwpm.com/ incorporates code from https://github.com/Valve/fingerprintjs2 (a widely used project). At the time of my testing, getChannelData was accessed on line 168 and 175 each time in a loop:

    for (var i = 0; i < evnt.renderedBuffer.length; i++) {
        sha1.update(evnt.renderedBuffer.getChannelData(0)[i].toString());
    }

    for (var i = 4500; 5e3 > i; i++) {
      pxi_output += Math.abs(evnt.renderedBuffer.getChannelData(0)[i]);
    }

evnt.renderedBuffer.length is 44100 (on the testing computer). So it means that we farble the same array 44100-times during the first loop and 5000-times during the second loop. It takes about 400ms to farble the array on my computer. So it would take about 5.5 hours to run the code.

Possible solutions:
1. Proxy the array and farble on the fly, only the requested items. But JShelter will need to go through the buffer anyway to compute the farbling hash.
2. Or somehow detect that we already farbled the array. But this will likely need to go through the whole array, and compare that with the previously farbled array(s) which will take a lot of time anyway.
3. Looking at the AudioBuffer API https://developer.mozilla.org/en-US/docs/Web/API/AudioBuffer, most of the methods do not modify the buffer. The only exception is AudioBuffer.copyToChannel(). So I am thinking to store the results of the farbled calls and invalidate them during calls of AudioBuffer.copyToChannel(). Unfortunately that will need to solve an issue of storing some internal information about the buffer and sharing them between wrappers which we do not do.

I think that only the method no. 3 is a viable solution.

I investigated further and went for a modified version of 3.

1. I find out that there was a bug in the strict implementation that resulted in throwing exception during getChannelData(). Fixed in https://pagure.io/JShelter/webextension/c/3e757883cc8495ebfda1c0bf4e9ed8b3b9325ada?branch=devel0.10
2. getChannelData() returns an array, a repeated call returns the same array that was already modified during the first call. So JShelter needs to store references to arrays that were already modified. This happens in https://pagure.io/JShelter/webextension/c/eb756a0427cc2d4d52888301ba3730488b4e96d6?branch=devel0.10. The downside is that we now create a new reference to the array which will delay garbage collection. For now, JShelter removes the array from its internal set of modified arrays after 5 minutes. That can result in lot of data for benign applications. On the other hand a fingerprinter can detect a change in the buffer readout after the 5 minutes. So we need to find a balance.

The plan is to ship this version as 0.10 but I will try some experiments tomorrow.

Fix works on eBay and works in jitsy.