2021-2023 charter feedback

[annevk]

Overall this charter looks good, but I'd like to push back on a few items and request the addition of one other item. I'd like to push back on:

• Trusted Types. See the discussion in https://github.com/w3c/webappsec-trusted-types/issues/342. Mozilla does not think this is fit for the long tail of websites.
• Content Security Policy: Embedded Enforcement. Essentially the same concern. CSP itself does not have broad adoption and industry buy-in, it seems too soon to standardize relatively large enhancements.
• Subresource Integrity Level 2. It's not clear anyone is working on this and I don't think there's a concrete proposal. Until that changes I'd rather not list it as a deliverable.
• Suborigins. Same.
• Origin Policy. Same.

And then it seems to me that Document Policy (to be renamed) should be listed as deliverable, to make it explicit what the group will be working on.

[shhnjk]

• Trusted Types. See the discussion in CfC to publish as an FPWD. webappsec-trusted-types#342. Mozilla does not think this is fit for the long tail of websites.

I’ve summarized the concept and the background of Trusted Types here. IMO, Trusted Types is a reasonable solution for things that can’t be covered by CSP. Furthermore, it’s a strong mitigation for SPAs against XSS, where there is only chance of DOM-based XSS.

Trusted Types is something that is proven to work in Google against DOM-based XSS, and I think it’s better to work on something that is known to solve the problem we have, rather than invent a new solution to the same problem.

[mikewest]

Hey Anne, apologies for the delayed response, and thanks for engaging here.

• On Trusted Types, I responded on the FPWD discussion to the claims made there. Here, you raise an additional concern about the mechanism's fitness for the long tail of websites. Assume for the moment that the claim is entirely true: that doesn't seem to me to be either a requirement or a top-level goal of the group. We're chartered to "develop security and policy mechanisms to improve the security of Web Applications", without a qualifier on application size. A mechanism's appropriateness for sites more generally doesn't seem material.

  But I also contest the claim: the story around libraries and frameworks in @koto's recent status update seems to support an alternative claim that web developers more generally will benefit from Trusted Types without having to rely upon it directly.

  Either way, the mechanism seems quite clearly in scope.

• I don't believe that SRI2, Suborigins, and Origin Policy were ever published by the group. I don't have any problem continuing to iterate on those via WICG when folks find time to do so. Dropping them as deliverables from the charter is pretty reasonable.

• Adopting Document Policy likewise seems reasonable, as it's split from work the group has previously published and is approaching maturity thanks to engagement from folks like you. :)

• CSPEE is somewhat harder. I agree that no one is working on the spec, but the mechanism does have usage in the wild, and has already been published by the group at https://www.w3.org/TR/csp-embedded-enforcement/. Still, given the state of the spec, I wouldn't object to shifting the published document to a NOTE, and moving the ED from the webappsec group to the WICG.

I think that leaves only Trusted Types as a point of disagreement?

[samuelweiler]

Thanks @annevk for raising the concerns, @shhnjk for details re: TT, and @mikewest for responding in detail. (And thanks to all of you for showing that I made the wrong call on https://github.com/w3c/webappsec/issues/590.)

I'll put together a PR for everything except TT. For TT, I'm continuing the discussion over at https://github.com/w3c/webappsec-trusted-types/issues/342#issuecomment-879166972

[mozfreddyb]

Thanks folks. We agree that Trusted Types is the remaining point of disagreement. Let's continue over there.

[plehegar]

closing since this is old and we have a new charter discussion anyway