Re: Publishing From-Origin Proposal as FPWD

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