On Thu, Jul 23, 2009 at 2:20 AM, Brianna Laugher<[email protected]> 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.) _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
