2009/7/23 Aryeh Gregor Simetrical+wikilist@gmail.com:
On Thu, Jul 23, 2009 at 1:02 AM, Ryan Lanerlane32@gmail.com wrote:
Check out how the Flickr API works. Users can give web and desktop apps privileges (read/write/delete).
It isn't really that bizarre of a concept.
Read/write/delete access to what? The only cases where read access would be relevant would be what, watchlist and preferences, pretty much? I don't think we'd want this for editing, or admin-only stuff like viewing deleted pages.
Eh? I do. Else why bother even having a write API? Why bother even having the login aspect to the API?
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.
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).
Brianna
On Thu, Jul 23, 2009 at 12:05 PM, Brianna Laugherbrianna.laugher@gmail.com wrote:
2009/7/23 Aryeh Gregor Simetrical+wikilist@gmail.com:
On Thu, Jul 23, 2009 at 1:02 AM, Ryan Lanerlane32@gmail.com wrote:
Check out how the Flickr API works. Users can give web and desktop apps privileges (read/write/delete).
It isn't really that bizarre of a concept.
Read/write/delete access to what? The only cases where read access would be relevant would be what, watchlist and preferences, pretty much? I don't think we'd want this for editing, or admin-only stuff like viewing deleted pages.
Eh? I do. Else why bother even having a write API? Why bother even having the login aspect to the API?
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.
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.
-- John Vandenberg
On Thu, Jul 23, 2009 at 2:05 AM, Brianna Laugherbrianna.laugher@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 Vandenbergjayvdb@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.
2009/7/23 Aryeh Gregor Simetrical+wikilist@gmail.com:
On Thu, Jul 23, 2009 at 2:05 AM, Brianna Laugherbrianna.laugher@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.
The value is that you don't train your users that it's OK to give their password away to random 3rd parties.
With OAuth, you could also request/authorise particular kinds of actions, rather than a carte-blanche (which is what handing over your password is). e.g. only edits, not deletes, protects or blocks (all of which are available in the API). In fact maybe Wiki*edia's OAuth implementation would specifically only allow edits, or non-admin actions, something like that.
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!
I imagine you could also have it so that actions made via the API identify where they are made from. (a la Twitter's "from web", "from twhirl" etc)
In that case, if that information was exposed in the UI, it would be easy to identify rogue applications and block them completely across the site.
In fact that would be far better than the case where you just hand over your password, and there is zero information about where that edit "really" came from.
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.
Well it sounds to me like you are opposed to the whole principle of having a write API. No?
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.
Client-side as in a desktop application? How is that any different? Couldn't an evil desktop app send its passwords off to its evil author who then uses them for evil purposes?
cheers, Brianna
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.
Client-side as in a desktop application? How is that any different? Couldn't an evil desktop app send its passwords off to its evil author who then uses them for evil purposes?
To emphasize this point, the desktop application could also use OAuth, which would avoid this issue as well. Also, you'd then be able to limit the actions of the desktop application as well.
V/r,
Ryan Lane
Brianna Laugher wrote:
2009/7/23 Aryeh Gregor Simetrical+wikilist@gmail.com:
On Thu, Jul 23, 2009 at 2:05 AM, Brianna Laugherbrianna.laugher@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.
The value is that you don't train your users that it's OK to give their password away to random 3rd parties.
With OAuth, you could also request/authorise particular kinds of actions, rather than a carte-blanche (which is what handing over your password is). e.g. only edits, not deletes, protects or blocks (all of which are available in the API). In fact maybe Wiki*edia's OAuth implementation would specifically only allow edits, or non-admin actions, something like that.
No, you just train them that it is OK to give almost full access to their account to random 3rd parties. For a non-admin, the ability to edit pages is the most important right. With the ability to edit pages, the 3rd party would be able to do pretty much anything you would need the password to do, except change the 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!
I imagine you could also have it so that actions made via the API identify where they are made from. (a la Twitter's "from web", "from twhirl" etc)
In that case, if that information was exposed in the UI, it would be easy to identify rogue applications and block them completely across the site.
The damage is still done. There might be hundreds of edits to clean up, accounts that need to be unblocked, emails wondering why dozens of high-profile articles are filled with shock porn, etc.
Or they could use the accounts to make valid-looking, but incorrect edits. Since the accounts are of trusted users, people may not question it and days might go by before someone realizes.
In fact that would be far better than the case where you just hand over your password, and there is zero information about where that edit "really" came from.
Or people could just do neither.
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.
Well it sounds to me like you are opposed to the whole principle of having a write API. No?
The write API has plenty of valid uses that don't require users to hand partial control of their account to 3rd parties.
On Thu, Jul 23, 2009 at 3:21 AM, Brianna Laugherbrianna.laugher@gmail.com wrote:
The value is that you don't train your users that it's OK to give their password away to random 3rd parties.
No, instead you train them to give away the ability to edit using their account to random third parties, without giving away their password. At least most people have had "Don't ever tell any third party your password" drilled into their head enough that they'll think twice before doing it.
With OAuth, you could also request/authorise particular kinds of actions, rather than a carte-blanche (which is what handing over your password is). e.g. only edits, not deletes, protects or blocks (all of which are available in the API). In fact maybe Wiki*edia's OAuth implementation would specifically only allow edits, or non-admin actions, something like that.
"Only non-admin edits" still means the unpreventable possibility of mass vandalism using accounts of trusted users.
I imagine you could also have it so that actions made via the API identify where they are made from. (a la Twitter's "from web", "from twhirl" etc)
In that case, if that information was exposed in the UI, it would be easy to identify rogue applications and block them completely across the site.
Okay, so you'd be able to identify the source. The fact that it's possible at all for a third party to create such chaos is still unacceptable. Even worse would be more subtle impersonation, which isn't obviously linked to the service (i.e., where the user would be suspected of having authorized it even if it was known that it was done through the service).
In fact that would be far better than the case where you just hand over your password, and there is zero information about where that edit "really" came from.
False dichotomy. The legitimate alternatives I presented are client-side apps, MediaWiki enhancements, and toolserver tools, not handing out your password. Any site found harvesting Wikipedia users' passwords should be immediately blocked at the server level.
Well it sounds to me like you are opposed to the whole principle of having a write API. No?
No. I'm opposed to giving any third party significant control over a large number of Wikipedia accounts. The write API is no different from the web API in that respect. In fact, without a write API, people could and did and do just screen-scrape. The API is just a convenience, it doesn't give anyone more rights and so has no security impact (except if it introduces bugs, obviously).
Client-side as in a desktop application? How is that any different? Couldn't an evil desktop app send its passwords off to its evil author who then uses them for evil purposes?
Any desktop application is already running with your privileges, and could already steal the password to Wikipedia and all your websites if it was malicious, so there's no increase in attack surface.
On Thu, Jul 23, 2009 at 3:29 AM, Ryan Lanerlane32@gmail.com wrote:
To emphasize this point, the desktop application could also use OAuth, which would avoid this issue as well. Also, you'd then be able to limit the actions of the desktop application as well.
No, you wouldn't, because it would just read your stored passwords from your home directory. Or read your cookies from your home directory, since those are generally stored in plaintext even if the passwords are stored encrypted or not at all. Or install a browser extension to do anything else it feels like with your web-related data. Or read your password and/or cookies from the network. Or set itself up as a keylogger. Or replace the browser shortcut with a link to a malicious imitation. Or . . . do I have to continue? If you've run a malicious desktop app, you're owned, period.
2009/7/23 Alex mrzmanwiki@gmail.com:
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!
I imagine you could also have it so that actions made via the API identify where they are made from. (a la Twitter's "from web", "from twhirl" etc)
In that case, if that information was exposed in the UI, it would be easy to identify rogue applications and block them completely across the site.
The damage is still done. There might be hundreds of edits to clean up, accounts that need to be unblocked, emails wondering why dozens of high-profile articles are filled with shock porn, etc.
Then we use something like Special:Nuke to mass-undo edits according to some criteria (like if they came from a particular Oauth-API-using app).
All the potential problems posed are ones that Wikipedia faces every day just because it lets people edit, period. I don't see how doing it via an API adds some massive new risk.
In fact that would be far better than the case where you just hand over your password, and there is zero information about where that edit "really" came from.
Or people could just do neither.
So, if someone builds a cool, *useful* 3rd party app, users are just going to not use it. Right.
If we provide the write API, surely we are implicitly saying to third parties, "It is OK to build an app that uses this." Why else would we provide it?
Well it sounds to me like you are opposed to the whole principle of having a write API. No?
The write API has plenty of valid uses that don't require users to hand partial control of their account to 3rd parties.
Really, what are they?
Probably it's good for bots. But that is really limited, compared to what might be possible.
IIRC the write API was originally developed for/by a phone company to develop a mobile editing platform. Is that acceptable?
2009/7/23 Aryeh Gregor Simetrical+wikilist@gmail.com:
On Thu, Jul 23, 2009 at 3:21 AM, Brianna Laugherbrianna.laugher@gmail.com wrote:
The value is that you don't train your users that it's OK to give their password away to random 3rd parties.
No, instead you train them to give away the ability to edit using their account to random third parties, without giving away their password.
Yes, and you put controls around it, so that the potential for damage is limited and controllable.
At least most people have had "Don't ever tell any third
party your password" drilled into their head enough that they'll think twice before doing it.
Right... so you never received any of that social networking spam, just because one of your email contacts put his Hotmail/Yahoo/Gmail password into some random site just so it could look for additional contacts?
If the thing is useful enough, people will give away their password. And currently they don't even have a choice not to.
I imagine you could also have it so that actions made via the API identify where they are made from. (a la Twitter's "from web", "from twhirl" etc)
In that case, if that information was exposed in the UI, it would be easy to identify rogue applications and block them completely across the site.
Okay, so you'd be able to identify the source. The fact that it's possible at all for a third party to create such chaos is still unacceptable. Even worse would be more subtle impersonation, which isn't obviously linked to the service (i.e., where the user would be suspected of having authorized it even if it was known that it was done through the service).
It's not unacceptable... it's how Wikipedia works!
But that is even *more* likely if you don't have OAuth and people have to hand over their passwords.
In fact that would be far better than the case where you just hand over your password, and there is zero information about where that edit "really" came from.
False dichotomy. The legitimate alternatives I presented are client-side apps, MediaWiki enhancements, and toolserver tools, not handing out your password. Any site found harvesting Wikipedia users' passwords should be immediately blocked at the server level.
So it's OK for a desktop (client-side) app to harvest passwords, but not a web app. Why?
MediaWiki enhancements - there is necessarily a high barrier to having an extension accepted into MediaWiki. The type of application I mentioned, which is only applicable to one topic area, is not likely to be enabled on en.wp. So too bad?
Toolserver tools - as previously mentioned, these are not allowed to harvest login info, so I don't understand their relevance here. Anyone can write a non-login-info-using, API-using 3rd party app whether or not it is hosted by the toolserver.
I love the idea of the write API because it removes the necessity to have MediaWiki as the only way to interact with Wikimedia content. The write API lets us innovate at the interface level just as we collaboratively innovate at the content level.
Why on earth would the API have delete, protect and block in it if there wasn't the idea that it could be used to build alternative editing interfaces?
On Thu, Jul 23, 2009 at 3:29 AM, Ryan Lanerlane32@gmail.com wrote:
To emphasize this point, the desktop application could also use OAuth, which would avoid this issue as well. Also, you'd then be able to limit the actions of the desktop application as well.
No, you wouldn't, because it would just read your stored passwords from your home directory. Or read your cookies from your home directory, since those are generally stored in plaintext even if the passwords are stored encrypted or not at all. Or install a browser extension to do anything else it feels like with your web-related data. Or read your password and/or cookies from the network. Or set itself up as a keylogger. Or replace the browser shortcut with a link to a malicious imitation. Or . . . do I have to continue? If you've run a malicious desktop app, you're owned, period.
Except that OAuth could help limit the damage?
regards, Brianna
On Thu, Jul 23, 2009 at 2:20 AM, Brianna Laugherbrianna.laugher@gmail.com wrote:
All the potential problems posed are ones that Wikipedia faces every day just because it lets people edit, period. I don't see how doing it via an API adds some massive new risk.
Well. If you had some way to clearly distinguish which automated tool made the edit, and a way for admins to block all edits from a specific tool as easily as they can currently block or revert all edits from a specific user, and no way to take dangerous admin-only actions (e.g. editing interface messages) using the tool -- then on reflection, I'll grant that I don't see any problems with it. The only serious risk, then, would be to a user's reputation, if the tool author is subtly malicious. That only affects the specific user, and is a risk they can decide to take or not.
That's a considerable amount of infrastructure that would be needed, though. I'm not sure it's worth the effort just for the sake of enabling web-based editing tools. Remember, for desktop tools this is pointless. They can already steal your password directly in a hundred different ways, so letting them edit directly using your credentials is as safe as running them at all. There are plenty of desktop tools that are already used as editing aids. I doubt the gain from allowing web-based tools as well would be worth implementing this whole authentication system.
So, if someone builds a cool, *useful* 3rd party app, users are just going to not use it. Right.
Sure they're not, if we block its IP address at the firewall as soon as it's reported to us. Practically speaking, I haven't heard of many such services becoming widespread, despite the fact that they're entirely possible if users can be persuaded to part with their passwords. It seems like MediaWiki enhancements *plus* toolserver tools *plus* client-side code (including custom JavaScript) are enough to keep pretty much everyone happy. Each of the three has its own limitations, but together they give fairly good coverage of the features people want.
IIRC the write API was originally developed for/by a phone company to develop a mobile editing platform. Is that acceptable?
Again, there's no increase in attack surface, because the one running the service is your ISP. They can already sniff your password unless you use SSL, if they're malicious. The problem is added points of failure. Currently the only way you could edit under someone else's name would be either to compromise their desktop, compromise Wikimedia, or compromise some party in between. Anything that only depends on the security of those three points is no worse than our current security.
Giving anyone on the Internet the ability to gather massive amounts of editing credentials adds a *new* point of failure. Not only that, but the new point of failure is much more serious than any of the existing three. We can (have to, really) assume that Wikimedia and large ISPs are hard to compromise; and while a desktop might be easy to compromise, it will have very limited access (to just one or a few accounts). A poorly-administered third-party site that has the ability to edit as thousands of different established users could be easy to compromise *and* have a big impact.
This is manageable if we allow such services to be monitored and blocked easily, but not otherwise. If you can't tell the third-party service from normal edits, then you'd be forced to just block all the misbehaving users -- but those might well include many of the admins who would normally do the blocking! That's why it's scary. If you can stop the service easily, then it becomes acceptable. I personally doubt it's worth the effort, but if someone's willing to do it, I don't see any insurmountable problems.
Right... so you never received any of that social networking spam, just because one of your email contacts put his Hotmail/Yahoo/Gmail password into some random site just so it could look for additional contacts?
I said think twice, not refrain from doing it in all cases.
If the thing is useful enough, people will give away their password.
Except in practice, they don't do it very often at all, at least for Wikipedia, and at least that I've heard of. Do you have any counterexamples beyond the one that triggered this thread?
So it's OK for a desktop (client-side) app to harvest passwords, but not a web app. Why?
I already explained this in detail. I'm not sure what part you don't get. A desktop app can impersonate you no matter what. Giving your password to it makes no appreciable difference to security. Using OAuth for desktop apps gives you no protection.
Toolserver tools - as previously mentioned, these are not allowed to harvest login info, so I don't understand their relevance here. Anyone can write a non-login-info-using, API-using 3rd party app whether or not it is hosted by the toolserver.
No, because toolserver tools have direct database access. That allows them to work in some situations (like that of the original post) without the need to request authentication at all. In the case of combined watchlists, some special access would have to be worked out, but it would be doable.
I love the idea of the write API because it removes the necessity to have MediaWiki as the only way to interact with Wikimedia content. The write API lets us innovate at the interface level just as we collaboratively innovate at the content level.
The write API doesn't allow anything new. It just makes some things easier and more reliable. Anything you could do with the write API, you could do by screen-scraping, just maybe less quickly and reliably. (With maybe a very small number of narrow exceptions.)
2009/7/24 Aryeh Gregor Simetrical+wikilist@gmail.com:
On Thu, Jul 23, 2009 at 2:20 AM, Brianna Laugherbrianna.laugher@gmail.com wrote:
All the potential problems posed are ones that Wikipedia faces every day just because it lets people edit, period. I don't see how doing it via an API adds some massive new risk.
Well. If you had some way to clearly distinguish which automated tool made the edit, and a way for admins to block all edits from a specific tool as easily as they can currently block or revert all edits from a specific user, and no way to take dangerous admin-only actions (e.g. editing interface messages) using the tool -- then on reflection, I'll grant that I don't see any problems with it. The only serious risk, then, would be to a user's reputation, if the tool author is subtly malicious. That only affects the specific user, and is a risk they can decide to take or not.
Yay!
That's a considerable amount of infrastructure that would be needed, though. I'm not sure it's worth the effort just for the sake of enabling web-based editing tools. Remember, for desktop tools this is pointless. They can already steal your password directly in a hundred different ways, so letting them edit directly using your credentials is as safe as running them at all. There are plenty of desktop tools that are already used as editing aids. I doubt the gain from allowing web-based tools as well would be worth implementing this whole authentication system.
Well, I don't know that I agree with this argument "we should just assume desktops are already compromised", but I'm not that interested in desktop applications so I will leave it aside.
Given that * the write API has only been enabled on Wikimedia sites since August 2008 (less than a year) * we don't do very much/any promotion of our API, and * our data is extremely complex (especially compared to, say, Twitter), I am not at all surprised that no web apps have yet spung up (or, only Watchlistr). I don't think the fact that no web apps have been created yet means that it has been judged as not-that-useful. I think it will take a while, and a few examples, for developers to start to get the idea of being creative with the MW API.
I love the idea of the write API because it removes the necessity to have MediaWiki as the only way to interact with Wikimedia content. The write API lets us innovate at the interface level just as we collaboratively innovate at the content level.
The write API doesn't allow anything new. It just makes some things easier and more reliable. Anything you could do with the write API, you could do by screen-scraping, just maybe less quickly and reliably. (With maybe a very small number of narrow exceptions.)
If you make something orders of magnitude easier, it is like a "new" thing.
Anyway I am glad that we have come to some kind of agreement. I expanded some info at http://www.mediawiki.org/wiki/OAuth based on this discussion.
cheers Brianna
On Thu, Jul 23, 2009 at 8:52 PM, Brianna Laugherbrianna.laugher@gmail.com wrote:
If you make something orders of magnitude easier, it is like a "new" thing.
I think you're overstating how much easier the write API is to use. Screen-scraping is not hard. We've always had plenty of screen-scraping bots, and we still do. I'd like to think that there's no proliferation of web-based third-party editing interfaces because you have to request users' passwords to get them to work, and that's an obviously stupid idea. Plus because existing non-web-based editing interfaces are good enough.
On Fri, Jul 24, 2009 at 2:52 AM, Brianna Laugherbrianna.laugher@gmail.com wrote:
2009/7/24 Aryeh Gregor Simetrical+wikilist@gmail.com:
On Thu, Jul 23, 2009 at 2:20 AM, Brianna Laugherbrianna.laugher@gmail.com wrote:
All the potential problems posed are ones that Wikipedia faces every day just because it lets people edit, period. I don't see how doing it via an API adds some massive new risk.
Well. If you had some way to clearly distinguish which automated tool made the edit,
....
Yay!
I dunno, a third input box name="botname"?
<input type="hidden" name="botname" />
On Fri, Jul 24, 2009 at 2:23 AM, Teioscar.vives@gmail.com wrote:
I dunno, a third input box name="botname"?
<input type="hidden" name="botname" />
I'm talking about in the case of a possibly malicious service, and only if it's using OAuth (or whatever). Presumably if it's using OAuth the user already gave it some unique identification token that we can just revoke, so I don't think the hard part here would be the identification itself. The hard part would be the rest: making it immediately obvious to everyone that a given change was made through a specific web service, and allowing admins to block such services easily. And implementing something like OAuth to begin with.
Brianna Laugher wrote:
2009/7/23 Alex mrzmanwiki@gmail.com:
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!
I imagine you could also have it so that actions made via the API identify where they are made from. (a la Twitter's "from web", "from twhirl" etc)
In that case, if that information was exposed in the UI, it would be easy to identify rogue applications and block them completely across the site.
The damage is still done. There might be hundreds of edits to clean up, accounts that need to be unblocked, emails wondering why dozens of high-profile articles are filled with shock porn, etc.
Then we use something like Special:Nuke to mass-undo edits according to some criteria (like if they came from a particular Oauth-API-using app).
All the potential problems posed are ones that Wikipedia faces every day just because it lets people edit, period. I don't see how doing it via an API adds some massive new risk.
Really? When was the last time a large quantity of accounts belonging to established users was hijacked and used for vandalism? Typically when vandalism happens, its coming from a very new account, so people don't think twice about it. If accounts belonging to established users start to vandalize, its going to cause quite a bit of confusion. At least the first couple times. I imagine after a few instances, communities may start to prohibit people from using such services.
In fact that would be far better than the case where you just hand over your password, and there is zero information about where that edit "really" came from.
Or people could just do neither.
So, if someone builds a cool, *useful* 3rd party app, users are just going to not use it. Right.
If we provide the write API, surely we are implicitly saying to third parties, "It is OK to build an app that uses this." Why else would we provide it?
So if people /really/ want a security hole, we should provide it for them? I don't think so.
Just because we provide an API doesn't mean we're asking for this. Would you say that because we allow anyone to edit, we're implicitly saying "Please, come vandalize our site"? We provide the API so that programmers can have a stable interface and their code won't break every time there's a slight change to the UI. We're making no assumptions as to who those programmers are.
Well it sounds to me like you are opposed to the whole principle of having a write API. No?
The write API has plenty of valid uses that don't require users to hand partial control of their account to 3rd parties.
Really, what are they?
Probably it's good for bots. But that is really limited, compared to what might be possible.
IIRC the write API was originally developed for/by a phone company to develop a mobile editing platform. Is that acceptable?
Yes, its very good for bots. Its also used with JavaScript. You make it sound like these are trivial uses.
A mobile editing platform is different from the applications being discussed here. A mobile editing platform should not require you to give any access to your account to a third party. All it should need is an app, installed on the phone that basically just provides a simplified editing interface. Or at worst, you're giving the information to a company who has an obligation to keep your personal data secure, and who you already trust with far more sensitive information, like your home address and credit card number. So that's totally different from some random website operated by some unknown person.
On a related note however, there's no reason why such an interface should require a 3rd party at all. There's been a lot of work done lately on a mobile version for Wikimedia sites. I believe its read-only at the moment, but I imagine the eventual goal is to have most of the capabilities of the regular site.
On 07/22/2009 08:21 PM, Brianna Laugher wrote:
I imagine you could also have it so that actions made via the API identify where they are made from. (a la Twitter's "from web", "from twhirl" etc)
In that case, if that information was exposed in the UI, it would be easy to identify rogue applications and block them completely across the site.
Exactly. :)
Permissions can be as fine grained as we want and it can be quite easy to revoke access on an individual or site basis.
-- brion
Brianna Laugher <brianna.laugher <at> gmail.com> writes:
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.
That can be done without giving out password, via javascript interfaces and cross-domain AJAX calls to the API. It would require a modern browser and some sort of permission (I'm not sure whether it has to be given in the browser or in the HTTP headers sent by wikipedia.hu), but is solid from a security point of view: you log in at wikipedia.org, get a session cookie, go to 3rdparty.org, the script loaded by your browser sends API requests to wikipedia.org and the browser attaches the cookie to them automatically, but 3rdparty.org cannot access them due to the browser's domain-based security rules. The worst it could do is misuse your account as long as you have the page open in your browser... not very dangerous. And the site is named in the referer of the AJAX request and can be easily filtered out if it's problematic.
On Wed, Jul 22, 2009 at 10:05 PM, Brianna Laugherbrianna.laugher@gmail.com wrote: [snip]
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.
Sweet.
I look forward to the bright future where I can create an enhanced AJAX edit-box for MediaWiki then throw it up with a bunch of ads and private-data-collection and avoid the pesky problem of open sourcing my code and contributing it back to the MediaWiki codebase in order to get it widely used.
2009/7/24 Gregory Maxwell gmaxwell@gmail.com:
On Wed, Jul 22, 2009 at 10:05 PM, Brianna Laugherbrianna.laugher@gmail.com wrote: [snip]
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.
Sweet.
I look forward to the bright future where I can create an enhanced AJAX edit-box for MediaWiki then throw it up with a bunch of ads and private-data-collection and avoid the pesky problem of open sourcing my code and contributing it back to the MediaWiki codebase in order to get it widely used.
This is again something that OAuth can help with. Applications have to register with the service provider before they start using OAuth & the API. That gives the service provider an opportunity to set certain requirements, such as 1) the application must be open source and/or 2) the application must not do certain things such as collect XYZ data.
You could also require applications to not have any ads, although I don't feel we have a moral obligation to protect our users from advertisements from API-using applications.
As for contributing back to MediaWiki (implicitly for use on Wikimedia sites), as I said before, there is necessarily a high barrier to having an extension enabled on a Wikimedia site, and something of a requirement of general across-the-board usefulness (rather than only being applicable to one topic area, as an example).
Toolserver apps are an example of how interesting and useful things can be separate to MediaWiki and complement it. There are also other third parties such as Wikiscanner, Wikirage, WikiDashboard, WikiChanges, WikiMindmap and WikipediaVision, to name a few. That is the "bright present".
Brianna
wikitech-l@lists.wikimedia.org