- From: David Ross <drx@google.com>
- Date: Wed, 11 Feb 2015 14:09:18 -0800
- To: Devdatta Akhawe <dev.akhawe@gmail.com>
- Cc: Deian Stefan <deian@cs.stanford.edu>, Martin Thomson <martin.thomson@gmail.com>, Brad Hill <hillbrad@gmail.com>, Jeffrey Yasskin <jyasskin@google.com>, Mike West <mkwst@google.com>, Wendy Seltzer <wseltzer@w3.org>, 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>
- Message-ID: <CAMM+ux5QrMc9w2L7wKjpjz1hioh2YaN_vJBLjnE2XXvPOkVfHw@mail.gmail.com>
Belated response to: > (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. I completely agree with Brad's addendum to the proposed charter to address this concern: > Restricting deep-linking for non-security purposes is not a goal of > this deliverable, and it should give resource owners no additional > ability to do so beyond current abilities of the web platform, e.g. by > providing a simple to deploy mechanism using client-side state to > supplement what can already be accomplished by a less-scalable > web application firewall. Preserving the ability to link on the web > platform will be prioritized." That being said, I think the criticism is a bit unfair. EPR is an opt-in feature with an intended audience largely separate from those who might wish to prevent deep linking on their web sites. I don't see any reason to believe that we will see excessive and inconsiderate application of EPR leading to linkability issues on the web at large. If a publisher is determined to prevent deep linking there are plenty of ways for them to do that today, whether they choose to make use of the web platform or not. IMO, quashing proposed platform functionality such as EPR constrains consumers of the web platform and serves to limit the attractiveness of the platform as a whole. EPR helps enable the web platform to support scenarios with very stringent security requirements. For example, XSS or XSRF is an unacceptable failure mode for sensitive applications. (Eg: Administrative consoles) Authors of these sensitive applications sometimes favor implementation as a legacy platform app, a mobile app, or even a command line app over the web app platform simply because of this security consideration. I believe it's important to provide the _option_ for developers to implement EPR to better meet their security requirements. Dave On Mon, Feb 9, 2015 at 8:48 AM, Devdatta Akhawe <dev.akhawe@gmail.com> wrote: > > If I am not mistaken what you are proposing here is your work on DCS > > [2]. I like DCS, but this is a different system. I think that web apps > > implementing the enforcement logic, while useful for more complex > > policies, is more difficult than associating a label with postMessages > > Forgive me if I gave that impression. That was not my intention. I > actually think the ideas proposed in COWL are definitely what we want: > confinement for things like ads, third-party widgets without the heavy > cost of doing isolation via iframes. I think that was the general > motivation discussed at TPAC too, although maybe I am forgetting > something. So, for example, I am definitely in favor of something like > the workers in the proposal. > > My only concern is whether or not we want to make "specify and > implement DC labels on the web patform" a part of the deliverable. It > seems you definitely want it to be part of the deliverable---but in > that case , I think the text should say this explicitly. I definitely > did not get that when I first read the text and we would have saved a > lot of email :) > > cheers > Dev > > > as a way of expressing security concern. (Because of labels, the COWL > > confinement enforcement mechanism also piggy-backs on CSP.) But, more > > importantly, DCS cannot safely allow for a number of use cases that COWL > > does. For example, we would not be able to build mashups wherein the > > parties are mutually distrusting. This is because an iframe (or worker) > > cannot impose any restrictions on its parent and there is no way to > > impose confinement restrictions on cross-origin contexts. > > > > DCS and COWL have some similarities, but also have different goals, so > > it is natural that the approaches differ and excell at different things. > > I think they may even be complimentary. But, if it's okay with you, > > Dev, I propose discussing DCS separately to avoid confusion. > > > > Thanks, > > Deian > > > > [1] http://www.scs.stanford.edu/~deian/pubs/stefan:2011:dclabels.pdf > > [2] http://devd.me/papers/dcs-esorics.pdf >
Received on Wednesday, 11 February 2015 22:09:46 UTC