W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2012

[webappsec] Summary of anticlickjacking proposals

From: Hill, Brad <bhill@paypal-inc.com>
Date: Thu, 3 May 2012 22:33:04 +0000
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E0CC727@DEN-EXDDA-S12.corp.ebay.com>
This morning's agenda at the WebAppSec Silicon Valley F2F was dedicated to anti-clickjacking.  We surveyed the threat landscape (thanks, Peleus) and evaluated the existing technology of ClearClick, the previously discussed protected UI elements proposal, and a discussion of server-side techniques.

The rough consensus of those present and participating was that a technology substantially similar to ClearClick offered the best way forward for a standard, with the following additions  and changes:

1)      It should initially be opt-in by resource owners.  We need to be very conservative about breaking existing resources with any new W3C standardized technology.

2)      There should be a policy channel for resources to indicate preferences to the client-side enforcement technology.  Presence of a policy would opt-in a resource to protection, and might convey:

a.       Optional: Size of the viewport or specific elements to be protected

b.      Optional: Timing thresholds

c.       Optional: Tolerance for variation (ClearClick uses 18% by default, some resources may want to be stricter)

d.      Required: Action to take in response to a violation: [block, report]

e.      Optional: A reporting URI to be pinged if a violation is detected

3)      There should initially not be a user experience - violations generate a ping to the report URI, but the opt-in policy is used to specify that the click should go through or be blocked with no user recourse.

In the longer-term, we'd also like implementing user-agents to also collect telemetry data on all sites, not only those that opt-in.  For example: browsers could do the rendered similarity test and record the percentage difference without taking enforcement action, so we could use aggregate data to answer questions like:

At a sensitivity X%:
                * What percentage of resources would generate a violation
                * How many times per year would the average user see a false-positive violation?

This would allow user-agents to make informed decisions about doing default opt-in, or default opt-in with a compatibility list.

As chair I proposed Giorgio Maone as the initial editor of such a draft, and he accepted, but would like a co-editor.  I can do this, but David Huang or an interested user-agent author might have more to contribute.

We'll revisit this summary on next week's call but I want to raise to the list:

1)      would anyone else like to volunteer to co-edit this specification

2)      are there objections to this general plan?


Brad Hill
WebAppSec co-chair
Received on Thursday, 3 May 2012 22:33:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:28 UTC