Brianna Laugher wrote:
2009/7/23 Alex <mrzmanwiki(a)gmail.com>om>:
> 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.
--
Alex (wikipedia:en:User:Mr.Z-man)