[Bug 23642] New: [security] Please require the relative-to-system-mixer sound volume model

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23642

            Bug ID: 23642
           Summary: [security] Please require the relative-to-system-mixer
                    sound volume model
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec
          Assignee: dave.null@w3.org
          Reporter: patrakov@gmail.com
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-admin@w3.org,
                    public-html-wg-issue-tracking@w3.org

The HTML5 spec says the following about the element's effective media volume:

"An element's effective media volume is determined as follows:

[...]

The element's effective media volume is volume, interpreted relative to the
range 0.0 to 1.0, with 0.0 being silent, and 1.0 being the loudest setting,
values in between increasing in loudness. The range need not be linear. The
loudest setting may be lower than the system's loudest possible setting; for
example the user could have set a maximum volume."

I think that the text needs to be clarified to rule out what I think is the
deliberate misinterpretation currently done in Webkit-GTK on Linux, especially
when the system runs PulseAudio in its default configuration with flat volumes.
In fact, Xabier Rodríguez Calvar (a WebKit-GTK developer) has explicitly asked
me to raise the issue with W3C during LinuxCon Europe 2013.

The misinterpretation done by WebKit-GTK + PulseAudio is that the volume is
interpreted as relative to the sound card's maximum hardware volume. I.e., if
the web page requests 100%, the master volume control of the system mixer will
be bumped, resulting in a sound much louder than intended - potentially up to
hardware or hearing damage. I think that it is a security issue to allow this
behaviour, and thus want the wording to be changed in the standard.

Another reason to change the wording is this annoyance-class bug: if a browser
implements the volume through any means that correspond to a slider in the
system mixer, any application that sets the volume using a timer will result in
that slider disobeying the user. This is indeed the case with Epiphany, Midori
or any other browser based on WebKit-GTK under Linux with PulseAudio. It would
be nice to disallow implementations that implement this annoyance.

In fact, all other browsers that I have tested (IE, Firefox, Chrome/Chromium,
Opera) implement the volume as relative to the one set by the user in the
system mixer, and I think that this behaviour is what was intended. There are
web pages in the wild relying on this (e.g. by setting volume to 1.0 explicitly
and assuming that it is just the safe default), e.g.
http://www.mikanse.com/FunWithDynamite/fun-with-dynamite.html (search for
"this.volume=1" in http://www.mikanse.com/FunWithDynamite/funwithdynamite.js)

Here are some relevant links:

https://bugzilla.gnome.org/show_bug.cgi?id=675217 (initial bug report)
http://jsfiddle.net/bteam/FbkGD/ (security-relevant reproducer - just
repeatedly changes the volume to 99% or 100% using a timer)
The end of https://bugs.webkit.org/show_bug.cgi?id=118974 (the root cause)
http://www.openwall.com/lists/oss-security/2013/10/22/6 (attempted CVE request,
not answered yet)

Here is the wanted clarification:

"The element's effective media volume is volume, interpreted relative to the
range 0.0 to 1.0, with 0.0 being silent, and 1.0 being the loudest setting,
values in between increasing in loudness. The range need not be linear. The
loudest setting must be equal to or lower than the volume set for the browser
in the system's mixer application, if the system has one. There may be other
methods for the user to set the inviolable maximum volume, and there must be at
least one such method. Volume changes done through the DOM or through the
browser UI must not result in any changes to the user-controllable elements of
the system mixer."

As I said, all major browsers already comply with the new requirements: the
inviolable maximum volume is set in the system mixer, and javascript doesn't
have access to it.

Of course, you are welcome to suggest a better wording that covers the issue.
There may be other ways to produce audio from HTML5, they may need a similar
clarification (requirement of a system-mixer-relative volume model) too.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Saturday, 26 October 2013 13:28:04 UTC