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

If touch events are restricted, how does the user pause the video?

From: Florian Bösch [mailto:pyalot@gmail.com]
Sent: Thursday, October 18, 2012 7:08 PM
To: Feross Aboukhadijeh
Cc: Carr, Wayne; Jonas Sicking; Vincent Scheib; Maciej Stachowiak; public-webapps@w3.org; Chris Pearce; Anne van Kesteren
Subject: Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

Note that that's a related but not identical stage of the process. There will still have to be a way to differentiate how to request fullscreen with those capabilities that you queried as being being possible. I'll summarize it as:

- First figure out what capabilities you can have
- If satisfied place you can place a button in your sites UI to indicate fullscreen
- Then go on to request fullscreen for these capabilities.

I'd also not focus this entirely on the keyboard. There are similar phishing problems for applications on mobiles that use an on-screen keyboard where not keyboard, but touch events would be restricted.
On Fri, Oct 19, 2012 at 4:01 AM, Florian Bösch <pyalot@gmail.com<mailto:pyalot@gmail.com>> wrote:
There are two problems with your proposal:

1) Apple has indicated of not being comfortable with keyboard (and/or UI?) events in fullscreen at all.
2) Apple has also indicated of not liking confirm prompts of any kind whatsoever.

If Apple cannot be swayed, then a fullscreen button will remain a "break my app" button for web application developers.

Which is why I proposed that vendors indicate which capabilities will be missing before any attempt to enter fullscreen, so that Apple does not have to be swayed to do things they indicated not wanting to do, but solves the "break my app" button problem for web application developers.

On Fri, Oct 19, 2012 at 3:31 AM, Feross Aboukhadijeh <feross@feross.org<mailto:feross@feross.org>> 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 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<mailto: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<mailto:jonas@sicking.cc>]
>Sent: Wednesday, October 17, 2012 1:44 AM
>To: Carr, Wayne
>Cc: Vincent Scheib; Maciej Stachowiak; public-webapps@w3.org<mailto: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<mailto: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