The HTML standard at https://html.spec.whatwg.org/multipage/embedded-content.html#effective-media-volume says:

"""
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, because there is a known implementation (WebKit-GTK on top of PulseAudio on Linux) that, while formally satisfying this standard, does so in a way that presents a security problem (CVE-2013-7324) and effectively claims that the problem is inherent in the standard.

Xabier Rodríguez Calvar (a WebKit-GTK developer) has explicitly asked me to raise the issue with W3C during LinuxCon Europe 2013. Ian 'Hixie' Hickson from W3C asked me to reraise the issue with WHATWG.

The issue is that the "loudest setting may be lower than..." phrase is interpreted as "may or may not, and we choose a not here for consistency with the desktop volume model". I.e. the javascript-settable volume is always interpreted as relative to the sound card's maximum hardware volume, because that's how PulseAudio interprets volumes of desktop apps by default. 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. It is a recognized 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 in 2013 (IE, Firefox, Chrome/Chromium, Opera) implement the volume as relative to the one set for the browser or for the tab by the user in the system mixer, and I think that this common-sense 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 (CVE request)
http://www.openwall.com/lists/oss-security/2014/02/10/13 (CVE assignment)

Here is one of the possible variants of 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 strictly increasing in loudness. The range need not be linear. If a system has a dedicated "master" volume control, or a specific volume control for the browser, its tab, or any other software component displaying HTML, then the 1.0 volume must be less than or equal to the limit set by any such control, and displaying the HTML must not result to any changes to the setting of this control. There may be other methods for the user to set the inviolable maximum loudness, and there must be at least one such method.
"""

If the above change is not suitable, maybe a note can be added elsewhere in the standard about this security issue so that implementors are aware of it.