- From: Anne van Kesteren <annevk@opera.com>
- Date: Tue, 05 Jul 2011 17:09:41 +0200
- To: "ext Hill, Brad" <bhill@paypal-inc.com>, "Arthur Barstow" <art.barstow@nokia.com>
- Cc: "WebApps WG" <public-webapps@w3.org>, "public-web-security@w3.org" <public-web-security@w3.org>, "Daniel Veditz" <dveditz@mozilla.com>
On Tue, 05 Jul 2011 16:30:26 +0200, Arthur Barstow <art.barstow@nokia.com> wrote: > Anne - please add some text re the consensus of the contents point and > then I'll start the CfC. http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html Now has "The contents of this document do not necessarily reflect the consensus of the Working Group." which I think is redundant with "Publication as a Working Draft does not imply endorsement by the W3C Membership." but moving on is more interesting. > On 7/1/11 1:52 PM, ext Hill, Brad wrote: >> The new WebAppSec WG charter draft does include a deliverable for >> secure mashups built with cross-domain framing, with the specific >> intent to put forward a proposal for anti-clickjacking in this space. >> >> However, I have concerns with nearly every aspect of this draft. >> >> First, I am concerned about mixed goals in the problem statement. It's >> definitely not in the proposed charter scope for the WebAppSec WG to >> address issues like bandwidth "theft" and license enforcement. Even >> for the WebApps WG, it is arguable that some of these goals go against >> core Web Architecture principles. (http://www.w3.org/TR/webarch/) >> >> Secondly, several of the goals, even if couched in terms of security, >> aren't in the interest of the user. If I go to a page, I want to see >> images, fonts and videos on it. Policies that prevent that from >> working are actually adversarial to the user. From a basic security >> principles perspective, the client-side UA is not the place for such >> restrictions to be enforced, as they can be easily disabled. >> Further, conflating mechanisms to protect the user (anti-clickjacking) >> with mechanisms adversarial to the user (font licensing) encourages the >> user to disable even the protections that they should want. >> >> Finally, don't think the proposed mechanism here for user-protection is >> adequate for many/most use cases at risk of clickjacking that web >> application owners would like to deploy. A binary frame/no-frame >> policy based on a whitelist of origins is both very limiting and not >> terribly secure. Consider a "like", "+1" or "pay" button. These may >> be framed on tens of thousands of origins, making a whitelist >> unmanageable. Or they may be framed-by-permission on an origin with >> tens of thousands of resources/pages/applications (forum, auction site, >> etc.) where an XSS or similar in any one of which would expose the >> framed content to clickjacking again. >> >> I think it's preferable to work towards a mechanism where resources can >> declare they can be framed, but only subject to some policy or set of >> capabilities which guarantee clickjacking protection, visibility, etc. I agree we should look at this more, but I think having a published draft helps. The background of this work is actually not clickjacking, but specifically @font-face (web font embedding mechanism) where a default same-origin restriction is considered. This was drafted as an alternative, opt-out mechanism, though can potentially be used for a number of other things as well. -- Anne van Kesteren http://annevankesteren.nl/
Received on Tuesday, 5 July 2011 15:10:46 UTC