- From: Giorgio Maone <g.maone@informaction.com>
- Date: Tue, 07 Jun 2011 19:43:48 +0200
- To: David Lindsay <thornmaker@gmail.com>
- CC: Michal Zalewski <lcamtuf@coredump.cx>, sird@rckc.at, public-web-security@w3.org
David Lindsay wrote, On 07/06/2011 19.33: > Also, there can be ui-redressing problems when everything on a page > gets overlaid *except* the click-target element. > This can be handled by enforcing visibility of a reasonably sized area of the owner document, centered on the click element (again, that's what ClearClick does). -- G > On Tue, Jun 7, 2011 at 12:36, Michal Zalewski <lcamtuf@coredump.cx> wrote: >>> <style> >>> #buyButton:hover{ >>> visibility: forced;/* or something else, I don't know.. */ >>> } >>> </style> >>> <button id="buyButton">Click here to purchase server for $500.00.</button> >> >> I see two potential problems here: >> >> 1) What do you do when you have two overlapping "always on top" >> elements? You can only render one. >> >> 2) What if the button is visible (and therefore interactive), but only >> for a very short period of time before a premeditated click (not >> enough to give the user a chance to respond)? >> >> In general, I had the impression that vendors were very unhappy about >> implementing any solutions to clickjacking that would involve >> determining the actual on-screen visibility of a rendered element, >> because that can be complicated in some settings (my proposal in 2008 >> was shot down on these grounds). >> >> /mz >> >> >
Received on Tuesday, 7 June 2011 17:44:11 UTC