On Thu, Jul 23, 2009 at 2:05 AM, Brianna Laugher<brianna.laug...@gmail.com> wrote: > Eh? I do. Else why bother even having a write API? Why bother even > having the login aspect to the API?
The API allows you to edit if you know the password of the account you're using. I can't see the value in creating some mechanism to allow editing from an account with some special limited authorization that's less than giving away the account password in practice. > I can imagine someone building an alternative edit interface for a > subset of Wikipedia content, say a WikiProject. Then the interface can > strip away all the general crud and just provide information relevant > to that topic area. If they're allowing a third party to edit using their account, the trust issues involved are substantially identical to just giving that service their password. > The OAuth provider typically has a page on the service (say en.wp) > that lists all the third party apps you have granted authorisation to. > This authorisation can be time-limited in itself, but if an app starts > misbehaving (say, doing edits you didn't tell it to do), you can > revoke its authorisation from the service directly (rather than having > to change your password to stop it). That doesn't greatly reduce the level of trust you'd need to have in a service to authorize it to edit under your name. Oh, great, if it goes rogue it can get my account desysopped/blocked and seriously confuse or annoy a large number of people who know me, but at least I won't have to change my password! On Thu, Jul 23, 2009 at 2:27 AM, John Vandenberg<jay...@gmail.com> wrote: > And moving slightly away from "editing", Flickr could have an "upload > to Wikimedia Commons" application which integrates nicely into their > UI, and retaining a link in their system to indicate the name of the > file over on Commons. Yeah, great, and let's also have users let Facebook edit arbitrary pages with their account name so that they can keep their profile synchronized across sites. This just strikes me as a horribly bad idea. When a user makes an edit, you should know that *that user made the edit*. Users should not be encouraged to let random third parties use their account for any purpose. On Flickr, the worst that could happen is their own stuff gets trashed. If a popular service goes rogue, then nobody has to care except the people who trusted it. No one else has the ability to do anything about it anyway. On a wiki, accounts could be used for vandalism. A rogue service means a huge number of established, trusted users, including sysops, suddenly starting to blank pages and add random profanity. And nobody will have any idea what to do because *it looks like it's a trusted user doing it*. And probably nobody has a list of who's given that service access to their account, either. Wikis are not a private sandbox. If you can affect no one but yourself, then sure, go ahead and allow foreign sites to screw with your account. That logic just doesn't apply on wikis. So, my two cents: no. Any application that's useful can be integrated into MediaWiki itself, or a toolserver tool, or a client-side program with access to the password. We have plenty of examples of all of these, and I fail to see how any use-case presented so far can't be met by them just as well as the OAuth proposal, when you account for the difference in security. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
