W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

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

From: Chris Pearce <cpearce@mozilla.com>
Date: Mon, 15 Oct 2012 11:54:34 +1300
Message-ID: <507B42AA.6090001@mozilla.com>
To: Maciej Stachowiak <mjs@apple.com>
CC: Anne van Kesteren <annevk@annevk.nl>, Florian Bösch <pyalot@gmail.com>, "Carr, Wayne" <wayne.carr@intel.com>, "public-webapps@w3.org" <public-webapps@w3.org>
On 14/10/12 00:49, Maciej Stachowiak wrote:
> On Oct 13, 2012, at 1:49 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> On Fri, Oct 12, 2012 at 8:25 PM, Florian Bösch <pyalot@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 

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.

Chris Pearce.
Received on Sunday, 14 October 2012 22:55:04 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:49 UTC