- From: Chris Pearce <cpearce@mozilla.com>
- Date: Mon, 15 Oct 2012 11:52:18 +1300
- To: "Carr, Wayne" <wayne.carr@intel.com>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>
- Message-ID: <507B4222.3050004@mozilla.com>
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 fullscreen. > 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. Regards, Chris Pearce.
Received on Sunday, 14 October 2012 22:52:48 UTC