W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: WebAppSec re-charter status

From: Brad Hill <hillbrad@gmail.com>
Date: Sun, 08 Feb 2015 22:58:38 +0000
Message-ID: <CAEeYn8hwS0JGuQsYaqX7tXq3i64t=sQBpp-wtLhsOWcK6Mp3rQ@mail.gmail.com>
To: Jeffrey Yasskin <jyasskin@google.com>, Mike West <mkwst@google.com>
Cc: Wendy Seltzer <wseltzer@w3.org>, Deian Stefan <deian@cs.stanford.edu>, David Ross <drx@google.com>, Dan Veditz <dveditz@mozilla.com>, Mounir Lamouri <mlamouri@google.com>, David Baron <dbaron@dbaron.org>, Anne van Kesteren <annevk@annevk.nl>, "public-webappsec@w3.org" <public-webappsec@w3.org>
I've pushed some edits to the proposed charter to address these objections
based on this discussion:


Diff here:


What do folks think?


On Fri Feb 06 2015 at 3:01:51 PM Jeffrey Yasskin <jyasskin@google.com>

> On Thu, Feb 5, 2015 at 12: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:
> ...
>> >      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?
> Chiming in as the editor of the Web Bluetooth spec: Our CG has consensus
> that we want to restrict our feature to "secure origins", whatever that
> means. I'd much rather WebAppSec figure out how to specify that than have
> to make up my own probably-incorrect definition. So, at minimum, we need
> the definition of
> https://w3c.github.io/webappsec/specs/powerfulfeatures/#sufficiently-secure-context
> to be in the scope of their charter. I don't think we care whether
> WebAppSec defines what a powerful feature is, since we'd opt into their
> recommendation regardless.
> Jeffrey
Received on Sunday, 8 February 2015 22:59:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:46 UTC