I wouldn't expect major obstacles from the W3C side to having Tobias participate there. -- Thomas Roessler, W3C <[email protected]> (@roessler)
On 2012-07-19, at 21:51 +0200, David Ross wrote: > #1 – fair point > #2 – I was worried that the current mechanism was multi-origin only, but it > sounds like that’s not the case. If so, this is good. > > NIH doesn’t sound like a great reason at all. > > Question for Tobias -- with a move to push this from the IETF to the W3C/CSP, > given your IETF affiliation would you still be able to contribute time to > this project? (Sorry if that’s an exceedingly blunt question, I’m not trying > to step on toes here.) Your work here thus far has been absolutely > invaluable and has allowed XFO/FO to make forward progress with very little > overhead. I really don’t want to lose the momentum. > > Dave > > > From: Adam Barth [mailto:[email protected]] > Sent: Wednesday, July 18, 2012 4:17 PM > To: David Ross > Cc: Hill, Brad; Tobias Gondrom; [email protected] > Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety directives > > Here are two reasons we should make Frame-Options into a > Content-Security-Policy directive rather than yet-another-one-off-HTTP-header: > > 1) By centralizing all the policy bits in one string, we gain network > benefits. For example, in the Chrome extension system, we have a field in > the manifest for specifying a Content Security Policy: > > http://code.google.com/chrome/extensions/contentSecurityPolicy.html > > While we could add a new attribute for every different bit of policy, it's > better for developers if there's just one place that contains the security > policy. > > 2) By moving Frame-Options into CSP, we can use the same origin-specifying > machinery that already exists in CSP rather than inventing > yet-another-way-of-specifying origins (e.g., in allow-from in the current > Frame-Options draft). By doing that, we make all these things work the same > way rather than siloing each off depending on which browser vendor first > decided this bit of policy was interesting. > > As far as I can tell, the main reason for not making Frame-Options a CSP > directive is that CSP was Not Invented Here. > > Adam > > > On Wed, Jul 11, 2012 at 5:22 PM, David Ross <[email protected]> wrote: > Responding to a few of the points in Brad's original mail on this thread... > > My concern is mostly around the degree to which a move to CSP might > complicate or stall the process. I'd also prefer not to see additional use > cases pop up (eg: click fraud prevention) that just were never in scope > before. > > I think that w.r.t. header bloat, the most sensible approach is to only allow > one origin to be specified. CSP by-design facilitates the use of multiple > origins. As we've discussed w/Frame-Options, there is a design pattern to > make the more basic single-origin approach functional. I would hate to see > hosts serving up source lists of hundreds of origins, just because they can. > I think that is exactly what will happen if we support multiple origins. > > With regard to obsolescence of X-FRAME-OPTIONS, it's easy to specify exactly > what happens in the FRAME-OPTIONS spec. I don't see that CSP inherently > improves on that but I may be missing something there. > > The advantage I see of bringing FRAME-OPTIONS into CSP is that it makes CSP > more comprehensive. But I suspect there are plenty of other header-related > security features that aren't defined by CSP (eg: the origin header, cookie > security). > > Finally, as Brad pointed out in the rosetta stone thread, Frame-Options > provides the flexibility to perform only a top level origin check as opposed > to a full ancestor check. (Specified via the "AllAncestors" flag.) > > David Ross > [email protected] > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Hill, Brad > Sent: Monday, July 09, 2012 5:03 PM > To: Tobias Gondrom; [email protected] > Cc: [email protected] > Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety directives > > Tobias, > > I'm happy to move the discussion primarily to websec, and I'll drop the cc: > to webappsec after this email. Thanks for the historical clarification, as > well. > > I'm not terribly concerned about which group does the work, as much as > arriving at the engineering solution that works best for user agent and > resource authors, some of whom have expressed preference for moving this > functionality into CSP. As both a chair and an individual, I don't have a > strong preference, but I think there are reasons in favor of each option and > it is worth re-opening the discussion now that the WebAppSec WG has a > concrete deliverable under development to address the same general class of > attacks. > > I'll send out a summary shortly of the similarities and differences between > the various options currently proposed for some additional context. > > -Brad Hill > > > > > _______________________________________________ > websec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/websec > > > _______________________________________________ > websec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/websec > > _______________________________________________ > websec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/websec
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
