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

@Michal
Yes, so making this configurable from within the feature
(force-visibility: none | Ns) would make this better?

Also, I read the previous conversation in WHATWG, but couldn't find
anything regarding this, you mean the solution (2)? or (3)?

I think the main difference is that in that case, the UA had to see
what elements where obstructing view which maybe explained why it was
more complex, but in this case, the UA just have to force the element
to be visible (obscuring anything in front of it, following certain
security constrains, being: not obscuring chrome UI, and not going
outside of the window [in frames of 1x1 for example]). If it fails to
do so for one of those reasons, then it will disable the element for
any action.

For <tab>/<enter> and similar, we might have to come up with other
solutions, but actually I think that the UX impact of showing a prompt
after someone did <tab>/<enter> is not so big (since they just have to
press enter one more time).

@Everyone
By the way, if anyone has any comments regarding implementation that
might make this unfeasible please let me know.. At first glance, I
don't see any other security/usability/implementation problems but I
might be wrong.

Greetings

-- Eduardo




On Tue, Jun 7, 2011 at 2:07 PM, Michal Zalewski <lcamtuf@coredump.cx> wrote:
>> 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.
>
> Yes, but there are no APIs to do it well right now. Monitoring
> onmouseover etc fails in a number of scenarios (IIRC, including
> closing, opening, and repositioning windows in certain ways), and
> again, is problematic with many accessibility features :-(
>
> /mz
>

Received on Tuesday, 7 June 2011 20:17:28 UTC