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: Florian Bösch <pyalot@gmail.com>
Date: Sat, 13 Oct 2012 13:58:07 +0200
Message-ID: <CAOK8ODi8H9XFjrKU+_PgOjmF8sbfhQETL3725bcskw2n9gNh6A@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, "Carr, Wayne" <wayne.carr@intel.com>, "public-webapps@w3.org" <public-webapps@w3.org>
On Sat, Oct 13, 2012 at 1:49 PM, Maciej Stachowiak <mjs@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.
Received on Saturday, 13 October 2012 11:58:35 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:55 GMT