[fwd] [wbs] response to 'Call for Review: Web Application Security Working Group'

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

(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

     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
    - 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


  The Automatic WBS Mailer

Received on Monday, 2 February 2015 23:36:30 UTC