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

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.

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

Received on Saturday, 13 October 2012 11:50:05 UTC