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. 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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
