[wg/audio] Audio Group Charter

[svgeesus]

New charter proposal, reviewers please take note.

Charter Review

Charter:

diff from previous charter
diff from template

What kind of charter is this? Check the relevant box / remove irrelevant branches.

• Existing

• Existing WG recharter

Horizontal Reviews: apply the Github label "Horizontal review requested" to request reviews for accessibility (a11y), internationalization (i18n), privacy, security, and TAG. Also add a "card" for this issue to the Strategy Funnel.

Communities suggested for outreach: Audio CG

Known or potential areas of concern: none

Where would charter proponents like to see issues raised? GitHub

Anything else we should think about as we review?

Note: proposed chairs should be copied @... on this issue.

@hoch @mdjp

[himorin]

• last entry in history table lack a link to charter (current running one) and extension
• top leading text has typo isis in The mission of the Audio Working Group isis to add

[svgeesus]

@himorin thanks, fixed

[himorin]

no comment or request from i18n

[ruoxiran]

no comment or request from APA.

[svgeesus]

@simoneonofri any comments from a security perspective?

[simoneonofri]

I have read the security consideration sections, which seem well-reasoned.

A further security consideration is that the element could be used to make the browser process a file with a format that contains an attack on the libraries to then encode/decode the file.

For instance:

• Vulnerabiities on VLC linked to the reproduction of media files.
• Crash problem on a browser related to reproducing a very large file
  Or even potential cross-origin-read issues

[hoch]

@simoneonofri Thanks for your feedback!

However, vulnerabilities on VLC and potential cross-origin-read issues are related to the AudioElement, which is not under the Audio WG's purview. See https://www.w3.org/2022/02/audio-2022.html.

Regarding the OOM crash problem, do you believe it is a security issue? In terms of the functionality of API, the WG believes the WebCodec is the right solution for such use case. See WebAudio/web-audio-api#2321 (comment).

[simoneonofri]

@simoneonofri Thanks for your feedback!

You're welcome @hoch

However, vulnerabilities on VLC and potential cross-origin-read issues are related to the AudioElement, which is not under the Audio WG's purview. See https://www.w3.org/2022/02/audio-2022.html.

Thank you for clarifying the scope. I understood it as an 'input' element where potentially malicious date streams could be received.

Regarding the OOM crash problem, do you believe it is a security issue? In terms of the functionality of API, the WG believes the WebCodec is the right solution for such use case. See WebAudio/web-audio-api#2321 (comment).

It depends on the reason for the crash. If it is for a memory allocation problem, it is possible.

About the specific issue, the expected behavior can be to "fail securely," often, when there is a malformed input, discarding it is an option; alternatively, it can be sanitized, but this may be complex/risky.

[hoch]

About the specific issue, the expected behavior can be to "fail securely," often, when there is a malformed input, discarding it is an option; alternatively, it can be sanitized, but this may be complex/risky.

First, to clarify the scope of the question I assume you're referring to decodeAudioData() method.

In Chromium, it is safe to crash on OOM and IMO it does not pose a security problem. Do we believe this is somehow documented in the spec? I thought this is more of an implementation issue.

[svgeesus]

@simoneonofri if you are now satisfied, please mark the security review as completed

@plh any additional comment from PING?

[plehegar]

No objection from PING to the charter

[svgeesus]

AC Review started