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: Rick Waldron <waldron.rick@gmail.com>
Date: Mon, 22 Oct 2012 19:44:29 -0400
To: Chris Pearce <cpearce@mozilla.com>
Cc: Maciej Stachowiak <mjs@apple.com>, Florian Bösch <pyalot@gmail.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>
Message-ID: <A80E2ACF62234283B20F5E26F2B98E35@gmail.com>


On Monday, October 22, 2012 at 6:04 PM, Chris Pearce 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.

What if applications, such as iA Writer wanted to offer a web version? Too bad, no keyboard for distraction-free mode?

(http://www.iawriter.com/)

Rick

> 
> 
> 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 23:45:00 GMT

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