- 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? Thanks, Brad Hill WebAppSec co-chair
Received on Thursday, 3 May 2012 22:33:39 UTC