Re: Impasse with GNOME bug 675217

["Alexander E. Patrakov" <patrakov gmail com>]

2013/11/18 Matthias Clasen <matthias clasen gmail com>:
> On Sat, Nov 16, 2013 at 9:20 AM, Alexander E. Patrakov <patrakov gmail com>
> wrote:
> > Hello.
> >
> > You are receiving this message because Michael Catanzaro (who is, if I
> > understand correctly, a GNOME developer, but not an official developer
> > of Epiphany, the GNOME web browser) advised me to contact the release
> > team what to do about the Epiphany browser vulnerability (initially
> > reported as regular bug #675217, and only long after that was a
> > malicious testcase constructed). The impasse is that nobody thinks
> > that this is a bug in his package, nobody is willing to do anything
> > (because it is someone else's bug or not a bug at all), and thus I
> > concluded that the bug needs to be escalated.
>
>
> Hi Alexander,
>
> I can't help but feel that you are on a bit of a crusade here - reporting
> this single issue in multiple avenues, and even trying to frame it as a
> security issue. Remember that epiphany is just an app - there's other web
> browsers out there if this one doesn't suit you...

I think that such behaviour is completely unacceptable even in a
browser that I don't use. It _is_ a security issue. That's why the
crusade.

> My own perspective on this issue is that it is an annoying bug, and epiphany
> could perhaps handle the situation better.

By itself, it is definitely not a bug in Epiphany. There is exactly
nothing (short of switching to a different web engine) that Epiphany
can do to resolve it. Implementing the relative volume model in WebKit
(as done in Firefox, Chromium and all Windows-based browsers) would
help, and I think this would be a proper solution. The problem is -
WebKit devs think that it is against the goals.

> It is somewhat similar to
> allowing web pages to 'go fullscreen' - browsers do that nowadays, but they
> usually display an overlay that tells the user how to get out. Something
> similar could perhaps be done for volume control.

The analogy is false. It would be true if the fullscreen web page
contained real fire that could burn the eyes - but then, allowing the
user to cancel the transition to full screen post-factum would not be
appropriate either.

There was indeed a suggestion (from Xabier Rodríguez Calvar) to deal
with it with UI prompts before the web page updates the volume level.
However, it would lead to such prompts in all well-intentioned HTML5
games that use the volume property to control how their sounds are
mixed together. Web developers would be unaware of such
game-distracting prompts, because most of them work on Windows, where
such prompts don't exist. Besides, this prompting (especially since
there exists a near-universally accepted solution with zero prompts)
violates the zero-prompt philosophy outlined in the "More secure with
less "security"" talk done at GUADEC 2013 by Stef Walter.

> That being said, I don't
> know the details of the relevant web standards.

Here is the link to the latest draft:
http://www.w3.org/html/wg/drafts/html/master/embedded-content-0.html#effective-media-volume

As you see, there is nothing that specifies the relation of the
javascript-settable volume and sound pressure produced, except this
phrase: "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 security issue is due to the currently-unspecified interpretation
of 1.0: all browsers interpret it to mean "what the system mixer says"
(and that's what web developers expect), except WebKit (and thus
Epiphany), who thinks that it is whatever PulseAudio thinks 100%
volume is. Which is 100% HW volume.

-- 
Alexander E. Patrakov