- From: Mike West <mkwst@google.com>
- Date: Thu, 5 Feb 2015 09:11:44 +0100
- To: 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>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAKXHy=cMFETkWGqs0n_0nBtrQO1ZFcn3Zb5QxyZMZ2Ti-O59+A@mail.gmail.com>
+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.)
Received on Thursday, 5 February 2015 08:12:33 UTC