[webkit-dev] Mouse Lock API

[Eric Uhrhane]

On Wed, Sep 21, 2011 at 10:44 AM, Alexey Proskuryakov <ap at webkit.org> wrote:
>
> This API seems clearly necessary to implement traditional FPS game controls.
> On the other hand, I would not want my browser to have this kind of
> functionality. Arguably the main benefit of browsers is that they cannot do
> many things, and are thus relatively safe to use, not yet triggering the
> sort of fear normally associated with installing software on desktop
> platforms. Interfering with mouse movement would be one of the most
> dangerous and frustrating things Web pages could possibly do.
> The specification draft acknowledges the problem of inability to interact
> with user agent and the rest of the OS in mouse lock mode. However, the
> suggested mitigations seem fairly weak. Users are not trained to hit Esc
> anytime their computer stops properly reacting to their actions - I
> certainly wouldn't think of doing that. A permanent reminder would be
> extremely annoying, and we cannot expect that it would be read anyway.
> Fullscreen is one mode where browsers are expected to take more control over
> user interaction. Perhaps mouse lock could be appropriate in fullscreen.
> However, regular fullscreen applications do not use a mouse lock, so users
> are not trained to escape it - one can always move the mouse pointer to top
> of screen to get back their menu bar.

Is that a Mac thing?  Mousing around in a fullscreen flash app on
Linux or Windows 7 certainly doesn't pop up a menu bar when I hit the
top.  And the way out is always to hit ESC [although there's often a
button as well, depending on the application], so I'm not sure what
the problem with fullscreen mouse lock would be.

> The only related case I can think of
> is emulators, which release the mouse on certain modifier keys, such as Cmd
> or Ctrl+Option. So, I'm not sure how a safe UI would work even in this case.
> I'm curious about the following provision in the spec:
>
> Mouse events normally considered user gestures (e.g. mousedown, click) for
> security purposes (such as when allowing pop-up windows) should not be
> treated as user gestures when under mouse lock to prevent malicious cross
> origin click redirecting.
>
> My understanding is that when browser is in control, the primary security
> concern is with making the user believe that they are interacting with a
> different site, and thus stealing confidential data the user types
> (especially passwords). Displaying a pop-up window sounds like a very minor
> issue when malicious code is already in main frame, can draw anything, and
> can control mouse movement. Is there a specific attack scenario where this
> limitation helps?
> - WBR, Alexey Proskuryakov
> 20.09.2011, в 20:53, Vincent Scheib написал(а):
>
> I have proposed Mouse Lock to be adopted by the W3 WebEvents Working Group:
> http://lists.w3.org/Archives/Public/public-webevents/2011JulSep/0064.html
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1424.html
>
> On Mon, Sep 12, 2011 at 4:50 PM, Vincent Scheib <scheib at chromium.org> wrote:
>>
>> A Mouse Lock API has been under discussion on the W3 public-webapps list
>> "Mouse Lock"(1) and earlier "Mouse Capture for Canvas"(2).
>> The primary goal is to enable use cases such as first person perspective
>> 3D applications. This is done by providing scripted access to mouse movement
>> data while locking the target of mouse events to a single element and
>> removing the cursor from view.
>> I have been working to formalize the discussions into a draft
>> specification: http://goo.gl/9G8pd, and have a work in progress prototype
>> for WebKit | Chrome. I will publish a WIP patch when it is ready for more
>> eyes. It will be developed behind a compile (and runtime) time flag.
>> I'd like to invite any specification discussion to the Mouse Lock thread
>> (1), and WebKit implementation discussion here.
>> Cheers, -Vince
>> --
>>
>> 1. http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/thread.html#msg960
>>
>> 2. http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/thread.html#msg437
>> W3 issue: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9557
>> Firefox issue: https://bugzilla.mozilla.org/show_bug.cgi?id=633602
>> Chrome issue: http://code.google.com/p/chromium/issues/detail?id=72754
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>