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-requ...@w3.org
[mailto:public-web-security-requ...@w3.org] On Behalf Of Anne van Kesteren
Sent: Thursday, June 30, 2011 7:23 AM
To: WebApps WG
Cc: public-web-secur...@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/