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: Vincent Scheib <scheib@google.com>
Date: Tue, 16 Oct 2012 13:56:54 -0700
Message-ID: <CAK-EfXnfGRnj7QhvfyhA545beP-fpiBQbdnQHr3okYTPGk1eSA@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Chris Pearce <cpearce@mozilla.com>, Florian Bösch <pyalot@gmail.com>, Anne van Kesteren <annevk@annevk.nl>, "Carr, Wayne" <wayne.carr@intel.com>, "public-webapps@w3.org" <public-webapps@w3.org>
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> wrote:

>
> On Oct 15, 2012, at 5:01 PM, Chris Pearce <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
>
>
>
Received on Tuesday, 16 October 2012 20:57:52 GMT

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