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


Regards,
Chris Pearce.

Reply via email to