- From: neil matatall <neil@matatall.com>
- Date: Thu, 8 Nov 2012 12:37:00 -0800
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <DF3FDCD49E6141D9AFD2BC54C17EFD6F@matatall.com>
[first post to the list, likely don't have all context, shame away] If accepted, how far do we take this idea? What about 'X-Content-Type-Options' as well? XFO - was that what the original 'frame-ancestors' was for? This seems like more of a stretch. These make logical sense to me at least, and would further reduce the number of X-headers. - FNG On Thursday, November 8, 2012 at 12:07 PM, Adam Barth wrote: > On Thu, Nov 8, 2012 at 12:01 PM, Hill, Brad <bhill@paypal-inc.com (mailto:bhill@paypal-inc.com)> wrote: > > As I’m here at the IETF, reviewing the websec’s charter statement and > > framework requirements, I note that one of the goals that drove the > > formation of both our WGs was to reduce fragmentation and duplication of > > security features and make it easier for resource owners to author policy > > through a consolidated, extensible mechanism. > > > > In that spirit, I wonder if another logical directive for CSP 1.1 might be > > to incorporate the features currently provide by “X-XSS-Protection”. It > > eliminates the need for another X- header, and seems like a logical fit. > > > > Would there be any interest in this from implementers who currently manage > > XSS filters in their browser? > > > > > Yes. > > Adam
Received on Thursday, 8 November 2012 21:24:30 UTC