Re: [w3ctag/design-reviews] Early TAG review request for Playout Statistics API for WebAudio (Issue #939)

Hi @martinthomson! We believe that this proposed API gives less detailed information about CPU load than #843 (Audio Render Capacity). Since audio should always run on realtime threads, general high CPU load should not impact audio. When CPU load is high enough to impact realtime threads to the point of causing glitches, the Render Capacity API should already show underruns and very high load.

As for the risk of side channeling, we have investigated this risk more closely since filing the issue. We have found that the API we are proposing is not necessary to set up an audio glitch-based side channel. One way to set up this side channel using only currently implemented APIs is the following:
* Website 1 creates multiple computationally expensive AudioContexts. I tested this with 3 AudioContexts that each contained one OscillatorNode and 4000 BiquadFilterNodes.
* Website 2 creates a single AudioContext with a ScriptProcessorNode that measures the time between consecutive calls to process.
* Website 2 will observe longer maximum intervals between AudioProcessingEvents while Website 1 is active. Website 1 can now send messages to Website 2 by creating and stopping AudioContexts.

I have tested this scheme (on Mac) on Chrome, Safari and Firefox and it works on all of them (though you might have to change the number of AudioContexts or Nodes a bit depending on browser). So this side channel already exists, and we do not believe it is made worse by the proposed API.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/939#issuecomment-2022954199
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/939/2022954199@github.com>