Please note the need to liaise with the groups that are affected by the permissions work. Otherwise, this is good.
On Fri, Jan 30, 2015 at 3:20 PM, L. David Baron <dba...@dbaron.org> wrote: > Here's a revised set of comments, mainly changing: > > - describes the objection to powerfulfeatures (part of objection (3)) > more clearly, but also, I think, scopes the objection a bit more > narrowly > > - makes objection (2) more explicit about being satisfied by an > option not to complete the work > > -David > > 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 . > > -- > 𝄞 L. David Baron http://dbaron.org/ 𝄂 > 𝄢 Mozilla https://www.mozilla.org/ 𝄂 > Before I built a wall I'd ask to know > What I was walling in or walling out, > And to whom I was like to give offense. > - Robert Frost, Mending Wall (1914) > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
