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

Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

From: Florian Bösch <pyalot@gmail.com>
Date: Tue, 23 Oct 2012 00:22:27 +0200
Message-ID: <CAOK8ODhxZrrQjprH0FJWHgdXVT7CGbPjhU9wGOG2hTn4d8LvsQ@mail.gmail.com>
To: Chris Pearce <cpearce@mozilla.com>
Cc: Maciej Stachowiak <mjs@apple.com>, Anne van Kesteren <annevk@annevk.nl>, "Carr, Wayne" <wayne.carr@intel.com>, "public-webapps@w3.org" <public-webapps@w3.org>, Feross Aboukhadijeh <feross@feross.org>, Jonas Sicking <jonas@sicking.cc>
FYI Flickr slideshows and Google street view are now fullscreen users.

On Tue, Oct 23, 2012 at 12:04 AM, Chris Pearce <cpearce@mozilla.com> wrote:

>  On 16/10/12 18:48, Maciej Stachowiak wrote:
>
> Many games could work with only non-alphanumeric keys or in some cases
> only the mouse. As could slideshows. You only need space/enter/arrows for a
> full screen slide presentation.
>
>
> FWIW I agree. Pretty much the only uses cases that I can envisage that
> would really need alpha-numeric keyboard access are games, or 3D modellers,
> like CAD software.
>
>
>
> On 19/10/12 14:31, Feross Aboukhadijeh wrote:
>
> I wrote the attack demo that prompted this discussion. Here are my
> thoughts on how to improve the spec and/or the implementations in browsers:
>
>  requestFullscreen() should trigger fullscreen mode with limited keyboard
> input allowed (only space, arrow keys, and perhaps some modifier keys like
> CTRL, ALT, etc.). The browser should display a notification that the user
> is in fullscreen mode, although it can fade away after some time since the
> risk of phishing is significantly reduced when keyboard input is limited
> (note that Safari currently sees fit to show NO notification at all about
> fullscreen mode because keyboard is limited).
>
>  This level of functionality will support 90% of current fullscreen use
> cases like video players, slideshow viewers, and games with simple input
> requirements.
>
>  However, the spec should also support an optional ALLOW_KEYBOARD_INPUT
> parameter to requestFullscreen() which, when passed, triggers fullscreen
> mode with full keyboard support (except for ESC to exit fullscreen). When
> this parameter is passed, the browser should show a prominent modal dialog
> on top of the page content, requesting permission to use fullscreen mode.
> No keyboard or mouse input should be allowed until the user clicks "Allow".
>
>
> This looks remarkably like Mozilla's original proposal:
> https://wiki.mozilla.org/Gecko:FullScreenAPI
>
> We chose not to implement this as it offers little protection against
> phishing or spoofing attacks that don't rely on keyboard access. In those
> cases making the user aware that they've entered fullscreen is pretty much
> the best defence the user has. Other than not having a fullscreen API at
> all.
>
> Our fullscreen approval UI in Firefox is based around the assumption that
> for most users the set of sites that use the fullscreen API that the user
> encounters on a daily basis is small, and users would tend to opt to
> "remember" the fullscreen approval for those domains. I'd imagine the set
> would be YouTube, Facebook, and possibly ${FavouriteGame}.com for most
> users. Thus users would see a notification and not an approval prompt *most
> of the time* when they entered fullscreen. But when some other site goes
> fullscreen they do get a prompt, which is out of the ordinary and more
> likely to be read.
>
>
>
> Chris Pearce
>
Received on Monday, 22 October 2012 22:22:56 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:55 GMT