Alternative editing interfaces using write API (was: Re: Watchlistr.com, an outside site that asks for Wikimedia passwords)

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Alternative editing interfaces using write API (was: Re: Watchlistr.com, an outside site that asks for Wikimedia passwords)

Brianna Laugher
2009/7/23 Aryeh Gregor <[hidden email]>:

> On Thu, Jul 23, 2009 at 1:02 AM, Ryan Lane<[hidden email]> wrote:
>> Check out how the Flickr API works. Users can give web and desktop
>> apps privileges (read/write/delete).
>>
>> It isn't really that bizarre of a concept.
>
> Read/write/delete access to what?  The only cases where read access
> would be relevant would be what, watchlist and preferences, pretty
> much?  I don't think we'd want this for editing, or admin-only stuff
> like viewing deleted pages.

Eh? I do. Else why bother even having a write API?  Why bother even
having the login aspect to the API?

I can imagine someone building an alternative edit interface for a
subset of Wikipedia content, say a WikiProject. Then the interface can
strip away all the general crud and just provide information relevant
to that topic area.

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).

Brianna

--
They've just been waiting in a mountain for the right moment:
http://modernthings.org/

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Alternative editing interfaces using write API (was: Re: Watchlistr.com, an outside site that asks for Wikimedia passwords)

John Mark Vandenberg
On Thu, Jul 23, 2009 at 12:05 PM, Brianna
Laugher<[hidden email]> wrote:

> 2009/7/23 Aryeh Gregor <[hidden email]>:
>> On Thu, Jul 23, 2009 at 1:02 AM, Ryan Lane<[hidden email]> wrote:
>>> Check out how the Flickr API works. Users can give web and desktop
>>> apps privileges (read/write/delete).
>>>
>>> It isn't really that bizarre of a concept.
>>
>> Read/write/delete access to what?  The only cases where read access
>> would be relevant would be what, watchlist and preferences, pretty
>> much?  I don't think we'd want this for editing, or admin-only stuff
>> like viewing deleted pages.
>
> Eh? I do. Else why bother even having a write API?  Why bother even
> having the login aspect to the API?
>
> I can imagine someone building an alternative edit interface for a
> subset of Wikipedia content, say a WikiProject. Then the interface can
> strip away all the general crud and just provide information relevant
> to that topic area.

And moving slightly away from "editing", Flickr could have an "upload
to Wikimedia Commons" application which integrates nicely into their
UI, and retaining a link in their system to indicate the name of the
file over on Commons.

--
John Vandenberg

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Alternative editing interfaces using write API (was: Re: Watchlistr.com, an outside site that asks for Wikimedia passwords)

Aryeh Gregor
In reply to this post by Brianna Laugher
On Thu, Jul 23, 2009 at 2:05 AM, Brianna
Laugher<[hidden email]> wrote:
> Eh? I do. Else why bother even having a write API?  Why bother even
> having the login aspect to the API?

The API allows you to edit if you know the password of the account
you're using.  I can't see the value in creating some mechanism to
allow editing from an account with some special limited authorization
that's less than giving away the account password in practice.

> I can imagine someone building an alternative edit interface for a
> subset of Wikipedia content, say a WikiProject. Then the interface can
> strip away all the general crud and just provide information relevant
> to that topic area.

If they're allowing a third party to edit using their account, the
trust issues involved are substantially identical to just giving that
service their password.

> 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!

On Thu, Jul 23, 2009 at 2:27 AM, John Vandenberg<[hidden email]> wrote:
> And moving slightly away from "editing", Flickr could have an "upload
> to Wikimedia Commons" application which integrates nicely into their
> UI, and retaining a link in their system to indicate the name of the
> file over on Commons.

Yeah, great, and let's also have users let Facebook edit arbitrary
pages with their account name so that they can keep their profile
synchronized across sites.  This just strikes me as a horribly bad
idea.  When a user makes an edit, you should know that *that user made
the edit*.  Users should not be encouraged to let random third parties
use their account for any purpose.

On Flickr, the worst that could happen is their own stuff gets
trashed.  If a popular service goes rogue, then nobody has to care
except the people who trusted it.  No one else has the ability to do
anything about it anyway.  On a wiki, accounts could be used for
vandalism.  A rogue service means a huge number of established,
trusted users, including sysops, suddenly starting to blank pages and
add random profanity.  And nobody will have any idea what to do
because *it looks like it's a trusted user doing it*.  And probably
nobody has a list of who's given that service access to their account,
either.

Wikis are not a private sandbox.  If you can affect no one but
yourself, then sure, go ahead and allow foreign sites to screw with
your account.  That logic just doesn't apply on wikis.

So, my two cents: no.  Any application that's useful can be integrated
into MediaWiki itself, or a toolserver tool, or a client-side program
with access to the password.  We have plenty of examples of all of
these, and I fail to see how any use-case presented so far can't be
met by them just as well as the OAuth proposal, when you account for
the difference in security.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Alternative editing interfaces using write API (was: Re: Watchlistr.com, an outside site that asks for Wikimedia passwords)

Brianna Laugher
2009/7/23 Aryeh Gregor <[hidden email]>:
> On Thu, Jul 23, 2009 at 2:05 AM, Brianna
> Laugher<[hidden email]> wrote:
>> Eh? I do. Else why bother even having a write API?  Why bother even
>> having the login aspect to the API?
>
> The API allows you to edit if you know the password of the account
> you're using.  I can't see the value in creating some mechanism to
> allow editing from an account with some special limited authorization
> that's less than giving away the account password in practice.

The value is that you don't train your users that it's OK to give
their password away to random 3rd parties.

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.

>> 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.

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.

> Yeah, great, and let's also have users let Facebook edit arbitrary
> pages with their account name so that they can keep their profile
> synchronized across sites.  This just strikes me as a horribly bad
> idea.  When a user makes an edit, you should know that *that user made
> the edit*.  Users should not be encouraged to let random third parties
> use their account for any purpose.

Well it sounds to me like you are opposed to the whole principle of
having a write API. No?

> So, my two cents: no.  Any application that's useful can be integrated
> into MediaWiki itself, or a toolserver tool, or a client-side program
> with access to the password.

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?

cheers,
Brianna

--
They've just been waiting in a mountain for the right moment:
http://modernthings.org/

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Alternative editing interfaces using write API (was: Re: Watchlistr.com, an outside site that asks for Wikimedia passwords)

Ryan Lane-2
>> So, my two cents: no.  Any application that's useful can be integrated
>> into MediaWiki itself, or a toolserver tool, or a client-side program
>> with access to the password.
>
> 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?
>

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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Alternative editing interfaces using write API (was: Re: Watchlistr.com, an outside site that asks for Wikimedia passwords)

Alex Zaddach
In reply to this post by Brianna Laugher
Brianna Laugher wrote:

> 2009/7/23 Aryeh Gregor <[hidden email]>:
>> On Thu, Jul 23, 2009 at 2:05 AM, Brianna
>> Laugher<[hidden email]> wrote:
>>> Eh? I do. Else why bother even having a write API?  Why bother even
>>> having the login aspect to the API?
>> The API allows you to edit if you know the password of the account
>> you're using.  I can't see the value in creating some mechanism to
>> allow editing from an account with some special limited authorization
>> that's less than giving away the account password in practice.
>
> The value is that you don't train your users that it's OK to give
> their password away to random 3rd parties.
>
> 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.

No, you just train them that it is OK to give almost full access to
their account to random 3rd parties. For a non-admin, the ability to
edit pages is the most important right. With the ability to edit pages,
the 3rd party would be able to do pretty much anything you would need
the password to do, except change the password.

>>> 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.

Or they could use the accounts to make valid-looking, but incorrect
edits. Since the accounts are of trusted users, people may not question
it and days might go by before someone realizes.

> 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.

>> Yeah, great, and let's also have users let Facebook edit arbitrary
>> pages with their account name so that they can keep their profile
>> synchronized across sites.  This just strikes me as a horribly bad
>> idea.  When a user makes an edit, you should know that *that user made
>> the edit*.  Users should not be encouraged to let random third parties
>> use their account for any purpose.
>
> 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.

--
Alex (wikipedia:en:User:Mr.Z-man)

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Alternative editing interfaces using write API (was: Re: Watchlistr.com, an outside site that asks for Wikimedia passwords)

Aryeh Gregor
In reply to this post by Brianna Laugher
On Thu, Jul 23, 2009 at 3:21 AM, Brianna
Laugher<[hidden email]> 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<[hidden email]> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Alternative editing interfaces using write API (was: Re: Watchlistr.com, an outside site that asks for Wikimedia passwords)

Brianna Laugher
2009/7/23 Alex <[hidden email]>:

>>>> 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 <[hidden email]>:
> On Thu, Jul 23, 2009 at 3:21 AM, Brianna
> Laugher<[hidden email]> 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<[hidden email]> 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/

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Alternative editing interfaces using write API (was: Re:Watchlistr.com, an outside site that asks for Wikimedia passwords)

Gergő Tisza
In reply to this post by Brianna Laugher
Brianna Laugher <brianna.laugher <at> gmail.com> writes:

> I can imagine someone building an alternative edit interface for a
> subset of Wikipedia content, say a WikiProject. Then the interface can
> strip away all the general crud and just provide information relevant
> to that topic area.

That can be done without giving out password, via javascript interfaces and
cross-domain AJAX calls to the API. It would require a modern browser and some
sort of permission (I'm not sure whether it has to be given in the browser or in
the HTTP headers sent by wikipedia.hu), but is solid from a security point of
view: you log in at wikipedia.org, get a session cookie, go to 3rdparty.org, the
script loaded by your browser sends API requests to wikipedia.org and the
browser attaches the cookie to them automatically, but 3rdparty.org cannot
access them due to the browser's domain-based security rules. The worst it could
do is misuse your account as long as you have the page open in your browser...
not very dangerous. And the site is named in the referer of the AJAX request and
can be easily filtered out if it's problematic.


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Alternative editing interfaces using write API (was: Re: Watchlistr.com, an outside site that asks for Wikimedia passwords)

Aryeh Gregor
In reply to this post by Brianna Laugher
On Thu, Jul 23, 2009 at 2:20 AM, Brianna
Laugher<[hidden email]> wrote:
> 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.

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.

> So, if someone builds a cool, *useful* 3rd party app, users are just
> going to not use it. Right.

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.

> IIRC the write API was originally developed for/by a phone company to
> develop a mobile editing platform. Is that acceptable?

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.

> 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?

I said think twice, not refrain from doing it in all cases.

> If the thing is useful enough, people will give away their password.

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?

> So it's OK for a desktop (client-side) app to harvest passwords, but
> not a web app. Why?

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.

> 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.

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.

> 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.

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.)

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Alternative editing interfaces using write API (was: Re: Watchlistr.com, an outside site that asks for Wikimedia passwords)

Alex Zaddach
In reply to this post by Brianna Laugher
Brianna Laugher wrote:

> 2009/7/23 Alex <[hidden email]>:
>>>>> 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)

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Alternative editing interfaces using write API (was: Re: Watchlistr.com, an outside site that asks for Wikimedia passwords)

Brion Vibber-3
In reply to this post by Brianna Laugher
On 07/22/2009 08:21 PM, Brianna Laugher wrote:
> 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.

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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Alternative editing interfaces using write API (was: Re: Watchlistr.com, an outside site that asks for Wikimedia passwords)

Brianna Laugher
In reply to this post by Aryeh Gregor
2009/7/24 Aryeh Gregor <[hidden email]>:

> On Thu, Jul 23, 2009 at 2:20 AM, Brianna
> Laugher<[hidden email]> wrote:
>> 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.
>
> 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.

Yay!

> 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.

Well, I don't know that I agree with this argument "we should just
assume desktops are already compromised", but I'm not that interested
in desktop applications so I will leave it aside.

Given that
* the write API has only been enabled on Wikimedia sites since August
2008 (less than a year)
* we don't do very much/any promotion of our API, and
* our data is extremely complex (especially compared to, say, Twitter),
I am not at all surprised that no web apps have yet spung up (or, only
Watchlistr). I don't think the fact that no web apps have been created
yet means that it has been judged as not-that-useful. I think it will
take a while, and a few examples, for developers to start to get the
idea of being creative with the MW API.


>> 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.
>
> 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.)

If you make something orders of magnitude easier, it is like a "new" thing.

Anyway I am glad that we have come to some kind of agreement. I
expanded some info at <http://www.mediawiki.org/wiki/OAuth> based on
this discussion.

cheers
Brianna

--
They've just been waiting in a mountain for the right moment:
http://modernthings.org/

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Alternative editing interfaces using write API (was: Re: Watchlistr.com, an outside site that asks for Wikimedia passwords)

Aryeh Gregor
On Thu, Jul 23, 2009 at 8:52 PM, Brianna
Laugher<[hidden email]> wrote:
> If you make something orders of magnitude easier, it is like a "new" thing.

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.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Alternative editing interfaces using write API (was: Re: Watchlistr.com, an outside site that asks for Wikimedia passwords)

Tei-2
In reply to this post by Brianna Laugher
On Fri, Jul 24, 2009 at 2:52 AM, Brianna
Laugher<[hidden email]> wrote:
> 2009/7/24 Aryeh Gregor <[hidden email]>:
>> On Thu, Jul 23, 2009 at 2:20 AM, Brianna
>> Laugher<[hidden email]> wrote:
>>> 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.
>>
>> Well.  If you had some way to clearly distinguish which automated tool
>> made the edit,
....
>
> Yay!
>

I dunno, a third input box name="botname"?

<input type="hidden" name="botname" />





--
--
ℱin del ℳensaje.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Alternative editing interfaces using write API (was: Re: Watchlistr.com, an outside site that asks for Wikimedia passwords)

Aryeh Gregor
On Fri, Jul 24, 2009 at 2:23 AM, Tei<[hidden email]> wrote:
> I dunno, a third input box name="botname"?
>
> <input type="hidden" name="botname" />

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.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Alternative editing interfaces using write API (was: Re: Watchlistr.com, an outside site that asks for Wikimedia passwords)

Gregory Maxwell
In reply to this post by Brianna Laugher
On Wed, Jul 22, 2009 at 10:05 PM, Brianna
Laugher<[hidden email]> wrote:
[snip]
> I can imagine someone building an alternative edit interface for a
> subset of Wikipedia content, say a WikiProject. Then the interface can
> strip away all the general crud and just provide information relevant
> to that topic area.

Sweet.

I look forward to the bright future where I can create an enhanced
AJAX edit-box for MediaWiki then throw it up with a bunch of ads and
private-data-collection and avoid the pesky problem of open sourcing
my code and contributing it back to the MediaWiki codebase in order to
get it widely used.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Alternative editing interfaces using write API (was: Re: Watchlistr.com, an outside site that asks for Wikimedia passwords)

Brianna Laugher
2009/7/24 Gregory Maxwell <[hidden email]>:

> On Wed, Jul 22, 2009 at 10:05 PM, Brianna
> Laugher<[hidden email]> wrote:
> [snip]
>> I can imagine someone building an alternative edit interface for a
>> subset of Wikipedia content, say a WikiProject. Then the interface can
>> strip away all the general crud and just provide information relevant
>> to that topic area.
>
> Sweet.
>
> I look forward to the bright future where I can create an enhanced
> AJAX edit-box for MediaWiki then throw it up with a bunch of ads and
> private-data-collection and avoid the pesky problem of open sourcing
> my code and contributing it back to the MediaWiki codebase in order to
> get it widely used.

This is again something that OAuth can help with.
Applications have to register with the service provider before they
start using OAuth & the API. That gives the service provider an
opportunity to set certain requirements, such as 1) the application
must be open source and/or 2) the application must not do certain
things such as collect XYZ data.

You could also require applications to not have any ads, although I
don't feel we have a moral obligation to protect our users from
advertisements from API-using applications.

As for contributing back to MediaWiki (implicitly for use on Wikimedia
sites), as I said before, there is necessarily a high barrier to
having an extension enabled on a Wikimedia site, and something of a
requirement of general across-the-board usefulness (rather than only
being applicable to one topic area, as an example).

Toolserver apps are an example of how interesting and useful things
can be separate to MediaWiki and complement it. There are also other
third parties such as Wikiscanner, Wikirage, WikiDashboard,
WikiChanges, WikiMindmap and WikipediaVision, to name a few. That is
the "bright present".

Brianna

--
They've just been waiting in a mountain for the right moment:
http://modernthings.org/

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l