Re: Req for feedback? Add attribute to elements to defeat clickjacking

@Michal

But what do you do if the button is visible in the corner of the
screen and then is moved over your mouse? Or if the window is
scrolled? So, even if it's visible it also needs to be in the same
position for that time, which might impact real use cases.

I think leaving that to the developer might be better, since he knows
his product better.. since I'm sure scrolling/moving and clicking soon
after (<1 second) might be common enough on some cases but very
uncommon on other.

By simply monitoring mousemove,mouseover,mousedown,mouseup events you
can know a lot of the user intent..
If the implementation of such checks are complicated, maybe some open
sourced library can be made public?

Anyway, I agree that letting the developer do stuff might make it easy
to make mistakes, so the simpler the better.

Maybe a:

#buyButton{
    force-visibility: none | 0s | 1s;
}

Where "none" is the default, and "0s" means that it should be visible,
but there's no timing constrain, and "1s" means it should be visible
without moving for 1 second?

Greetings!!

-- Eduardo




On Tue, Jun 7, 2011 at 11:56 AM, Michal Zalewski <lcamtuf@coredump.cx> wrote:
>>> 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)?
>> This is something the host page could detect right? How long the mouse
>> is hovered over.
>
> And for that part - sort of, though not very easily (there are many
> odd corner cases, plus considerations with accessibility technologies
> or keyboard browsing).
>
> But most importantly, it's ugly, like framebusting or referrer
> clicking. Browser-enforced minimum visibility would probably be a
> useful part of a proposal like that. But that brings us pretty close
> to the original whatwg discussion ;-)
>
> /mz
>

Received on Tuesday, 7 June 2011 18:40:06 UTC