- From: Brad Porter <bwporter@yahoo.com>
- Date: Fri, 22 Feb 2008 07:50:25 -0800 (PST)
- To: "Close, Tyler J." <tyler.close@hp.com>, Jonas Sicking <jonas@sicking.cc>
- Cc: Ian Hickson <ian@hixie.ch>, "WAF WG \(public\)" <public-appformats@w3.org>
- Message-ID: <999094.15691.qm@web53501.mail.re2.yahoo.com>
Once the user gives data to an entity, that data becomes the property of the entity. Entities have privacy policies that state how they share that data. It would be nice if every entity asked my intent before they did any sharing of data they captured from me, but that isn't how most entity-to-entity data-sharing of personal information is done today and isn't something I think we should enforce at the access-control layer. I believe redefining privacy policy on the web should be out-of-scope for access-control. --Brad "Close, Tyler J." <tyler.close@hp.com> wrote: 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
Received on Friday, 22 February 2008 15:50:39 UTC