Daniel Veditz <dved...@mozilla.com> wrote: > 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.
Yes, I agree I was mistaken. You can read more about COWL at http://cowl.ws/. Note, in particular, that the prototype is a modification of Firefox. Also note this acknowledgement from the second COWL paper: "We thank Bobby Holley, Blake Kaplan, Ian Melven, Garret Robinson, Brian Smith, and Boris Zbarsky for helpful discussions of the design and implementation of COWL." > (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. I think it would be good to work out how much of the problem is solved by same-origin cookies and related things, and how much is left over for EPR to solve, before the working group dives into EPR. EPR and CSP pinning look like they have a lot of overlap with app manifests. > 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. I think that "Powerful Features" is a terrible name, but I support the webappsec work on it. Cheers, Brian _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
