W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2010

[whatwg] api for fullscreen() - security issues

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Sat, 30 Jan 2010 22:38:36 -0600
Message-ID: <dd0fbad1001302038s7460f0a9p3e5286547e3aeee6@mail.gmail.com>
On Sat, Jan 30, 2010 at 9:08 PM, Simon Fraser <smfr at me.com> wrote:
> * require that?enterFullscreen() is being called inside a user-event handler
> (e.g. click or keypress) to avoid drive-by fullscreen annoyances.

This one seems kind of weird.  Does the spec currently distinguish
significantly between a user-initiated click and a script-initiated

> * disallow?enterFullscreen() from a frame or iframe

Makes sense, though consider its interaction with sandboxed iframes
(that is, you may actually *want* the ability to turn on
fullscreen-ability for an iframe).

> * show an animation as the window enters fullscreen so the user can see the
> transition taking place

How would this interact with an author hooking CSS Transitions to the
element keyed on the :fullscreen pseudoclass?  If we implement the
actual fullscreen effect essentially purely in CSS, I'd prefer the
minimum amount of magic here.

> * show an hard-to-spoof overlay with some text that tells the user that they
> can use the Escape key to exit fullscreen, and prevent the page from
> capturing this keypress.
> * show an affordance to allow the user to exit fullscreen (e.g. a close
> button) when the user moves the mouse

Both of these make a lot of sense to me, and match the way fullscreen
effects work today, so users will understand it.

> * make the location field available to the user so that they can see the URL
> even when in fullscreen

This partially defeats the purpose of fullscreen.  ^_^  Though, it may
be worthwhile to do so anyway, as it would be a major indicator that
something is being spoofed.

> * drop out of fullscreen if navigating to another page

Sounds very reasonable.

> * if focussed on an element, drop out of fullscreen if that element is
> removed from the DOM

Definitely a good idea.

> * limit arbitrary keyboard input unless 'enableKeys' is true

Already has some history, so would probably be a decent idea.

> * disallow window.open etc. while in fullscreen

I don't fully understand this restriction's justification.

Received on Saturday, 30 January 2010 20:38:36 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:20 UTC