Playout Statistics API for WebAudio 2025-01-31 > 2025-03-01

[Hernqvist]

This proposal has passed early tag review, which requested that PING should take a look at it before moving to Audio WG. This is why the spec is not yet a TR.

• name of spec to be reviewed: Playout Statistics API for WebAudio

• URL of spec: https://wicg.github.io/web_audio_playout/

• Current Rec/Note phase? Not a rec yet.

• What and when is your next expected transition? Will be presented to Audio WG after PING review.

• What has changed since any previous review? No previous PING review.

• Please point to the results of your self-review: https://docs.google.com/document/d/1wGv_mr7Lgg2w-6PuKDrcScoa8IvYAOW3PMTFW85O3Gw/edit?tab=t.0

• Where and how to file issues arising? File issues in https://github.com/WICG/web_audio_playout

• Pointer to any explainer for the spec? https://github.com/WICG/web_audio_playout

Other comments: We are running an origin trial for this feature in Chrome, see https://chromestatus.com/feature/5172818344148992

[tomrittervg]

As a drive-by-comment not on behalf of the group, to me I can see a few different concerns:

1. Is this a stable-ish source of fingerprinting entropy? i.e. Does a user consistently have a sufficiently stable performance for a particular input that it can be used as part of a fingerprint?
2. This is a side channel exposing some information about the load of the computer, and we've seen a multitude of attacks that exploit that information.
3. Tying in with the above, this can be used as a covert channel between two cooperating origins.

I'm not concerned about #3. #1 I am skeptical about but I also have no relevant experience with WebAudio that would give me an informed opinion.

With my Tor Browser hat on, I can say that the concern of #1 and #2 would most likely lead us to disable the API or hardcode it to return data that is not representative of actual performance as we did with the analogous video performance APIs.

[Hernqvist]

Thank you for your concerns!

1. We do not believe that it is a very good source of fingerprinting entropy, for the following reasons:

• For most users the API will only return 0 glitches, because under normal conditions no glitches happen at all.
• In order to use the API for fingerprinting, we would need to create a condition/input that causes glitches consistently. Since audio runs only on high-priority threads, this involves loading the system's CPU to 100%.
• In our experiments, glitches from such a fingerprinting input is to some extent already detectable by JS in other ways, such as measuring the time between audio callbacks in ScriptProcessorNode or AudioWorkletProcessor.

2. The API gives a binary signal about CPU load: either the system is under critical load to the point of causing audio glitches, or it isn't. The API does not show different data for 80% CPU load or 90% CPU load, because neither will cause glitches. So it's not good for measuring gradual CPU load.
   It could be conceived that an attacker would gradually increase CPU load until glitches occur, and estimate more fine-grained CPU load or capacity that way. As mentioned though, this is probably already possible using existing JS APIs.

3. Yes, we have some discussion about the covert channel in the self-review here. Our conclusion is that it is impractical, and also already possible without this API.