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)
signature.asc
Description: Digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
