Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
I support this recharter (disclaimer: I'm a co-chair so of course I do). -Dan Veditz On Fri, Feb 22, 2019 at 5:29 PM L. David Baron wrote: > The W3C is proposing a revised charter for: > > Web Application Security (WebAppSec) Working Group > https://www.w3.org/2019/02/webappsec-2019-proposed-charter.html > https://lists.w3.org/Archives/Public/public-new-work/2019Feb/0010.html > > Mozilla has the opportunity to send comments or objections through > Friday, March 15. > > Please reply to this thread if you think there's something we should > say as part of this charter review, or if you think we should > support or oppose it. Given our involvement, we should probably > have some comment, even if it's simply in support. > > A comparison with the current charter is: > > https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2011%2Fwebappsec%2Fcharter-2017.html&doc2=https%3A%2F%2Fwww.w3.org%2F2019%2F02%2Fwebappsec-2019-proposed-charter.html > and the document's own summary of the changes is: > > Added Feature Policy > > Dropped User Interface Security and the Visibility API, > Confinement with Origin Web Labels > > Origin-Wide Policy becomes Site-Wide Policy > > (I'm happy about the addition of Feature Policy, since I think it's > important for, among other things, improvements to permission > prompts triggered from iframes.) > > -David > > -- > π L. David Baron http://dbaron.org/ π > π’ Mozilla https://www.mozilla.org/ π > Before I built a wall I'd ask to know > What I was walling in or walling out, > And to whom I was like to give offense. >- Robert Frost, Mending Wall (1914) > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
The W3C is proposing a revised charter for: Web Application Security (WebAppSec) Working Group https://www.w3.org/2019/02/webappsec-2019-proposed-charter.html https://lists.w3.org/Archives/Public/public-new-work/2019Feb/0010.html Mozilla has the opportunity to send comments or objections through Friday, March 15. Please reply to this thread if you think there's something we should say as part of this charter review, or if you think we should support or oppose it. Given our involvement, we should probably have some comment, even if it's simply in support. A comparison with the current charter is: https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2011%2Fwebappsec%2Fcharter-2017.html&doc2=https%3A%2F%2Fwww.w3.org%2F2019%2F02%2Fwebappsec-2019-proposed-charter.html and the document's own summary of the changes is: Added Feature Policy Dropped User Interface Security and the Visibility API, Confinement with Origin Web Labels Origin-Wide Policy becomes Site-Wide Policy (I'm happy about the addition of Feature Policy, since I think it's important for, among other things, improvements to permission prompts triggered from iframes.) -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla https://www.mozilla.org/ π Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Wed, Feb 11, 2015 at 2:02 AM, Mike West wrote:
>
>
>> https://mikewest.github.io/internetdrafts/origin-cookies/draft-west-origin-cookies-00.html
>>
>> https://mikewest.github.io/internetdrafts/first-party-cookies/draft-west-first-party-cookies-00.html
>>
>> Not many people are interested thus far is my understanding. Copied
>> Mike if he has anything to add.
>
>
> Some folks on the HTTP WG list (Martin in particular) had some interesting
> feedback, but my general impression was that I was the only one excited
> about it. I don't intend to let either spec die, as I think they're
> potentially important, but I haven't prioritized building a prototype to
> play with.
>
βA Mozilla colleague, Mark Goodwin, βhas worked on a nearly identical
proposal ("SameDomain" rather than "first-party") and tested a patch. Given
all the existing cookie specs live in the IETF I don't think WASWG is the
right place for it, but I'd dearly love to see it come to life.
https://github.com/mozmark/SameDomain-cookies/blob/master/samedomain.txt
https://bugzilla.mozilla.org/show_bug.cgi?id=795346
-
βDan Veditzβ
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
Daniel Veditz wrote: > On Thu, Jan 29, 2015 at 10:32 PM, L. David Baron 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
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Wed, Feb 11, 2015 at 12:47 AM, Daniel Veditz wrote: > 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 > 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. > My concern (as raised on the list) is that as phrased it appears to be an open research question how to actually "share data with untrusted code", for the reasons that have been raised already. Presumably we shouldn't be proposing standardization of things we don't actually know how to do. Were this IETF I would suggest that this go to IRTF. I'm fine with this being phrased as a belt-and-suspenders thing (along the usual lines of CSP) where you are just trying to prevent accidental leaks by the confined code. -Ekr (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
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Wed, Feb 11, 2015 at 11:20 AM, Jonas Sicking wrote: > On Wed, Feb 11, 2015 at 1:52 AM, Anne van Kesteren > wrote: > > On Wed, Feb 11, 2015 at 10:42 AM, Jonas Sicking > wrote: > >> Has the group looked at expanding the feature set of cookies to allow > >> better CSRF protection? > > > > Mike has: > > > > > https://mikewest.github.io/internetdrafts/origin-cookies/draft-west-origin-cookies-00.html > > > https://mikewest.github.io/internetdrafts/first-party-cookies/draft-west-first-party-cookies-00.html > > > > Not many people are interested thus far is my understanding. Copied > > Mike if he has anything to add. > > I haven't ready the above proposals, so won't comment on those > specifically. But I'm certainly interested in seeing mozilla implement > something in this space. > > Fixing cross-site cookies would remove one of the big security > advantages that other platforms have over the web. > Talk to Mozilla's own Mark Goodwin (CC'd. Hi, Mark!) who had similar ideas (see http://people.mozilla.org/~mgoodwin/SameDomain/samedomain-latest.txt), and who might be interested in prototyping. -mike -- Mike West , @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.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Wed, Feb 11, 2015 at 1:52 AM, Anne van Kesteren wrote: > On Wed, Feb 11, 2015 at 10:42 AM, Jonas Sicking wrote: >> Has the group looked at expanding the feature set of cookies to allow >> better CSRF protection? > > Mike has: > > > https://mikewest.github.io/internetdrafts/origin-cookies/draft-west-origin-cookies-00.html > > https://mikewest.github.io/internetdrafts/first-party-cookies/draft-west-first-party-cookies-00.html > > Not many people are interested thus far is my understanding. Copied > Mike if he has anything to add. I haven't ready the above proposals, so won't comment on those specifically. But I'm certainly interested in seeing mozilla implement something in this space. Fixing cross-site cookies would remove one of the big security advantages that other platforms have over the web. >> Another thing that would be very useful is page-specific or >> tab-specific cookies. So that websites like gmail could keep you >> logged in using different accounts in different tabs. Right now that >> essentially require the website to add a user identifier to the URL of >> all requests that are coming from a page, which is quite a demanding >> task. > > I thought sessionStorage addressed this. (Although of course it's a > poor API since it's synchronous.) That still requires that you manually adjust the URL all network requests that you do through any API. I.e. all img.src, all , all XHR requests, all WebSocket constructors need to manually append an account identifier to the URL. SessionStorage doesn't help there at all. Not any more than JS variables do. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Wed, Feb 11, 2015 at 10:52 AM, Anne van Kesteren wrote: > On Wed, Feb 11, 2015 at 10:42 AM, Jonas Sicking wrote: > > Has the group looked at expanding the feature set of cookies to allow > > better CSRF protection? > This doesn't seem like a good fit for WebAppSec. Various IETF groups have generally been responsible for cookies. > Mike has: > > > https://mikewest.github.io/internetdrafts/origin-cookies/draft-west-origin-cookies-00.html > > https://mikewest.github.io/internetdrafts/first-party-cookies/draft-west-first-party-cookies-00.html > > Not many people are interested thus far is my understanding. Copied > Mike if he has anything to add. Some folks on the HTTP WG list (Martin in particular) had some interesting feedback, but my general impression was that I was the only one excited about it. I don't intend to let either spec die, as I think they're potentially important, but I haven't prioritized building a prototype to play with. Coincidentally, I talked to a colleague just this morning who might have some spare cycles coming up, so who knows. Maybe he'll build a prototype for us. :) -mike -- Mike West , @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.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Wed, Feb 11, 2015 at 10:42 AM, Jonas Sicking wrote: > Has the group looked at expanding the feature set of cookies to allow > better CSRF protection? Mike has: https://mikewest.github.io/internetdrafts/origin-cookies/draft-west-origin-cookies-00.html https://mikewest.github.io/internetdrafts/first-party-cookies/draft-west-first-party-cookies-00.html Not many people are interested thus far is my understanding. Copied Mike if he has anything to add. > Another thing that would be very useful is page-specific or > tab-specific cookies. So that websites like gmail could keep you > logged in using different accounts in different tabs. Right now that > essentially require the website to add a user identifier to the URL of > all requests that are coming from a page, which is quite a demanding > task. I thought sessionStorage addressed this. (Although of course it's a poor API since it's synchronous.) -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Wed, Feb 11, 2015 at 12:47 AM, Daniel Veditz wrote: > (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. Has the group looked at expanding the feature set of cookies to allow better CSRF protection? I.e. it seems like it would be useful to be able to set a cookie but declare that it should only be sent along with same-origin requests. Or even allow even more stringent requirements such as "only send with same-origin POST requests coming from pages under /foo/bar"? That seems like it could provide the same type of CSRF protection without breaking links. Is that something that would fit in this new charter? Another thing that would be very useful is page-specific or tab-specific cookies. So that websites like gmail could keep you logged in using different accounts in different tabs. Right now that essentially require the website to add a user identifier to the URL of all requests that are coming from a page, which is quite a demanding task. Note that I'm not talking about a UA feature which would allow the user to use different cookie jars in different tabs. That can already be built without any needed changes to the cookie spec. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
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 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
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Fri, Jan 30, 2015 at 3:15 PM, L. David Baron wrote: > On Friday 2015-01-30 11:14 +0100, Anne van Kesteren wrote: > > On Fri, Jan 30, 2015 at 7:32 AM, L. David Baron > wrote: > > > I'm particularly interested in review of point (3) in what I've > written; > > > I feel that the argument I've written so far is weak, I think because I > > > don't particularly understand the concerns about the powerfulfeatures > > > draft. > > > > So for what it's worth, I think I'm in disagreement with Eric about > > what WebAppSec's role should/could be. Groups at the W3C that go at it > > alone often make questionable choices when it comes to a number of > > things that are not their expertise so having some amount of informal > > oversight is definitely warranted. And the group of people that make > > up WebAppSec definitely appears to have the competence. > > > > I don't really see where else "powerful features" would go and we do > > need it. (Now permissions API is another matter as that requires UX > > expertise.) > > My understanding is that the objections to powerfulfeatures are over > the possibility of powerfulfeatures defining what is and isn't a > powerful feature, because that should be decided primarily by the > group developing the feature. > That and the attempt by WebAppSec to mandate particular comsec treatment for said features. Is that the part you think is important, or is the part that you > think is important the part that defines algorithms for whether a > context/origin is sufficiently secure or trustworthy? I'm fine with a taxonomy of the security level of contexts/origins. -Ekr > > -David > > -- > π L. David Baron http://dbaron.org/ π > π’ Mozilla https://www.mozilla.org/ π > Before I built a wall I'd ask to know > What I was walling in or walling out, > And to whom I was like to give offense. >- Robert Frost, Mending Wall (1914) > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Fri, Jan 30, 2015 at 10:40 PM, Brian Smith wrote: > Anyway, my point isn't to suggest that Mozilla should ask for this > item to be removed from the charter. Rather, my point is that this > item has some pretty big, non-obvious ramifications (not just related > to tracking) that Mozilla should understand. I think what you said > about it being described in an unclear way is a good response. Joel > Weinberger from the Chrome Security Team already explained a lot of it > to me privately. I recommend talking to him about it, if you want to > understand it better. > Perhaps I don't understand very well either, but from your emails at least, isn't materially different from a same-origin perspective as given that scripts adopt the including origin. So there isn't any advantage to the site for this specific case. Iframes are different of course, but I don't see how this materially changes the game. After all, those tools would be able to use sub-origin information to aid in identification in the same way that the site might use them against them. This all comes down to the information that the blocking tools have available for use in identifying unwanted material. Those tools are already far more sophisticated and granular than origin. If you think that artificially impeding the escalation of this "arms race" is worthwhile, I guess that's a fine position to hold, but I just can't see this particular non-obvious ramification to be especially dangerous from this perspective. The only thing that concerns me here is that it creates a division that only advantages a small few. Sites big enough to have a need for multiple distinct isolation zones. And what *won't* be partitioned. Will we also ensure that permissions (geolocation, user media, etc...) are similarly partitioned? Or will a large provider be able to share information that is of advantage to it, while benefiting from isolation on what it wants isolated. I don't have a fundamental objection to that level of control, but it seems like a lot of work. And I wonder who benefits. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Sat, Jan 31, 2015 at 12:15 AM, L. David Baron wrote: > My understanding is that the objections to powerfulfeatures are over > the possibility of powerfulfeatures defining what is and isn't a > powerful feature, because that should be decided primarily by the > group developing the feature. It's not clear to me that other groups have done a good job of that, historically. Delegating this to the TAG instead could be done I suppose, except that a) the TAG has no security experts (although one is elected now) and b) the TAG has endorsed this approach already. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
L. David Baron wrote: > Is the argument you're making that if the site can serve the ads > from the same hostname rather than having to use a different > hostname to get same-origin protection, then ad-blocking (or > tracking-blocking) tools will no longer be able to block the ads? Yes. Anyway, my point isn't to suggest that Mozilla should ask for this item to be removed from the charter. Rather, my point is that this item has some pretty big, non-obvious ramifications (not just related to tracking) that Mozilla should understand. I think what you said about it being described in an unclear way is a good response. Joel Weinberger from the Chrome Security Team already explained a lot of it to me privately. I recommend talking to him about it, if you want to understand it better. Cheers, Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
Please note the need to liaise with the groups that are affected by the permissions work. Otherwise, this is good. On Fri, Jan 30, 2015 at 3:20 PM, L. David Baron wrote: > Here's a revised set of comments, mainly changing: > > - describes the objection to powerfulfeatures (part of objection (3)) >more clearly, but also, I think, scopes the objection a bit more >narrowly > > - makes objection (2) more explicit about being satisfied by an >option not to complete the work > > -David > > There are a number of problematic aspects to this charter to which > we object: > > (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. > > (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. > > (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). > > 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. > > (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 . > > -- > π L. David Baron http://dbaron.org/ π > π’ Mozilla https://www.mozilla.org/ π > Before I built a wall I'd ask to know > What I was walling in or walling out, > And to whom I was like to give offense. >- Robert Frost, Mending Wall (1914) > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
This seems good to me. On Fri, Jan 30, 2015 at 3:20 PM, L. David Baron wrote: > Here's a revised set of comments, mainly changing: > > - describes the objection to powerfulfeatures (part of objection (3)) >more clearly, but also, I think, scopes the objection a bit more >narrowly > > - makes objection (2) more explicit about being satisfied by an >option not to complete the work > > -David > > There are a number of problematic aspects to this charter to which > we object: > > (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. > > (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. > > (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). > > 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. > > (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 . > > -- > π L. David Baron http://dbaron.org/ π > π’ Mozilla https://www.mozilla.org/ π > Before I built a wall I'd ask to know > What I was walling in or walling out, > And to whom I was like to give offense. >- Robert Frost, Mending Wall (1914) > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
Here's a revised set of comments, mainly changing: - describes the objection to powerfulfeatures (part of objection (3)) more clearly, but also, I think, scopes the objection a bit more narrowly - makes objection (2) more explicit about being satisfied by an option not to complete the work -David There are a number of problematic aspects to this charter to which we object: (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. (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. (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). 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. (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 . -- π L. David Baron http://dbaron.org/ π π’ Mozilla https://www.mozilla.org/ π Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Friday 2015-01-30 11:14 +0100, Anne van Kesteren wrote: > On Fri, Jan 30, 2015 at 7:32 AM, L. David Baron wrote: > > I'm particularly interested in review of point (3) in what I've written; > > I feel that the argument I've written so far is weak, I think because I > > don't particularly understand the concerns about the powerfulfeatures > > draft. > > So for what it's worth, I think I'm in disagreement with Eric about > what WebAppSec's role should/could be. Groups at the W3C that go at it > alone often make questionable choices when it comes to a number of > things that are not their expertise so having some amount of informal > oversight is definitely warranted. And the group of people that make > up WebAppSec definitely appears to have the competence. > > I don't really see where else "powerful features" would go and we do > need it. (Now permissions API is another matter as that requires UX > expertise.) My understanding is that the objections to powerfulfeatures are over the possibility of powerfulfeatures defining what is and isn't a powerful feature, because that should be decided primarily by the group developing the feature. Is that the part you think is important, or is the part that you think is important the part that defines algorithms for whether a context/origin is sufficiently secure or trustworthy? -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla https://www.mozilla.org/ π Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Friday 2015-01-30 10:18 -0800, Eric Rescorla wrote: > I think there's some competence there, certainly, but I'm not convinced > it represents a balanced set of the views on this topic. If there is to > be oversight, it should probably be at that TAG level, IMHO. For many topics, oversight from the TAG can mean oversight from the one person on the TAG who's interested in the topic, which may be less likely to be balanced... -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla https://www.mozilla.org/ π Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Fri, Jan 30, 2015 at 2:14 AM, Anne van Kesteren wrote: > Thanks David! > > On Fri, Jan 30, 2015 at 7:32 AM, L. David Baron wrote: > > I'm particularly interested in review of point (3) in what I've written; > > I feel that the argument I've written so far is weak, I think because I > > don't particularly understand the concerns about the powerfulfeatures > > draft. > > So for what it's worth, I think I'm in disagreement with Eric about > what WebAppSec's role should/could be. Groups at the W3C that go at it > alone often make questionable choices when it comes to a number of > things that are not their expertise so having some amount of informal > oversight is definitely warranted. And the group of people that make > up WebAppSec definitely appears to have the competence. > I think there's some competence there, certainly, but I'm not convinced it represents a balanced set of the views on this topic. If there is to be oversight, it should probably be at that TAG level, IMHO. -Ekr ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
This seems satisfactory to me. On Thu, Jan 29, 2015 at 10:32 PM, L. David Baron wrote: > Here are the comments I have so far on this charter, based on the > thread. I'd note that this is a relatively large set of demands to make > in the charter review stage at the AC, especially for a recharter of a > WG that we're involved in. So it may come across to W3C staff as > somewhat demanding. > > I'm particularly interested in review of point (3) in what I've written; > I feel that the argument I've written so far is weak, I think because I > don't particularly understand the concerns about the powerfulfeatures > draft. > > I also haven't included anything about Brian's objection to the > suborigin namespaces work because I don't understand the objection, and > I don't see how to extract any actionable charter feedback directly from > Brian's message. (Or is it that the deliverable should be removed from > the charter? If so, I could use an explanation as to why.) > > In any case, here's the feedback I have so far. Comments are > welcome through roughly 5pm California time on Friday -- > particularly actionable ones that suggest how to revise this > feedback or at least say how the charter should be different! > > (Sorry for not getting this gathered together sooner.) > > -David > > > There are a number of problematic aspects to this charter to which > we object: > > (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. > > (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. > > (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 (which may be comfortable with, although some of us > have serious concerns about whether it is actually workable), or > whether it's 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. > > At a minimum, it would be good to rephrase this item so that it > doesn't use the term "powerful features". It would probably be > preferable to explicitly state that work like the powerfulfeatures > draft is not in the scope of the working group. > > (4) We believe the charter should have provision for asynchronous > decision making, perhaps as in > http://www.w3.org/2012/webapps/charter/#decisions . > > -- > π L. David Baron http://dbaron.org/ π > π’ Mozilla https://www.mozilla.org/ π > Before I built a wall I'd ask to know > What I was walling in or walling out, > And to whom I was like to give offense. >- Robert Frost, Mending Wall (1914) > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Friday 2015-01-30 08:54 -0800, Daniel Veditz wrote: > On Thu, Jan 29, 2015 at 10:32 PM, L. David Baron wrote: > > > There are a number of problematic aspects to this charter to which > > we object: > > > > (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. > > > > (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. > > > > If something is in the charter and there's an initial draft spec, that > doesn't mean the final spec will be the same or that the WG has to > ultimately approve the spec at all, does it? Both of these ideas are > promising attempts to address particular security issues that are prevalent > on the web. They also both raise issues that may or may not be addressable > as the WG refines the specs. As long as we can object to the final specs if > they go off the rails these concepts are worth exploring. Regarding (1), it sounds like you know what it is and perhaps could explain it? Regarding (2), does it make sense for the charter to say that it's a potential deliverable, but that the working group may choose not to proceed depending on tradeoffs? -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla https://www.mozilla.org/ π Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Thu, Jan 29, 2015 at 10:32 PM, L. David Baron wrote: > There are a number of problematic aspects to this charter to which > we object: > > (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. > > (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. > βIf something is in the charter and there's an initial draft spec, that doesn't mean the final spec will be the same or that the WG has to ultimately approve the spec at all, does it? Both of these ideas are promising attempts to address particular security issues that are prevalent on the web. They also both raise issues that may or may not be addressable as the WG refines the specs. As long as we can object to the final specs if they go off the rails these concepts are worth exploring. -Dan Veditzβ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
Thanks David! On Fri, Jan 30, 2015 at 7:32 AM, L. David Baron wrote: > I'm particularly interested in review of point (3) in what I've written; > I feel that the argument I've written so far is weak, I think because I > don't particularly understand the concerns about the powerfulfeatures > draft. So for what it's worth, I think I'm in disagreement with Eric about what WebAppSec's role should/could be. Groups at the W3C that go at it alone often make questionable choices when it comes to a number of things that are not their expertise so having some amount of informal oversight is definitely warranted. And the group of people that make up WebAppSec definitely appears to have the competence. I don't really see where else "powerful features" would go and we do need it. (Now permissions API is another matter as that requires UX expertise.) -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Thu, Jan 29, 2015 at 10:27 PM, Eric Rescorla wrote: > On Thu, Jan 29, 2015 at 12:56 PM, L. David Baron wrote: >> On Friday 2015-01-16 09:58 +0100, Anne van Kesteren wrote: >>> Also, can we request that they adopt a public asynchronous decision >>> policy? I think we should start making that request from any WG. >> >> What do the Mozillians involved in the WG think about this? > > It depends what this means. If it means that decisions have to be confirmed > on the list then fine. If it means that they can't be made F2F or on calls > and then confirmed the list, then not so fine. I would phrase the latter as the people at the F2F or call proposing a decision and the list asynchronously deciding on it. So I think we are in agreement. I would not want to preclude discussion outside of the list, that seems unworkable and also impossible. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
Here are the comments I have so far on this charter, based on the thread. I'd note that this is a relatively large set of demands to make in the charter review stage at the AC, especially for a recharter of a WG that we're involved in. So it may come across to W3C staff as somewhat demanding. I'm particularly interested in review of point (3) in what I've written; I feel that the argument I've written so far is weak, I think because I don't particularly understand the concerns about the powerfulfeatures draft. I also haven't included anything about Brian's objection to the suborigin namespaces work because I don't understand the objection, and I don't see how to extract any actionable charter feedback directly from Brian's message. (Or is it that the deliverable should be removed from the charter? If so, I could use an explanation as to why.) In any case, here's the feedback I have so far. Comments are welcome through roughly 5pm California time on Friday -- particularly actionable ones that suggest how to revise this feedback or at least say how the charter should be different! (Sorry for not getting this gathered together sooner.) -David There are a number of problematic aspects to this charter to which we object: (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. (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. (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 (which may be comfortable with, although some of us have serious concerns about whether it is actually workable), or whether it's 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. At a minimum, it would be good to rephrase this item so that it doesn't use the term "powerful features". It would probably be preferable to explicitly state that work like the powerfulfeatures draft is not in the scope of the working group. (4) We believe the charter should have provision for asynchronous decision making, perhaps as in http://www.w3.org/2012/webapps/charter/#decisions . -- π L. David Baron http://dbaron.org/ π π’ Mozilla https://www.mozilla.org/ π Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Sunday 2015-01-18 21:00 -0800, Brian Smith wrote: > L. David Baron wrote: > > http://www.w3.org/2014/12/webappsec-charter-2015.html > > Please see the threads at > > [1] https://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0179.html > [2] > https://groups.google.com/d/topic/mozilla.dev.privacy/Rbm1XdfXX6k/discussion > > In particular, although I think the sub-origin work is potentially > very useful, it seems to have some pretty negative unintended > consequences. Even if you don't share my specific concerns about the > potential negative interaction between the sub-origin part of the > proposed charter with respect to Mozilla's Tracking Protection work, I'm having trouble understanding those concerns. Is the argument you're making that if the site can serve the ads from the same hostname rather than having to use a different hostname to get same-origin protection, then ad-blocking (or tracking-blocking) tools will no longer be able to block the ads? I suppose I can see that it could make some forms of ad-blocking (network-level rather than URI-level) more difficult. But it's not clear to me what the additional tracking potential is in this case. I don't see where it introduces vectors for sharing cookies (or other similar data) between sites that don't already exist. -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla https://www.mozilla.org/ π Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Thu, Jan 29, 2015 at 1:59 PM, L. David Baron wrote: > > Is this arguably a violation of the priority of constituencies principle? > > It seems like it may serve the site more than the user. > > Do you want to insist that it be removed from the charter, or is > this something you think should be addressed during the development > of the spec (perhaps via some requirement that should be added to > the charter)? In my experience, it's customary for controversial issues like this to be discussed more in detail before entering them onto an official work plan. I'm only casually following the working group mailing list, is there a proposal (or proposals) that outlines a direction for this work? As for the permissions work, I'm not enthused by its presence, and would prefer if it were stricken. I realize at this point that might be unrealistic. Currently, there is no requirement to engage with the groups that might be affected by this work. That must be fixed by adding to the liaison section: a trivial change. Ultimately though, I have serious reservations about the viability of the effort - permissions grants are contextual, and the proposed API fails to address that requirement - but I am happy to engage in discussion to that effect. I don't know what expectations are with respect to chartered items, but if listing on a charter implies some inevitability: a commitment to complete the listed work, I think that I would rather object to its inclusion. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Thursday 2015-01-29 13:27 -0800, Eric Rescorla wrote: > On Thu, Jan 29, 2015 at 12:56 PM, L. David Baron wrote: > > > On Friday 2015-01-16 09:58 +0100, Anne van Kesteren wrote: > > > On Fri, Jan 16, 2015 at 12:53 AM, L. David Baron > > wrote: > > > > Please reply to this thread if you think there's something else we > > > > should say, or if you think we should support the charter. > > > > > > I think in general it's fine, but there's a couple things: > > > > > > * "Confinement with Origin Web Labels" the description does not make > > > it clear what this actually is. > > > > I suppose I can ask that the description be made clearer. Is there > > something in particular that you think it should say? > > > > > * "Entry Point Regulation for Web Applications" in a way this is nice > > > for defense-in-depth, but also seems to allow a site to completely > > > isolate itself from the rest of the web. > > > > I don't see what feedback you want me to give here. > > > Is this arguably a violation of the priority of constituencies principle? > It seems like it may serve the site more than the user. Do you want to insist that it be removed from the charter, or is this something you think should be addressed during the development of the spec (perhaps via some requirement that should be added to the charter)? -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla https://www.mozilla.org/ π Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Thu, Jan 29, 2015 at 12:56 PM, L. David Baron wrote: > On Friday 2015-01-16 09:58 +0100, Anne van Kesteren wrote: > > On Fri, Jan 16, 2015 at 12:53 AM, L. David Baron > wrote: > > > Please reply to this thread if you think there's something else we > > > should say, or if you think we should support the charter. > > > > I think in general it's fine, but there's a couple things: > > > > * "Confinement with Origin Web Labels" the description does not make > > it clear what this actually is. > > I suppose I can ask that the description be made clearer. Is there > something in particular that you think it should say? > > > * "Entry Point Regulation for Web Applications" in a way this is nice > > for defense-in-depth, but also seems to allow a site to completely > > isolate itself from the rest of the web. > > I don't see what feedback you want me to give here. Is this arguably a violation of the priority of constituencies principle? It seems like it may serve the site more than the user. > > * "Permissions API" this has been tried several times before. Given > > that there's hardly any involvement from UX in standards, it's not > > clear that this is a good idea. See also > > > http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html > > Are you ok with sicking's response to this? > > > Also, can we request that they adopt a public asynchronous decision > > policy? I think we should start making that request from any WG. > > What do the Mozillians involved in the WG think about this? It depends what this means. If it means that decisions have to be confirmed on the list then fine. If it means that they can't be made F2F or on calls and then confirmed the list, then not so fine. -Ekr -David > > -- > π L. David Baron http://dbaron.org/ π > π’ Mozilla https://www.mozilla.org/ π > Before I built a wall I'd ask to know > What I was walling in or walling out, > And to whom I was like to give offense. >- Robert Frost, Mending Wall (1914) > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Friday 2015-01-16 09:58 +0100, Anne van Kesteren wrote: > On Fri, Jan 16, 2015 at 12:53 AM, L. David Baron wrote: > > Please reply to this thread if you think there's something else we > > should say, or if you think we should support the charter. > > I think in general it's fine, but there's a couple things: > > * "Confinement with Origin Web Labels" the description does not make > it clear what this actually is. I suppose I can ask that the description be made clearer. Is there something in particular that you think it should say? > * "Entry Point Regulation for Web Applications" in a way this is nice > for defense-in-depth, but also seems to allow a site to completely > isolate itself from the rest of the web. I don't see what feedback you want me to give here. > * "Permissions API" this has been tried several times before. Given > that there's hardly any involvement from UX in standards, it's not > clear that this is a good idea. See also > http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html Are you ok with sicking's response to this? > Also, can we request that they adopt a public asynchronous decision > policy? I think we should start making that request from any WG. What do the Mozillians involved in the WG think about this? -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla https://www.mozilla.org/ π Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
L. David Baron wrote: > The W3C is proposing a revised charter for: > > Web Application Security Working Group > http://www.w3.org/2014/12/webappsec-charter-2015.html > https://lists.w3.org/Archives/Public/public-new-work/2014Dec/0008.html > > Mozilla has the opportunity to send comments, objections, or support > through Friday January 30. > > Mozilla is involved in this working group; see membership at > https://www.w3.org/2000/09/dbwg/details?group=49309&public=1&order=org . > > Please reply to this thread if you think there's something else we > should say, or if you think we should support the charter. Please see the threads at [1] https://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0179.html [2] https://groups.google.com/d/topic/mozilla.dev.privacy/Rbm1XdfXX6k/discussion In particular, although I think the sub-origin work is potentially very useful, it seems to have some pretty negative unintended consequences. Even if you don't share my specific concerns about the potential negative interaction between the sub-origin part of the proposed charter with respect to Mozilla's Tracking Protection work, it is still a good idea for Mozilla to spend some time to fully understand all the intended and unintended consequences of the sub-origin concept and the specific design being proposed for it. Cheers, Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Fri, Jan 16, 2015, at 08:58 AM, Anne van Kesteren wrote: > On Fri, Jan 16, 2015 at 12:53 AM, L. David Baron > wrote: > > Please reply to this thread if you think there's something else we > > should say, or if you think we should support the charter. > > I think in general it's fine, but there's a couple things: > > * "Confinement with Origin Web Labels" the description does not make > it clear what this actually is. > > * "Entry Point Regulation for Web Applications" in a way this is nice > for defense-in-depth, but also seems to allow a site to completely > isolate itself from the rest of the web. Indeed. It reads to me to allow sites to trivially get a browser to prevent deep linking, which doesn't seem desirable. David ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Fri, Jan 16, 2015 at 12:58 AM, Anne van Kesteren wrote: > * "Permissions API" this has been tried several times before. Given > that there's hardly any involvement from UX in standards, it's not > clear that this is a good idea. See also > http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html Note that the scope of this spec is very narrow (which sadly isn't reflected in the name). The scope *only* covers querying if a given API will be automatically denied, automatically granted or if UI will be displayed. So it's not attempting to solve permissions in general. Nor does it allow even asking for permission to use a particular API. This might not seem like terribly important functionality, but it's something that web developers ask for a lot. With this API they can do things like hide "turn on camera" buttons if the user has permanently forbidden a website from using camera. Or they can inform the user that a security dialog is about to be displayed. Right now well-meaning websites see a lot of dropoff whenever they cause a security dialog to be displayed because many people don't understand the dialog and (wisely) choose "no". Obviously a lot of users also choose "yes" even when they don't understand a security dialog, but far from all do. By enabling websites to check if a dialog will be displayed, the "good guys" will have the ability to educate the user. I don't think there are any security risks with enabling websites to do this education. The bad guys can simply always put up text which tries to trick the user that a dialog is harmless. There could be some privacy concerns with this API. If we add the ability to set blanket policies like "forbid camera for all websites except for X.com and Y.com", then websites could use the fact that they see a "access will be automatically denied" as extra fingerprinting bits. However there are ways to implement such policies without leaking additional information. We can simply make the permissions API lie and return whatever the default behavior is until the website actually tries to use the given API. At that point we could automatically deny and then make the permissions API reflect the real behavior. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Fri, Jan 16, 2015 at 9:31 AM, Martin Thomson wrote: > On Fri, Jan 16, 2015 at 12:58 AM, Anne van Kesteren > wrote: > > > * "Permissions API" this has been tried several times before. Given > > that there's hardly any involvement from UX in standards, it's not > > clear that this is a good idea. See also > > > > > http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html > > > > I share this reservation. I also think that this could undermine the work > that has been done with respect to user consent in other areas. > Specifically the Media Capture task force and the Geolocation working > group. I'd expect statements in the charter regarding liaison with > affected groups at a minimum, if not actual prior consultation (and I've > seen no evidence of that). Indeed: more generally, there's a certain flavor in this charter of setting up WebAppSec as the decider for how security features should be implemented in other W3C WGs (for instance, Powerful Features). I don't think that that's very helpful or really matches WebAppSec's historical role. -Ekr ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Fri, Jan 16, 2015 at 12:58 AM, Anne van Kesteren wrote: > * "Permissions API" this has been tried several times before. Given > that there's hardly any involvement from UX in standards, it's not > clear that this is a good idea. See also > > http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html > I share this reservation. I also think that this could undermine the work that has been done with respect to user consent in other areas. Specifically the Media Capture task force and the Geolocation working group. I'd expect statements in the charter regarding liaison with affected groups at a minimum, if not actual prior consultation (and I've seen no evidence of that). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
On Fri, Jan 16, 2015 at 12:53 AM, L. David Baron wrote: > Please reply to this thread if you think there's something else we > should say, or if you think we should support the charter. I think in general it's fine, but there's a couple things: * "Confinement with Origin Web Labels" the description does not make it clear what this actually is. * "Entry Point Regulation for Web Applications" in a way this is nice for defense-in-depth, but also seems to allow a site to completely isolate itself from the rest of the web. * "Permissions API" this has been tried several times before. Given that there's hardly any involvement from UX in standards, it's not clear that this is a good idea. See also http://robert.ocallahan.org/2011/06/permissions-for-web-applications_30.html Also, can we request that they adopt a public asynchronous decision policy? I think we should start making that request from any WG. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
The W3C is proposing a revised charter for: Web Application Security Working Group http://www.w3.org/2014/12/webappsec-charter-2015.html https://lists.w3.org/Archives/Public/public-new-work/2014Dec/0008.html Mozilla has the opportunity to send comments, objections, or support through Friday January 30. Mozilla is involved in this working group; see membership at https://www.w3.org/2000/09/dbwg/details?group=49309&public=1&order=org . Please reply to this thread if you think there's something else we should say, or if you think we should support the charter. I'd note that the charter doesn't say anything about asynchronous decision making, which is a bit unusual. -David -- π L. David Baron http://dbaron.org/ π π’ Mozilla https://www.mozilla.org/ π Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Proposed W3C Charter: Web Application Security (WebAppSec) Working Group
___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
