[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
  • [x] 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 https://github.com/WebAudio/web-audio-api/issues/2321#issuecomment-829399855.

[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.

[romankulkovsf]

I need help

On Tue, Jul 9, 2024, 10:52 AM Hongchan Choi @.***> wrote:

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.

— Reply to this email directly, view it on GitHub https://github.com/w3c/strategy/issues/470#issuecomment-2218319077, or unsubscribe https://github.com/notifications/unsubscribe-auth/BFQ6X424MYYDZ7NBPUHQOBLZLQPO3AVCNFSM6AAAAABJMWBD4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJYGMYTSMBXG4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[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

[himorin]

considering change around proposed recommendation, first sentence in success criteria as In order to advance to Proposed Recommendation, seems to be better reverted into the original charter template?

[svgeesus]

The charter template was only updated last week but yes it would be better to fold in that change.

[svgeesus]

The charter has been updated to fold in that change

[plehegar]

Announced