W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

Re: full screen api

From: Chris Pearce <cpearce@mozilla.com>
Date: Mon, 15 Oct 2012 11:52:18 +1300
Message-ID: <507B4222.3050004@mozilla.com>
To: "Carr, Wayne" <wayne.carr@intel.com>
CC: "public-webapps@w3.org" <public-webapps@w3.org>
On 13/10/12 07:20, Carr, Wayne wrote:
> There’s a recent post on a phishing attack using the full screen api 
> [1][2}[3].

It's worth noting that this attack has been possible in Flash for years, 
and the sky hasn't fallen.

> Running the example attack, Firefox and Chrome both put up a popup at 
> the top saying the site has gone full screen and asking to approve or 
> deny.  But for both of them the screen is already full screen and 
> active (Firefox greys the content but doesn’t disable it).  So if the 
> user doesn’t see the popup or ignores it, they can think they’re 
> interacting with another site.  In the example, it is a bank.
> Why not require in the spec that it doesn’t go full screen until after 
> the user approves?

This is basically for scripts/authors' benefit. If permission must be 
requested before entering fullscreen there's no way for script to 
distinguish between the case of the user being about to approve/deny the 
permisison request, or the user having ignored the permission request. 
So it's harder for script to know whether/when it should take its 
fallback path.

However I believe the current specification could be interpreted to 
allow a permission prompt before entering fullscreen; the specification 
for requestFullscreen() says it runs asynchronously, which gives scope 
for a permission request before or approval request after entering 

>   That would at least force the user to pay attention to the popup.

If you're going to argue that people won't pay attention to an approval 
prompt shown after entering fullscreen, then the same argument also 
applies to showing the approval UI before entering fullscreen.

Chris Pearce.
Received on Sunday, 14 October 2012 22:52:48 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:49 UTC