Jonas Sicking wrote: > Close, Tyler J. wrote: > > Sending the user's credentials without the user's consent > > creates a host of security problems, such as the one around > > headers the WG is currently struggling with and the one's > > I've written about on this list recently, without enabling > > any actually viable designs. For example, if the user's > > credentials are not used, and the target resource has to > > opt-in, it is OK to let the third-party web page specify > > whatever headers it wants, so long as the HTTP request is > > still well formed, since the third-party could have sent just > > such a request from its own machine. > > All these problems exist even if we don't send cookies. The reason is > intranet servers behind firewalls. These sites authenticate simply > through the users ability to connect to the server.
Note that I included the clause ", and the target resouce has to opt-in," to catch the case of an intranet server that relies solely on the client's IP address to authenticate the client. > I've argued this in the past (in a discussion on JSONRequest vs. AC > iirc), that disabling cookies doesn't actually buy any reliably > protection, but it does risk giving us (spec writers) a false sense of > security. Since not sending cookies does protect services that operate on the open Internet, it is a great exageration to say this measure "doesn't actually buy any reliably (sp) protection". A great number of valuable services are given clear protection by this measure. To date, no one has presented a viable design that uses the user's cookies in a cross-domain request. There is a reason for that. It would be a neat trick indeed to claim you were enforcing the user's wishes, without ever getting any expression of those wishes from the user. Automatically sending cookies is a way of bypassing the step of getting the user's consent, when getting the user's consent is a necessary step in enforcing the user's wishes. --Tyler
