- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 14 Apr 2008 20:06:09 +0000 (UTC)
- To: Jon Ferraiolo <jferrai@us.ibm.com>
- Cc: "public-appformats@w3.org" <public-appformats@w3.org>
On Mon, 14 Apr 2008, Jon Ferraiolo wrote: > Thomas Roessler <tlr@w3.org> wrote on 04/14/2008 08:21:50 AM: > > On 2008-04-14 08:07:10 -0700, Jon Ferraiolo wrote: > > > > > On the architecture side, Access Control is just plain wrong, with > > > the PEP on the client instead of the server, which requires data to > > > be sent along the pipe to the client, where the client is trusted to > > > discard the data if the user isn't allowed to see the data; it is > > > just plain architecturally wrong to transmit data that is not meant > > > to be seen. > > > > This seems to confuse the attacker model a bit. It's not about the > > user not being permitted to see the data, it's about a web application > > from a different origin not being allowed to manipulate the data, even > > though the user is allowed to see the data. > > The comment in question wasn't about CSRF or other data-setting attacks > on a server, but instead about how it is architecturally wrong to send > data that ultimately will be thrown out when it reaches the client. If I > was outside of the standards world and wrote some code that did this, I > would be embarrassed to show such an implementation during a code > walkthrough. The policy check should be done before the data is > transmitted. XDR also has the PEP on the client side. There haven't been any suggestions as to how to put the PEP on the server while still blocking access to existing deployed servers. Note that AC actually does support having a PEP on the server-side as well if that is desired. So it's the best of both worlds -- it supports existing servers as well as providing for a server-side PEP. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 14 April 2008 20:07:05 UTC