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

WebGL FPSes with fullscreen support
- http://media.tojicode.com/q3bsp/
- https://developer.mozilla.org/en-US/demos/detail/bananabread
- http://dl.dropbox.com/u/6873971/data/cube2/index.html

On Sat, Oct 13, 2012 at 9:58 PM, Florian Bösch <pyalot@gmail.com> wrote:

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