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
