Hi Brad, I'm not attempting to redefine privacy policy policy. Indeed, the points I'm making have nothing to do with controlling what a site does with information the user has voluntarily given it. For a concrete example of what I'm talking about, let's use Ian's proposed calendar example.
Site A hosts a calendar on behalf of user X. Site A wants to let user X easily add events suggested by other sites. How do we design a protocol that allows this to be accomplished in a safe and easy way, while avoiding as many pitfalls as possible? Ian suggests that Site A enumerate all sites that are allowed to use this protocol so that they may then populate the user's calendar without any restraint by the user. I've given multiple reasons why I think this option is not viable. Please refer to the earlier messages in this thread. Instead, I've proposed that the browser not send any of the user's credentials in a cross-domain request. In this case, the user would have to explicitly pass some authorization token to the third-party site to enable the request to be processed by Site A. A potential user interface for this action would be to drag and drop a bookmark which contains the authorization token onto the calendar update widget provided by the third party site. In this way, Site A can accept requests from anyone and so doesn't have to answer tricky questions like: "Do I trust Site B?". And yet, Site A still knows it's only processing requests initiated by the user, since the requests must have the authorization token from the user. The widespread vulnerability to XSRF makes it clear that developers aren't used to thinking about the implications of letting third-party sites automatically use the user's credentials. That alone suggests widening the number of cases to think about is dangerous. I am further arguing that there is nothing to be gained in this widening. Viable designs require the user's consent for Site B to issue a request to Site A on the user's behalf. In such a scenario, Site B is claiming to Site A that the user wants something. Designing the protocol such that Site B makes this claim without giving Site A any way to verify the claim is asking for trouble. Back to your privacy comparison, this is not about controlling what you do with what the user told you, but controlling how you claim to another that you speak on the user's behalf. --Tyler ________________________________ From: Brad Porter [mailto:[EMAIL PROTECTED] Sent: Friday, February 22, 2008 7:50 AM To: Close, Tyler J.; Jonas Sicking Cc: Ian Hickson; WAF WG (public) Subject: RE: Mozilla security review of Access Control 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." <[EMAIL PROTECTED]> 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
