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 <mailto: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/132a3187-f230-c029-b1dc-1a85eed1c884%40chromium.org.
