- From: Wendy Seltzer <wseltzer@w3.org>
- Date: Mon, 2 Feb 2015 18:36:29 -0500
- To: www-archive@w3.org
Forwarded to public archive with permission from David Baron. ----- Forwarded message from David Baron via WBS Mailer <sysbot+wbs@w3.org> ----- Date: Fri, 30 Jan 2015 23:24:01 +0000 From: David Baron via WBS Mailer <sysbot+wbs@w3.org> To: dbaron@XXXXX, w3t-archive@w3.org, w3c-archive@w3.org Subject: [wbs] response to 'Call for Review: Web Application Security Working Group' The following answers have been successfully submitted to 'Call for Review: Web Application Security Working Group' (Advisory Committee) for Mozilla Foundation by David Baron. The reviewer's organization suggests changes to this Charter, and only supports the proposal if the changes are adopted [Formal Objection]. Additional comments about the proposal: There are a number of problematic aspects to this charter to which we object: (1) The "Confinement with Origin Web Labels" deliverable is described in a way that makes it unclear what the deliverable would do. It should be clearer. Furthermore, the lack of clarity means we couldn't evaluate whether we are comfortable with it being in the charter. (2) The "Entry Point Regulation for Web Applications" deliverable seems to have serious risks of breaking the ability to link. It's not clear that the security benefits of this specification outweigh the risks to the abilities of Web users. At the very least, the charter should be explicit that the group may decide not to complete this item because of these tradeoffs. (3) In the scope section, the item "Application awareness of powerful features which may require explicit user permission to enable." It's not clear whether this part of the scope is intended to allow https://w3c.github.io/permissions/ to be a document in the working group, or whether it's intended to put https://w3c.github.io/webappsec/specs/powerfulfeatures/ in the scope of the working group. (I've heard separately that the powerfeatures draft was intended to be in the charter as a deliverable but was accidentally omitted.) It seems like this probably refers to the Permissions API spec, and if it does, it would probably be best to avoid the use of the term "powerful features" to avoid confusion. We may be comfortable with the Permissions API spec, although some of us have concerns about it, and for that perhaps the charter should be explicit about potentially abandoning the work as in point (2). We have more serious concerns about the scope of the powerfulfeatures spec. In particular, we don't believe the WebAppSec WG should be in the role of policing the specifications of other groups (which is not the role it has historically held) or defining general (and likely overly-broad) rules to determine when a feature has an important effect on a user's privacy or security. Therefore, we would like to see producing enforceable definitions of what is a powerful feature as explicitly out of scope for the Web Application Security WG, since that determination should be made primarily by the working group developing the feature, perhaps in consultation with the Web Application Security WG. (4) We believe the charter should have provision for asynchronous decision making, perhaps as in http://www.w3.org/2014/06/webapps-charter.html#decisions . The reviewer's organization intends to participate in these groups: - Web Application Security Working Group The reviewer's organization: - intends to review drafts as they are published and send comments. - intends to develop experimental implementations and send experience reports. - intends to develop products based on this work. - intends to apply this technology in our operations. Answers to this questionnaire can be set and changed at https://www.w3.org/2002/09/wbs/33280/WebAppSec-Recharter-2015/ until 2015-01-30. Regards, The Automatic WBS Mailer
Received on Monday, 2 February 2015 23:36:30 UTC