Re: Publishing From-Origin Proposal as FPWD
On Tue, 05 Jul 2011 17:50:57 +0200, Hill, Brad bh...@paypal-inc.com wrote: 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. It would be helpful if you could articulate what exactly of http://www.w3.org/TR/webarch/ argues against having this feature. As for users disabling this feature in their user agent, that would of course be a problem and mean the feature would not work. How likely this is to happen is somewhat unclear to me. Sites wishing to prevent bandwidth theft can already do so via Referer header checking, which has the annoying side effect that sometimes not even direct linking towards such a resource works. And as for clickjacking, because of the design of the header as it stands now it can replace the non-standard X-Frame-Options. This does indeed not give fine-grained control, but you do not need that for all cases. -- Anne van Kesteren http://annevankesteren.nl/
Re: Publishing From-Origin Proposal as FPWD
Thanks Björn and Brad for your comments. I agree early comments from a broad set of stakeholders is important and I encourage everyone to please send all technical feedback on this spec to: public-webapps@w3.org -Art Barstow On 7/5/11 11:14 PM, ext Hill, Brad wrote: To the procedural points: I am not a member of the Web Applications WG. I do not have standing to block or make a formal objection to this moving forward as a FPWD. Responsibility to measure consensus and the decision to move forward within that WG rests with Art. The opinion of the proposed Web Applications Security WG (currently in the process of being chartered and of which I am a proposed co-chair) was solicited as to whether the work should move to that forum or be a joint deliverable with the Content Security Policy. Additionally, one of the goals of the draft was to address concerns around clickjacking, an item under the proposed charter scope of the WebAppSec WG. Wearing that (still phantom) hat, I can say is that there isn't consensus to move this proposed mechanism as a cross-domain framing security solution to FPWD, alone or as part of the CSP, in the WebAppSec WG, at this time. Until AC approval, we can't move anything to FPWD at this time. :) My other concerns with the proposal are put forward only as an interested member of the community. I expect there will be ample opportunity to discuss them. If Art feels that moving forward to FPWD is the best next step to foster that and other discussions, I'm more than happy to participate there to the extent the WG welcomes my feedback and finds it useful. Thanks, Brad Hill -Original Message- From: public-web-security-requ...@w3.org [mailto:public-web-security-requ...@w3.org] On Behalf Of Bjoern Hoehrmann Sent: Tuesday, July 05, 2011 4:38 PM To: Marcos Caceres Cc: WebApps WG; public-web-secur...@w3.org Subject: Re: Publishing From-Origin Proposal as FPWD * Marcos Caceres wrote: On Tue, Jul 5, 2011 at 5:50 PM, Hill, Bradbh...@paypal-inc.com wrote: 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. I note that the Web Applications Working Group's Charter, if Brad Hill is a member, does require the rest of the Working Group to duly consider his points before moving on without consensus. If not, then the group is not required to wait with publication, but not discussing the points in a timely manner, without an argument how publication is urgent in some way, does not inspire confidence that the arguments will be heard and duly handled. Publication will enable wider discussion - particularly wrt the issues you have raised. Not publishing it is tantamount to saying I OBJECT TO PROGRESS!. If you are correct, more people will see it and the proposal will be shot down. Otherwise, other opinions will flourish that may sway your position (or a new perspective will emerge all together). In any case, calling for a spec not to be published, no matter how bad it is, is not the right way to do this. Publishing a spec is just a formality which can lead to discussion. The more invested people are into something, the less likely they are to cut their losses; by doing things, you frame the discussion in favour of doing more. You get people to think more about how something can be fixed rather than thinking about whether to abandon the work, or use a very different approach. If you just propose an idea to me, we can talk about it more freely than if you had already invested a lot of effort on implementing the idea and asked me to review the idea after the fact. (~ Die normative Kraft des Faktischen) Realizing something is a bad idea early is therefore very important and not objecting to progress. Not wasting time on bad ideas is certainly progress, even if only indirectly as you'd work on other things instead. As such it is quite important to react timely to design critique with care and detail. Psychologically, if you press ahead, you communicate that you care more about moving on than discussing details, which is likely to turn away the people more interested in details and quality; and the same is of course true for draft of genuinely bad quality. Which is just to say this is actually an important matter; sometimes it is best to go ahead and put your ideas into practise whatever others may be saying, other times it turns out that you should have listened more. That is why we allow people to block actions, not necessarily progress, but only up to the point where arguments have been duly considered. And here we have yet to do that. Until that happens, short of someone making the case for urgency, I would agree the group should not publish and talk about this instead. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am
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-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/
Re: Publishing From-Origin Proposal as FPWD
On Tue, 05 Jul 2011 16:30:26 +0200, Arthur Barstow art.bars...@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/
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.bars...@nokia.com] Sent: Tuesday, July 05, 2011 7:30 AM To: Hill, Brad; Anne van Kesteren Cc: WebApps WG; public-web-secur...@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-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/
Re: Publishing From-Origin Proposal as FPWD
Hi Brad, On Tue, Jul 5, 2011 at 5:50 PM, Hill, Brad bh...@paypal-inc.com wrote: 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. Publication will enable wider discussion - particularly wrt the issues you have raised. Not publishing it is tantamount to saying I OBJECT TO PROGRESS!. If you are correct, more people will see it and the proposal will be shot down. Otherwise, other opinions will flourish that may sway your position (or a new perspective will emerge all together). In any case, calling for a spec not to be published, no matter how bad it is, is not the right way to do this. Publishing a spec is just a formality which can lead to discussion. -- Marcos Caceres http://datadriven.com.au
Re: Publishing From-Origin Proposal as FPWD
On Jul 5, 2011, at 8:57 , Marcos Caceres wrote: Hi Brad, On Tue, Jul 5, 2011 at 5:50 PM, Hill, Brad bh...@paypal-inc.com wrote: 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. Publication will enable wider discussion - particularly wrt the issues you have raised. Not publishing it is tantamount to saying I OBJECT TO PROGRESS!. If you are correct, more people will see it and the proposal will be shot down. Otherwise, other opinions will flourish that may sway your position (or a new perspective will emerge all together). In any case, calling for a spec not to be published, no matter how bad it is, is not the right way to do this. Publishing a spec is just a formality which can lead to discussion. I guess this raises two questions... a) I would obviously like to hear more about Marcos's objections, and I suppose that I will b) probably not in this forum, I'd be curious to know what the valid reasons might be to objecting to publication at all, if I don't think this spec. should exist is not one of them. If there are no valid grounds for objection, we wouldn't bother asking for consensus. Personally, I think publishing a WD indicates some consent that work in a given area should be considered and is relevant. David Singer Multimedia and Software Standards, Apple Inc.
Re: Publishing From-Origin Proposal as FPWD
* Marcos Caceres wrote: On Tue, Jul 5, 2011 at 5:50 PM, Hill, Brad bh...@paypal-inc.com wrote: 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. I note that the Web Applications Working Group's Charter, if Brad Hill is a member, does require the rest of the Working Group to duly consider his points before moving on without consensus. If not, then the group is not required to wait with publication, but not discussing the points in a timely manner, without an argument how publication is urgent in some way, does not inspire confidence that the arguments will be heard and duly handled. Publication will enable wider discussion - particularly wrt the issues you have raised. Not publishing it is tantamount to saying I OBJECT TO PROGRESS!. If you are correct, more people will see it and the proposal will be shot down. Otherwise, other opinions will flourish that may sway your position (or a new perspective will emerge all together). In any case, calling for a spec not to be published, no matter how bad it is, is not the right way to do this. Publishing a spec is just a formality which can lead to discussion. The more invested people are into something, the less likely they are to cut their losses; by doing things, you frame the discussion in favour of doing more. You get people to think more about how something can be fixed rather than thinking about whether to abandon the work, or use a very different approach. If you just propose an idea to me, we can talk about it more freely than if you had already invested a lot of effort on implementing the idea and asked me to review the idea after the fact. (~ Die normative Kraft des Faktischen) Realizing something is a bad idea early is therefore very important and not objecting to progress. Not wasting time on bad ideas is certainly progress, even if only indirectly as you'd work on other things instead. As such it is quite important to react timely to design critique with care and detail. Psychologically, if you press ahead, you communicate that you care more about moving on than discussing details, which is likely to turn away the people more interested in details and quality; and the same is of course true for draft of genuinely bad quality. Which is just to say this is actually an important matter; sometimes it is best to go ahead and put your ideas into practise whatever others may be saying, other times it turns out that you should have listened more. That is why we allow people to block actions, not necessarily progress, but only up to the point where arguments have been duly considered. And here we have yet to do that. Until that happens, short of someone making the case for urgency, I would agree the group should not publish and talk about this instead. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
RE: Publishing From-Origin Proposal as FPWD
To the procedural points: I am not a member of the Web Applications WG. I do not have standing to block or make a formal objection to this moving forward as a FPWD. Responsibility to measure consensus and the decision to move forward within that WG rests with Art. The opinion of the proposed Web Applications Security WG (currently in the process of being chartered and of which I am a proposed co-chair) was solicited as to whether the work should move to that forum or be a joint deliverable with the Content Security Policy. Additionally, one of the goals of the draft was to address concerns around clickjacking, an item under the proposed charter scope of the WebAppSec WG. Wearing that (still phantom) hat, I can say is that there isn't consensus to move this proposed mechanism as a cross-domain framing security solution to FPWD, alone or as part of the CSP, in the WebAppSec WG, at this time. Until AC approval, we can't move anything to FPWD at this time. :) My other concerns with the proposal are put forward only as an interested member of the community. I expect there will be ample opportunity to discuss them. If Art feels that moving forward to FPWD is the best next step to foster that and other discussions, I'm more than happy to participate there to the extent the WG welcomes my feedback and finds it useful. Thanks, Brad Hill -Original Message- From: public-web-security-requ...@w3.org [mailto:public-web-security-requ...@w3.org] On Behalf Of Bjoern Hoehrmann Sent: Tuesday, July 05, 2011 4:38 PM To: Marcos Caceres Cc: WebApps WG; public-web-secur...@w3.org Subject: Re: Publishing From-Origin Proposal as FPWD * Marcos Caceres wrote: On Tue, Jul 5, 2011 at 5:50 PM, Hill, Brad bh...@paypal-inc.com wrote: 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. I note that the Web Applications Working Group's Charter, if Brad Hill is a member, does require the rest of the Working Group to duly consider his points before moving on without consensus. If not, then the group is not required to wait with publication, but not discussing the points in a timely manner, without an argument how publication is urgent in some way, does not inspire confidence that the arguments will be heard and duly handled. Publication will enable wider discussion - particularly wrt the issues you have raised. Not publishing it is tantamount to saying I OBJECT TO PROGRESS!. If you are correct, more people will see it and the proposal will be shot down. Otherwise, other opinions will flourish that may sway your position (or a new perspective will emerge all together). In any case, calling for a spec not to be published, no matter how bad it is, is not the right way to do this. Publishing a spec is just a formality which can lead to discussion. The more invested people are into something, the less likely they are to cut their losses; by doing things, you frame the discussion in favour of doing more. You get people to think more about how something can be fixed rather than thinking about whether to abandon the work, or use a very different approach. If you just propose an idea to me, we can talk about it more freely than if you had already invested a lot of effort on implementing the idea and asked me to review the idea after the fact. (~ Die normative Kraft des Faktischen) Realizing something is a bad idea early is therefore very important and not objecting to progress. Not wasting time on bad ideas is certainly progress, even if only indirectly as you'd work on other things instead. As such it is quite important to react timely to design critique with care and detail. Psychologically, if you press ahead, you communicate that you care more about moving on than discussing details, which is likely to turn away the people more interested in details and quality; and the same is of course true for draft of genuinely bad quality. Which is just to say this is actually an important matter; sometimes it is best to go ahead and put your ideas into practise whatever others may be saying, other times it turns out that you should have listened more. That is why we allow people to block actions, not necessarily progress, but only up to the point where arguments have been duly considered. And here we have yet to do that. Until that happens, short of someone making the case for urgency, I would agree the group should not publish and talk about this instead. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: Publishing From-Origin Proposal as FPWD
On 6/30/11 10:31 PM, ext Daniel Veditz wrote: On 6/30/11 9:31 AM, Maciej Stachowiak wrote: On Jun 30, 2011, at 7:22 AM, Anne van Kesteren wrote: (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.) I approve of publishing this as FWPD. I also don't think it makes sense to tie this to CSP. Conceptually it's similar to the CSP frame-ancestors directive--which we've decided doesn't fit in CSP either. Most of CSP is can load while frame-ancestors was can be loaded by. We've proposed that the frame-ancestors functionality be moved into an expanded/standardized X-Frame-Options mechanism, but a standardized From-Origin would work just as well (better?). It may still make sense to put From-Origin in the WebSecurity (not-quite) WG along with CORS rather than free floating in WebApps. But I don't have strong feelings about that. I don't feel strongly about the charter issue either. (As I understand it, CORS will be a joint deliverable between WebApps WG and WebAppSec WG and as such, my expectation is that both WGs will participate in decisions such as does the spec meet Last Call Working Draft requirements?.) Mozilla would be interested in implementing this feature regardless. This is good to read. Based on the feeback so far, I will start a CfC to publish a First Public Working Draft of Anne's spec. -Art Barstow [1] http://lists.w3.org/Archives/Public/www-tag/2011Jun/0192.html
RE: Publishing From-Origin Proposal as FPWD
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/
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/
Re: Publishing From-Origin Proposal as FPWD
On Jun 30, 2011, at 7:22 AM, Anne van Kesteren wrote: 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.) I approve of publishing this as FWPD. I also don't think it makes sense to tie this to CSP. Regards, Maciej
Re: Publishing From-Origin Proposal as FPWD
On 6/30/11 9:31 AM, Maciej Stachowiak wrote: On Jun 30, 2011, at 7:22 AM, Anne van Kesteren wrote: (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.) I approve of publishing this as FWPD. I also don't think it makes sense to tie this to CSP. Conceptually it's similar to the CSP frame-ancestors directive--which we've decided doesn't fit in CSP either. Most of CSP is can load while frame-ancestors was can be loaded by. We've proposed that the frame-ancestors functionality be moved into an expanded/standardized X-Frame-Options mechanism, but a standardized From-Origin would work just as well (better?). It may still make sense to put From-Origin in the WebSecurity (not-quite) WG along with CORS rather than free floating in WebApps. But I don't have strong feelings about that. Mozilla would be interested in implementing this feature regardless. -Dan Veditz
