A new version of the charter has been uploaded that hopefully addresses these objections
On Thu, Jan 29, 2015 at 10:32 PM, L. David Baron <dba...@dbaron.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. > Brian's objections seem to be to a different "sub-origin" proposal from Joel Weinberger of Google. COWL is essentially a data-tainting proposal that builds on the capabilities of CSP to make it safer to use 3rd party libraries and mashups. Having it in the charter is not a commitment that Mozilla will implement this, but it's a promising idea and having it in the charter means it's in scope for WASWG to discuss it. Here's a slide deck explaining COWL: http://cowl.ws/talks/cowl-w3c.pdf A more detailed paper (co-authored by Mozilla's own Dave Herman): http://www.scs.stanford.edu/~deian/pubs/stefan:2014:protecting.pdf (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. > The Working Group is also concerned that we not break the ability to do links on the web. We have added that as an explicit requirement in the charter. This work item is the most nebulous item in the charter. It has some promising ideas that could help prevent CSRF type attacks; it might also turn out to be completely unworkable and be dropped. We'd like it to be in the charter so we can explore these concepts under the W3 IPR commitments of the WG members. > (3) > [...] It's not clear whether this part of the scope is intended to put > [...] > https://w3c.github.io/webappsec/specs/powerfulfeatures/ in the scope > of the working group, which we believe should not be, because 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), and we believe that in general specifications > about how to write other specifications have not been successful, > particularly if they attempt to have any mandatory status. > This item was indeed a reference to the Powerful Features spec, which has been explicitly added to the deliverables section. The Web Application Security WG has been directed by the TAG to "document best practices" on this (http://www.w3.org/2001/tag/doc/web-https). The charter has been clarified to note that only the "algorithm for determining if a given context is sufficiently secure" will be normative, and advice on when a feature might designate itself as requiring a secure context will be non-normative. (4) We believe the charter should have provision for asynchronous > decision making, perhaps as in > http://www.w3.org/2012/webapps/charter/#decisions . > The charter was amended to add this. It's no change in practice but it's nice to have it documented. Updated charter: https://w3c.github.io/webappsec/admin/webappsec-charter-2015.html Diffs: https://github.com/w3c/webappsec/commit/433dcc996c092309b88c4e1ecad425ea80a49aed -Dan Veditz _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
