- From: Alex Russell <slightlyoff@google.com>
- Date: Thu, 5 Feb 2015 12:44:45 +0000
- 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>, "www-tag@w3.org List" <www-tag@w3.org>, Daniel Appelquist <appelquist@gmail.com>
- Message-ID: <CANr5HFUZPcOX_WMy4oeV4qPAP-X83v=yf1xh4mYRM4r8J9Qffw@mail.gmail.com>
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. > >
Received on Thursday, 5 February 2015 12:45:47 UTC