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

"Apple has also indicated of not liking confirm prompts of any kind
whatsoever"

To reiterate: for 90% (probably more) of fullscreen use cases, there would
be no confirmation prompt at all. Only when the developer specifically
requests keyboard access would there need to be a prompt. Thus, developers
of video website and video slideshow tools can avoid requesting keyboard
access and need not get any prompt at all if Apple so chooses. A prompt
should only be necessary for games or complex fullscreen web apps with lots
of shortcuts. Since the user only needs to confirm this one time (the
browser can remember their choice), this burden seems minimal. The cost of
restricting all keyboard input for convenience or for an idealogical
aversion to dialogs is very high. We'd basically making the open web
useless for fullscreen games. What's the point of the pointerlock
specification then?

Also, we're defining a spec for the open web here, right? I don't think
that worrying about what one vendor may or may not implement is useful. The
spec should reflect what we want the open web platform to look like. A
fullscreen mode that is secure against phishing yet supports keyboard input
for games and other complex web apps is pretty important for the web. Can
we make the spec reflect this?

Feross


On Thu, Oct 18, 2012 at 7:50 PM, Carr, Wayne <wayne.carr@intel.com> wrote:

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