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