[webkit-dev] Request for position on AudioContext.outputLatency

[youenn fablet]

Thanks Hongchan,

It is good to hear that these discussions are happening.
A first good step would be to add the corresponding fingerprinting markup
to the web audio spec.

A few additional thoughts:

https://w3c.github.io/mediacapture-output/ allows listing devices that a
user granted.
In case devices are exposed to JS, exposing latency for those devices seems
fine.
I also wonder whether output latency might be useful outside of
AudioContext and whether it would make sense to expose this information on
MediaDevices as well. Could that be a device selection choice?

The main issue is with the default system audio output. Passive filtering
should not be allowed in that case. For instance, if the AudioContext is
not producing audio, exposing latency does not make sense.

I am a bit unclear about when latency can change, for instance say audio
context is running and the default system speaker is changed. If it can
change, should there be some form of events to let the application know. Or
should it be left to things like MediaDevices.ondevicechange?


Le lun. 13 déc. 2021 à 20:00, Hongchan Choi <hongchan at chromium.org> a
écrit :

> Hi Youenn,
>
> Thanks for your response.
>
> Say I switch from builtin speakers to Bluetooth headset using MacOS system
>> menu.
>>
>
> If changing a device doesn't reflect the current status correctly, the
> feature is not useful. That said, the accuracy/precision of a value being
> served is up to the user agent's discretion.
>
> If so, the spec should identify this as potential fingerprinting and
>> should provide mitigations.
>> And we should evaluate fingerprinting-free alternatives.
>
>
> We are aware of the issue and it is being discussed in the blink-dev I2S
> thread.
>
> What does PING WG think about this?
>
>
> Please note that Web Audio API is currently a W3C Recommendation.
> - The WG went through several PING reviews in 2020, for example:
> https://github.com/WebAudio/web-audio-api/issues/2061
> - One of device-related PING threads:
> https://github.com/w3cping/tracking-issues/issues/50
>
> As a result of the privacy discussion, the spec has a dedicated section on
> security and privacy:
> https://webaudio.github.io/web-audio-api/#priv-sec
>
> The relevant excerpt:
> "Fingerprinting via latency is also possible; it might be possible to
> deduce this from baseLatency and outputLatency. Mitigation strategies
> include adding jitter (dithering) and quantization so that the exact skew
> is incorrectly reported. 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."
>
> Cheers,
> Hongchan
>
>
> On Mon, Dec 13, 2021 at 1:15 AM youenn fablet <youennf at gmail.com> wrote:
>
>> Looking at https://www.w3.org/TR/webaudio/#dom-audiocontext-outputlatency,
>> it states that:
>> > If the audio output device is changed the outputLatency
>> <https://www.w3.org/TR/webaudio/#dom-audiocontext-outputlatency> attribute
>> value will be updated accordingly.
>>
>> The use case seems ok, but I worry about fingerprinting if it means this
>> allows a web page to passively identify user speakers.
>> Say I switch from builtin speakers to Bluetooth headset using MacOS
>> system menu.
>>
>> If so, the spec should identify this as potential fingerprinting and
>> should provide mitigations.
>> And we should evaluate fingerprinting-free alternatives.
>> What does PING WG think about this?
>>
>> Le lun. 13 déc. 2021 à 09:39, Yoav Weiss via webkit-dev <
>> webkit-dev at lists.webkit.org> a écrit :
>>
>>> (Sent on behalf of Hongchan Choi, who failed to subscribe to this
>>> mailing list)
>>>
>>> Hey folks!
>>>
>>> AudioContext.outputLatency is to inform the time at which the first
>>> sample in the buffer is actually processed by the audio output device. This
>>> is useful when synchronizing the audio generated by Web Audio to other
>>> audio or video sources or to visual cues [1].
>>>
>>> This is already implemented in FireFox and we're looking to ship it in
>>> Chrome soon [2][3]. Would you all be interested in this feature?
>>>
>>> Thanks,
>>> Hongchan
>>>
>>> [1] https://www.w3.org/TR/webaudio/#dom-audiocontext-outputlatency
>>> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1324552
>>> [3]
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/dTQniJNVVMY/m/hPFwY1fbBQAJ
>>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20211215/3da9ef96/attachment.htm>