Ian Hickson wrote: > On Thu, 21 Feb 2008, Close, Tyler J. wrote: > > > > > > If the command is something simple like adding an event > to a calendar, > > > the ideal UI doesn't involve the user doing anything in the way of > > > giving credentials -- or indeed anything else -- to anyone. Just a > > > click "add this event to my calendar" or some such. We > still need to > > > know who the user is. > > > > I gather this means you're assuming the third party web > page is coded to > > only add events to calendars maintained by a single web site. > > It's only an example, but yes, I am -- for example, it could > be a widget > specific to this calendar mechanism. > > Or another example could be a button for Facebook that adds someone as > your friend when you click it. Or a button for players of a > MMORPG where > it adds the person to the user's address book. Or any number of other > things where the Web page is not being trusted by the service > provider to > do anything risky, where the user has already authenticated with the > service provider, and where no additional UI is to be shown.
Beyond the vendor lock-in issue, there are additional problems that make such designs not viable. The social networking site has an incentive to support updates from as many third-party sites as possible. Combine this incentive with the prohibitive cost of vetting a third-party mashup and you have a strong bias towards accepting updates from everyone. As the site's policy moves in this direction, it becomes more vulnerable to spam. The site's operator is faced with a distasteful tradeoff between wider adoption and spam. In contrast, the design I described in the previous email does not create such a tradeoff. By requiring explicit user consent you can cut down on spam (depending on how you define spam, eliminate it) while still having a policy of accepting requests from anyone. 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. --Tyler
