W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

Re: [Bug 19297] New: May user agents apply additional restrictions on entering pointer lock?

From: Florian Bösch <pyalot@gmail.com>
Date: Tue, 9 Oct 2012 12:09:34 +0200
Message-ID: <CAOK8ODh340Wo0hkLHp8CMqBQ0NVyqZb9Uye2d9BuGgX=DbtCtw@mail.gmail.com>
To: Charles McCathie Nevile <chaals@yandex-team.ru>
Cc: bugzilla@jessica.w3.org, public-webapps@w3.org
On Tue, Oct 9, 2012 at 11:41 AM, Charles McCathie Nevile <
chaals@yandex-team.ru> wrote:

> On Tue, 09 Oct 2012 08:43:13 +0200, Florian Bösch <pyalot@gmail.com>
> wrote:
>  Cheer up everyone, we've got somebody dedicated to writing fullscreen
>> exploits now :) http://feross.org/html5-**fullscreen-api-<http://feross.org/html5-fullscreen-api->
>> >attack/
>> Summary: Change blindness may make phishing attacks feasible (displaying
>> a mock browser/page in fullscreen)
>> Cause: Switch to fullscreen before user consent.
>> Fix: Switch to fullscreen after user consent.
>> Questions:
>> - Is this a problem?
> The blog shows why it is a problem? It matches a very well-known class of
> problem. So I would say "Yes, there is a problem here".
>  - Does the proposed fix address the problem?
> The question of "what gets tp go fullscreen" matters. Getting user consent
> to go fullscreen, but then making something else the actual thing that
> takes the screen, may not solve the problem because it still enables the
> attack to be developed.

I think the reasoning to allow for elements to be fullscreened is pretty
solid (video players, webgl overlays etc.). If an element cannot be made
fullscreen (where such functionality is desired as in video players,
containers containing UI and webgl, game portals embedding iframes etc.) it
just leads to developers emptying the <body> and replacing the
style/content with what they want in there, which ends up with the same
result just in a much more inconvenient and slow fashion. You ultimately
cannot prevent the page showing something else entirely upon entering
fullscreen, but you can make it much more tedious for legitimate uses by
removing the element fullscreen functionality. To that end, there wouldn't
be a point not to do the element fullscreen capability.

The reasoning to allow for javascript polled fullscreen is also pretty
solid. The use-case for element fullscreen is evident and desired. Absent
any means to target what element, a fullscreen menu/shortcut won't be able
to do it right.

Short of actually removing JS polled fullscreen you cannot address the
issue on the basis of "whenever something goes fullscreen it can be
something else". Yet, the case for fullscreen altogether is also pretty
evident. This would come down to a choice between having fullscreen and not
having fullscreen at all, which I think, is not a choice anybody would be
happy with.

The fix proposed works on the principle that the message to enter
fullscreen disconnects the immediate display of the phish (the change
blindness) from the actual action with the expected result (clicking link)
by layering a dialog/indefinite delay until clicked between a link and a
display, thereby removing the "blindness" almost entirely (you have to look
at the screen to click a confirmation dialog, upon clicking the dialog, the
screen will change a lot). I would propose making this confirmation fairly
obstrusive/centered (like in firefox, chrome uses a very easily ignored

Ultimately you have to accept that if you want fullscreen, and if you asked
the user, and the user clicked yes, then this is all you can do. The only
other choice is not to do fullscreen which would in my opinion exceed the
remit of a reasonable security measure by far.

>  - What is the reasoning to switch before user consent?
> It allows developers to control more of the experience (which they
> generally want). Given the price in security for the user, I would say the
> end is not justified.
I don't understand how it gives more control over the experience.
Received on Tuesday, 9 October 2012 10:10:03 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:49 UTC