Re: Defenses against phishing via the fullscreen api (was Re: full screen api)
On Thu, Dec 20, 2012 at 8:08 AM, Maciej Stachowiak m...@apple.com wrote: On Dec 18, 2012, at 6:44 AM, Anne van Kesteren ann...@annevk.nl 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)
On Dec 18, 2012, at 6:44 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Oct 23, 2012 at 12:50 AM, Maciej Stachowiak m...@apple.com 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)
On Thu, Dec 20, 2012 at 8:08 AM, Maciej Stachowiak m...@apple.com 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)
On Tue, Oct 23, 2012 at 12:50 AM, Maciej Stachowiak m...@apple.com 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)
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)
FYI Flickr slideshows and Google street view are now fullscreen users.
On Tue, Oct 23, 2012 at 12:04 AM, Chris Pearce cpea...@mozilla.com 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)
On Oct 22, 2012, at 3:04 PM, Chris Pearce cpea...@mozilla.com 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)
On Tue, Oct 23, 2012 at 12:50 AM, Maciej Stachowiak m...@apple.com 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)
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)
I wrote the attack demo that prompted this discussion. Here are my thoughts on how to improve the spec and/or the implementations in browsers: requestFullscreen() should trigger fullscreen mode with limited keyboard input allowed (only space, arrow keys, and perhaps some modifier keys like CTRL, ALT, etc.). The browser should display a notification that the user is in fullscreen mode, although it can fade away after some time since the risk of phishing is significantly reduced when keyboard input is limited (note that Safari currently sees fit to show NO notification at all about fullscreen mode because keyboard is limited). This level of functionality will support 90% of current fullscreen use cases like video players, slideshow viewers, and games with simple input requirements. However, the spec should also support an optional ALLOW_KEYBOARD_INPUT parameter to requestFullscreen() which, when passed, triggers fullscreen mode with full keyboard support (except for ESC to exit fullscreen). When this parameter is passed, the browser should show a prominent modal dialog on top of the page content, requesting permission to use fullscreen mode. No keyboard or mouse input should be allowed until the user clicks Allow. This level of functionality will support the remaining fullscreen use cases, namely games which require more complex keyboard interactions. Most developers who use the fullscreen API will not need to pass the ALLOW_KEYBOARD_INPUT parameter, so most of the common use cases (YouTube, slideshows, etc.) will be frictionless for the user since a phishing attack is extremely unlikely. The advantages of this approach are: - The 90% of users who use fullscreen mode on YouTube and other video sites continue to use the fullscreen API as they always have. No modal prompt. No UI in the way of the video. It just works. - Browser games are free to continue to innovate. We aren't needlessly crippling fullscreen mode and crushing this innovation. - Developers can assume that fullscreen will always fully work (without arbitrary restrictions), simplifying development and preventing some apps from being browser-specific (splintering the web). Possible disadvantages are: - The API is now slightly more complex (but a single optional parameter hardly complex imo) - Users may wonder why 90% of sites (YouTube, slideshow sites, etc.) can enter fullscreen mode without a prompt, but some sites require them to explicitly Allow fullscreen in order for it to work. Currently, Flash Player 11.3 and later uses a similar approach to the one I've outlined here and it appears to be simple for developers to use as well as successfully mitigating the risk of phishing for users. Flash has two fullscreen modes: normal and interactive. Normal mode disallows keyboard input and shows minimal UI (it just shows Press ESC to exit fullscreen mode for a few seconds). Interactive mode disallows keyboard input completely until the user expressly allows it. You can check out an example of interactive mode here: http://leebrimelow.com/flash/fullkeys/ For an example of normal mode just go to YouTube and fullscreen any video. This solution is really elegant, imo. Thoughts on this approach? Feross On Wed, Oct 17, 2012 at 10:07 AM, Carr, Wayne wayne.c...@intel.com wrote: Requiring that the user approve before a full screen UI is active to prevent mimicking a bank site in a browser isn't dictating what the UI looks like. And it can be detectable to the web page - it can be the full screen notification doesn't happen until after the user has approved it. There are different approaches today, but none of them prevent the user from interacting with the full screen app before they've approved it going full screen. -Original Message- From: Jonas Sicking [mailto: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 wayne.c...@intel.com wrote: Chrome supports Fullscreen with keyboard enabled. We use a notification that persists until a user notices and dismisses it. We may modify it in the future to make this more noticeable, e.g. dimming page contents similar to FireFox. It would be safer if this was not only dimmed, but was modal, so the user could not interact with the rest of the full screen contents of that page until they responded to the notification. Then they couldn’t accidentally interact with a full screen app masquerading as a browser. (Either that or don’t go full screen until the user responded to the notification.) We have generally always left UI up to implementations. For several reasons: * If it's not detectable by the webpage, then it doesn't really matter from a web compat point of view, so no need
Re: Defenses against phishing via the fullscreen api (was Re: full screen api)
Apple has also indicated of not liking confirm prompts of any kind whatsoever To reiterate: for 90% (probably more) of fullscreen use cases, there would be no confirmation prompt at all. Only when the developer specifically requests keyboard access would there need to be a prompt. Thus, developers of video website and video slideshow tools can avoid requesting keyboard access and need not get any prompt at all if Apple so chooses. A prompt should only be necessary for games or complex fullscreen web apps with lots of shortcuts. Since the user only needs to confirm this one time (the browser can remember their choice), this burden seems minimal. The cost of restricting all keyboard input for convenience or for an idealogical aversion to dialogs is very high. We'd basically making the open web useless for fullscreen games. What's the point of the pointerlock specification then? Also, we're defining a spec for the open web here, right? I don't think that worrying about what one vendor may or may not implement is useful. The spec should reflect what we want the open web platform to look like. A fullscreen mode that is secure against phishing yet supports keyboard input for games and other complex web apps is pretty important for the web. Can we make the spec reflect this? Feross On Thu, Oct 18, 2012 at 7:50 PM, Carr, Wayne wayne.c...@intel.com 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 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 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
Re: Defenses against phishing via the fullscreen api (was Re: full screen api)
On Fri, Oct 19, 2012 at 4:50 AM, Carr, Wayne wayne.c...@intel.com 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)
On Fri, Oct 19, 2012 at 9:08 AM, Feross Aboukhadijeh fer...@feross.orgwrote:
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
$('buttonFullscreen/button').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)
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 fer...@feross.orgwrote: I wrote the attack demo that prompted this discussion. Here are my thoughts on how to improve the spec and/or the implementations in browsers: requestFullscreen() should trigger fullscreen mode with limited keyboard input allowed (only space, arrow keys, and perhaps some modifier keys like CTRL, ALT, etc.). The browser should display a notification that the user is in fullscreen mode, although it can fade away after some time since the risk of phishing is significantly reduced when keyboard input is limited (note that Safari currently sees fit to show NO notification at all about fullscreen mode because keyboard is limited). This level of functionality will support 90% of current fullscreen use cases like video players, slideshow viewers, and games with simple input requirements. However, the spec should also support an optional ALLOW_KEYBOARD_INPUT parameter to requestFullscreen() which, when passed, triggers fullscreen mode with full keyboard support (except for ESC to exit fullscreen). When this parameter is passed, the browser should show a prominent modal dialog on top of the page content, requesting permission to use fullscreen mode. No keyboard or mouse input should be allowed until the user clicks Allow. This level of functionality will support the remaining fullscreen use cases, namely games which require more complex keyboard interactions. Most developers who use the fullscreen API will not need to pass the ALLOW_KEYBOARD_INPUT parameter, so most of the common use cases (YouTube, slideshows, etc.) will be frictionless for the user since a phishing attack is extremely unlikely. The advantages of this approach are: - The 90% of users who use fullscreen mode on YouTube and other video sites continue to use the fullscreen API as they always have. No modal prompt. No UI in the way of the video. It just works. - Browser games are free to continue to innovate. We aren't needlessly crippling fullscreen mode and crushing this innovation. - Developers can assume that fullscreen will always fully work (without arbitrary restrictions), simplifying development and preventing some apps from being browser-specific (splintering the web). Possible disadvantages are: - The API is now slightly more complex (but a single optional parameter hardly complex imo) - Users may wonder why 90% of sites (YouTube, slideshow sites, etc.) can enter fullscreen mode without a prompt, but some sites require them to explicitly Allow fullscreen in order for it to work. Currently, Flash Player 11.3 and later uses a similar approach to the one I've outlined here and it appears to be simple for developers to use as well as successfully mitigating the risk of phishing for users. Flash has two fullscreen modes: normal and interactive. Normal mode disallows keyboard input and shows minimal UI (it just shows Press ESC to exit fullscreen mode for a few seconds). Interactive mode disallows keyboard input completely until the user expressly allows it. You can check out an example of interactive mode here: http://leebrimelow.com/flash/fullkeys/ For an example of normal mode just go to YouTube and fullscreen any video. This solution is really elegant, imo. Thoughts on this approach? Feross On Wed, Oct 17, 2012 at 10:07 AM, Carr, Wayne wayne.c...@intel.comwrote: 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 wayne.c...@intel.com wrote: Chrome supports Fullscreen with keyboard enabled. We use
Re: Defenses against phishing via the fullscreen api (was Re: full screen api)
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 wayne.c...@intel.com wrote: Chrome supports Fullscreen with keyboard enabled. We use a notification that persists until a user notices and dismisses it. We may modify it in the future to make this more noticeable, e.g. dimming page contents similar to FireFox. It would be safer if this was not only dimmed, but was modal, so the user could not interact with the rest of the full screen contents of that page until they responded to the notification. Then they couldn’t accidentally interact with a full screen app masquerading as a browser. (Either that or don’t go full screen until the user responded to the notification.) We have generally always left UI up to implementations. For several reasons: * If it's not detectable by the webpage, then it doesn't really matter from a web compat point of view, so no need to specify. * Leaving UI up to implementations means that implementations can experiment and improve over time. * Generally implementations have been reluctant to allow specifications to dictate UI. And since test suites can't test it anyway, they could simply ignore the spec and still pass test suites. * Many times when trying to specify UI, such as when HTTP required UI for POST, the result has been really bad. There were some efforts in a separate WG around trying to standardize security related UI in order to provide more reliable and secure UI. IIRC this was mostly around the secure-connection UIs (a.k.a. the lock icon) in the URL bar. Of course, things like are keys enabled while in fullscreen mode is very noticeable to the page, so it makes sense to put in the spec. And of course we always need to ensure that the spec is implementable in a safe way using *some* UI strategy. But whether dimming should be done, when exactly to switch to fullscreen mode, and how fullscreen notifications work I think fall under leave it up to implementations rule. The fact that we have so many different strategies for how to handle the fullscreen UI in current implementations I think is a testament to that the current strategy works. Implementations are *very* concerned about security, you can bet that they will do their utmost to protect users and adjust UI as needed in order to do so. Thinking that we can do better and putting requirements in the spec will just have the opposite effect since it means that implementations can't do better than whatever we come up with. / Jonas
RE: Defenses against phishing via the fullscreen api (was Re: full screen api)
If touch events are restricted, how does the user pause the video? From: Florian Bösch [mailto: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 pya...@gmail.commailto: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 fer...@feross.orgmailto: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 it. You can check out an example of interactive mode here: http://leebrimelow.com/flash/fullkeys/ For an example of normal mode
Re: Defenses against phishing via the fullscreen api (was Re: full screen api)
On Tue, Oct 16, 2012 at 4:48 PM, Carr, Wayne wayne.c...@intel.com wrote: Chrome supports Fullscreen with keyboard enabled. We use a notification that persists until a user notices and dismisses it. We may modify it in the future to make this more noticeable, e.g. dimming page contents similar to FireFox. It would be safer if this was not only dimmed, but was modal, so the user could not interact with the rest of the full screen contents of that page until they responded to the notification. Then they couldn’t accidentally interact with a full screen app masquerading as a browser. (Either that or don’t go full screen until the user responded to the notification.) We have generally always left UI up to implementations. For several reasons: * If it's not detectable by the webpage, then it doesn't really matter from a web compat point of view, so no need to specify. * Leaving UI up to implementations means that implementations can experiment and improve over time. * Generally implementations have been reluctant to allow specifications to dictate UI. And since test suites can't test it anyway, they could simply ignore the spec and still pass test suites. * Many times when trying to specify UI, such as when HTTP required UI for POST, the result has been really bad. There were some efforts in a separate WG around trying to standardize security related UI in order to provide more reliable and secure UI. IIRC this was mostly around the secure-connection UIs (a.k.a. the lock icon) in the URL bar. Of course, things like are keys enabled while in fullscreen mode is very noticeable to the page, so it makes sense to put in the spec. And of course we always need to ensure that the spec is implementable in a safe way using *some* UI strategy. But whether dimming should be done, when exactly to switch to fullscreen mode, and how fullscreen notifications work I think fall under leave it up to implementations rule. The fact that we have so many different strategies for how to handle the fullscreen UI in current implementations I think is a testament to that the current strategy works. Implementations are *very* concerned about security, you can bet that they will do their utmost to protect users and adjust UI as needed in order to do so. Thinking that we can do better and putting requirements in the spec will just have the opposite effect since it means that implementations can't do better than whatever we come up with. / Jonas
Re: Defenses against phishing via the fullscreen api (was Re: full screen api)
On Tue, Oct 16, 2012 at 5:42 AM, Florian Bösch pya...@gmail.com wrote: On Tue, Oct 16, 2012 at 7:48 AM, Maciej Stachowiak m...@apple.com 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)
On Wed, Oct 17, 2012 at 12:06 PM, Florian Bösch pya...@gmail.com wrote: On Wed, Oct 17, 2012 at 4:51 PM, Rick Waldron waldron.r...@gmail.comwrote: 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)
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 wayne.c...@intel.com wrote: Chrome supports Fullscreen with keyboard enabled. We use a notification that persists until a user notices and dismisses it. We may modify it in the future to make this more noticeable, e.g. dimming page contents similar to FireFox. It would be safer if this was not only dimmed, but was modal, so the user could not interact with the rest of the full screen contents of that page until they responded to the notification. Then they couldn’t accidentally interact with a full screen app masquerading as a browser. (Either that or don’t go full screen until the user responded to the notification.) We have generally always left UI up to implementations. For several reasons: * If it's not detectable by the webpage, then it doesn't really matter from a web compat point of view, so no need to specify. * Leaving UI up to implementations means that implementations can experiment and improve over time. * Generally implementations have been reluctant to allow specifications to dictate UI. And since test suites can't test it anyway, they could simply ignore the spec and still pass test suites. * Many times when trying to specify UI, such as when HTTP required UI for POST, the result has been really bad. There were some efforts in a separate WG around trying to standardize security related UI in order to provide more reliable and secure UI. IIRC this was mostly around the secure-connection UIs (a.k.a. the lock icon) in the URL bar. Of course, things like are keys enabled while in fullscreen mode is very noticeable to the page, so it makes sense to put in the spec. And of course we always need to ensure that the spec is implementable in a safe way using *some* UI strategy. But whether dimming should be done, when exactly to switch to fullscreen mode, and how fullscreen notifications work I think fall under leave it up to implementations rule. The fact that we have so many different strategies for how to handle the fullscreen UI in current implementations I think is a testament to that the current strategy works. Implementations are *very* concerned about security, you can bet that they will do their utmost to protect users and adjust UI as needed in order to do so. Thinking that we can do better and putting requirements in the spec will just have the opposite effect since it means that implementations can't do better than whatever we come up with. / Jonas
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 m...@apple.com wrote: On Oct 15, 2012, at 5:01 PM, Chris Pearce 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)
On Tue, Oct 16, 2012 at 10:56 PM, Vincent Scheib sch...@google.com 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)
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 m...@apple.commailto:m...@apple.com wrote: On Oct 15, 2012, at 5:01 PM, Chris Pearce cpea...@mozilla.commailto: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)
On Oct 14, 2012, at 3:54 PM, Chris Pearce 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)
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 m...@apple.com wrote: On Oct 14, 2012, at 3:54 PM, Chris Pearce 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)
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 pya...@gmail.com 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 m...@apple.com wrote: On Oct 14, 2012, at 3:54 PM, Chris Pearce 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)
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 m...@apple.com 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 pya...@gmail.com 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 m...@apple.com wrote: On Oct 14, 2012, at 3:54 PM, Chris Pearce 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)
On Oct 15, 2012, at 5:01 PM, Chris Pearce 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)
On 14/10/12 00:49, Maciej Stachowiak wrote: On Oct 13, 2012, at 1:49 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Oct 12, 2012 at 8:25 PM, Florian Bösch pya...@gmail.com 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
Defenses against phishing via the fullscreen api (was Re: full screen api)
On Oct 13, 2012, at 1:49 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Oct 12, 2012 at 8:25 PM, Florian Bösch pya...@gmail.com 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
Re: Defenses against phishing via the fullscreen api (was Re: full screen api)
On Sat, Oct 13, 2012 at 1:49 PM, Maciej Stachowiak m...@apple.com 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.
Re: Defenses against phishing via the fullscreen api (was Re: full screen api)
On Oct 13, 2012, at 4:58 AM, Florian Bösch pya...@gmail.com wrote: On Sat, Oct 13, 2012 at 1:49 PM, Maciej Stachowiak m...@apple.com 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)
You're making fullscreen useless for games. On Sat, Oct 13, 2012 at 9:56 PM, Maciej Stachowiak m...@apple.com wrote: On Oct 13, 2012, at 4:58 AM, Florian Bösch pya...@gmail.com wrote: On Sat, Oct 13, 2012 at 1:49 PM, Maciej Stachowiak m...@apple.com 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)
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 pya...@gmail.com wrote: You're making fullscreen useless for games. On Sat, Oct 13, 2012 at 9:56 PM, Maciej Stachowiak m...@apple.com wrote: On Oct 13, 2012, at 4:58 AM, Florian Bösch pya...@gmail.com wrote: On Sat, Oct 13, 2012 at 1:49 PM, Maciej Stachowiak m...@apple.com 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
