Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[Brian Wolff]

On 10/2/14, Kevin Wayne Williams  wrote:
> Derric Atzrott schreef op 2014/09/30 6:08:
>> Hello everyone,
>> [snip]
>> There must be a way that we can allow users to work from Tor.
>> [snip more]
>>
> I think the first step is to work harder to block devices, not IP
> addresses. One jerk with a cell phone cycles through so many IP
> addresses so quickly in such active ranges that our current protection
> techniques are useless. Any child can figure out how to pull his cable
> modem out of the wall and plug it back in.
>
> Focusing on what signature we can obtain from (or plant on) the device
> and how to make that signature available to and manageable by admins is
> the key. Maybe we require a WMF supplied app before one can edit from a
> mobile device. Maybe we plant cookies on every machine that edits
> Wikipedia to allow us to track who's using the machine and block access
> to anyone that won't permit the cookies to be stored. There are probably
> other techniques. The thing to remember is that the vast majority of our
> sockpuppeteers are actually fairly stupid and the ones that aren't will
> make their way past any technique short of retina scanning. It doesn't
> matter whether a blocking technique allows a tech-savvy user to bypass
> it somehow. Anything is better than a system that anyone can bypass by
> turning his cable modem off and on.
>
> Once we have a system that allows us to block individual devices
> reasonably effectively, it won't matter whether those people are using
> Tor to get to us or not.
>
> KWW
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


So all we need is either:
A) Magic browser fingerprinting with no (or almost no) false positives
when used against everyone in the world. With the fingerprinting code
having at most access to javascript to run code (but preferably not
even needing that) and it has to be robust in the face of the user
being able to maliciously modify the code as they please.
B) tamper proof modules inside every device to uniquely identify it.
(Can we say police state?)

Arguably those aren't making the assumption that "[users] are actually
fairly stupid". But even a simplified version of those requirements,
such as, must block on per device basis, must involve more work than
unpluging a cable modem to get unblocked, dwells into the territory of
absurdly hard.

Although perhaps there are some subset of the population we could use
additional methods on. Cookies are pretty useless (If you think
getting a new IP is easy, you should see what it takes to delete a
cookie). Supercookies (e.g. Evercookie ) might be more useful, but
many people view such things as evil. Certain browsers might have a
distinctive enough fingerprint to block based on that, but I doubt
we'd ever be able to do that for all browsers. These things are also
likely to be considered "security vulnrabilities", so probably not
something to be relied on over long term as people fix the issues that
allow people to be tracked this way.


> Once we have a system that allows us to block individual devices
> reasonably effectively, it won't matter whether those people are using
> Tor to get to us or not

If you can find a way to link a tor user to the device they are using,
then you have essentially broken Tor. Which is not an easy feat.

--bawolff

p.s. Obligatory xkcd https://xkcd.com/1425/

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] State of the DumpHTML extension

[Quim Gil]

Thank you Daniel for this email.

On Mon, Sep 29, 2014 at 10:16 AM, Daniel Friesen  wrote:

> The DumpHTML extension looks like it's in a pretty bad state, it doesn't
> work at all in the current version of MediaWiki.
>
> This seems to be an unfortunate symptom of how it's used and how it's
> treated by core developers.
>

What you are describing is clearly a MediaWiki problem, not just a DumpHTML
problem. The Wiki Release Team and the MediaWiki Cooperation group should
be helpful in situations like this, and this is why I'm proposing this task:

Take DumpHTML as a use case of 3rd party extension that MediaWiki
maintainers cannot ignore
https://phabricator.wikimedia.org/T536


DumpHTML is most useful when someone is shutting down and archiving
> their wiki, so it doesn't get tested regularly.
>
> The act of creating a version of wiki pages suitable for offline use
> from static files is something which inherently requires different
> behaviour from things deep within core.
>
> Because DumpHTML has been segregated into an extension and core doesn't
> support an offline/dump mode internally DumpHTML has to use a bunch of
> hacks to make core behave properly during the dump.
>
> Then, because they are completely unaware of DumpHTML's needs, core
> developers make improvements to core that then break DumpHTML without
> providing it an alternative interface to get what it needs out of core.
>
>
> For one DumpHTML needs to proxy and mess with file repo behaviours. To
> do that it messed with properties like thumbScriptUrl, but then those
> properties were protected leaving DumpHTML unsupported.
> This was reported as a bug a month ago, which has gone relatively
> unnoticed:
> https://bugzilla.wikimedia.org/show_bug.cgi?id=69824
>
> It also subclassed RepoGroup and since it proxied existing repo
> instances instead of working with repo info it had to bypass the
> __constructor. But then a $repoGroup->cache was added to the
> __constructor in core, breaking DumpHTML in another way.
>
> There are probably more issues that I haven't found yet while trying to
> workaround the other issues.
>
> --
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[Kevin Wayne Williams]

Derric Atzrott schreef op 2014/09/30 6:08:

Hello everyone,
[snip]
There must be a way that we can allow users to work from Tor.
[snip more]

I think the first step is to work harder to block devices, not IP 
addresses. One jerk with a cell phone cycles through so many IP 
addresses so quickly in such active ranges that our current protection 
techniques are useless. Any child can figure out how to pull his cable 
modem out of the wall and plug it back in.


Focusing on what signature we can obtain from (or plant on) the device 
and how to make that signature available to and manageable by admins is 
the key. Maybe we require a WMF supplied app before one can edit from a 
mobile device. Maybe we plant cookies on every machine that edits 
Wikipedia to allow us to track who's using the machine and block access 
to anyone that won't permit the cookies to be stored. There are probably 
other techniques. The thing to remember is that the vast majority of our 
sockpuppeteers are actually fairly stupid and the ones that aren't will 
make their way past any technique short of retina scanning. It doesn't 
matter whether a blocking technique allows a tech-savvy user to bypass 
it somehow. Anything is better than a system that anyone can bypass by 
turning his cable modem off and on.


Once we have a system that allows us to block individual devices 
reasonably effectively, it won't matter whether those people are using 
Tor to get to us or not.


KWW

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki Security and Maintenance Releases: 1.19.20, 1.22.12 and 1.23.5

[Brian Wolff]

On 10/1/14, Markus Glaser  wrote:
> Hello everyone,
>
> I would like to announce the release of MediaWiki 1.19.20, 1.22.12 and
> 1.23.5. This is a security release. Download links are given at the end of
> this email.
>
> == Security ==
> * (bug 70672) SECURITY: OutputPage: Remove separation of css and js module
> allowance.
>

Hmm. Lots of third parties use CSS in MediaWiki:Common.css to make
significant theming customizations without making a "real" skin.
Perhaps the release notes should mention that users who do this will
have their log in page suddenly look out of place.

Given that this change really only makes it mildly harder for a novice
attacker to do something evil, and there exists potential use cases it
breaks perhaps it should be behind a config variable defaulting to the
more secure setting. (A moderately skilled attacker should easily be
able to think of ways around this to steal users passwords. Once an
attacker can get javascript inserted, its pretty much game over.
Trying to "limit" damage of a malicious user modifying site js, is
like trying to unbreak an egg. Once the egg is broken, well you know
the story about humpty dumpty)

--bawolff

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[Legoktm]

On 10/1/14 8:02 AM, John wrote:
> Prior to TOR being enabled we need to be able to flag both logged in and
> logged out edits made via TOR.

There's a $wgTorTagChanges option which does exactly that, except it's
currently disabled in CommonSettings.php.

-- Legoktm

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[Legoktm]

On 10/1/14 9:09 AM, John wrote:
> The abuse filter has no way of identifying TOR exit nodes, thus it cannot
> be used for this. Some developer will need to interface with the TOR
> blocking  code and use the same TOR identification methods to ID and label
> both logged in and logged out edits made via TOR.

The TorBlock extension already adds a "tor_exit_node" variable[1] to the
AbuseFilter, which is a simple boolean value whether the edit is being
made through tor or not.

[1]
https://github.com/wikimedia/mediawiki-extensions-TorBlock/blob/master/TorBlock.class.php#L129

-- Legoktm

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[John]

My example means that unless TOR is hard blocked attackers can create 6
accounts per day on there home IP and just wait till they go stale and use
6 attack accounts per day. There isn't a need for infinite accounts, just
that soft blocking is pointless in this case

On Wednesday, October 1, 2014, Brian Wolff  wrote:

> On Oct 1, 2014 3:56 PM, "Derric Atzrott"  >
> wrote:
> >
> > Another idea for a potential technical solution, this one provided
> > by the user Mirimir on the Tor mailing list.  I thought this was
> > actually a pretty good idea.
> >
> > > Wikimedia could authenticate users with GnuPG keys. As part of the
> > > process of creating a new account, Wikimedia could randomly specify the
> > > key ID (or even a longer piece of the fingerprint) of the key that the
> > > user needs to generate. Generating the key would require arbitrarily
> > > great effort, but would impose negligible cost on Wikimedia or users
> > > during subsequent use. Although there's nothing special about such
> GnuPG
> > > keys as proof of work, they're more generally useful.
> >
> > As a proof of work I think it works out pretty well.  The cost of
> creating
> > a key with a given fingerprint is non-trivial, but low enough that
> > someone wishing to create an account to edit might well go through with
> > it if they knew it would only be a one-time thing.
> >
> > This doesn't completely eliminate the issue of socks, but honestly if we
> > make the key generation time reasonably long, it would probably deter
> > most socks as they might as well just drive to the nearest Starbucks.
> >
> > Someone else on the Tor mailing list suggested that we basically relax
> > IPBE, which while not on topic for this list, I thought I'd mention
> > just because it has been mentioned.  They actually basically
> > described our current system, except with the getting the IPBE stage
> > a lot easier.
> >
> > The following was also pointed out to me:
> >
> > > [I]t's also trivial to evade using proxies, with or without Tor.
> > > Blocking Tor (or even all known proxies) only stops the clueless.
> > > Anyone serious about evading a block could just use a private proxy
> > > on AWS (via Tor). [snip] The bottom line is that blocking Tor harms
> > > numerous innocent users, and by no means excludes seriously malicious
> > > users.
> >
> > I did respond to this to explain our concerns, which is what netted
> > the GPG idea.  Does anyone see any glaringly obvious problems with
> > requiring an easily blockable and difficult to create proof of work
> > to edit via Tor?
> >
> > Thank you,
> > Derric Atzrott
> >
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org 
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> The problem with proof of work things is that they kind of have the wrong
> kind of scarcity for this problem.
>
> *someone legit wants to edit, takes them hours to be able to. (Which is not
> ideal)
> *someone wants to abuse the system, spend a couple months before hand
> generating the work offline, use all at once for thousand strong sock
> puppet army. (Which makes the system ineffective at preventing abuse)
>
> --bawolff
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org 
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[Brian Wolff]

On Oct 1, 2014 3:56 PM, "Derric Atzrott" 
wrote:
>
> Another idea for a potential technical solution, this one provided
> by the user Mirimir on the Tor mailing list.  I thought this was
> actually a pretty good idea.
>
> > Wikimedia could authenticate users with GnuPG keys. As part of the
> > process of creating a new account, Wikimedia could randomly specify the
> > key ID (or even a longer piece of the fingerprint) of the key that the
> > user needs to generate. Generating the key would require arbitrarily
> > great effort, but would impose negligible cost on Wikimedia or users
> > during subsequent use. Although there's nothing special about such GnuPG
> > keys as proof of work, they're more generally useful.
>
> As a proof of work I think it works out pretty well.  The cost of creating
> a key with a given fingerprint is non-trivial, but low enough that
> someone wishing to create an account to edit might well go through with
> it if they knew it would only be a one-time thing.
>
> This doesn't completely eliminate the issue of socks, but honestly if we
> make the key generation time reasonably long, it would probably deter
> most socks as they might as well just drive to the nearest Starbucks.
>
> Someone else on the Tor mailing list suggested that we basically relax
> IPBE, which while not on topic for this list, I thought I'd mention
> just because it has been mentioned.  They actually basically
> described our current system, except with the getting the IPBE stage
> a lot easier.
>
> The following was also pointed out to me:
>
> > [I]t's also trivial to evade using proxies, with or without Tor.
> > Blocking Tor (or even all known proxies) only stops the clueless.
> > Anyone serious about evading a block could just use a private proxy
> > on AWS (via Tor). [snip] The bottom line is that blocking Tor harms
> > numerous innocent users, and by no means excludes seriously malicious
> > users.
>
> I did respond to this to explain our concerns, which is what netted
> the GPG idea.  Does anyone see any glaringly obvious problems with
> requiring an easily blockable and difficult to create proof of work
> to edit via Tor?
>
> Thank you,
> Derric Atzrott
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

The problem with proof of work things is that they kind of have the wrong
kind of scarcity for this problem.

*someone legit wants to edit, takes them hours to be able to. (Which is not
ideal)
*someone wants to abuse the system, spend a couple months before hand
generating the work offline, use all at once for thousand strong sock
puppet army. (Which makes the system ineffective at preventing abuse)

--bawolff
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] MediaWiki Security and Maintenance Releases: 1.19.20, 1.22.12 and 1.23.5

[Markus Glaser]

Hello everyone,

I would like to announce the release of MediaWiki 1.19.20, 1.22.12 and 1.23.5. 
This is a security release. Download links are given at the end of this email. 

== Security ==
* (bug 70672) SECURITY: OutputPage: Remove separation of css and js module 
allowance.

Full release notes for 1.23.5:


Full release notes for 1.22.12:


Full release notes for 1.19.20:


Public keys:


**
1.23.5
**
Download:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.5.tar.gz

Patch to previous version (1.23.4):
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.5.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-core-1.23.5.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.5.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.23/mediawiki-1.23.5.patch.gz.sig

Note:
There is no i18n patch as there are no changes in translation.

**
1.22.12
**
Download:
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.12.tar.gz

Patch to previous version (1.22.11):
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.12.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-core-1.22.12.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.12.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.22/mediawiki-1.22.12.patch.gz.sig

Note:
There is no i18n patch as there are no changes in translation.


**
1.19.20
**
Download:
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.20.tar.gz

Patch to previous version (1.19.19):
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.20.patch.gz

GPG signatures:
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-core-1.19.20.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.20.tar.gz.sig
https://releases.wikimedia.org/mediawiki/1.19/mediawiki-1.19.20.patch.gz.sig

Note:
There is no i18n patch as there are no changes in translation.


Markus Glaser
(Wiki Release Team)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Bash update to fix shellshock

[Matthew Flaschen]

Some of you may have heard of the latest bash vulnerability (codenamed 
"Shellshock").


Bash has been patched, but you may need to update.

In most cases, you can update GNU/Linux distributions with the standard 
update tool (e.g. apt-get, yum, or the graphical equivalent).


For OS X, you currently need to install it separately, from 
http://support.apple.com/kb/DL1769?viewlocale=en_US&locale=en_US .


Matt Flaschen

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Tech Talk: The Dashboarding Problem: October 6

[Rachel Farrand]

Please join us for the following tech talk:

Tech Talk: *The Dashboarding Problem*
Date: October 6
Time: 1900 UTC

Link to live YouTube stream 
IRC channel for questions: #wikimedia-office
Google+ page
,
another
place for questions

Talk description:
The Analytics team has been busy exploring dashboarding and visualizing
editor engagement data. We found that while most people focus on
visualization, data access and information architecture are just as
important and separate problems.
Mike Bostock solved visualization and the design team took care of
information architecture, so we built a dashboard around their work.
In this talk we share our learnings from developing dashiki, our new
dashboard stack. We will talk about why we believe a server-less javascript
app was the right architecture for the problem, how with about 900 lines of
javascript we transform data into Vega grammar, and how knockout components
helped us stay modular.

While we'll look at some javascript, the talk is high level, about 30
minutes long, and everyone that is interested in dashboarding,
visualization, and modularity  is welcome to attend.

Dashiki Code: https://github.com/wikimedia/analytics-dashiki

Editor Dashboard: https://metrics.wmflabs.org/static/public/dash/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[Derric Atzrott]

Another idea for a potential technical solution, this one provided
by the user Mirimir on the Tor mailing list.  I thought this was
actually a pretty good idea.

> Wikimedia could authenticate users with GnuPG keys. As part of the
> process of creating a new account, Wikimedia could randomly specify the
> key ID (or even a longer piece of the fingerprint) of the key that the
> user needs to generate. Generating the key would require arbitrarily
> great effort, but would impose negligible cost on Wikimedia or users
> during subsequent use. Although there's nothing special about such GnuPG
> keys as proof of work, they're more generally useful.

As a proof of work I think it works out pretty well.  The cost of creating
a key with a given fingerprint is non-trivial, but low enough that
someone wishing to create an account to edit might well go through with
it if they knew it would only be a one-time thing.

This doesn't completely eliminate the issue of socks, but honestly if we
make the key generation time reasonably long, it would probably deter
most socks as they might as well just drive to the nearest Starbucks.

Someone else on the Tor mailing list suggested that we basically relax
IPBE, which while not on topic for this list, I thought I'd mention
just because it has been mentioned.  They actually basically
described our current system, except with the getting the IPBE stage
a lot easier.

The following was also pointed out to me:

> [I]t's also trivial to evade using proxies, with or without Tor. 
> Blocking Tor (or even all known proxies) only stops the clueless.
> Anyone serious about evading a block could just use a private proxy
> on AWS (via Tor). [snip] The bottom line is that blocking Tor harms
> numerous innocent users, and by no means excludes seriously malicious
> users.

I did respond to this to explain our concerns, which is what netted
the GPG idea.  Does anyone see any glaringly obvious problems with
requiring an easily blockable and difficult to create proof of work
to edit via Tor?

Thank you,
Derric Atzrott


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wrapping signatures with a for discoverability

[Bartosz Dziewoński]

2014-10-01 17:17 GMT+02:00 Ryan Schmidt :
> The idea of  seems fine to me as a way to semantically designate 
> signatures, however I'd like to caution against using a  in the 
> expanded text, as while it may not be an issue with WMF wikis, some 
> third-party wikis format signatures like you would in a forum (in that there 
> is a signature "block" underneath the post, alas I cannot find that wiki 
> again so no example), and these signatures can contain block-level elements. 
> Rendering to a  may break that style of discussion, perhaps we can 
> instead render to a  and set display: inline for it in the default css. 
> Then a wiki could override this to move it wherever or display it as a block 
> if they so choose.

Using a  inside list markup (and we inexplicably use list markup
for discussions) will probably cause HTML Tidy to throw up all over
the output, a  is probably the only option. As you can see by
the list of blockers to
https://bugzilla.wikimedia.org/show_bug.cgi?id=2542 , Tidy will
horribly break most of interesting kinds of markup.

(Not that I think trying to mark up sigs is a very good idea in
general, for the reasons Brion mentioned.)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[Brad Jorsch (Anomie)]

On Wed, Oct 1, 2014 at 11:05 AM, Jackmcbarn  wrote:

> Good point; I hadn't thought of that. What if we made some sort of
> semi-soft IP block that allowed accounts to edit only if they had fresh
> CheckUser data from a non-blocked IP, or something along those lines?
>

That would rather defeat the purpose of using Tor, if you had to sign in
from a non-Tor IP every month or so.


-- 
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[Brian Wolff]

>>
>>
> I wish it was a contrived problem.  However, this is the conceit by which
> the edits are attributed for licensing purposes, and it's a non-trivial
> matter.  While I'm fully supportive of finding another way to do this, it
> is a fundamental issue that would require fairly extensive
> legal consultation to change, given that we've been using "IP address as
> assigned to a specific individual" as the licensee for...what, almost 14
> years?
>
> We know that Tor exit nodes are (by definition) not IP addresses assigned
> to the contributor, and there is no reasonable prospect of tracing back to
> the original IP address (unlike many other anonymising proxies).  Thus the
> attribution issue.

Realistically there is no reasonable prospect of tracing back an
individual IP to a real person 80% of the time without a court order,
which is extremely unlikely to ever happen. Even then you can only
really link the IP to who's paying the bill, which is only weakly
circumstantially related to who really "owns" the edit.

If we're going to consider the theoretical possibility that we can
might be able to link back an IP to a person with certainly, we might
as well start considering that we might be able to do the same if we
get everyone in the tor circuit to collude...

--bawolff

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[John]

The abuse filter has no way of identifying TOR exit nodes, thus it cannot
be used for this. Some developer will need to interface with the TOR
blocking  code and use the same TOR identification methods to ID and label
both logged in and logged out edits made via TOR.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[Risker]

On 1 October 2014 11:00, Brian Wolff  wrote:

> 
> >
> > >  > There also needs to be a good answer to the "attribution problem"
> that
> > > has
> > > > long been identified as a secondary concern related to Tor and other
> > > proxy
> > > > systems.  The absence of a good answer to this issue may be
> sufficient in
> > > > itself to derail any proposed trial.
> > >
> > > Which problem is that?
> > >
> >
> > If I understand it correctly, right now we attribute edits made without
> an
> > account to the IP address. Allowing edits via Tor should probably not be
> > attributing such edits to the exit node's IP.
> >
>
> This quite frankly seems like a contrived problem. A random (normal) ip
> address hardly associates an edit to a person unless you steal an isps
> records. Wait a year and it would probably be impossible to figure out who
> owned some random dynamic ip address no matter how hard you tried. I dont
> think attributing edits to an exit node introduces any new attribution
> issues that are not already present.
>
>
I wish it was a contrived problem.  However, this is the conceit by which
the edits are attributed for licensing purposes, and it's a non-trivial
matter.  While I'm fully supportive of finding another way to do this, it
is a fundamental issue that would require fairly extensive
legal consultation to change, given that we've been using "IP address as
assigned to a specific individual" as the licensee for...what, almost 14
years?

We know that Tor exit nodes are (by definition) not IP addresses assigned
to the contributor, and there is no reasonable prospect of tracing back to
the original IP address (unlike many other anonymising proxies).  Thus the
attribution issue.

I've copied Luis Villa on this specific email just as a heads up that this
matter might land on the Legal & Community Advocacy doorstep, but I don't
think we should expect a formal legal response about this.

Risker/Anne
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wrapping signatures with a for discoverability

[James Forrester]

On 1 October 2014 08:17, Ryan Schmidt  wrote:

> The idea of  seems fine to me as a way to semantically designate
> signatures, however I'd like to caution against using a  in the
> expanded text, as while it may not be an issue with WMF wikis, some
> third-party wikis format signatures like you would in a forum (in that
> there is a signature "block" underneath the post, alas I cannot find that
> wiki again so no example), and these signatures can contain block-level
> elements. Rendering to a  may break that style of discussion, perhaps
> we can instead render to a  and set display: inline for it in the
> default css. Then a wiki could override this to move it wherever or display
> it as a block if they so choose.
>
> Another alternative is keep the span, but add a hook to allow extensions
> to fully modify the output (including changing the span to something else),
> that way we can keep the sig semantically valid for the 99.99% of them that
> are actually used inline.
>

​Or, more simply, span.sig { display: block; } in your site​ CSS, rather
than putting the burden on, as you put it, the "99.99%"… :-)

​J.
-- 
James D. Forrester
Product Manager, Editing
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[Derric Atzrott]

> Prior to TOR being enabled we need to be able to flag both logged in and
> logged out edits made via TOR.

This is something that can be handled easily by AbuseFilter.  It has the
option to flag edits made by certain users or from certain IP addresses
if I remember correctly.

Even if it doesn't this should be fairly trivial to put together I would
imagine (though correct me if I am wrong).

Thank you,
Derric Atzrott


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wrapping signatures with a for discoverability

[Ryan Schmidt]

The idea of  seems fine to me as a way to semantically designate 
signatures, however I'd like to caution against using a  in the expanded 
text, as while it may not be an issue with WMF wikis, some third-party wikis 
format signatures like you would in a forum (in that there is a signature 
"block" underneath the post, alas I cannot find that wiki again so no example), 
and these signatures can contain block-level elements. Rendering to a  
may break that style of discussion, perhaps we can instead render to a  
and set display: inline for it in the default css. Then a wiki could override 
this to move it wherever or display it as a block if they so choose.

Another alternative is keep the span, but add a hook to allow extensions to 
fully modify the output (including changing the span to something else), that 
way we can keep the sig semantically valid for the 99.99% of them that are 
actually used inline.

Also, +1 from me on *not* automatically changing old sigs as they get updated, 
as we could lose valuable temporal information that way (such as the 
aforementioned "I'm being paid to edit" disclosure). Wrapping existing 
signatures in  seems fine if someone wants to code that system, but that's 
the extent I would personally go with modifying existing signatures.

Regards,
Ryan Schmidt

On Oct 1, 2014, at 7:42 AM, Derric Atzrott  wrote:

>>> From the standpoint of programmatically detecting a signature, the above
>>> could be cleaned up and work well enough.
>> Would this mean that if people had a fancy sig, and they changed it,
>> it would automatically update everywhere with this magic tag instead
>> of just applying to new signatures? (Which might be cool)
>> 
>> Downside to that you might have some tricky issue where people change
>> their sig after the fact to be something malicious (For some
>> definition of malicious), and then all the old sigs change without an
>> edit to track it and generally be a vehicle for mass vandalism.
>> (Didn't that use to be an issue on /. ?)
> 
> I haven't looked at the actual patch yet, but based on the discussion
> it seems like this code would allow us to update pages if people's
> signatures changed?  I too am not sure this is a good idea.
> 
> I do though support the idea of wrapping signatures in a 
> markup to make it easier to programatically detect them.  That
>  markup could be rendered as a span with a class="sig" as well
> which allow those who are just scraping the HTML of the page to be
> able to detect them as well.
> 
>> This also makes working out what the state of the page at time X quite
>> hard for things like "Please note that I am being paid to edit by XYZ Inc."
>> that come and go from month to month to be seen.
> 
> This is one of my biggest concerns as well.
> 
> Thank you,
> Derric Atzrott
> 
> 
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[Jackmcbarn]

Good point; I hadn't thought of that. What if we made some sort of
semi-soft IP block that allowed accounts to edit only if they had fresh
CheckUser data from a non-blocked IP, or something along those lines?

On Wed, Oct 1, 2014 at 10:57 AM, John  wrote:

> Uh, Creating sleeper accounts from good IPs lettting them go stale beyond
> CU retention, and you have an infinite number of accounts you can then use
> to skip past the softblocks on tor and create havoc. Anything short of a
> hard block wont stop open proxy abuse.
>
> On Wed, Oct 1, 2014 at 10:44 AM, Jackmcbarn  wrote:
>
> > On Wed, Oct 1, 2014 at 10:40 AM, Brad Jorsch (Anomie) <
> > bjor...@wikimedia.org
> > > wrote:
> >
> > > One simple solution would be to disallow IP edits via Tor, i.e.
> > > softblock[1] all Tor exit nodes instead of hardblocking them.
> > >
> > >
> > >  [1]:
> > >
> > >
> >
> https://en.wikipedia.org/wiki/Wikipedia:Blocking_policy#Setting_block_options
> > >
> > I'd agree with this. I've never understood why we even hardblock open
> > proxies at all instead of just softblocking with account creation
> disabled.
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[John]

Prior to TOR being enabled we need to be able to flag both logged in and
logged out edits made via TOR.

On Wed, Oct 1, 2014 at 11:00 AM, Brian Wolff  wrote:

> On Oct 1, 2014 11:40 AM, "Brad Jorsch (Anomie)" 
> wrote:
> >
> > On Wed, Oct 1, 2014 at 10:29 AM, Brian Wolff  wrote:
> >
> > > On Oct 1, 2014 10:55 AM, "Risker"  wrote:
> > > >
> > > > This is something that has to be discussed *on the projects
> themselves*,
> > > > not on mailing lists that have (comparatively) very low participation
> by
> > > > active editors.
> > >
> > > Unless people want to trial on mw.org (assuming there is dev buy in,
> not
> > > sure we are there yet)
> > >
> >
> > Does mw.org receive the level of vandalism and other unhelpful edits
> (where
> > people would like to use Tor to avoid IP blocking in making those edits)
> > that it would make for a useful test?
>
> If we are testing something potentially very disruptive, no harm starting
> small. At the very least it would show if we could enable tor on mw.org.
> The results could help decide if further testing on more "real" wikis is
> justified.
>
> >
> > >  > There also needs to be a good answer to the "attribution problem"
> that
> > > has
> > > > long been identified as a secondary concern related to Tor and other
> > > proxy
> > > > systems.  The absence of a good answer to this issue may be
> sufficient in
> > > > itself to derail any proposed trial.
> > >
> > > Which problem is that?
> > >
> >
> > If I understand it correctly, right now we attribute edits made without
> an
> > account to the IP address. Allowing edits via Tor should probably not be
> > attributing such edits to the exit node's IP.
> >
>
> This quite frankly seems like a contrived problem. A random (normal) ip
> address hardly associates an edit to a person unless you steal an isps
> records. Wait a year and it would probably be impossible to figure out who
> owned some random dynamic ip address no matter how hard you tried. I dont
> think attributing edits to an exit node introduces any new attribution
> issues that are not already present.
>
> --bawolff
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[Brian Wolff]

On Oct 1, 2014 11:40 AM, "Brad Jorsch (Anomie)" 
wrote:
>
> On Wed, Oct 1, 2014 at 10:29 AM, Brian Wolff  wrote:
>
> > On Oct 1, 2014 10:55 AM, "Risker"  wrote:
> > >
> > > This is something that has to be discussed *on the projects
themselves*,
> > > not on mailing lists that have (comparatively) very low participation
by
> > > active editors.
> >
> > Unless people want to trial on mw.org (assuming there is dev buy in, not
> > sure we are there yet)
> >
>
> Does mw.org receive the level of vandalism and other unhelpful edits
(where
> people would like to use Tor to avoid IP blocking in making those edits)
> that it would make for a useful test?

If we are testing something potentially very disruptive, no harm starting
small. At the very least it would show if we could enable tor on mw.org.
The results could help decide if further testing on more "real" wikis is
justified.

>
> >  > There also needs to be a good answer to the "attribution problem"
that
> > has
> > > long been identified as a secondary concern related to Tor and other
> > proxy
> > > systems.  The absence of a good answer to this issue may be
sufficient in
> > > itself to derail any proposed trial.
> >
> > Which problem is that?
> >
>
> If I understand it correctly, right now we attribute edits made without an
> account to the IP address. Allowing edits via Tor should probably not be
> attributing such edits to the exit node's IP.
>

This quite frankly seems like a contrived problem. A random (normal) ip
address hardly associates an edit to a person unless you steal an isps
records. Wait a year and it would probably be impossible to figure out who
owned some random dynamic ip address no matter how hard you tried. I dont
think attributing edits to an exit node introduces any new attribution
issues that are not already present.

--bawolff
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[John]

And any kind of account creation block will cause issues with users who
work across multiple projects as SUL auto account creation is also blocked.

On Wed, Oct 1, 2014 at 10:57 AM, John  wrote:

> Uh, Creating sleeper accounts from good IPs lettting them go stale beyond
> CU retention, and you have an infinite number of accounts you can then use
> to skip past the softblocks on tor and create havoc. Anything short of a
> hard block wont stop open proxy abuse.
>
> On Wed, Oct 1, 2014 at 10:44 AM, Jackmcbarn  wrote:
>
>> On Wed, Oct 1, 2014 at 10:40 AM, Brad Jorsch (Anomie) <
>> bjor...@wikimedia.org
>> > wrote:
>>
>> > One simple solution would be to disallow IP edits via Tor, i.e.
>> > softblock[1] all Tor exit nodes instead of hardblocking them.
>> >
>> >
>> >  [1]:
>> >
>> >
>> https://en.wikipedia.org/wiki/Wikipedia:Blocking_policy#Setting_block_options
>> >
>> I'd agree with this. I've never understood why we even hardblock open
>> proxies at all instead of just softblocking with account creation
>> disabled.
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[John]

Uh, Creating sleeper accounts from good IPs lettting them go stale beyond
CU retention, and you have an infinite number of accounts you can then use
to skip past the softblocks on tor and create havoc. Anything short of a
hard block wont stop open proxy abuse.

On Wed, Oct 1, 2014 at 10:44 AM, Jackmcbarn  wrote:

> On Wed, Oct 1, 2014 at 10:40 AM, Brad Jorsch (Anomie) <
> bjor...@wikimedia.org
> > wrote:
>
> > One simple solution would be to disallow IP edits via Tor, i.e.
> > softblock[1] all Tor exit nodes instead of hardblocking them.
> >
> >
> >  [1]:
> >
> >
> https://en.wikipedia.org/wiki/Wikipedia:Blocking_policy#Setting_block_options
> >
> I'd agree with this. I've never understood why we even hardblock open
> proxies at all instead of just softblocking with account creation disabled.
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[Jackmcbarn]

On Wed, Oct 1, 2014 at 10:40 AM, Brad Jorsch (Anomie)  wrote:

> One simple solution would be to disallow IP edits via Tor, i.e.
> softblock[1] all Tor exit nodes instead of hardblocking them.
>
>
>  [1]:
>
> https://en.wikipedia.org/wiki/Wikipedia:Blocking_policy#Setting_block_options
>
I'd agree with this. I've never understood why we even hardblock open
proxies at all instead of just softblocking with account creation disabled.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[Brad Jorsch (Anomie)]

On Wed, Oct 1, 2014 at 10:29 AM, Brian Wolff  wrote:

> On Oct 1, 2014 10:55 AM, "Risker"  wrote:
> >
> > This is something that has to be discussed *on the projects themselves*,
> > not on mailing lists that have (comparatively) very low participation by
> > active editors.
>
> Unless people want to trial on mw.org (assuming there is dev buy in, not
> sure we are there yet)
>

Does mw.org receive the level of vandalism and other unhelpful edits (where
people would like to use Tor to avoid IP blocking in making those edits)
that it would make for a useful test?


>  > There also needs to be a good answer to the "attribution problem" that
> has
> > long been identified as a secondary concern related to Tor and other
> proxy
> > systems.  The absence of a good answer to this issue may be sufficient in
> > itself to derail any proposed trial.
>
> Which problem is that?
>

If I understand it correctly, right now we attribute edits made without an
account to the IP address. Allowing edits via Tor should probably not be
attributing such edits to the exit node's IP.

One simple solution would be to disallow IP edits via Tor, i.e.
softblock[1] all Tor exit nodes instead of hardblocking them.


 [1]:
https://en.wikipedia.org/wiki/Wikipedia:Blocking_policy#Setting_block_options
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[Brian Wolff]

On Oct 1, 2014 10:55 AM, "Risker"  wrote:
>
> This is something that has to be discussed *on the projects themselves*,
> not on mailing lists that have (comparatively) very low participation by
> active editors.

Unless people want to trial on mw.org (assuming there is dev buy in, not
sure we are there yet)

> There also needs to be a good answer to the "attribution problem" that has
> long been identified as a secondary concern related to Tor and other proxy
> systems.  The absence of a good answer to this issue may be sufficient in
> itself to derail any proposed trial.

Which problem is that?

>
> Not saying a trial can't happenjust making it clear that it's not
> something that is within the purview of developers (volunteer or staff)
> because the blocking of Tor has always been directly linked to behaviour
> and core policy, not to technical issues.

I agree that any such trial should have local community buy in.

--bawolff
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[Risker]

This is something that has to be discussed *on the projects themselves*,
not on mailing lists that have (comparatively) very low participation by
active editors.  Sending to another mailing list, even a broader one than
this, isn't going to get the buy-in needed from the people who will have to
clean up the messes.  You will need buy-in from at least the following
groups:

   - A significant number of editors from the project involved in the trial
   - Stewards
   - Global sysops/global rollbackers
   - Checkusers

You will also have to absolutely guarantee that the trial will end on the
date stated *regardless of what happens during the trial*, and that there
will be non-project support for the collection and analysis of data.  One
of the reasons projects tend to not want to participate in trials is the
unwillingness to return to status quo ante because someone/developers/the
WMF/etc has decided on their own basis that the results were favourable
without any analysis of actual data.  Frankly, we've experienced this so
often on English Wikipedia that it's resulted in major showdowns with the
WMF that have had a real and ongoing impact on the WMF's ability to develop
and improve software. (Don't kid yourself, this will be seen as a WMF
proposal even though it may be coming from volunteer developers.)

Edit filters are developed project-by-project, and cannot be relied upon to
catch problem edits; even with the huge number of edit filters on enwiki,
there is still significant spamming and vandalism happening.  Many of the
projects most severely impacted by inappropriate editing are smaller
projects with comparatively few active editors and few edit filters, where
recent changes are not routinely reviewed; stewards and global
sysops/rollbackers are often the people who clean up the messes there.

There also needs to be a good answer to the "attribution problem" that has
long been identified as a secondary concern related to Tor and other proxy
systems.  The absence of a good answer to this issue may be sufficient in
itself to derail any proposed trial.

Not saying a trial can't happenjust making it clear that it's not
something that is within the purview of developers (volunteer or staff)
because the blocking of Tor has always been directly linked to behaviour
and core policy, not to technical issues.  I very much disagree that this
is a technical issue; Tor's blocking is a technical solution to a genuine
policy/behaviour problem.

Risker/Anne

On 1 October 2014 09:05, Derric Atzrott 
wrote:

> > If, as it seems right now, the problem is technical (weed out the bots
> > and vandals) rather than ideological (as we allow anonymous
> > contributions after all) we can find a way to allow people to edit any
> > wikipedia via TOR while minimizing the amount of vandalism allowed.
> >
> > Of course, let's not kid ourselves - it will require some special
> > measures probably, and editing via TOR would probably end up not being
> > as easy as editing via a public-facing IP (we may e.g. restrict
> > publishing via TOR to users that have logged in and have done 5 "good"
> > edits reviewed by others, or we can use modern bot-detecting
> > techniques in that case - those are just ideas).
>
> I would be curious to see what percentage of problematic edits are
> caught by running all prospective edits through AbuseFilter and
> ClueBotNG.  I suspect those two tools would catch a large
> percentage of the vandalism edits.  I understand that they catch most
> of such edits that regular IP users make.  This would be a good start
> and would give us a little bit of data as to what other sorts of
> measures might need to be taken to make this sort of thing work.
>
> AbuseFilter has the ability to tag edits for further review so we
> could leverage that functionality to tag Tor edits during a trial.
>
> I could reach out to the maintainer of ClueBotNG and see what could
> be done to get it to interface with AbuseFilter such that any edits
> it sees as unconstructive are tagged, and if that isn't possible
> maybe just have it log such edits somewhere special.
>
> > We've had this conversation a few times and I'd love to see creative
> > approaches to a trial/pilot with data driving future decisions.
>
> If I approached Wikimedia-l with the idea of a limited trial with
> the above approach for maybe two weeks' time with all Tor edits
> being tagged, do you think they might bite?
>
> > It clearly is the kind of problem where people do
> > like to _look_ for clever technical fixes, which is why it's a
> > recurring topic on this list.
>
> I suspect one exists somewhere.  I'll reach out to the folks at the
> Tor project and see if they have any suggestions for ways to
> prevent abuse from a technical standpoint. Especially in regards to
> Sockpuppet abuse.  I agree with Giuseppe that the measures that will
> need to be put in place will make editing via Tor more difficult than
> editing without Tor, but that's acceptable so long as 

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[Derric Atzrott]

> If, as it seems right now, the problem is technical (weed out the bots
> and vandals) rather than ideological (as we allow anonymous
> contributions after all) we can find a way to allow people to edit any
> wikipedia via TOR while minimizing the amount of vandalism allowed.
> 
> Of course, let's not kid ourselves - it will require some special
> measures probably, and editing via TOR would probably end up not being
> as easy as editing via a public-facing IP (we may e.g. restrict
> publishing via TOR to users that have logged in and have done 5 "good"
> edits reviewed by others, or we can use modern bot-detecting
> techniques in that case - those are just ideas).

I would be curious to see what percentage of problematic edits are
caught by running all prospective edits through AbuseFilter and
ClueBotNG.  I suspect those two tools would catch a large
percentage of the vandalism edits.  I understand that they catch most
of such edits that regular IP users make.  This would be a good start
and would give us a little bit of data as to what other sorts of
measures might need to be taken to make this sort of thing work.

AbuseFilter has the ability to tag edits for further review so we
could leverage that functionality to tag Tor edits during a trial.

I could reach out to the maintainer of ClueBotNG and see what could
be done to get it to interface with AbuseFilter such that any edits
it sees as unconstructive are tagged, and if that isn't possible
maybe just have it log such edits somewhere special.

> We've had this conversation a few times and I'd love to see creative
> approaches to a trial/pilot with data driving future decisions.

If I approached Wikimedia-l with the idea of a limited trial with
the above approach for maybe two weeks' time with all Tor edits
being tagged, do you think they might bite?

> It clearly is the kind of problem where people do
> like to _look_ for clever technical fixes, which is why it's a
> recurring topic on this list.

I suspect one exists somewhere.  I'll reach out to the folks at the
Tor project and see if they have any suggestions for ways to
prevent abuse from a technical standpoint. Especially in regards to
Sockpuppet abuse.  I agree with Giuseppe that the measures that will
need to be put in place will make editing via Tor more difficult than
editing without Tor, but that's acceptable so long as they are not
as prohibitively difficult as they are currently.

Without having spoken to the Tor Project though,
the Nymble approach seems like a reasonable way to go to me.  The
protocol could potentially be modified to accept some sort of
proof of work rather than their public facing IP address as well.
If we had a system where in order to be issued a certificate in
Nymble you had to complete a proof-of-work that took perhaps
several hours of computation and was issued for a week, that might
be a sufficient barrier to stop most socks, though definitely some
more data needs gathered.

Thank you,
Derric Atzrott


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[Derric Atzrott]

> If, as it seems right now, the problem is technical (weed out the bots
> and vandals) rather than ideological (as we allow anonymous
> contributions after all) we can find a way to allow people to edit any
> wikipedia via TOR while minimizing the amount of vandalism allowed.
> 
> Of course, let's not kid ourselves - it will require some special
> measures probably, and editing via TOR would probably end up not being
> as easy as editing via a public-facing IP (we may e.g. restrict
> publishing via TOR to users that have logged in and have done 5 "good"
> edits reviewed by others, or we can use modern bot-detecting
> techniques in that case - those are just ideas).

I would be curious to see what percentage of problematic edits are
caught by running all prospective edits through AbuseFilter and
ClueBotNG.  I suspect those two tools would catch a large
percentage of the vandalism edits.  I understand that they catch most
of such edits that regular IP users make.  This would be a good start
and would give us a little bit of data as to what other sorts of
measures might need to be taken to make this sort of thing work.

AbuseFilter has the ability to tag edits for further review so we
could leverage that functionality to tag Tor edits during a trial.

I could reach out to the maintainer of ClueBotNG and see what could
be done to get it to interface with AbuseFilter such that any edits
it sees as unconstructive are tagged, and if that isn't possible
maybe just have it log such edits somewhere special.

> We've had this conversation a few times and I'd love to see creative
> approaches to a trial/pilot with data driving future decisions.

If I approached Wikimedia-l with the idea of a limited trial with
the above approach for maybe two weeks' time with all Tor edits
being tagged, do you think they might bite?

> It clearly is the kind of problem where people do
> like to _look_ for clever technical fixes, which is why it's a
> recurring topic on this list.

I suspect one exists somewhere.  I'll reach out to the folks at the
Tor project and see if they have any suggestions for ways to
prevent abuse from a technical standpoint. Especially in regards to
Sockpuppet abuse.  I agree with Giuseppe that the measures that will
need to be put in place will make editing via Tor more difficult than
editing without Tor, but that's acceptable so long as they are not
as prohibitively difficult as they are currently.

Without having spoken to the Tor Project though,
the Nymble approach seems like a reasonable way to go to me.  The
protocol could potentially be modified to accept some sort of
proof of work rather than their public facing IP address as well.
If we had a system where in order to be issued a certificate in
Nymble you had to complete a proof-of-work that took perhaps
several hours of computation and was issued for a week, that might
be a sufficient barrier to stop most socks, though definitely some
more data needs gathered.

Thank you,
Derric Atzrott


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wrapping signatures with a for discoverability

[Derric Atzrott]

>> From the standpoint of programmatically detecting a signature, the above
>> could be cleaned up and work well enough.
>>
> Would this mean that if people had a fancy sig, and they changed it,
> it would automatically update everywhere with this magic tag instead
> of just applying to new signatures? (Which might be cool)
> 
> Downside to that you might have some tricky issue where people change
> their sig after the fact to be something malicious (For some
> definition of malicious), and then all the old sigs change without an
> edit to track it and generally be a vehicle for mass vandalism.
> (Didn't that use to be an issue on /. ?)

I haven't looked at the actual patch yet, but based on the discussion
it seems like this code would allow us to update pages if people's
signatures changed?  I too am not sure this is a good idea.

I do though support the idea of wrapping signatures in a 
markup to make it easier to programatically detect them.  That
 markup could be rendered as a span with a class="sig" as well
which allow those who are just scraping the HTML of the page to be
able to detect them as well.

> This also makes working out what the state of the page at time X quite
> hard for things like "Please note that I am being paid to edit by XYZ Inc."
> that come and go from month to month to be seen.

This is one of my biggest concerns as well.

Thank you,
Derric Atzrott


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[Vito]

From my experience too, though I definitely appreciate Tor's 
transparency/fairness compared to VPNs/other stuffs'.


Vito

Inviato con AquaMail per Android
http://www.aqua-mail.com


Il 30 settembre 2014 23:02:27 "Marc A. Pelletier"  ha 
scritto:



On 09/30/2014 09:08 AM, Derric Atzrott wrote:
> "[H]ow can we quantify the loss to Wikipedia, and to society at large, from
> turning away anonymous contributors? Wikipedians say 'we have to 
blacklist all
> these IP addresses because of trolls' and 'Wikipedia is rotting because 
nobody

> wants to edit it anymore' in the same breath, and we believe these points
> are related."

I've been doing adminwork on enwiki since 2007 and I can tell give you
two anecdotal data points:

(a) Previously unknown TOR endpoints get found out because they
invariably are the source of vandalism and/or spam.

(b) I have never seen a good edit from a TOR endpoint.  Ever.

A third one I can add since I have held checkuser (2009):

(c) I have never seen accounts created via TOR or that edited through
TOR that weren't demonstrably block evasion, vandalism or (most often)
spamming.

None of this is TOR-specific, the same observations apply to open
proxies in general, and the almost totality of hosted servers.  Long
blocks of open proxies or co-lo ranges that time out after *years* being
blocked invariably start spewing spam and vandalism, often the very day
the block expired.

-- Marc


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[Vito]

The impact of Tor upon editors' accountability must be, anyway, clearly 
discussed with the Foundation as maintainer (from a legal pov too).
I can be considered a sort of "stakeholder" for patrollers and what I want 
is "something" lowering Tor risk of vandalism/sockpuppeting at an ADSL-like 
level.  Once that level would be reached, to me, you can even block every 
non-Tor user ;p


Vito

Inviato con AquaMail per Android
http://www.aqua-mail.com


Il 01 ottobre 2014 09:23:08 Giuseppe Lavagetto  
ha scritto:



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 30/09/14 23:02, Marc A. Pelletier wrote:
> On 09/30/2014 09:08 AM, Derric Atzrott wrote:
>> "[H]ow can we quantify the loss to Wikipedia, and to society at
>> large, from turning away anonymous contributors? Wikipedians say
>> 'we have to blacklist all these IP addresses because of trolls'
>> and 'Wikipedia is rotting because nobody wants to edit it
>> anymore' in the same breath, and we believe these points are
>> related."
>
> I've been doing adminwork on enwiki since 2007 and I can tell give
> you two anecdotal data points:
>
> (a) Previously unknown TOR endpoints get found out because they
> invariably are the source of vandalism and/or spam.
>
> (b) I have never seen a good edit from a TOR endpoint.  Ever.
>
> A third one I can add since I have held checkuser (2009):
>
> (c) I have never seen accounts created via TOR or that edited
> through TOR that weren't demonstrably block evasion, vandalism or
> (most often) spamming.
>
> None of this is TOR-specific, the same observations apply to open
> proxies in general, and the almost totality of hosted servers.
> Long blocks of open proxies or co-lo ranges that time out after
> *years* being blocked invariably start spewing spam and vandalism,
> often the very day the block expired.
>

Hi Marc :)

I know I don't need to convince you that TOR is a good thing in general.

Still, I don't see how the abusive nature of what is being done via
TOR makes it less valuable to our community, in particular in the
post-Snowden era. Without involving countries where freedom of speech
is not legally granted, it is reasonable to assume someone doing an
edit that may look 'unfriendly' to the US or UK governments will feel
uncomfortable doing that without TOR.

If, as it seems right now, the problem is technical (weed out the bots
and vandals) rather than ideological (as we allow anonymous
contributions after all) we can find a way to allow people to edit any
wikipedia via TOR while minimizing the amount of vandalism allowed.

Of course, let's not kid ourselves - it will require some special
measures probably, and editing via TOR would probably end up not being
as easy as editing via a public-facing IP (we may e.g. restrict
publishing via TOR to users that have logged in and have done 5 "good"
edits reviewed by others, or we can use modern bot-detecting
techniques in that case - those are just ideas).

Cheers,
Giuseppe
- --
Giuseppe Lavagetto
Wikimedia Foundation - TechOps Team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlQrq84ACgkQTwZ0G8La7IAWLgCglkaCutKP64khUn4zXpSsFnlD
HMkAoL4HoAw7Rx4PoGvqo0D5lDKOBawd
=RIjq
-END PGP SIGNATURE-

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[Erik Moeller]

On Tue, Sep 30, 2014 at 2:33 PM, Federico Leva (Nemo)
 wrote:
>> There must be a way that we can allow users to work from Tor.

> RESOLVED FIXED http://meta.wikimedia.org/wiki/NOP

Not quite; if your _only_ means of access is Tor and you have no prior
editing history to point to (which may be a situation if you're in a
country where Internet access is heavily censored/monitored), this
process is currently quite restrictive in terms of actually granting
global exemptions as previously demonstrated. [1]

We've had this conversation a few times and I'd love to see creative
approaches to a trial/pilot with data driving future decisions. But
given that the global exemption process is entirely a community
(steward) process, it's not clear to me that WMF can/should do very
much here directly. I also don't think it's really a technical problem
first and foremost. It clearly is the kind of problem where people do
like to _look_ for clever technical fixes, which is why it's a
recurring topic on this list.

As a social problem, I stick with my original suggestion [2] to relax
the global exemption rules a bit, monitor globally exempt accounts for
abuse and constructive activity, and try to determine whether the
cost/benefit ratio of relaxed rules is worth it. This could be done as
a time-limited trial (say 30 days), and requires no new technology. If
the cost/benefit ratio actually is worse, there are many non-technical
ways to raise the barrier while still having a clearer path to success
for sufficiently motivated people than today (say, the well-worn tool
all bureaucracies use to manage intake, "fill out this form").

As Derric pointed out, as a policy issue it's a bit OT here, though it
requires people who understand the full technical complexity to make a
cogent case for a pilot on Meta and elsewhere. IOW -- I think many
people who've been talking on this list about this issue share the
right end goal, but it's the wrong target audience.

Erik

[1] https://lists.wikimedia.org/pipermail/wikitech-l/2014-January/074049.html
[2] https://lists.wikimedia.org/pipermail/wikitech-l/2014-January/074070.html
-- 
Erik Möller
VP of Product & Strategy, Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tor and Anonymous Users (I know, we've had this discussion a million times)

[Giuseppe Lavagetto]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 30/09/14 23:02, Marc A. Pelletier wrote:
> On 09/30/2014 09:08 AM, Derric Atzrott wrote:
>> "[H]ow can we quantify the loss to Wikipedia, and to society at
>> large, from turning away anonymous contributors? Wikipedians say
>> 'we have to blacklist all these IP addresses because of trolls'
>> and 'Wikipedia is rotting because nobody wants to edit it
>> anymore' in the same breath, and we believe these points are
>> related."
> 
> I've been doing adminwork on enwiki since 2007 and I can tell give
> you two anecdotal data points:
> 
> (a) Previously unknown TOR endpoints get found out because they 
> invariably are the source of vandalism and/or spam.
> 
> (b) I have never seen a good edit from a TOR endpoint.  Ever.
> 
> A third one I can add since I have held checkuser (2009):
> 
> (c) I have never seen accounts created via TOR or that edited
> through TOR that weren't demonstrably block evasion, vandalism or
> (most often) spamming.
> 
> None of this is TOR-specific, the same observations apply to open 
> proxies in general, and the almost totality of hosted servers.
> Long blocks of open proxies or co-lo ranges that time out after
> *years* being blocked invariably start spewing spam and vandalism,
> often the very day the block expired.
> 

Hi Marc :)

I know I don't need to convince you that TOR is a good thing in general.

Still, I don't see how the abusive nature of what is being done via
TOR makes it less valuable to our community, in particular in the
post-Snowden era. Without involving countries where freedom of speech
is not legally granted, it is reasonable to assume someone doing an
edit that may look 'unfriendly' to the US or UK governments will feel
uncomfortable doing that without TOR.

If, as it seems right now, the problem is technical (weed out the bots
and vandals) rather than ideological (as we allow anonymous
contributions after all) we can find a way to allow people to edit any
wikipedia via TOR while minimizing the amount of vandalism allowed.

Of course, let's not kid ourselves - it will require some special
measures probably, and editing via TOR would probably end up not being
as easy as editing via a public-facing IP (we may e.g. restrict
publishing via TOR to users that have logged in and have done 5 "good"
edits reviewed by others, or we can use modern bot-detecting
techniques in that case - those are just ideas).

Cheers,
Giuseppe
- -- 
Giuseppe Lavagetto
Wikimedia Foundation - TechOps Team
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlQrq84ACgkQTwZ0G8La7IAWLgCglkaCutKP64khUn4zXpSsFnlD
HMkAoL4HoAw7Rx4PoGvqo0D5lDKOBawd
=RIjq
-END PGP SIGNATURE-

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l