Re: WebAppSec re-charter status

+dveditz, dbaron, annevk from Mozilla. Hi!

On Wed, Feb 4, 2015 at 1:16 PM, Wendy Seltzer <wseltzer@w3.org> wrote:

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

+Deian, perhaps you can come up with a paragraph or so clarifying the
proposed deliverable?


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

+David (Ross), FYI. I share the concern, and though I think it's mostly
outweighed by the security benefits ERP promises, I'd certainly support
adding such text to the charter.


> > (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).
>

+Mounir, FYI.


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

I mostly agree with Anne's suggestions at
https://groups.google.com/d/msg/mozilla.dev.platform/yEqC74IgnqQ/eYOJGtXCEEsJ
that
we've collectively made some bad decisions in the past. I don't see the
suggestions in the powerful features spec as "policing" other
specifications so much as providing a framework in which other
specifications can (and should) make decisions. I would certainly prefer
that they had normative strength, however.

Note that the TAG's https://w3ctag.github.io/web-https/#implementation suggests
that WebAppSec document best practices here, and mnot@ agreed with the
value of having a normative doc at
https://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0344.html.
Would structuring the document as a joint deliverable allay concerns that
WebAppSec is attempting a coup?


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


This seems to be coming to a nice resolution in
https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0085.html.

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)