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

Re: WebAppSec re-charter status

From: Jeffrey Yasskin <jyasskin@google.com>
Date: Fri, 6 Feb 2015 14:58:45 -0800
Message-ID: <CANh-dXnMrvQQ0S00g+-56+23DY5GhwPNnY0yUCq8WHHb4_TOrA@mail.gmail.com>
To: 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>
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 Friday, 6 February 2015 22:59:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:10 UTC