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.
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?
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?
2009/7/23 Aryeh Gregor <Simetrical+wikilist(a)gmail.com>om>:
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.
Yes, and you put controls around it, so that the potential for damage
is limited and controllable.
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.
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?
If the thing is useful enough, people will give away their password.
And currently they don't even have a choice not to.
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).
It's not unacceptable... it's how Wikipedia works!
But that is even *more* likely if you don't have OAuth and people have
to hand over their passwords.
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.
So it's OK for a desktop (client-side) app to harvest passwords, but
not a web app. Why?
MediaWiki enhancements - there is necessarily a high barrier to having
an extension accepted into MediaWiki. The type of application I
mentioned, which is only applicable to one topic area, is not likely
to be enabled on en.wp. So too bad?
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.
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.
Why on earth would the API have delete, protect and block in it if
there wasn't the idea that it could be used to build alternative
editing interfaces?
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.
Except that OAuth could help limit the damage?
regards,
Brianna
--
They've just been waiting in a mountain for the right moment:
http://modernthings.org/