RE: New clickjacking research published

> From: bhill@paypal-inc.com
...
> Thank you for your comments, Fred.  I've updated the Implementation Considerations section of our editors' draft spec to reflect some of your concerns, and I'd encourage you to review what we're considering specifying, as it is informed by, but certainly not identical to, David's work.
> 
> http://dvcs.w3.org/hg/user-interface-safety/raw-file/tip/user-interface-safety.html

Thank you for the revisions, this does address many of my concerns.

The "Obstruction Check" defined in section "5. Input Protection Heuristic" would appear to be
able to work adequately irrespective of extensions modifying the documents assuming that
extensions will not make an embedded frame transparent or make it unclickable which does seem
a reasonable restriction.

There may be issues with overlays added to the top level document by extensions.  However if
these overlays were based in chrome then this would seem to not be an issue with your proposal
because they would not appear when generating the top-level document view.

In contrast the Incontext design compares the OS-level view "what the user sees" and this could
include even extension chrome which would make it problematic to work with extensions - or even
with standard browser chrome such as pull down menus or developer tools.

I still think that automatically reporting violations back to the server is the wrong thing to do.
In any case it is good to have a defined standard report format that can be used.  I guess a
browser config option can be added to just disable these reports.

ClearClick will prompt the user in case of a detected issue.  Your proposal does flag a UIEvent
but there appears to be no mention of how a web browser default handlers would respond to
such events.  Perhaps a suggestion to have browsers inform users could be added to the document
if appropriate.

Would you happen to know if CSS alone can be used for timing attacks?  Perhaps using transitions.
If so then perhaps transitions would need to be checked or restricted if ever adding CSS checks.


> I have some concerns with your proposed alternative approach:
> 
> "UI widgets would be limited to a standard set with well known and
>  expected behavior - standard buttons and forms etc. ... This may
> limit the scope of customization that a web application can achieve in
> such contexts but this seems like a small price to pay.  This approach
> is also consistent with the roots and success of the web.  It builds on
> user experience and expectations for the operation of a standard set
> of widgets."
> 
> I think our experience with the web is actually the opposite - that standard buttons and forms with limited customization are widely loathed and rarely used, even when the cost in security is quite high.  Perhaps the biggest reason that we are still stuck using insecure, plaintext password, forms-based auth instead of more secure and phishing-resistant methods is that application owners value the ability to have full control, customization and branding of their login experience above almost all else.  They absolutely hate the current experience of HTTP based auth, and user agents have not been able to arrive at any agreement on how to present it in a standardized manner that is any more palatable to application authors.

Thank you for the perspective.  Are standard buttons and forms 'widely loathed' by content authors or by users (or both)?

It would seem that a good deal of customization could be permitted without UI redress concerns.

A suggestion to add standard social networking and payment widgets may not be well received then.

cheers
Fred