X-Frame-Options, or solving the wrong problem

On modern computers, JavaScript allows you to exploit the limits of human perception: you can open, reposition, and close browser windows, or load and navigate away from specific HTML documents, without giving the user any chance to register this event, let alone react consciously.

I have discussed some aspects of this problem in the past:
my recent entry showcased an exploit that flips between two unrelated websites so quickly that you can't see it happening; and my earlier geolocation hack leveraged the delay between visual stimulus and premeditated response to attack browser security UIs.

A broader treatment of these problems - something that I consider to be one of the great unsolved problems in browser engineering - is given in "The Tangled Web". But today, I wanted to showcase another crude proof-of-concept illustrating why our response to
clickjacking - and the treatment of it as a very narrow challenge specific to mouse clicks and <iframe> tags - is somewhat short-sighted. So, without further ado:

• http://lcamtuf.coredump.cx/clickit/
  

There are more complicated but comprehensive approaches that may make it possible for web applications to ensure that they are given a certain amount of non-disrupted, meaningful screen time; but they are unpopular with browser vendors, and unlikely to fly any time soon.