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

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>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>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
>>
>
>