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

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