From tlr@w3.org Thu Mar 3 14:31:55 2011 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7D663A687C for ; Thu, 3 Mar 2011 14:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETXgFX-aYJ3a for ; Thu, 3 Mar 2011 14:31:54 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id 992EA3A687B for ; Thu, 3 Mar 2011 14:31:54 -0800 (PST) Received: from [178.254.73.133] (helo=[192.168.2.115]) by jay.w3.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1PvH4w-0006Ze-1c; Thu, 03 Mar 2011 17:33:02 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Thomas Roessler Date: Thu, 3 Mar 2011 23:33:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0C6961A9-C367-42EF-BF1D-14A1B12E33E0@w3.org> References: <8B274F0B-5DDA-47F2-A014-67B105A3C13B@w3.org> To: websec@ietf.org X-Mailer: Apple Mail (2.1082) Subject: [websec] Fwd: W3C workshop on Web Tracking and User Privacy X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 22:31:56 -0000 FYI -- Thomas Roessler, W3C (@roessler) Begin forwarded message: > From: Thomas Roessler > Date: 3 March 2011 22:42:57 GMT+01:00 > To: public-privacy@w3.org > Cc: Thomas Roessler > Subject: W3C workshop on Web Tracking and User Privacy >=20 > Colleagues, >=20 > the call for participation for the W3C workshop on Web Tracking and = User Privacy is now published: > http://www.w3.org/2011/track-privacy/ >=20 > The position paper deadline is 25 March. The workshop is on 28/29 = April in Princeton. I look forward to having many of you there! >=20 > Thanks, > -- > Thomas Roessler, W3C (@roessler) >=20 >=20 From Jeff.Hodges@KingsMountain.com Fri Mar 4 05:47:45 2011 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06D883A69DF for ; Fri, 4 Mar 2011 05:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.593 X-Spam-Level: X-Spam-Status: No, score=-98.593 tagged_above=-999 required=5 tests=[AWL=-2.183, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_56=0.6, MANGLED_STOP=2.3, SARE_LWSHORTT=1.24, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eKgy+NBjmxJ for ; Fri, 4 Mar 2011 05:47:41 -0800 (PST) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 376093A69D7 for ; Fri, 4 Mar 2011 05:47:41 -0800 (PST) Received: (qmail 16769 invoked by uid 0); 4 Mar 2011 13:48:50 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 4 Mar 2011 13:48:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=It7igpPbGp1gBrOm5aCQiMrVAvH6Yp+Q0chhlguvESUi5lbBFjKsxKumFNYy4IL52bJASNYUA5/RiGPs2pX18vmvmFe4hK6JFCFuPGqUddgZfz0Nhk+8z8XienASiTmB; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PvVNB-0001rh-P4 for websec@ietf.org; Fri, 04 Mar 2011 06:48:50 -0700 Message-ID: <4D70EDC0.3000305@KingsMountain.com> Date: Fri, 04 Mar 2011 05:48:48 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: [websec] draft: draft-hodges-websec-framework-reqs-00 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 13:47:45 -0000 per the websec charter, we're supposed to produce a "HTTP Application Security Problem Statement and Requirements" document. the deadline for I-D -00 submission is this coming monday and I have a drafty draft to submit then. Here's it's present state in order to give you a bit of a heads up and chance (sorry it not much time) to quickly review before then (but this is just a -00 and this is to get discussion kicked off now and in Prague). =JeffH ------- Network Working Group J. Hodges Internet-Draft A. Steingruebl Intended status: Standards Track PayPal Expires: August 27, 2011 Feb 23, 2011 Web Security Framework: Problem Statement and Requirements draft-hodges-websec-framework-reqs-00 Abstract Web-based malware and attacks are proliferating rapidly on the Internet. New web security mechanisms are also rapidly growing in number, although in an incoherent fashion. This document provides a brief overview of the present situation and the various seemingly piece-wise approaches being taken to mitigate the threats. It then provides an overview of requirements as presently being expressed by the community in various online and face-to-face discussions. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 27, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Hodges & Steingruebl Expires August 27, 2011 [Page 1] Internet-Draft WebSec Framework Reqs Feb 2011 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. The Present State of Affairs . . . . . . . . . . . . . . . 3 2.2. High-level Use Cases . . . . . . . . . . . . . . . . . . . 4 3. Document Conventions . . . . . . . . . . . . . . . . . . . . . 5 4. Overall Constraints . . . . . . . . . . . . . . . . . . . . . 5 5. Overall Requirements . . . . . . . . . . . . . . . . . . . . . 6 6. Attacks and Threats to Address . . . . . . . . . . . . . . . . 8 6.1. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Detailed Functional Requirements . . . . . . . . . . . . . . . 11 9. Extant Policies to Coalesce? . . . . . . . . . . . . . . . . . 18 10. Example Concrete Approaches . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 13. Informative References . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Hodges & Steingruebl Expires August 27, 2011 [Page 2] Internet-Draft WebSec Framework Reqs Feb 2011 1. Introduction [ Please disscuss this draft on the websec@ietf.org mailing list [WebSec]. ] 2. Overview 2.1. The Present State of Affairs Over the past few years, we have seen a proliferation of AJAX-based web applications (AJAX being shorthand for asynchronous JavaScript and XML), as well as Rich Internet Applications (RIAs), based on so- called Web 2.0 technologies. These applications bring both luscious eye-candy and convenient functionality--e.g. social networking--to their users, making them quite compelling. At the same time, we are seeing an increase in attacks against these applications and their underlying technologies [1]. The latter include (but aren't limited to) Cross-Site-Request Forgery (CSRF) -based attacks [2], content- sniffing cross-site-scripting (XSS) attacks [3], attacks against browsers supporting anti-XSS policies [4], clickjacking attacks [5], malvertising attacks [6], as well as man-in-the-middle (MITM) attacks against "secure" (e.g. Transport Layer Security (TLS/SSL)-based [7]) web sites along with distribution of the tools to carry out such attacks (e.g. sslstrip) [8]. During the same time period we have also witnessed the introduction of new web security indicators, techniques, and policy communication mechanisms sprinkled throughout the various layers of the Web and HTTP. We have a new cookie security flag called HTTPOnly [9]. We have the anti-clickjacking X-Frame-Options HTTP header [10], the Strict-Transport-Security HTTP header [11], anti-CSRF headers (e.g. Origin) [12], an anti-sniffing header (X-Content-Type-Options: nosniff) [13], various approaches to content restrictions [14] [15] and notably Mozilla Content Security Policy (CSP; conveyed via a HTTP header) [16], the W3C's Cross-Origin Resource Sharing (CORS; also conveyed via a HTTP header) [17], as well as RIA security controls such as the crossdomain.xml file used to express a site's Adobe Flash security policy [18]. There's also the Application Boundaries Enforcer (ABE) [19], included as a part of NoScript [20], a popular Mozilla Firefox security extension. Sites can express their ABE rule-set at a well-known web address for downloading by individual clients [21], similarly to Flash's crossdomain.xml. Amidst this haphazard collage of new security mechanisms at least one browser vendor has even devised a new HTTP header that disables one of their newly created security features: witness the X-XSS-Protection header that disables the new anti-XSS features [22] in Microsoft's Internet Explorer 8 (IE8). Hodges & Steingruebl Expires August 27, 2011 [Page 3] Internet-Draft WebSec Framework Reqs Feb 2011 Additionally, there are various proposals aimed at addressing other facets of inherent web vulnerabilities, for example: JavaScript postMessage-based mashup communications [23], hypertext isolation techniques [24], and service security policies advertised via the Domain Name System (DNS) [25]. Going even further, there are efforts to redesign web browser architectures [26], of which Google Chrome and IE8 are deployed examples. An even more radical approach is exhibited in the Gazelle Web Browser [27], which features a browser kernel embodied in a multi-principal OS construction providing cross- principal protection and fair sharing of all system resources. Not to be overlooked is the fact that even though there is a plethora of "standard" browser security features--e.g. the Same Origin Policy (SOP), network-related restrictions, rules for third-party cookies, content-handling mechanisms, etc. [28]--they are not implemented uniformly in today's various popular browsers and RIA frameworks [29]. This makes life even harder for web site administrators in that allowances must be made in site security posture and approaches in consideration of which browser a user may be wielding at any particular time. Although industry and researchers collectively are aware of all the above issues, we observe that the responses to date have been issue- specific and uncoordinated. What we are ending up with looks perhaps similar to Frankenstein's monster [30]--a design with noble intents but whose final execution is an almost-random amalgamation of parts that do not work well together. It can even cause destruction on its own [31]. 2.2. High-level Use Cases From our perspective as web site security practitioners, we believe that in the intermediate term we have the goal of deplying web browsers featuring more coherent security properties than they do today. We feel that cooperatively working to address specific subsets of the overall problem space will yield measurable results for both site operators and our users. For example, we want to be able to deploy security policies for site- wide cookie handling, content restrictions, secure connection preferences, and various other things. We believe that continuing the current defacto practice of designing new, disjoint, HTTP headers for expressing individual facets of overall site security policies is not desirable for even the intermediate term. The individual headers, however expeditious in the near-term, should be replaced with a more generic, decarative, extensible, security policy expression and communication mechanism for the Web--a "website Hodges & Steingruebl Expires August 27, 2011 [Page 4] Internet-Draft WebSec Framework Reqs Feb 2011 security policy framework". This policy communication mechanism must be secure and should have two facets, one for communicating securely out-of-band of the HTTP protocol to allow for secure client policy store bootstrapping, and then another in-band over HTTP/HTTPS for ease of policy delivery, configuration, and to leverage existing deployments. For out-of-band secure client policy store bootstrapping, potential approaches are factory-installed web browser configuration, site security policy download a la Flash's crossdomain.xml and Maone's ABE for Web Authors [21], and DNS-based policy advertisement leveraging the security of DNS Security (DNSSEC) [32]. In general, what we are striving for is to provide web site administrators the tools for managing, in a least privilege [33] manner, the overall security characteristics of their web site/ applications when realized in the context of user agents. 3. Document Conventions Note: ..is a note to the reader. These are points that should be expressly kept in mind and/or considered. Warning: This is how a warning is shown. These are things that can have suboptimal downside risks if not heeded. [[XXXn: Some of the more major known issues are marked like this (where "n" in "XXXn" is a number). --JeffH]] [[TODOn: Things to fix (where "n" in "TODOn" is a number). --JeffH]] 4. Overall Constraints Regardless of the overall approaches chosen for conveying site security policies, we believe that to be deployed at Internet-scale, and to be as widely usable as possible for both novice and expert alike, the overall solution approach will need to address these three points of tension: Granularity: There has been much debate during the discussion of some policy mechanisms (e.g. CSP) as to how fine-grained such mechanisms should be. The argument against fine-grained mechanisms is that site administrators will cause themselves pain by instantiating policies that do not yield the intended results. E.g. simply copying the expressed policies of a similar site. Hodges & Steingruebl Expires August 27, 2011 [Page 5] Internet-Draft WebSec Framework Reqs Feb 2011 The claim is that this would occur for various reasons stemming from the mechanisms' complexity [34]. Configurability: Not infrequently, the complexity of underlying facilities, e.g. in server software, is not well-packaged and thus administrators are obliged to learn more about the intricacies of these systems than otherwise might be necessary. This is sometimes used as an argument for "dumbing down" the capabilities of policy expression mechanisms [34]. Usability: Research shows that when security warnings are displayed, users are often given too much information as well as being allowed to relatively easily bypass the warnings and continue with their potentially compromising activity [35] [36] [37] [38] [39]. Thus users have become trained to "click through" security notifications "in order to get work done", though not infrequently rendering themselves insecure and perhaps compromised [40]. In the next section we discuss various high-level requirements derived with the guidance of the latter tension points. 5. Overall Requirements 1. Policy conveyance: in-band: We believe that a regime based on HTTP header(s) is appropriate. However we must devise a generalized, extensible HTTP security header(s) such that the on-going "bloat" of the number of disjoint HTTP security headers is mitigated and there is a documented framework that we can leverage as new approaches and/or threats emerge. Note: The distinction between in-band and out-of-band signaling is difficult to characterize because some seemingly out-of-band mechanisms rely on the same protocols (HTTP/HTTPS) and infrastructure (transparent proxy servers) as the protocols they ostensibly protect. Hodges & Steingruebl Expires August 27, 2011 [Page 6] Internet-Draft WebSec Framework Reqs Feb 2011 It may be reasonable to devise a small set of headers to convey different classes of policies, e.g. web application content policies versus web application network capabilities policies. out-of-band: This policy communication mechanism must be secure and should have two facets, one for communicating securely out- of-band of the HTTP protocol to allow for secure client policy store bootstrapping. potential approaches are factory-installed web browser configuration, site security policy download a la Flash's crossdomain.xml and Maone's ABE for Web Authors [21], and DNS-based policy advertisement leveraging the security of DNS Security (DNSSEC) [32]. 2. Granularity: In terms of granularity, vast arrays of stand-alone blog, wiki, hosted web account, and other "simple" web sites could ostensibly benefit from relatively simple, pre-determined policies. However, complex sites--e.g. payment, ecommerce, software-as-a-service, mashup sites, etc.--often differ in various ways, as well as being inherently complex implementation-wise. One-size-fits-all policies will generally not work well for them. Thus, we believe that to be effective for a broad array of web site and application types, the policy expression mechanism must fundamentally facilitate fine-grained control. For example, CSP offers such control. In order to address the less complex needs of the more simple classes of web sites, the policy expression mechanism could have a "macro"-like feature enabling "canned policy profiles". Or, the configuration facilities of various components of the web infrastructure can be enhanced to provide an appropriately simple veneer over the complexity. 3. Configurability: With respect to configurability, development effort should be applied to creating easy-to-use administrative interfaces addressing the simple cases, like those mentioned above, while providing advanced administrators the tools to craft and manage fine-grained multi-faceted policies. Thus more casual or novice administrators can be aided in readily choosing, or be provided with, safe default policies while other classes of sites have the tools to craft the detailed policies they require. Examples of such an approach are Microsoft's Hodges & Steingruebl Expires August 27, 2011 [Page 7] Internet-Draft WebSec Framework Reqs Feb 2011 "Packaging Wizard" [41] that easily auto-generates a quite complicated service deployment descriptor on behalf of less experienced administrators, and Firefox's simple Preferences dialog [42] as compared to its detailed about:config configuration editor page [43]. In both cases, simple usage by inexperienced users is anticipated and provided for on one hand, while complex tuning of the myriad underlying preferences is provided for on the other. 4. Usability: Much has been learned over the last few years about what does and does not work with respect to security indicators in web browsers and web pages, as noted above, these lessons should be applied to the security indicators rendered by new proposed security mechanisms. We believe that in cases of user agents venturing into insecure situations, their response should be to fail the connections by default without user recourse, rather than displaying warnings along with bypass mechanisms, as is current practice. For example, the Strict Transport Security specification stipulates the former hard-fail behavior. 6. Attacks and Threats to Address This section enumerates various attacks and threats that ought to be mitigated by a web security policy framework. In terms of defining threats in contrast to attacks, Lucas supplied this: <"Re: More on XSS mitigation (was Re: XSS mitigation in browsers)" (Lucas Adamski). http://lists.w3.org/Archives/Public/ public-web-security/2011Jan/0089.html> "... There's a fundamental question about whether we should be looking at these problems from an attack vs threat standpoint. An attack is XSS [or CSRF, or Response Splitting, etc.]. A threat is that an attacker could compromise a site via content injection to trick the user to disclosing confidential information (by injecting a plugin or CSS to steal data or fool the user into sending their password to the attacker's site). ..." 6.1. Attacks The below attacks should be mitigated by a web application security framework (see [44] for a definition and taxonomy of attacks): Hodges & Steingruebl Expires August 27, 2011 [Page 8] Internet-Draft WebSec Framework Reqs Feb 2011 1. cross-site-scripting (XSS) [2] [44] 2. Cross-Site-Request Forgery (CSRF) [3] [44] 3. Man-in-the-middle (MITM) attacks against "secure" (e.g. Transport Layer Security (TLS/SSL)-based [7] [8] [44]) web sites 4. Response Splitting [44] 5. more (ie eg from [44] ?) ? 6.2. Threats Via the attacks above, an attacker can.. 1. Obtain a victim's confidential web application credentials (e.g. cookie theft), and use the credentials to impersonate the victim and enter into transactions, often with the aim of monetizing the transaction results to the attacker's benefit. 2. Insert themselves as a Man-in-the-Middle (MITM) between victim and various services, thus is able to instigate, control, intercept, and attempt to monetize various transactions and interactions with web applications, to the benefit of the attacker. 3. Enumerate various user agent information stores, e.g. browser history, facilitating views of the otherwise confidential habits of the victim. This information could possibly be used in various offline attacks against the victim directly, e.g. blackmail, denial of services, law enforcement actions, etc. 4. Use gathered information and credentials to construct and present a falsified persona of the victim (e.g. for character assassination). There is a risk of exfiltration of otherwise confidential victim information with all the threats listed above. 7. Use Cases This section outlines various concrete use cases. Where applicable, source email messages are cited. 1. I'm a web application site administrator. My web app includes static user-supplied content (e.g. submitted from user agents via HTML FORM + HTTP POST), but either my developers don't properly Hodges & Steingruebl Expires August 27, 2011 [Page 9] Internet-Draft WebSec Framework Reqs Feb 2011 sanitize user-supplied content in all cases or/and content injection vulnerabilities exist or materialize (for various reasons). This leaves my web app vulnerable to cross-site scripting. I wish I could set overall web app-wide policies that prevent user- supplied content from injecting malicious content (e.g. JavaScript) into my web app. 2. I'm a web application site administrator. My web application is intended, and configured, to be uniformly served over HTTPS, but my developers mistakenly keep including content via insecure channels (e.g. via HTTP-only; resulting in so-called "mixed content"). I wish I could set a policy for my web app that prevents user agents from loading content insecurely even if my web app is otherwise telling them to do so. 3. I'm a web application site administrator. My site has a policy that we can only include content from certain trusted providers (e.g., our CDN, Amazon S3), but my developers keep adding dependencies on origins I don't trust. I wish I could set a policy for my site that prevents my web app from accidentally loading resources outside my whitelist. 4. I'm a web application site administrator. I want to ensure that my web app is never framed by other web apps. 5. I'm a developer of a web application which will be included (i.e. framed) by third parties within their own web apps. I would like to ensure that my web app directs user agents to only load resources from URIs I expect it to (possibly even down to specific URI paths), without affecting the containing web app or any other web apps it also includes. 6. I'm a web application site administrator. My web app frames other web apps whose behavior, properties, and policies are not 100% known or predictable. I need to be able to apply policies that both protect my web app from potential vulnerabilities or attacks introduced by the framed web apps, and that work to ensure that the desired interactions between my web app and the framed apps are securely realized. Hodges & Steingruebl Expires August 27, 2011 [Page 10] Internet-Draft WebSec Framework Reqs Feb 2011 8. Detailed Functional Requirements Many of the below functional requirements are extracted from a recent discussion on the [public-web-security] list. Particular messages are cited inline and appropriate quotes extracted and reproduced here. Inline citations are provided for definitions of various terms. 1. Policy expression syntax: * Declarative. <"declarative languages". http://www.encyclopedia.com/ doc/1O11-declarativelanguages.html> * Extensible. <"Extensibility". https://secure.wikimedia.org/wikipedia/en/wiki/Extensible> <"Re: XSS mitigation in browsers" (Lucas Adamski). http:// lists.w3.org/Archives/Public/public-web-security/2011Jan/ 0066.html> "On a conceptual level, I am not really a believer in the current proliferation of orthogonal atomic mechanisms intended to solve very specific problems. Security is a holistic discipline, and so I'm a big supporter of investing in an extensible declarative security policy mechanism that could evolve as the web and the threats that it faces do. Web developers have a hard enough time with security already without being expected to master a potentially large number of different security mechanisms, each with their own unique threat model, implementation and syntax. Not to mention trying to figure out how they're expected to interact with each other... how to manage the gaps and intersections between the models." <"Re: Scope and complexity (was Re: More on XSS mitigation)" (Adam Barth). http://lists.w3.org/Archives/Public/ public-web-security/2011Jan/0108.html> "I guess I wish we had an extensibility model more like HTML where we could grow the security protections over time. For example, we can probably agree that both and