[webkit-dev] Mouse Lock API
Adam Barth
abarth at webkit.org
Wed Sep 21 13:30:09 PDT 2011
On Wed, Sep 21, 2011 at 1:15 PM, Vincent Scheib <scheib at chromium.org> wrote:
> Re: Alexey Proskuryakov's comment:
>
>> 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?
>
> The concern I was attempting to address is primarily that of click jacking.
> E.g. Preventing a malicious top level page from directing unintended clicks
> to an iframe with a target site (e.g. a bank).
> Upon reflection, perhaps the correct way to limit this is to require the
> target element to match the top level origin as well. Then user gestures can
> only be delivered to the top level origin.
I wouldn't worry too much about that. A site can already mount a
clickjacking attack without using mouselock. It's not clear to me
that mouselock make the situation any worse than it is already.
Adam
> Re: Mouse lock can be a nuisance.
> Yes, it can, but it also is essential for many compelling applications and
> user interactions. We believe user-agents can find a balance of providing
> that ability and diminishing it's abuse. The example of
> Flash's abusable full screen mode is relevant in that I believe the amount
> of users enjoying the feature vastly outweigh the amount of nuisance caused.
> We'll seek to find the appropriate ease of use and reduction of nuisance,
> but in the extreme can fall back onto heavy weight measures such as
> installing a web-app or prompting for permission first. The API is designed
> to tolerate these methods (asynchronous success/failure).
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
More information about the webkit-dev
mailing list