On Thu, Jul 23, 2009 at 3:21 AM, Brianna
Laugher<brianna.laugher(a)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 Lane<rlane32(a)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.