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

Re: [Bug 19297] New: May user agents apply additional restrictions on entering pointer lock?

From: Florian Bösch <pyalot@gmail.com>
Date: Tue, 9 Oct 2012 08:43:13 +0200
Message-ID: <CAOK8ODhyt3ErTbCg3K=h+ZtkUFSCiR2Q27o9fgHcSrqFDpfbaQ@mail.gmail.com>
To: bugzilla@jessica.w3.org
Cc: public-webapps@w3.org
Cheer up everyone, we've got somebody dedicated to writing fullscreen
exploits now :) http://feross.org/html5-fullscreen-api-attack/

Summary: Change blindness may make phishing attacks feasible (displaying a
mock browser/page in fullscreen)
Cause: Switch to fullscreen before user consent.
Fix: Switch to fullscreen after user consent.
Questions:
 - Is this a problem?
 - Does the proposed fix address the problem?
 - What is the reasoning to switch before user consent?

On Fri, Oct 5, 2012 at 6:45 PM, <bugzilla@jessica.w3.org> wrote:

> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19297
>
>            Summary: May user agents apply additional restrictions on
>                     entering pointer lock?
>            Product: WebAppsWG
>            Version: unspecified
>           Platform: All
>         OS/Version: All
>             Status: NEW
>           Severity: normal
>           Priority: P2
>          Component: Pointer Lock
>         AssignedTo: scheib@chromium.org
>         ReportedBy: scheib@chromium.org
>          QAContact: public-webapps-bugzilla@w3.org
>                 CC: mike@w3.org, public-webapps@w3.org
>
>
> The pointer lock spec Working Draft 29 May 2012 is written specifying
> several
> requirements to enter mouse lock, and leaving user agents to add additional
> constraints to prevent nuisance and enforce security policies.
>  Specifically
> the Element requestPointerLock method section [1] states "The user agent
> determines if pointer lock state will be entered" and the Security section
> [2]
> includes varying policies including 'A conservative approach' requiring
> user
> gestures and 'A full screen approach' requiring full screen.
>
> Initial implementations have added additional constraints beyond those
> explicitly listed in [1]. Firefox 14 introduced pointer lock requiring that
> fullscreen be entered and confirmed and that the pointer lock target match
> the
> fullscreen element. Chrome 22 introduced pointer lock with a more
> permissive
> policy, allowing pointer lock of any element after fullscreen has been
> confirmed. Chrome also permitted pointer lock outside of fullscreen if it
> was
> requested via a user gesture.
>
> Concern was raised in public-webapps discussion [3] that all user agents
> should
> use the same policy and that be incorporated into the specification.
>
> [1] http://www.w3.org/TR/2012/WD-pointerlock-20120529/#methods
> [2] http://www.w3.org/TR/2012/WD-pointerlock-20120529/#security
> [3]
> http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0010.html
>
> --
> Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>
>
Received on Tuesday, 9 October 2012 06:43:41 GMT

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