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

> Chrome supports Fullscreen with keyboard enabled. We use a notification that persists until a user notices and
> dismisses it. We may modify it in the future to make this more noticeable, e.g. dimming page contents similar to FireFox.

It would be safer if this was not only dimmed, but was modal, so the user could not interact with the rest of the full screen contents of that page until they responded to the notification.  Then they couldn’t accidentally interact with a full screen app masquerading as a browser.

(Either that or don’t go full screen until the user responded to the notification.)


From: Vincent Scheib [mailto:scheib@google.com]
Sent: Tuesday, October 16, 2012 1:57 PM
To: Maciej Stachowiak
Cc: Chris Pearce; Florian Bösch; Anne van Kesteren; Carr, Wayne; public-webapps@w3.org
Subject: Re: Defenses against phishing via the fullscreen api (was Re: full screen api)

Chrome supports Fullscreen with keyboard enabled. We use a notification that persists until a user notices and dismisses it. We may modify it in the future to make this more noticeable, e.g. dimming page contents similar to FireFox.

I personally think it would be unfortunate to support multiple modes of Fullscreen. It seems to add complexity for developers and disjoint experiences for users. If the experience is the same for users, what is the point of having the API split? If it's not the same, then there is confusion over why some pages go fullscreen in different ways.

However, if other browsers only implement fullscreen without keyboard support then clearly it would be best if developers could detect this when composing their application interface, avoiding prompting users to enter fullscreen if it will not work correctly.

On Mon, Oct 15, 2012 at 10:48 PM, Maciej Stachowiak <mjs@apple.com<mailto:mjs@apple.com>> wrote:

On Oct 15, 2012, at 5:01 PM, Chris Pearce <cpearce@mozilla.com<mailto:cpearce@mozilla.com>> wrote:

> On 16/10/12 11:39, Maciej Stachowiak wrote:
>>
>> That's why I liked having a separate API to request fullscreen with full alphanumeric keyboard access. This allows apps to determine if fullscreen with keyboard is available on a given browser, and allows browsers to set separate security policies for that case.
>
> Would you implement keyboard access in fullscreen via this API if we spec'd it? Or are you looking for a way to for authors to determine if key input isn't supported in fullscreen mode?
Our most likely short-term goal would be the latter (enabling capability detection) but I wouldn't take full keyboard access off the table forever. We would want the freedom to apply different security policy to that case when/if we do it though.

>
>
>> I think the spec should change back to having two distinct APIs, even though Mozilla is not interested in making a distinction between the two cases.
>
> I'd say fullscreen video is the only fullscreen use case where page script shouldn't need key events dispatched to it. I'm sure some other fullscreen uses wouldn't want key events, but most non-trivial users of fullscreen would want keyboard shortcuts or input.
Many games could work with only non-alphanumeric keys or in some cases only the mouse. As could slideshows. You only need space/enter/arrows for a full screen slide presentation.

What are the cases where webpage-driven (as opposed to browser-chrome-driven) fullscreen is really compelling, but they need full keyboard access including alphanumeric keys? (Not saying there aren't any, I am just not sure what they would be - fullscreen Nethack?)

>
> Anyway, I'm curious what the Chrome guys think.
Likewise.


Cheers,
Maciej