Thanks for the feedback, Mike. This is really helpful! Mitigation strategies include adding jitter (dithering) and quantization so > that the exact skew is incorrectly reported >
This bit refers to the randomization mechanism deployed by other browsers, but this approach defeats the purpose of this specific API and it is also argued in the spec: Note however that most audio systems aim for low latency, to synchronise > the audio generated by WebAudio to other audio or video sources or to > visual cues (for example in a game, or an audio recording or music making > environment). Excessive latency decreases usability and may be an > accessibility issue. If the reported value is incorrect, the A/V synchronization won't be possible. (Perhaps chcunningham@ can say more about this use case.) One mitigation idea: we can do some research to collect values reported by major platforms/devices and devise a reasonable "bucket system" for them. On Tue, Nov 16, 2021 at 8:14 AM Mike Taylor <miketa...@chromium.org> wrote: > I suppose it would be nice to do some testing to verify the idea that > there's a small number of platform + audio device pairs. I was hoping > Mozilla's > hardware survey <https://data.firefox.com/dashboard/hardware> might have > something on that, but it doesn't track speakers. > > Just from some simple testing with the following script (thanks dmcardle@ > for the snippet) in Firefox on macOS by 3 people, we have very different > values that change dramatically when you unplug a headset: > > ``` > (function getNextSample() { > console.log((new AudioContext).outputLatency); > setTimeout(getNextSample, 10); > })(); > ``` > Here's the values on my macbook, using Firefox Nightly: > bose headset plugged in: 0.005895833 > take headset out: 0.013083333 > plug bose headset back in: 0.005875 (different, but stable) > > https://www.w3.org/TR/webaudio/#priv-sec mentions some mitigation > strategies - do we have a plan to apply any of them? > > On 11/15/21 11:53 AM, Ajay Rahatekar wrote: > > The small number of platform + audio output device combination i.e. a > large number of users with the same platform and output device (users on > macOS using airpods) would likely be a natural obfuscator. Not sure if we > have data about the distribution. > > On Mon, Nov 15, 2021 at 8:05 AM Mike Taylor <miketa...@chromium.org> > wrote: > >> On 11/15/21 10:56 AM, Hongchan Choi wrote: >> >> On Mon, Nov 15, 2021 at 6:49 AM Mike Taylor <miketa...@chromium.org> >> wrote: >> >>> On 11/15/21 1:47 AM, Yoav Weiss wrote: >>> >>> On Fri, Nov 12, 2021 at 5:33 PM 'Ajay Rahatekar' via blink-dev < >>> blink-dev@chromium.org> wrote: >>> >>>> >>>> TAG review status >>>> >>>> Completed: Web Audio API specification is W3C Recommendation. >>>> >>>> Risks >>>> >>>> There is a risk of the feature being used for fingerprinting. However >>>> outputLatency >>>> is the buffer size of the platform-provided audio callback, so the value is >>>> inherently platform-specific. That said, the majority of the platform audio >>>> buffer size is widely known. (MacOS = 128 frames, Windows = 10ms, Android = >>>> 96 frames, etc) >>>> >>>> This feature does not expose more than what you can query/infer from >>>> the UA string. >>>> >>> >>> Would that exposure map cleanly to UA-Platform >>> <https://wicg.github.io/ua-client-hints/#sec-ch-ua-platform>, which is >>> considered low-entropy and exposed by default? Or would it add more than >>> that? >>> >>> /cc +Mike Taylor <miketa...@chromium.org> >>> >>>> Looking at >>> https://www.w3.org/TR/webaudio/#dom-audiocontext-outputlatency, it >>> states that it depends on the platform _and_ the hardware output device. If >>> I use an app using outputLatency with speaker A, then switch to speaker B, >>> will the outputLatency remain the same? >>> >> >> The specification says: If the audio output device is changed the >> outputLatency attribute value will be updated accordingly. >> >> So the answer is no. The value will change accordingly. >> >> If that's the case, then outputLatency can reveal more entropy than just >> platform alone, right? It would be useful to know what this looks like in >> practice, or what mitigations we might be able to apply depending on the >> size of these latency differences. >> > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGJqXNtj-7qa9i2Gb%3D4ZuPQa-sAOEz09BnJeS9zpf%3D2TKkE32w%40mail.gmail.com.
