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

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 level of functionality will support the remaining fullscreen use
cases, namely games which require more complex keyboard interactions. Most
developers who use the fullscreen API will not need to pass
the ALLOW_KEYBOARD_INPUT parameter, so most of the common use cases
(YouTube, slideshows, etc.) will be frictionless for the user since a
phishing attack is extremely unlikely.

The advantages of this approach are:
- The 90% of users who use fullscreen mode on YouTube and other video sites
continue to use the fullscreen API as they always have. No modal prompt. No
UI in the way of the video. It just works.
- Browser games are free to continue to innovate. We aren't needlessly
crippling fullscreen mode and crushing this innovation.
- Developers can assume that fullscreen will always fully work (without
arbitrary restrictions), simplifying development and preventing some apps
from being browser-specific (splintering the web).

Possible disadvantages are:
- The API is now slightly more complex (but a single optional parameter
hardly "complex" imo)
- Users may wonder why 90% of sites (YouTube, slideshow sites, etc.) can
enter fullscreen mode without a prompt, but some sites require them to
explicitly "Allow" fullscreen in order for it to work.

Currently, Flash Player 11.3 and later uses a similar approach to the one
I've outlined here and it appears to be simple for developers to use as
well as successfully mitigating the risk of phishing for users. Flash has
two fullscreen modes: "normal" and "interactive". "Normal mode" disallows
keyboard input and shows minimal UI (it just shows "Press ESC to exit
fullscreen mode" for a few seconds). "Interactive mode" disallows keyboard
input completely until the user expressly allows it.

You can check out an example of "interactive mode" here:
http://leebrimelow.com/flash/fullkeys/ For an example of "normal mode" just
go to YouTube and fullscreen any video. This solution is really elegant,
imo.

Thoughts on this approach?

Feross


On Wed, Oct 17, 2012 at 10:07 AM, Carr, Wayne <wayne.carr@intel.com> wrote:

> Requiring that the user approve before a full screen UI is active to
> prevent mimicking a bank site in a browser isn't dictating what the UI
> looks like.
>
> And it can be detectable to the web page - it can be the full screen
> notification doesn't happen until after the user has approved it.
>
> There are different approaches today, but none of them prevent the user
> from interacting with the full screen app before they've approved it going
> full screen.
>
> >-----Original Message-----
> >From: Jonas Sicking [mailto:jonas@sicking.cc]
> >Sent: Wednesday, October 17, 2012 1:44 AM
> >To: Carr, Wayne
> >Cc: Vincent Scheib; Maciej Stachowiak; public-webapps@w3.org; Chris
> Pearce;
> >Florian Bösch; Anne van Kesteren
> >Subject: Re: Defenses against phishing via the fullscreen api (was Re:
> full screen
> >api)
> >
> >On Tue, Oct 16, 2012 at 4:48 PM, Carr, Wayne <wayne.carr@intel.com>
> wrote:
> >>> Chrome supports Fullscreen with keyboard enabled. We use a
> >>> notification that persists until a user notices and dismisses it. We
> >>> may modify it in the future to make this more noticeable, e.g.
> >>> dimming page contents similar to FireFox.
> >>
> >> It would be safer if this was not only dimmed, but was modal, so the
> >> user could not interact with the rest of the full screen contents of
> >> that page until they responded to the notification.  Then they
> >> couldn’t accidentally interact with a full screen app masquerading as a
> browser.
> >>
> >> (Either that or don’t go full screen until the user responded to the
> >> notification.)
> >
> >We have generally always left UI up to implementations. For several
> reasons:
> >
> >* If it's not detectable by the webpage, then it doesn't really matter
> from a web
> >compat point of view, so no need to specify.
> >* Leaving UI up to implementations means that implementations can
> experiment
> >and improve over time.
> >* Generally implementations have been reluctant to allow specifications to
> >dictate UI. And since test suites can't test it anyway, they could simply
> ignore the
> >spec and still pass test suites.
> >* Many times when trying to specify UI, such as when HTTP required UI for
> POST,
> >the result has been really bad.
> >
> >There were some efforts in a separate WG around trying to standardize
> security
> >related UI in order to provide more reliable and secure UI.
> >IIRC this was mostly around the secure-connection UIs (a.k.a. "the lock
> icon") in
> >the URL bar.
> >
> >Of course, things like "are keys enabled while in fullscreen mode" is very
> >noticeable to the page, so it makes sense to put in the spec. And of
> course we
> >always need to ensure that the spec is implementable in a safe way using
> *some*
> >UI strategy. But whether dimming should be done, when exactly to switch to
> >fullscreen mode, and how fullscreen notifications work I think fall under
> "leave it
> >up to implementations"
> >rule.
> >
> >The fact that we have so many different strategies for how to handle the
> >fullscreen UI in current implementations I think is a testament to that
> the current
> >strategy works. Implementations are *very* concerned about security, you
> can
> >bet that they will do their utmost to protect users and adjust UI as
> needed in
> >order to do so. Thinking that we can do better and putting requirements
> in the
> >spec will just have the opposite effect since it means that
> implementations can't
> >do better than whatever we come up with.
> >
> >/ Jonas
>