- From: Close, Tyler J. <tyler.close@hp.com>
- Date: Thu, 3 Jan 2008 18:56:22 +0000
- To: Jonas Sicking <jonas@sicking.cc>
- CC: Mark Nottingham <mnot@yahoo-inc.com>, Ian Hickson <ian@hixie.ch>, Anne van Kesteren <annevk@opera.com>, "public-appformats@w3.org" <public-appformats@w3.org>
Jonas Sicking wrote: > You do realize that the current spec lets the server do all the > enforcement if it so pleases? It can check the relevant headers and > simply send back an empty document if it does not want to allow access > to the resource. > > It does however have the *option* to let the client do the > authentication. If it doesn't trust the client to do this > correctly all > the authentication can take place on the server. I don't want to pay the complexity cost for this feature: - when implementing a client - when implementing a proxy - when doing a security review of server software written by someone else - when reading the inevitable bug reports about browser implementation errors - when determining whether or not an IT department should allow installation of a particular browser - when explaining to people that no, it isn't actually an access-control mechanism The current mishmash of security constraints in the browser is pretty haphazard and this proposal just piles on more stuff, for not good enough reasons IMO. We need to be moving in the direction of simpler and more consistent. This proposal is not moving in that direction, it's making things worse by putting yet another cross-domain access policy manager in the browser. --Tyler
Received on Thursday, 3 January 2008 18:57:50 UTC