Here are the comments I have so far on this charter, based on the thread. I'd note that this is a relatively large set of demands to make in the charter review stage at the AC, especially for a recharter of a WG that we're involved in. So it may come across to W3C staff as somewhat demanding.
I'm particularly interested in review of point (3) in what I've written;
I feel that the argument I've written so far is weak, I think because I
don't particularly understand the concerns about the powerfulfeatures
draft.
I also haven't included anything about Brian's objection to the
suborigin namespaces work because I don't understand the objection, and
I don't see how to extract any actionable charter feedback directly from
Brian's message. (Or is it that the deliverable should be removed from
the charter? If so, I could use an explanation as to why.)
In any case, here's the feedback I have so far. Comments are
welcome through roughly 5pm California time on Friday --
particularly actionable ones that suggest how to revise this
feedback or at least say how the charter should be different!
(Sorry for not getting this gathered together sooner.)
-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.
(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 (which may be comfortable with, although some of us
have serious concerns about whether it is actually workable), or
whether it's intended to put
https://w3c.github.io/webappsec/specs/powerfulfeatures/ in the scope
of the working group, which we believe should not be, because 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), and we believe that in general specifications
about how to write other specifications have not been successful,
particularly if they attempt to have any mandatory status.
At a minimum, it would be good to rephrase this item so that it
doesn't use the term "powerful features". It would probably be
preferable to explicitly state that work like the powerfulfeatures
draft is not in the scope of the working group.
(4) We believe the charter should have provision for asynchronous
decision making, perhaps as in
http://www.w3.org/2012/webapps/charter/#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
