On the topic of whether allowing Tor users to edit is a concern, I believe
so. Because of Tor blocks, it is sometimes extremely difficult, or even
impossible altogether, to edit Wikipedia for some users. I believe we
should give these users the opportunity to contribute rather than have them
punished because of others who misuse Tor for spamming/sockpuppeting.

As far as a solution goes, I have a complete codebase for
Extension:TokenAuth, which allows users to have MediaWiki sign a blinded
token, which can then be used to bypass a specific IP block in order to log
in and edit. It is almost ready; there are just a few functionality
problems with the JavaScript crypto library.

*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | [email protected]


On Sat, Dec 29, 2012 at 7:12 PM, Platonides <[email protected]> wrote:

> On 28/12/12 18:29, Tilman Bayer wrote:
> > On Fri, Dec 28, 2012 at 1:26 AM, Sumana Harihareswara wrote:
> >> I've floated this problem past Tor and privacy people, and here are a
> >> few ideas:
> >>
> >> 1) Just use the existing mechanisms more leniently.  Encourage the
> >> communities (Wikimedia & Tor) to use
> >> https://en.wikipedia.org/wiki/Wikipedia:Request_an_account (to get an
> >> account from behind Tor) and to let more people get IP block exemptions
> >> even before they've made any edits (< 30 people have gotten exemptions
> >> on en.wp in 2012).  Add encouraging "get an exempt account" language to
> >> the "you're blocked because you're using Tor" messaging.  Then if
> >> there's an uptick in vandalism from Tor then they can just tighten up
> >> again.
>
> This seems the right approach.
>
>
> >> 2) Encourage people with closed proxies to re-vitalize
> >> https://en.wikipedia.org/wiki/Wikipedia:WOCP .  Problem: using closed
> >> proxies is okay for people with some threat models but not others.
>
>
> I didn't know about it. This is an interesting concept. It would be
> possible to setup some 'public wikipedia proxys' (eg. by an European
> chapter) and encourage its use.
> It would still be possible to checkuser people going through that, but
> a 2-tier process would be needed (wiki checkuser + proxy admin) thus
> protecting from a “rogue checkuser” (Is that the primary concern of good
> editors wishing to use proxys?). We could use that setup for gaining
> information about usage (eg. it was 90% spam).
>
>
> >> 3) Look at Nymble - http://freehaven.net/anonbib/#oakland11-formalizing
> >> and http://cgi.soic.indiana.edu/~kapadia/nymble/overview.php .  It
> would
> >> allow Wikimedia to distance itself from knowing people's identities, but
> >> still allow admins to revoke permissions if people acted up.  The user
> >> shows a real identity, gets a token, and exchanges that token over tor
> >> for an account.  If the user abuses the site, Wikimedia site admins can
> >> blacklist the user without ever being able to learn who they were or
> >> what other edits they did.  More: https://cs.uwaterloo.ca/~iang/ Ian
> >> Golberg's, Nick Hopper's, and Apu Kapadia's groups are all working on
> >> Nymble or its derivatives.  It's not ready for production yet, I bet,
> >> but if someone wanted a Big Project....
> >
> > As Brad and Ariel point out, Nymble in the form described on the linked
> > project page does not seem to allow long-term blocks, and cannot deal
> with
> > dynamic IPs. In other words, it would only provide the analogue of
> > autoblock functionality for Tor users. The linked paper by Henry and
> > Goldberg is more realistic about these limitations, discussing IP
> addresses
> > only as one of several possible "unique identifiers" (§V). From the
> > concluding remarks to that chapter, it seems most likely that they would
> > recommend "some form of PKI or government ID-based registration" for our
> > purposes.
>
> Requiring a government ID for connecting through tor would be even worse
> for privacy.
>
> I completely agree that matching with the IP address used to request the
> nymble token is not enough. Maybe if the tokens were instead based in
> ISP+zone geolocation, that could be a way. Still, that would still miss
> linkability for vandals which use eg. both their home and work connections.
>
>
> > 3a) A token authorization system (perhaps a MediaWiki extension) where
> > the server blindly signs a token, and then the user can use that token
> > to bypass the Tor blocks.  (Tyler mentioned he saw this somewhere in a
> > Bugzilla suggestion; I haven't found it.)
>
> Bug 3729 ?
>
>
> >> Thoughts? Are any of you interested in working on this problem?  #tor on
> >> the OFTC IRC server is full of people who'd be interested in talking
> >> about this.
>
> This is a social problem. We have the tools to fix it (account creation
> + ip block exemption). If someone asked me for that (in a project where
> I can) because they are censored by their government I would gladly
> grant it.
> That also means that when they replaced 'Jimbo' with 'penis', 5 minutes
> after getting their account, I would notice and kick them out.
> In my experience, far more people is trying to use tor in wikipedia for
> vandalising than for doing constructive edits / due to local censorship.
> Although I concede that it's probably the opposite on ‘certain wikis’ I
> don't edit.
> The problem with global solutions are vandals abusing it.
>
> "If I don't get caught on 10 edits I can edit through tor" is a candle
> for vandals. Note that "I don't get caught" is different than "doing a
> constructive edit".
>
> An idea would be to force some recaptcha-style work before giving such
> tokens, so even though we know they will abuse the system, we are still
> using them as improving force (although the following vandalism could
> still be worse than what we gained).
>
>
> I also wonder if we are not aiming too high, trying to solve the
> anonimity and traceability problems on the internet, while we have for
> instance captchas forced to anons and newbies on a couple wikis due to a
> bot vandalism done years ago (bug 41745).
>
>
> _______________________________________________
> Wikitech-l mailing list
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to