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

You're making fullscreen useless for games.

On Sat, Oct 13, 2012 at 9:56 PM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> On Oct 13, 2012, at 4:58 AM, Florian Bösch <pyalot@gmail.com> wrote:
>
> 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.
>
>
> Our current intended behavior in Safari is to never allow alphanumeric
> keyboard access in fullscreen. No cancel/allow prompt. Did you read the
> part where I explained why such prompts are useless for security?
>
>
>
>> 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.
>
>
> That depends on what you think "most of its intended purpose" is. Many
> native video fullscreen implementations already have behavior somewhat like
> this, because they expect that the user is not producing UI events most of
> the time while watching the video. It may be annoying in the context of a
> game or slideshow. So far I have encountered such uses much less often than
> video.
>
> Regards,
> Maciej
>
>