Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[wg/audio] Audio Group Charter #470

Closed
1 task done
svgeesus opened this issue Jun 16, 2024 · 17 comments
Closed
1 task done

[wg/audio] Audio Group Charter #470

svgeesus opened this issue Jun 16, 2024 · 17 comments

Comments

@svgeesus
Copy link
Contributor

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
Copy link

himorin commented Jun 18, 2024

  • 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
Copy link
Contributor Author

@himorin thanks, fixed

@himorin
Copy link

himorin commented Jun 25, 2024

no comment or request from i18n

@ruoxiran
Copy link

no comment or request from APA.

@svgeesus
Copy link
Contributor Author

svgeesus commented Jul 2, 2024

@simoneonofri any comments from a security perspective?

@simoneonofri
Copy link

simoneonofri commented Jul 8, 2024

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:

@hoch
Copy link

hoch commented Jul 8, 2024

@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
Copy link

@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
Copy link

hoch commented Jul 9, 2024

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

This comment was marked as off-topic.

@svgeesus
Copy link
Contributor Author

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

@plh any additional comment from PING?

@plehegar
Copy link
Member

No objection from PING to the charter

@svgeesus
Copy link
Contributor Author

AC Review started

@himorin
Copy link

himorin commented Nov 5, 2024

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
Copy link
Contributor Author

svgeesus commented Nov 5, 2024

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

@svgeesus
Copy link
Contributor Author

svgeesus commented Nov 5, 2024

The charter has been updated to fold in that change

@plehegar
Copy link
Member

plehegar commented Nov 8, 2024

Announced

@plehegar plehegar closed this as completed Nov 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment