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

On Thu, Jul 23, 2009 at 3:21 AM, Brianna Laugher<brianna.laugher(a)gmail.com> wrote: 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. "Only non-admin edits" still means the unpreventable possibility of mass vandalism using accounts of trusted users. 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). 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. 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). 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 Lane<rlane32(a)gmail.com> wrote: 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.

On Thu, Jul 23, 2009 at 2:20 AM, Brianna Laugher<brianna.laugher(a)gmail.com> wrote: 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. 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. 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. I said think twice, not refrain from doing it in all cases. 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? 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. 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. 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.)

On Thu, Jul 23, 2009 at 8:52 PM, Brianna Laugher<brianna.laugher(a)gmail.com> wrote: 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:23 AM, Tei<oscar.vives(a)gmail.com> wrote: 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.

On 07/22/2009 08:21 PM, Brianna Laugher wrote: 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