RE: Publishing From-Origin Proposal as FPWD

Well, my disagreement is not with its content; I think we should not move forward with this spec at all.

I feel that the goals of this draft are either inconsistent with the basic architecture of the web, cannot be meaningfully accomplished by the proposed mechanism, or both, and I haven't seen any discussion of these concerns yet.   

-Brad

-----Original Message-----
From: Arthur Barstow [mailto:art.barstow@nokia.com] 
Sent: Tuesday, July 05, 2011 7:30 AM
To: Hill, Brad; Anne van Kesteren
Cc: WebApps WG; public-web-security@w3.org; Daniel Veditz
Subject: Re: Publishing From-Origin Proposal as FPWD

Hi Brad, Anne,

As I mentioned in [1], I think there is sufficient support for WebApps to publish this spec as a FPWD and I will start a Call for Consensus to more formally determine WebApps' level of support.

A WG may publish a FPWD without consensus on the _contents_ of the spec. 
The Status of the Document section may be explicit on this point. We try to employ a "publish early, publish often" to encourage early and frequent comments and I think a FPWD will help stimulate comments.

Anne - please add some text re the consensus of the contents point and then I'll start the CfC.

-Art Barstow

[1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0012.html

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.
>
> Brad Hill
>
> -----Original Message-----
> From: public-web-security-request@w3.org 
> [mailto:public-web-security-request@w3.org] On Behalf Of Anne van 
> Kesteren
> Sent: Thursday, June 30, 2011 7:23 AM
> To: WebApps WG
> Cc: public-web-security@w3.org
> Subject: Publishing From-Origin Proposal as FPWD
>
> Hi hi,
>
> Is there anyone who has objections against publishing http://dvcs.w3.org/hg/from-origin/raw-file/tip/Overview.html as a FPWD.
> The idea is mainly to gather more feedback to see if there is any interest in taking this forward.
>
> (Added public-web-security because of the potential for doing this in 
> CSP instead. Though that would require a slight change of scope for 
> CSP, which I'm not sure is actually desirable.)
>
> Cheers,
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>

Received on Tuesday, 5 July 2011 15:51:27 UTC