Re: WebAppSec re-charter status

On Thu, Feb 5, 2015 at 8:11 AM, Mike West <mkwst@google.com> wrote:

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

I'm much more concerned by the notion that it would be up to individual WGs
to define what a "powerful feature" is without review.

The TAG could either facilitate these discussions, help define (or approve)
of stable criteria, or perhaps serve as a way to adjudicate the question.

+dka so that we can discuss at next week's call.


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