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

[Yoav Weiss via webkit-dev]

 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  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@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@lists.webkit.org
>>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>>>
>>>>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Yoav Weiss via webkit-dev]

Copying Hongchan's reply to the list..

On Mon, Dec 13, 2021 at 8:00 PM Hongchan Choi  wrote:

> 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  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@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@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Yoav Weiss via webkit-dev]

(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@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position: Aligning high-resolution timer granularity to cross-origin isolated capability

[Yoav Weiss via webkit-dev]

On Wed, Mar 17, 2021 at 5:51 PM Geoff Garen  wrote:

> For the 100 microsecond value — our research suggests that you need a much
> higher value in vulnerable contexts.
>
> For the guaranteed isolated case — have you considered the use of high
> precision time to carry out non-Spectre timing attacks?
>

Could you elaborate on those 2 points?


>
> Thanks,
> Geoff
>
> On Mar 17, 2021, at 3:38 AM, Yoav Weiss via webkit-dev <
> webkit-dev@lists.webkit.org> wrote:
>
> Hey folks,
>
> We recently changed <https://github.com/w3c/hr-time/pull/93> the HR-time
> spec <https://w3c.github.io/hr-time/> to better align its resolution
> clamping with cross-origin isolated capability
> <https://html.spec.whatwg.org/multipage/webappapis.html#concept-settings-object-cross-origin-isolated-capability>,
> and now I'm interested in shipping this change in Chromium.
> In practice that means that Chromium would be reducing its resolution in
> non-isolated contexts (regardless of the platform's site-isolation status)
> to 100 microseconds, and increasing it in cross-origin isolated contexts
> (even in platforms without site-isolation, e.g. Android) to 5 microseconds.
>
> As WebKit already clamps those timers to 1ms (AFAIK), I'd mostly like your
> position on the latter. Would y'all be interested in increasing timer
> granularity in contexts which have guarantees against pulling in
> cross-origin resources without their opt-in?
>
> I'd appreciate your thoughts on the matter.
>
> Cheers :)
> Yoav
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Request for position: Aligning high-resolution timer granularity to cross-origin isolated capability

[Yoav Weiss via webkit-dev]

Hey folks,

We recently changed  the HR-time
spec  to better align its resolution
clamping with cross-origin isolated capability
,
and now I'm interested in shipping this change in Chromium.
In practice that means that Chromium would be reducing its resolution in
non-isolated contexts (regardless of the platform's site-isolation status)
to 100 microseconds, and increasing it in cross-origin isolated contexts
(even in platforms without site-isolation, e.g. Android) to 5 microseconds.

As WebKit already clamps those timers to 1ms (AFAIK), I'd mostly like your
position on the latter. Would y'all be interested in increasing timer
granularity in contexts which have guarantees against pulling in
cross-origin resources without their opt-in?

I'd appreciate your thoughts on the matter.

Cheers :)
Yoav
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev