Team Report on WebAppSec Charter Formal Objection

 

Status: Shared with Council March 10, 2022. Draft shared with Commenters and WG Chairs 2 March-9 March, 2022, for review. Public.

Procedural History

• Call for Review to the Advisory Committee on June 9, 2021 .
• Results  of the Advisory Committee review. Review ended on July 9, 2021.
• Proposed WG Charter  as reviewed by the AC
• Revised and final charter
• Diff file between the proposed and final versions
• WebAppSec Group Charters history
• Group Publications

After discussion in the Web Application Security Working Group, and with the support of the WG, Team proposed a re-charter  to the Advisory Committee for review (2021-06-09 through 2021-07-09). The charter got 17 reviews:

• 14 votes of support (one with suggested editorial changes)
• 2 Formal Objections: Mozilla and 51Degrees
• 1 “does not support … but is not raising a Formal Objection” ([ Member1 ], echoing Mozilla’s FO)

This Council is considering only Mozilla’s Formal Objection.

The Working Group Charter

The Web Application Security Working Group (WebAppSec) has been operating since 2011. Its precise scope contours have evolved, supporting an ongoing mission “ to develop mechanisms and best practices which improve the security of Web Applications.” The WG has 97 participants  from 26 organizations, including 6 invited experts.

The re-charter proposed to the AC added some new deliverables from incubation and adopted Patent Policy 2020. As Team informed the AC at the time: “The WG has adopted three specs from incubation that fit with the group's prior scope: Trusted Types, Change Password URL, and Fetch Metadata.  The WG may also do maintenance on the existing WebCrypto API.  Most specs will now be published as CR snapshots.”

The Formal Objections

Mozilla Formally Objected, and sent their objection to public-new-work .

We have filed a GitHub issue on the charter prior to this survey response with our concerns with a number of the deliverables listed in the charter:

https://github.com/w3c/webappsec/issues/595

There appears to be some progress with considering dropping many of the deliverables we have asked to be dropped, however it’s worth listing those here explicitly (please see the GitHub issue for details about why each of these should be dropped from the charter)

* Trusted Types

* Content Security Policy: Embedded Enforcement. In particular, we’d like to see maintenance on CSP, but no new features at this point.

* Subresource Integrity Level 2

* Suborigins

* Origin Policy

In general, we believe that specs should only be put on the standards track (included as a Working Group deliverable towards a Recommendation) when there is at least some explicit *interest* from two or more practical (web impactful) implementations.

We request that specs be dropped that have shown interest from only one implementer, otherwise we are at risk of a single-implementation spec, which will only ever serve as documentation (i.e. not an actual open standard), as we know that monoculture based standards end-up becoming de facto, based on the one specific implementation’s details, bugs, interpretations, and not what is written in a specification.

[ Member1] states: “We agree in general with Mozilla's objection—"that specs should only be put on the standards track (included as a Working  Group deliverable towards a Recommendation) when there is at least some explicit *interest* from two or more practical (web impactful) implementations."”

 

Discussion and Lack of Consensus

Mozilla raised some of its concerns on GitHub , where, after discussion, participants in the WG reached consensus to remove all but one of the deliverables Mozilla had identified as problematic, namely SRI2, Suborigins, and Origin Policy, and CSPEE. These other deliverables had been listed in prior charters, but had not seen recent activity. The non-Mozilla co-chair concluded  that those specs could continue to incubate in WICG (SRI2, Suborigins, and Origin Policy) or be published as Note (CSPEE), because he recognized there was not significant interest/activity in the WG.    

The WG held an ad hoc call  on August 17, 2021, regarding Trusted Types, in which proponents and objecters participated. The chairs did not identify a  consensus position on this deliverable nor on the meta-issue, Mozilla’s request “that specs should only be put on the standards track (included as a Working Group deliverable towards a Recommendation) when there is at least some explicit *interest* from two or more practical (web impactful) implementations .”

Discussion continued on the github thread of a CfC to publish Trusted Types: https://github.com/w3c/webappsec-trusted-types/issues/342  

Analysis

Arguments against Rec-track inclusion of Trusted Types:

• Its inherent complexity makes it difficult to adopt by the long tail of websites.
• Only one implementation currently exists (Chromium), and other implementers have not shown explicit interest.

Arguments for Rec-track inclusion of Trusted Types:

• Trusted Types ( conceptual explanation ) is a browser API that enables web applications to prevent DOM-based Cross-Site Scripting (DOM XSS), one of the most prevalent web application security vulnerabilities. See Trusted Types - mid 2021 report .
• It is supported by several popular frameworks and libraries. Id.  Those can take some of the development burden off application developers.
• Trusted Types can be useful for web applications that migrate to it, without negatively impacting those that do not.
• Microsoft has shared their experience in Edge: Eliminating XSS from WebUI with Trusted Types | Microsoft Browser Vulnerability Research .
• TAG was satisfied  in design review.
• Public discussions have already helped shape and improve the API; WebAppSec WG provides a good place to continue discussions. Rec-track advancement will still be evaluated for implementation experience.