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

[Anne van Kesteren]

On Thu, Dec 20, 2012 at 8:08 AM, Maciej Stachowiak  wrote:
> On Dec 18, 2012, at 6:44 AM, Anne van Kesteren  wrote:
>> The specification is modeled after Gecko and Chrome and very much
>> intents to have keyboard access working. As per usual, everything that
>> is not restricted is expected to work.
>
> That seems like a bad basis to make a decision about a security issue.

I'm not sure I follow. How specifications are written has no influence
on how decisions regarding them are made.


>> I am willing to add some wording to the security section to make the
>> risks of keyboard access more clear. Does anyone have some suggested
>> wording?
>
> What would be the point? Web developers can't protect themselves from 
> phishing attacks by other sites, and as you state the spec currently does not 
> allow UAs to limit keyboard access. So who is the audience for such as 
> security considerations warning? End users?

I think the specification should state that certain keys should be
protected, such as the key used by the user agent to fully exit
fullscreen.


> At minimum, I'd like the spec to explicitly allow not providing full keyboard 
> access, as requested in my original message on this thread:
>
>>> Despite both of these defenses having drawbacks, I think it is wise for 
>>> implementations to implement at least one of them. I think the spec should 
>>> explicitly permit implementations to apply either or both of these 
>>> limitations, and should discuss their pros and cons in the Security 
>>> Considerations section.
>
> As you point out, the spec does not currently allow this behavior. Are you 
> rejecting this request? If so, why? Safari has had this behavior since 
> forever and is unlikely to change in the foreseeable future, so it seems 
> pointless to disallow it.

Allowing Safari's behavior is bad for a large number of use cases,
such as games and presentations that need to respond to key input.


> And given this difference in UA behavior, it seems useful to let web 
> developers feature-detect the difference in behavior somehow.

Does Safari implement the standardized API already?
http://trac.webkit.org/browser/trunk/Source/WebCore/dom/Document.idl
suggests it is still prefixed.


-- 
http://annevankesteren.nl/

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

[Florian Bösch]

On Thu, Dec 20, 2012 at 8:08 AM, Maciej Stachowiak  wrote:

> And given this difference in UA behavior, it seems useful to let web
> developers feature-detect the difference in behavior somehow.
>
It would be useful to be able to detect it. But it's in no way cruical, we
can just do if($.browser.safari){ $('body').empty().text('Please use
Chrome') }

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

[Maciej Stachowiak]

On Dec 18, 2012, at 6:44 AM, Anne van Kesteren  wrote:

> On Tue, Oct 23, 2012 at 12:50 AM, Maciej Stachowiak  wrote:
>> Based on all this, I continue to think that requesting keyboard access
>> should involve separate API, so that it can be feature-detected and given
>> different security treatment by vendors as desired. This is what Flash does,
>> and they have the most experience dealing with the security implications of
>> fullscreen on the Web.
> 
> Gecko and Chrome have indicated they do not desire this distinction.
> You have indicated your desire to maybe enable keyboard access in the
> future, but you do not have a thought out UI. Given this is the data
> we are working with it seems unwise to change direction at this point.
> 
> The specification is modeled after Gecko and Chrome and very much
> intents to have keyboard access working. As per usual, everything that
> is not restricted is expected to work.

That seems like a bad basis to make a decision about a security issue.

> 
> I am willing to add some wording to the security section to make the
> risks of keyboard access more clear. Does anyone have some suggested
> wording?

What would be the point? Web developers can't protect themselves from phishing 
attacks by other sites, and as you state the spec currently does not allow UAs 
to limit keyboard access. So who is the audience for such as security 
considerations warning? End users?


At minimum, I'd like the spec to explicitly allow not providing full keyboard 
access, as requested in my original message on this thread:

>> Despite both of these defenses having drawbacks, I think it is wise for 
>> implementations to implement at least one of them. I think the spec should 
>> explicitly permit implementations to apply either or both of these 
>> limitations, and should discuss their pros and cons in the Security 
>> Considerations section.

As you point out, the spec does not currently allow this behavior. Are you 
rejecting this request? If so, why? Safari has had this behavior since forever 
and is unlikely to change in the foreseeable future, so it seems pointless to 
disallow it.

And given this difference in UA behavior, it seems useful to let web developers 
feature-detect the difference in behavior somehow.

Regards,
Maciej

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

[Anne van Kesteren]

On Tue, Oct 23, 2012 at 12:50 AM, Maciej Stachowiak  wrote:
> Based on all this, I continue to think that requesting keyboard access
> should involve separate API, so that it can be feature-detected and given
> different security treatment by vendors as desired. This is what Flash does,
> and they have the most experience dealing with the security implications of
> fullscreen on the Web.

Gecko and Chrome have indicated they do not desire this distinction.
You have indicated your desire to maybe enable keyboard access in the
future, but you do not have a thought out UI. Given this is the data
we are working with it seems unwise to change direction at this point.

The specification is modeled after Gecko and Chrome and very much
intents to have keyboard access working. As per usual, everything that
is not restricted is expected to work.

I am willing to add some wording to the security section to make the
risks of keyboard access more clear. Does anyone have some suggested
wording?


-- 
http://annevankesteren.nl/

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

[Rick Waldron]

On Monday, October 22, 2012 at 6:04 PM, Chris Pearce wrote:

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

What if applications, such as iA Writer wanted to offer a web version? Too bad, 
no keyboard for distraction-free mode?

(http://www.iawriter.com/)

Rick

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

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

[Florian Bösch]

On Tue, Oct 23, 2012 at 12:50 AM, Maciej Stachowiak  wrote:

> Based on all this, I continue to think that requesting keyboard access
> should involve separate API, so that it can be feature-detected and given
> different security treatment by vendors as desired. This is what Flash
> does, and they have the most experience dealing with the security
> implications of fullscreen on the Web.
>
I support the notion that if not all vendors can agree on the exact
behavior/restrictions that an API is required to make this transparent to
the application developer both before attempting to request fullscreen
(capability discovery) and as a parameter to request fullscreen (which will
only succeed if that capability is offered).

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

[Maciej Stachowiak]

On Oct 22, 2012, at 3:04 PM, Chris Pearce  wrote:

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

There may be phishing scenarios that work without keyboard access, but I expect 
they are *far* less common and harder to pull off. To argue from anecdote, I 
visit many sites where I identify myself with a typed password, and none where 
I exclusively have a mouse-based credential that does not involve typing 
(though I've seen sites that use it as an additional factor). I think it's not 
justified to conclude that the phishing risk with and without alphanumeric 
keyboard access is identical. They are not.

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

I think the chance of the user paying attention to a prompt that, every time 
they have seen it before, has been completely harmless, is pretty low. The odds 
of the user making an informed security decision based on what the prompt says 
is even lower.

Based on all this, I continue to think that requesting keyboard access should 
involve separate API, so that it can be feature-detected and given different 
security treatment by vendors as desired. This is what Flash does, and they 
have the most experience dealing with the security implications of fullscreen 
on the Web.

Regards,
Maciej

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

[Florian Bösch]

FYI Flickr slideshows and Google street view are now fullscreen users.

On Tue, Oct 23, 2012 at 12:04 AM, Chris Pearce  wrote:

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

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

[Chris Pearce]

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

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

[Feross Aboukhadijeh]

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  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:jo...@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 
> 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 ac

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

[Feross Aboukhadijeh]

"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  wrote:

>  If touch events are restricted, how does the user pause the video?
>
> ** **
>
> *From:* Florian Bösch [mailto:pya...@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  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 
> 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 shou

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

[Florian Bösch]

On Fri, Oct 19, 2012 at 9:08 AM, Feross Aboukhadijeh wrote:

> "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?
>
If you cannot convince Apple to go along with the "prompt when full input
required" it doesn't matter.


> 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?
>
The reason why one vendor matters in this is:

#1
$('Fullscreen').appendTo('#mycontainer').click(function(){
requestFullScreenWithInputs(); }
  a) Unknown if that button mutates to a "break my app button"
  b) In presence of possibility of a button becoming a "break my app
button" we cannot offer that button
  c) That button would have to be hidden behind an educational dialog for
the user that it is possible that after pressing the button nothing works,
and that it's not our fault.


#2 if(!$.browser.safari){ ... } or if($.browser.chrome || $.browser.firefox
|| etc.){ ... }
  a) If a vendor changes his mind against input, a button may mutate to a
"break my app" button
  b) If a vendor changes his mind for input, users won't get the feature
  c) Ties fullscreen buttons to a flawed assumption, will likely lead to
broken fullscreen apps for decades after a vendor changed his mind.

That is why it is important that we can figure that out beforehand. Since I
see zero chance to lock all vendors into one set of restrictions and UX.
And since that is so, again I re-iterate the method from a developers
perspective should be:

Step #1: Query the availability of a *capability* (not just keyboard
because vendors might not support other inputs as well)
Step #2: Decide if you can offer a fullscreen button with the capabilities
you just queried, if yes, place a fullscreen button in your app
Step #3: Upon the user pressing that button, request fullscreen with the
capability you know you can get

Again I re-iterate, keyboard is not the only concern here. You have to
consider other inputs as well since vendors might choose to restrict those
as well.
Again I re-iterate, the standard is unlikely to lock one vendor into one
set of restrictions/UX
Again I re-iterate, since that is so we need a solution that will hold up
to a shifting restrictions landscape and allow app developers to
confidently use that feature without fear if it will break their app.
Again I re-iterate, we cannot have a "break my app button" in our apps.

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

[Florian Bösch]

On Fri, Oct 19, 2012 at 4:50 AM, Carr, Wayne  wrote:

>  If touch events are restricted, how does the user pause the video?
>
If you do not disable click/touch on devices with an onscreen keyboard, how
do you defend against phishing?

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

[Carr, Wayne]

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

From: Florian Bösch [mailto:pya...@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 
mailto:pya...@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 
mailto:fer...@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 i

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

[Florian Bösch]

d
>> 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 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:jo...@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 
>>> 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
>>>
>>
>>
>

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

[Florian Bösch]

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

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

[Carr, Wayne]

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:jo...@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  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

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

[Rick Waldron]

On Wed, Oct 17, 2012 at 12:06 PM, Florian Bösch  wrote:

> On Wed, Oct 17, 2012 at 4:51 PM, Rick Waldron wrote:
>
>> I'm not sure where this falls, but how would things like control-w or
>> cmd-w work? If the non-alphanumerics work, but the alphanumerics do not...
>> will that close the window?
>>
> Far as I understood it the "keyboard disabled" refers to keyboard events
> to JS/DOM, it's not a statement about key response by the browser. There is
> a separate topic called "keyboardlock" which is intended to deal with
> things where you wouldn't want a special key interrupting your game (such
> as a windows key, ctrl+tab etc.) Though I don't know how far or favored
> that is.
>

It seems I was reading too literally—thanks for the clarification!

Rick

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

[Florian Bösch]

On Wed, Oct 17, 2012 at 4:51 PM, Rick Waldron wrote:

> I'm not sure where this falls, but how would things like control-w or
> cmd-w work? If the non-alphanumerics work, but the alphanumerics do not...
> will that close the window?
>
Far as I understood it the "keyboard disabled" refers to keyboard events to
JS/DOM, it's not a statement about key response by the browser. There is a
separate topic called "keyboardlock" which is intended to deal with things
where you wouldn't want a special key interrupting your game (such as a
windows key, ctrl+tab etc.) Though I don't know how far or favored that is.

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

[Rick Waldron]

On Tue, Oct 16, 2012 at 5:42 AM, Florian Bösch  wrote:

> On Tue, Oct 16, 2012 at 7:48 AM, Maciej Stachowiak  wrote:
>
>> What are the cases where webpage-driven (as opposed to
>> browser-chrome-driven) fullscreen is really compelling, but they need full
>> keyboard access including alphanumeric keys? (Not saying there aren't any,
>> I am just not sure what they would be - fullscreen Nethack?)
>>
> There are many games that require key input. There exist popular
> keymappings for certain genres (such FPSes) that are colloquially shortned
> to the moniker WASD. FPS games (and any other game that uses the mouse for
> view control) usually prefers WASD over cursor keys because it allows the
> arms to rest at a relaxed position, whereas using the cursor keys for the
> same either involves a painful posture or an adjustment of the keyboard
> position.
>
> Beyond the simple directional control, which give you 2 axes of freedom.
> There are games (such as descent, flight simulators, strategy games etc)
> where often a third axis might be needed. A common input scheme for these
> games is QWEASD.
>
> Beyond a simple 3-axis implementation there are categories of games (like
> RTSes or RPGs) which make heavy use of shortcuts (for instance starcraft
> and world of warcraft, nethack, etc.) because they need to deal with a
> large catalogue of actions to be performed and clicking around in menus
> would mostly be undesired by frequent players.
>
> Beyond axial control and shortcuts games do require keyboard input for
> text (such as in entering an avatar nickname, chatting etc.)
>
> Beyond axial control, shortcuts and text input there is a good reason to
> allow people to map the game action keys to whatever keys they prefer. It
> is considered bad form to assume everybody is comfortable with the same
> input scheme/locations. This problem becomes especially apparent in
> physically disabled users who often cannot use standard input schemes at
> all.
>

I'm not sure where this falls, but how would things like control-w or cmd-w
work? If the non-alphanumerics work, but the alphanumerics do not... will
that close the window?

Thanks!

Rick

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

[Jonas Sicking]

On Tue, Oct 16, 2012 at 4:48 PM, Carr, Wayne  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

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

[Carr, Wayne]

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


From: Vincent Scheib [mailto:sch...@google.com]
Sent: Tuesday, October 16, 2012 1:57 PM
To: Maciej Stachowiak
Cc: Chris Pearce; Florian Bösch; Anne van Kesteren; Carr, Wayne; 
public-webapps@w3.org
Subject: Re: Defenses against phishing via the fullscreen api (was Re: full 
screen api)

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.

I personally think it would be unfortunate to support multiple modes of 
Fullscreen. It seems to add complexity for developers and disjoint experiences 
for users. If the experience is the same for users, what is the point of having 
the API split? If it's not the same, then there is confusion over why some 
pages go fullscreen in different ways.

However, if other browsers only implement fullscreen without keyboard support 
then clearly it would be best if developers could detect this when composing 
their application interface, avoiding prompting users to enter fullscreen if it 
will not work correctly.

On Mon, Oct 15, 2012 at 10:48 PM, Maciej Stachowiak 
mailto:m...@apple.com>> wrote:

On Oct 15, 2012, at 5:01 PM, Chris Pearce 
mailto:cpea...@mozilla.com>> wrote:

> On 16/10/12 11:39, Maciej Stachowiak wrote:
>>
>> That's why I liked having a separate API to request fullscreen with full 
>> alphanumeric keyboard access. This allows apps to determine if fullscreen 
>> with keyboard is available on a given browser, and allows browsers to set 
>> separate security policies for that case.
>
> Would you implement keyboard access in fullscreen via this API if we spec'd 
> it? Or are you looking for a way to for authors to determine if key input 
> isn't supported in fullscreen mode?
Our most likely short-term goal would be the latter (enabling capability 
detection) but I wouldn't take full keyboard access off the table forever. We 
would want the freedom to apply different security policy to that case when/if 
we do it though.

>
>
>> I think the spec should change back to having two distinct APIs, even though 
>> Mozilla is not interested in making a distinction between the two cases.
>
> I'd say fullscreen video is the only fullscreen use case where page script 
> shouldn't need key events dispatched to it. I'm sure some other fullscreen 
> uses wouldn't want key events, but most non-trivial users of fullscreen would 
> want keyboard shortcuts or input.
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.

What are the cases where webpage-driven (as opposed to browser-chrome-driven) 
fullscreen is really compelling, but they need full keyboard access including 
alphanumeric keys? (Not saying there aren't any, I am just not sure what they 
would be - fullscreen Nethack?)

>
> Anyway, I'm curious what the Chrome guys think.
Likewise.


Cheers,
Maciej

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

[Florian Bösch]

On Tue, Oct 16, 2012 at 10:56 PM, Vincent Scheib  wrote:

> However, if other browsers only implement fullscreen without keyboard
> support then clearly it would be best if developers could detect this when
> composing their application interface, avoiding prompting users to enter
> fullscreen if it will not work correctly.
>
It is absolutely mandatory that if entering fullscreen will disable random
capabilities (such as the keyboard) that developers can query that. The
reason as you've mentioned is that if you enter fullscreen and things stop
working, that is not an acceptable situation. Users will think the
application has a bug and close the sites tab.

In the presence of an unknown working state after entering fullscreen,
developers could never place a button to allow entering fullscreen.
Developers would have to hide the option to enter fullscreen behind a
dialog educating users that they can enter fullscreen, but if things stop
working it is not the fault of the application offering that button, but of
the browser vendor, and that instead of closing a tab of a bugged
application, they should try it without fullscreen and pretty please don't
blame the developer for making a buggy app. I consider that bad UX btw.

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

[Vincent Scheib]

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.

I personally think it would be unfortunate to support multiple modes of
Fullscreen. It seems to add complexity for developers and disjoint
experiences for users. If the experience is the same for users, what is the
point of having the API split? If it's not the same, then there is
confusion over why some pages go fullscreen in different ways.

However, if other browsers only implement fullscreen without keyboard
support then clearly it would be best if developers could detect this when
composing their application interface, avoiding prompting users to enter
fullscreen if it will not work correctly.

On Mon, Oct 15, 2012 at 10:48 PM, Maciej Stachowiak  wrote:

>
> On Oct 15, 2012, at 5:01 PM, Chris Pearce  wrote:
>
> > On 16/10/12 11:39, Maciej Stachowiak wrote:
> >>
> >> That's why I liked having a separate API to request fullscreen with
> full alphanumeric keyboard access. This allows apps to determine if
> fullscreen with keyboard is available on a given browser, and allows
> browsers to set separate security policies for that case.
> >
> > Would you implement keyboard access in fullscreen via this API if we
> spec'd it? Or are you looking for a way to for authors to determine if key
> input isn't supported in fullscreen mode?
>
> Our most likely short-term goal would be the latter (enabling capability
> detection) but I wouldn't take full keyboard access off the table forever.
> We would want the freedom to apply different security policy to that case
> when/if we do it though.
>
> >
> >
> >> I think the spec should change back to having two distinct APIs, even
> though Mozilla is not interested in making a distinction between the two
> cases.
> >
> > I'd say fullscreen video is the only fullscreen use case where page
> script shouldn't need key events dispatched to it. I'm sure some other
> fullscreen uses wouldn't want key events, but most non-trivial users of
> fullscreen would want keyboard shortcuts or input.
>
> 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.
>
> What are the cases where webpage-driven (as opposed to
> browser-chrome-driven) fullscreen is really compelling, but they need full
> keyboard access including alphanumeric keys? (Not saying there aren't any,
> I am just not sure what they would be - fullscreen Nethack?)
>
> >
> > Anyway, I'm curious what the Chrome guys think.
>
> Likewise.
>
>
> Cheers,
> Maciej
>
>
>

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

[Florian Bösch]

On Tue, Oct 16, 2012 at 7:48 AM, Maciej Stachowiak  wrote:

> What are the cases where webpage-driven (as opposed to
> browser-chrome-driven) fullscreen is really compelling, but they need full
> keyboard access including alphanumeric keys? (Not saying there aren't any,
> I am just not sure what they would be - fullscreen Nethack?)
>
There are many games that require key input. There exist popular
keymappings for certain genres (such FPSes) that are colloquially shortned
to the moniker WASD. FPS games (and any other game that uses the mouse for
view control) usually prefers WASD over cursor keys because it allows the
arms to rest at a relaxed position, whereas using the cursor keys for the
same either involves a painful posture or an adjustment of the keyboard
position.

Beyond the simple directional control, which give you 2 axes of freedom.
There are games (such as descent, flight simulators, strategy games etc)
where often a third axis might be needed. A common input scheme for these
games is QWEASD.

Beyond a simple 3-axis implementation there are categories of games (like
RTSes or RPGs) which make heavy use of shortcuts (for instance starcraft
and world of warcraft, nethack, etc.) because they need to deal with a
large catalogue of actions to be performed and clicking around in menus
would mostly be undesired by frequent players.

Beyond axial control and shortcuts games do require keyboard input for text
(such as in entering an avatar nickname, chatting etc.)

Beyond axial control, shortcuts and text input there is a good reason to
allow people to map the game action keys to whatever keys they prefer. It
is considered bad form to assume everybody is comfortable with the same
input scheme/locations. This problem becomes especially apparent in
physically disabled users who often cannot use standard input schemes at
all.

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

[Maciej Stachowiak]

On Oct 15, 2012, at 5:01 PM, Chris Pearce  wrote:

> On 16/10/12 11:39, Maciej Stachowiak wrote:
>> 
>> That's why I liked having a separate API to request fullscreen with full 
>> alphanumeric keyboard access. This allows apps to determine if fullscreen 
>> with keyboard is available on a given browser, and allows browsers to set 
>> separate security policies for that case.
> 
> Would you implement keyboard access in fullscreen via this API if we spec'd 
> it? Or are you looking for a way to for authors to determine if key input 
> isn't supported in fullscreen mode?

Our most likely short-term goal would be the latter (enabling capability 
detection) but I wouldn't take full keyboard access off the table forever. We 
would want the freedom to apply different security policy to that case when/if 
we do it though. 

> 
> 
>> I think the spec should change back to having two distinct APIs, even though 
>> Mozilla is not interested in making a distinction between the two cases.
> 
> I'd say fullscreen video is the only fullscreen use case where page script 
> shouldn't need key events dispatched to it. I'm sure some other fullscreen 
> uses wouldn't want key events, but most non-trivial users of fullscreen would 
> want keyboard shortcuts or input.

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.

What are the cases where webpage-driven (as opposed to browser-chrome-driven) 
fullscreen is really compelling, but they need full keyboard access including 
alphanumeric keys? (Not saying there aren't any, I am just not sure what they 
would be - fullscreen Nethack?)

> 
> Anyway, I'm curious what the Chrome guys think.

Likewise.


Cheers,
Maciej

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

[Chris Pearce]

On 16/10/12 11:39, Maciej Stachowiak wrote:


That's why I liked having a separate API to request fullscreen with 
full alphanumeric keyboard access. This allows apps to determine if 
fullscreen with keyboard is available on a given browser, and allows 
browsers to set separate security policies for that case.


Would you implement keyboard access in fullscreen via this API if we 
spec'd it? Or are you looking for a way to for authors to determine if 
key input isn't supported in fullscreen mode?



I think the spec should change back to having two distinct APIs, even 
though Mozilla is not interested in making a distinction between the 
two cases.


I'd say fullscreen video is the only fullscreen use case where page 
script shouldn't need key events dispatched to it. I'm sure some other 
fullscreen uses wouldn't want key events, but most non-trivial users of 
fullscreen would want keyboard shortcuts or input.


Anyway, I'm curious what the Chrome guys think.

Chrome's requestFullscreen implementation takes a parameter/flag 
Element.ALLOW_KEYBOARD_INPUT to denote whether key input should be 
allowed. I thought they ignored that and just always allowed key input 
fullscreen, but I see now that they do honour it.



Regards,
Chris P.





Regards,
Maciej

On Oct 15, 2012, at 3:45 AM, Florian Bösch > wrote:


Ok, so here's my question. You have a webapp (that oh, happens to be 
a game, or a slideshow app, or a video player with controls, etc.) 
which needs keyboard/UI events access to work (come to think of it, 
can you honestly think of any sort of usecase that does work entirely 
without user intercation?). Anyways, so now this app needs to figure 
out if it's worth the bother to even display a fullscreen 
icon/request fullscren (see, after all, there woulnd't be a point if 
there's no keyboard/UI access).


So how does an app do that? How do we figure out what the random 
behavior changes are that vendors add, that would break our app, that 
make it pointless to try to use the API on that vendors browser? Anyone?


On Mon, Oct 15, 2012 at 12:32 PM, Maciej Stachowiak > wrote:



On Oct 14, 2012, at 3:54 PM, Chris Pearce mailto:cpea...@mozilla.com>> wrote:

> On 14/10/12 00:49, Maciej Stachowiak wrote:
>>
>> Despite both of these defenses having drawbacks, I think it is
wise for implementations to implement at least one of them. I
think the spec should explicitly permit implementations to apply
either or both of these limitations, and should discuss their
pros and cons in the Security Considerations section.
>
>
> I don't support making these mandatory, but they should
certainly be added to the Security Considerations section; we
considered them, and we may indeed re-consider them in future if
it proves necessary.
>
> I support making the spec general enough that implementors can
chose their security features based on their requirements; what's
appropriate for a desktop browser may not be appropriate for a
tablet, for example.

I agree with both of these comments (in case it wasn't clear). I
suggest that these mechanisms should be permitted, not mandatory.
Right now it is not entirely clear if either is permitted per spec.

Regards,
Maciej

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

[Florian Bösch]

A function to query the capabilities obtainable after entering fullscreen
would also work from an application developers point of view:

navigator.fullscreenCapability.keyboard -> true/false
navigator.fullscreenCapability.mouse -> true/false
navigator.fullscreenCapability.ui -> true/false
navigator.fullscreenCapability.pointerlock -> true/false
navigator.fullscreenCapability.keyboardlock -> true/false
navigator.fullscreenCapability.gamepads -> true/false
navigator.fullscreenCapability.touch -> true/false
navigator.fullscreenCapability.penTablet -> true/false
etc.

So app developers will know not to show a fullscreen button when they know
that a user pressing that button would break their app.

On Tue, Oct 16, 2012 at 12:39 AM, Maciej Stachowiak  wrote:

>
> That's why I liked having a separate API to request fullscreen with full
> alphanumeric keyboard access. This allows apps to determine if fullscreen
> with keyboard is available on a given browser, and allows browsers to set
> separate security policies for that case. I think the spec should change
> back to having two distinct APIs, even though Mozilla is not interested in
> making a distinction between the two cases.
>
> Regards,
> Maciej
>
> On Oct 15, 2012, at 3:45 AM, Florian Bösch  wrote:
>
> Ok, so here's my question. You have a webapp (that oh, happens to be a
> game, or a slideshow app, or a video player with controls, etc.) which
> needs keyboard/UI events access to work (come to think of it, can you
> honestly think of any sort of usecase that does work entirely without user
> intercation?). Anyways, so now this app needs to figure out if it's worth
> the bother to even display a fullscreen icon/request fullscren (see, after
> all, there woulnd't be a point if there's no keyboard/UI access).
>
> So how does an app do that? How do we figure out what the random behavior
> changes are that vendors add, that would break our app, that make it
> pointless to try to use the API on that vendors browser? Anyone?
>
> On Mon, Oct 15, 2012 at 12:32 PM, Maciej Stachowiak  wrote:
>
>>
>> On Oct 14, 2012, at 3:54 PM, Chris Pearce  wrote:
>>
>> > On 14/10/12 00:49, Maciej Stachowiak wrote:
>> >>
>> >> Despite both of these defenses having drawbacks, I think it is wise
>> for implementations to implement at least one of them. I think the spec
>> should explicitly permit implementations to apply either or both of these
>> limitations, and should discuss their pros and cons in the Security
>> Considerations section.
>> >
>> >
>> > I don't support making these mandatory, but they should certainly be
>> added to the Security Considerations section; we considered them, and we
>> may indeed re-consider them in future if it proves necessary.
>> >
>> > I support making the spec general enough that implementors can chose
>> their security features based on their requirements; what's appropriate for
>> a desktop browser may not be appropriate for a tablet, for example.
>>
>> I agree with both of these comments (in case it wasn't clear). I suggest
>> that these mechanisms should be permitted, not mandatory. Right now it is
>> not entirely clear if either is permitted per spec.
>>
>> Regards,
>> Maciej
>>
>>
>
>

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

[Maciej Stachowiak]

That's why I liked having a separate API to request fullscreen with full 
alphanumeric keyboard access. This allows apps to determine if fullscreen with 
keyboard is available on a given browser, and allows browsers to set separate 
security policies for that case. I think the spec should change back to having 
two distinct APIs, even though Mozilla is not interested in making a 
distinction between the two cases.

Regards,
Maciej

On Oct 15, 2012, at 3:45 AM, Florian Bösch  wrote:

> Ok, so here's my question. You have a webapp (that oh, happens to be a game, 
> or a slideshow app, or a video player with controls, etc.) which needs 
> keyboard/UI events access to work (come to think of it, can you honestly 
> think of any sort of usecase that does work entirely without user 
> intercation?). Anyways, so now this app needs to figure out if it's worth the 
> bother to even display a fullscreen icon/request fullscren (see, after all, 
> there woulnd't be a point if there's no keyboard/UI access).
> 
> So how does an app do that? How do we figure out what the random behavior 
> changes are that vendors add, that would break our app, that make it 
> pointless to try to use the API on that vendors browser? Anyone?
> 
> On Mon, Oct 15, 2012 at 12:32 PM, Maciej Stachowiak  wrote:
> 
> On Oct 14, 2012, at 3:54 PM, Chris Pearce  wrote:
> 
> > On 14/10/12 00:49, Maciej Stachowiak wrote:
> >>
> >> Despite both of these defenses having drawbacks, I think it is wise for 
> >> implementations to implement at least one of them. I think the spec should 
> >> explicitly permit implementations to apply either or both of these 
> >> limitations, and should discuss their pros and cons in the Security 
> >> Considerations section.
> >
> >
> > I don't support making these mandatory, but they should certainly be added 
> > to the Security Considerations section; we considered them, and we may 
> > indeed re-consider them in future if it proves necessary.
> >
> > I support making the spec general enough that implementors can chose their 
> > security features based on their requirements; what's appropriate for a 
> > desktop browser may not be appropriate for a tablet, for example.
> 
> I agree with both of these comments (in case it wasn't clear). I suggest that 
> these mechanisms should be permitted, not mandatory. Right now it is not 
> entirely clear if either is permitted per spec.
> 
> Regards,
> Maciej
> 
> 

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

[Florian Bösch]

Ok, so here's my question. You have a webapp (that oh, happens to be a
game, or a slideshow app, or a video player with controls, etc.) which
needs keyboard/UI events access to work (come to think of it, can you
honestly think of any sort of usecase that does work entirely without user
intercation?). Anyways, so now this app needs to figure out if it's worth
the bother to even display a fullscreen icon/request fullscren (see, after
all, there woulnd't be a point if there's no keyboard/UI access).

So how does an app do that? How do we figure out what the random behavior
changes are that vendors add, that would break our app, that make it
pointless to try to use the API on that vendors browser? Anyone?

On Mon, Oct 15, 2012 at 12:32 PM, Maciej Stachowiak  wrote:

>
> On Oct 14, 2012, at 3:54 PM, Chris Pearce  wrote:
>
> > On 14/10/12 00:49, Maciej Stachowiak wrote:
> >>
> >> Despite both of these defenses having drawbacks, I think it is wise for
> implementations to implement at least one of them. I think the spec should
> explicitly permit implementations to apply either or both of these
> limitations, and should discuss their pros and cons in the Security
> Considerations section.
> >
> >
> > I don't support making these mandatory, but they should certainly be
> added to the Security Considerations section; we considered them, and we
> may indeed re-consider them in future if it proves necessary.
> >
> > I support making the spec general enough that implementors can chose
> their security features based on their requirements; what's appropriate for
> a desktop browser may not be appropriate for a tablet, for example.
>
> I agree with both of these comments (in case it wasn't clear). I suggest
> that these mechanisms should be permitted, not mandatory. Right now it is
> not entirely clear if either is permitted per spec.
>
> Regards,
> Maciej
>
>

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

[Maciej Stachowiak]

On Oct 14, 2012, at 3:54 PM, Chris Pearce  wrote:

> On 14/10/12 00:49, Maciej Stachowiak wrote:
>> 
>> Despite both of these defenses having drawbacks, I think it is wise for 
>> implementations to implement at least one of them. I think the spec should 
>> explicitly permit implementations to apply either or both of these 
>> limitations, and should discuss their pros and cons in the Security 
>> Considerations section.
> 
> 
> I don't support making these mandatory, but they should certainly be added to 
> the Security Considerations section; we considered them, and we may indeed 
> re-consider them in future if it proves necessary.
> 
> I support making the spec general enough that implementors can chose their 
> security features based on their requirements; what's appropriate for a 
> desktop browser may not be appropriate for a tablet, for example.

I agree with both of these comments (in case it wasn't clear). I suggest that 
these mechanisms should be permitted, not mandatory. Right now it is not 
entirely clear if either is permitted per spec.

Regards,
Maciej

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

[Florian Bösch]

On Mon, Oct 15, 2012 at 12:54 AM, Chris Pearce  wrote:

> I support making the spec general enough that implementors can chose their
> security features based on their requirements; what's appropriate for a
> desktop browser may not be appropriate for a tablet, for example.
>
An implementation, all implementations, should adhere to guaranteed modes
of behavior. Supporting a zoo of varying behaviors for the same
API/specification which cover the entire range from entirely unusable to
well usable makes supporting a given API really difficult for application
developers.

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

[Chris Pearce]

On 14/10/12 00:49, Maciej Stachowiak wrote:

On Oct 13, 2012, at 1:49 AM, Anne van Kesteren  wrote:


On Fri, Oct 12, 2012 at 8:25 PM, Florian Bösch  wrote:

There was a limited discussion on that a few days ago with the limited
consensus (?) being that requiring user-consent up front before switching to
fullscreen is desired, should be in the standard and isn't sacrificing UX.

There was no implementor involved in that discussion. I want to see
their feedback before changing the standard.

Also, FYI, http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
is not maintained, http://fullscreen.spec.whatwg.org/ is.

I think it's unlikely that Apple would implement a requirement of prior user 
consent before entering fullscreen.

I also personally think OK/Cancel security nag dialogs are a very poor security mechanism 
in general. Users do not read them, and placing them in the path of operations that are 
harmless the vast majority of the time only has the effect of training users to click ok 
on dialogs. "Cancel or allow" dialogs are nearly useless for real security and 
seem mainly to provide CYA security - if a user gets hacked, you can tell them they were 
bad for clicking OK on the dialog.

Now, there are some limited cases where a permissions dialog may make sense. 
Specifically, these are cases where the user can reasonably be expected to 
relate the risk to the functionality requested. For example, when a site asks 
for your geolocation, a user can generally understand that there may be privacy 
implications to having a location tracked. But this does not really apply to 
fullscreen. A user is not likely to understand the security implications of 
fullscreen. So they won't be able to make a reasoned risk assessment based on a 
warning dialog. This situation is much like bad certificate warnings, where the 
evidence indicates that users almost always click through, even relatively 
informed users.


I think the most effective defense against phishing via fullscreen is to 
prevent keyboard access. The original design for requestFullscreen had an 
optional argument for requesting keyboard access, which led to a warning in 
some browsers and which for Safari we chose to ignore as the risk outweighed 
the benefit. The new spec does not have this parameter and makes no mention of 
keyboard access. It is not even clear if refusing to send key events or grant 
keyboard focus in fullscreen would be conforming. I think this should be fixed. 
I think the spec should at minimum explicitly allow browsers to block delivery 
of key events (or at least key events for alphanumeric keys). Regrettably, this 
defense would not be very effective on pure touchscreen devices, since there is 
no physical keyboard and the soft keyboard can likely be convincingly faked 
with HTML.




We want keyboard access for games, and I think that a 
nag-on-keyboard-input would have to be intrusive to be effective, which 
makes using the fullscreen API unpalatable for games.


I think having two separate fullscreen modes, one with keyboard access 
and one without doesn't make sense, because (I think) authors will 
mostly use the withKeys version anyway, since most authors will want 
keyboard shortcuts in their web pages' fullscreen features.


I also think it would be confusing to users to have two separate 
permission/approval prompts as well, one for withKeys and one for 
withoutKeys.


You could ditch the approval prompt for fullscreenWithoutKeys, but some 
websites require their users to use an onscreen number pad to enter a 
pin number (via mouse clicks) in order to login (in order to guard 
against keyloggers...), and such sites can be spoofed in the withoutKeys 
version - and touch devices like tablets are vulnerable to having their 
keyboards spoofed.


So we opted to make our fullscreen approval UI obvious and modal.


The second most effective defense that I can think of is a distinctive visible 
indicator that prevents convincingly faking the system UI. The common 
notification to press escape to exit partly serves that purpose. A potentially 
more effective version would be to show a noticeable visible indicator every 
time the user moves the mouse, presses a key, or registers a tap on a 
touchscreen. Ideally this would cover key areas needed to fake a real browser 
UI such as where the toolbar and address bar would go, and would indicate what 
site is showing the fullscreen UI. However, while such an effect is reasonable 
for fullscreen video (where the user will mostly watch without interacting), it 
might be distracting for fullscreen games, or the fullscreen mode of a 
presentation program, or a fullscreen editor.

Despite both of these defenses having drawbacks, I think it is wise for 
implementations to implement at least one of them. I think the spec should 
explicitly permit implementations to apply either or both of these limitations, 
and should discuss their pros and cons in the Security Considerations section

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

[Florian Bösch]

WebGL FPSes with fullscreen support
- http://media.tojicode.com/q3bsp/
- https://developer.mozilla.org/en-US/demos/detail/bananabread
- http://dl.dropbox.com/u/6873971/data/cube2/index.html

On Sat, Oct 13, 2012 at 9:58 PM, Florian Bösch  wrote:

> You're making fullscreen useless for games.
>
>
> On Sat, Oct 13, 2012 at 9:56 PM, Maciej Stachowiak  wrote:
>
>>
>> On Oct 13, 2012, at 4:58 AM, Florian Bösch  wrote:
>>
>> On Sat, Oct 13, 2012 at 1:49 PM, Maciej Stachowiak  wrote:
>>
>>> I think the most effective defense against phishing via fullscreen is to
>>> prevent keyboard access. The original design for requestFullscreen had an
>>> optional argument for requesting keyboard access, which led to a warning in
>>> some browsers and which for Safari we chose to ignore as the risk
>>> outweighed the benefit. The new spec does not have this parameter and makes
>>> no mention of keyboard access. It is not even clear if refusing to send key
>>> events or grant keyboard focus in fullscreen would be conforming. I think
>>> this should be fixed. I think the spec should at minimum explicitly allow
>>> browsers to block delivery of key events (or at least key events for
>>> alphanumeric keys). Regrettably, this defense would not be very effective
>>> on pure touchscreen devices, since there is no physical keyboard and the
>>> soft keyboard can likely be convincingly faked with HTML.
>>>
>> I've got no objection against a user poll for things like keyboard
>> interactions in fullscreen as long as the implemention honors the intent to
>> show this once for a session or remembered state and not all the time when
>> going back and forth.
>>
>>
>> Our current intended behavior in Safari is to never allow alphanumeric
>> keyboard access in fullscreen. No cancel/allow prompt. Did you read the
>> part where I explained why such prompts are useless for security?
>>
>>
>>
>>> The second most effective defense that I can think of is a distinctive
>>> visible indicator that prevents convincingly faking the system UI. The
>>> common notification to press escape to exit partly serves that purpose. A
>>> potentially more effective version would be to show a noticeable visible
>>> indicator every time the user moves the mouse, presses a key, or registers
>>> a tap on a touchscreen. Ideally this would cover key areas needed to fake a
>>> real browser UI such as where the toolbar and address bar would go, and
>>> would indicate what site is showing the fullscreen UI. However, while such
>>> an effect is reasonable for fullscreen video (where the user will mostly
>>> watch without interacting), it might be distracting for fullscreen games,
>>> or the fullscreen mode of a presentation program, or a fullscreen editor
>>>
>> Such a scheme would render fullscreen virtually useless for most of its
>> intended purpose.
>>
>>
>> That depends on what you think "most of its intended purpose" is. Many
>> native video fullscreen implementations already have behavior somewhat like
>> this, because they expect that the user is not producing UI events most of
>> the time while watching the video. It may be annoying in the context of a
>> game or slideshow. So far I have encountered such uses much less often than
>> video.
>>
>> Regards,
>> Maciej
>>
>>
>

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

[Florian Bösch]

You're making fullscreen useless for games.

On Sat, Oct 13, 2012 at 9:56 PM, Maciej Stachowiak  wrote:

>
> On Oct 13, 2012, at 4:58 AM, Florian Bösch  wrote:
>
> On Sat, Oct 13, 2012 at 1:49 PM, Maciej Stachowiak  wrote:
>
>> I think the most effective defense against phishing via fullscreen is to
>> prevent keyboard access. The original design for requestFullscreen had an
>> optional argument for requesting keyboard access, which led to a warning in
>> some browsers and which for Safari we chose to ignore as the risk
>> outweighed the benefit. The new spec does not have this parameter and makes
>> no mention of keyboard access. It is not even clear if refusing to send key
>> events or grant keyboard focus in fullscreen would be conforming. I think
>> this should be fixed. I think the spec should at minimum explicitly allow
>> browsers to block delivery of key events (or at least key events for
>> alphanumeric keys). Regrettably, this defense would not be very effective
>> on pure touchscreen devices, since there is no physical keyboard and the
>> soft keyboard can likely be convincingly faked with HTML.
>>
> I've got no objection against a user poll for things like keyboard
> interactions in fullscreen as long as the implemention honors the intent to
> show this once for a session or remembered state and not all the time when
> going back and forth.
>
>
> Our current intended behavior in Safari is to never allow alphanumeric
> keyboard access in fullscreen. No cancel/allow prompt. Did you read the
> part where I explained why such prompts are useless for security?
>
>
>
>> The second most effective defense that I can think of is a distinctive
>> visible indicator that prevents convincingly faking the system UI. The
>> common notification to press escape to exit partly serves that purpose. A
>> potentially more effective version would be to show a noticeable visible
>> indicator every time the user moves the mouse, presses a key, or registers
>> a tap on a touchscreen. Ideally this would cover key areas needed to fake a
>> real browser UI such as where the toolbar and address bar would go, and
>> would indicate what site is showing the fullscreen UI. However, while such
>> an effect is reasonable for fullscreen video (where the user will mostly
>> watch without interacting), it might be distracting for fullscreen games,
>> or the fullscreen mode of a presentation program, or a fullscreen editor
>>
> Such a scheme would render fullscreen virtually useless for most of its
> intended purpose.
>
>
> That depends on what you think "most of its intended purpose" is. Many
> native video fullscreen implementations already have behavior somewhat like
> this, because they expect that the user is not producing UI events most of
> the time while watching the video. It may be annoying in the context of a
> game or slideshow. So far I have encountered such uses much less often than
> video.
>
> Regards,
> Maciej
>
>

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

[Maciej Stachowiak]

On Oct 13, 2012, at 4:58 AM, Florian Bösch  wrote:

> On Sat, Oct 13, 2012 at 1:49 PM, Maciej Stachowiak  wrote:
> I think the most effective defense against phishing via fullscreen is to 
> prevent keyboard access. The original design for requestFullscreen had an 
> optional argument for requesting keyboard access, which led to a warning in 
> some browsers and which for Safari we chose to ignore as the risk outweighed 
> the benefit. The new spec does not have this parameter and makes no mention 
> of keyboard access. It is not even clear if refusing to send key events or 
> grant keyboard focus in fullscreen would be conforming. I think this should 
> be fixed. I think the spec should at minimum explicitly allow browsers to 
> block delivery of key events (or at least key events for alphanumeric keys). 
> Regrettably, this defense would not be very effective on pure touchscreen 
> devices, since there is no physical keyboard and the soft keyboard can likely 
> be convincingly faked with HTML.
> I've got no objection against a user poll for things like keyboard 
> interactions in fullscreen as long as the implemention honors the intent to 
> show this once for a session or remembered state and not all the time when 
> going back and forth.

Our current intended behavior in Safari is to never allow alphanumeric keyboard 
access in fullscreen. No cancel/allow prompt. Did you read the part where I 
explained why such prompts are useless for security?

>  
> The second most effective defense that I can think of is a distinctive 
> visible indicator that prevents convincingly faking the system UI. The common 
> notification to press escape to exit partly serves that purpose. A 
> potentially more effective version would be to show a noticeable visible 
> indicator every time the user moves the mouse, presses a key, or registers a 
> tap on a touchscreen. Ideally this would cover key areas needed to fake a 
> real browser UI such as where the toolbar and address bar would go, and would 
> indicate what site is showing the fullscreen UI. However, while such an 
> effect is reasonable for fullscreen video (where the user will mostly watch 
> without interacting), it might be distracting for fullscreen games, or the 
> fullscreen mode of a presentation program, or a fullscreen editor
> Such a scheme would render fullscreen virtually useless for most of its 
> intended purpose. 

That depends on what you think "most of its intended purpose" is. Many native 
video fullscreen implementations already have behavior somewhat like this, 
because they expect that the user is not producing UI events most of the time 
while watching the video. It may be annoying in the context of a game or 
slideshow. So far I have encountered such uses much less often than video.

Regards,
Maciej

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

[Florian Bösch]

On Sat, Oct 13, 2012 at 1:49 PM, Maciej Stachowiak  wrote:

> I think the most effective defense against phishing via fullscreen is to
> prevent keyboard access. The original design for requestFullscreen had an
> optional argument for requesting keyboard access, which led to a warning in
> some browsers and which for Safari we chose to ignore as the risk
> outweighed the benefit. The new spec does not have this parameter and makes
> no mention of keyboard access. It is not even clear if refusing to send key
> events or grant keyboard focus in fullscreen would be conforming. I think
> this should be fixed. I think the spec should at minimum explicitly allow
> browsers to block delivery of key events (or at least key events for
> alphanumeric keys). Regrettably, this defense would not be very effective
> on pure touchscreen devices, since there is no physical keyboard and the
> soft keyboard can likely be convincingly faked with HTML.
>
I've got no objection against a user poll for things like keyboard
interactions in fullscreen as long as the implemention honors the intent to
show this once for a session or remembered state and not all the time when
going back and forth.


> The second most effective defense that I can think of is a distinctive
> visible indicator that prevents convincingly faking the system UI. The
> common notification to press escape to exit partly serves that purpose. A
> potentially more effective version would be to show a noticeable visible
> indicator every time the user moves the mouse, presses a key, or registers
> a tap on a touchscreen. Ideally this would cover key areas needed to fake a
> real browser UI such as where the toolbar and address bar would go, and
> would indicate what site is showing the fullscreen UI. However, while such
> an effect is reasonable for fullscreen video (where the user will mostly
> watch without interacting), it might be distracting for fullscreen games,
> or the fullscreen mode of a presentation program, or a fullscreen editor
>
Such a scheme would render fullscreen virtually useless for most of its
intended purpose.

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

[Maciej Stachowiak]

On Oct 13, 2012, at 1:49 AM, Anne van Kesteren  wrote:

> On Fri, Oct 12, 2012 at 8:25 PM, Florian Bösch  wrote:
>> There was a limited discussion on that a few days ago with the limited
>> consensus (?) being that requiring user-consent up front before switching to
>> fullscreen is desired, should be in the standard and isn't sacrificing UX.
> 
> There was no implementor involved in that discussion. I want to see
> their feedback before changing the standard.
> 
> Also, FYI, http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html
> is not maintained, http://fullscreen.spec.whatwg.org/ is.

I think it's unlikely that Apple would implement a requirement of prior user 
consent before entering fullscreen.

I also personally think OK/Cancel security nag dialogs are a very poor security 
mechanism in general. Users do not read them, and placing them in the path of 
operations that are harmless the vast majority of the time only has the effect 
of training users to click ok on dialogs. "Cancel or allow" dialogs are nearly 
useless for real security and seem mainly to provide CYA security - if a user 
gets hacked, you can tell them they were bad for clicking OK on the dialog.

Now, there are some limited cases where a permissions dialog may make sense. 
Specifically, these are cases where the user can reasonably be expected to 
relate the risk to the functionality requested. For example, when a site asks 
for your geolocation, a user can generally understand that there may be privacy 
implications to having a location tracked. But this does not really apply to 
fullscreen. A user is not likely to understand the security implications of 
fullscreen. So they won't be able to make a reasoned risk assessment based on a 
warning dialog. This situation is much like bad certificate warnings, where the 
evidence indicates that users almost always click through, even relatively 
informed users.


I think the most effective defense against phishing via fullscreen is to 
prevent keyboard access. The original design for requestFullscreen had an 
optional argument for requesting keyboard access, which led to a warning in 
some browsers and which for Safari we chose to ignore as the risk outweighed 
the benefit. The new spec does not have this parameter and makes no mention of 
keyboard access. It is not even clear if refusing to send key events or grant 
keyboard focus in fullscreen would be conforming. I think this should be fixed. 
I think the spec should at minimum explicitly allow browsers to block delivery 
of key events (or at least key events for alphanumeric keys). Regrettably, this 
defense would not be very effective on pure touchscreen devices, since there is 
no physical keyboard and the soft keyboard can likely be convincingly faked 
with HTML.

The second most effective defense that I can think of is a distinctive visible 
indicator that prevents convincingly faking the system UI. The common 
notification to press escape to exit partly serves that purpose. A potentially 
more effective version would be to show a noticeable visible indicator every 
time the user moves the mouse, presses a key, or registers a tap on a 
touchscreen. Ideally this would cover key areas needed to fake a real browser 
UI such as where the toolbar and address bar would go, and would indicate what 
site is showing the fullscreen UI. However, while such an effect is reasonable 
for fullscreen video (where the user will mostly watch without interacting), it 
might be distracting for fullscreen games, or the fullscreen mode of a 
presentation program, or a fullscreen editor.

Despite both of these defenses having drawbacks, I think it is wise for 
implementations to implement at least one of them. I think the spec should 
explicitly permit implementations to apply either or both of these limitations, 
and should discuss their pros and cons in the Security Considerations section.

Regards,
Maciej