Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Wikipedia: Wikitech

TorBlock extension enabled

 

 

First page Previous page 1 2 3 Next page Last page  View All Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded


dgerard at gmail

Jun 8, 2008, 1:08 PM

Post #51 of 58 (535 views)
Permalink
Re: TorBlock extension enabled [In reply to]

2008/6/8 Gerard Meijssen <gerard.meijssen [at] gmail>:

> There is a balance between on the one hand the vandals, the sock puppeteers,
> the insane and on the other hand the people who need the anonymity that TOR
> can offer. At this moment I am afraid that only one side of the picture has
> been considered.


Yes, you are quite right that only the pro-TOR side of the picture was
considered in implementing this extension. That's why those of us with
serious concerns are now raising them.


- d.

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


Platonides at gmail

Jun 8, 2008, 1:26 PM

Post #52 of 58 (544 views)
Permalink
Re: TorBlock extension enabled [In reply to]

Simetrical wrote:
> On Sun, Jun 8, 2008 at 2:16 PM, David Gerard wrote:
>> Indeed. This extension appears to be for the benefit of TOR and no-one
>> else. Why not all open proxies? (Because that would not be of benefit
>> to the projects.) Why TOR? Ideological reasons to be pro-TOR? How does
>> specifically enabling TOR fit the Wikimedia Foundation's mission?
>
> I would imagine that detecting Tor is easier than detecting anonymous
> proxies in general, although I haven't looked at the extension.

That's exactly the point. Tor outgoing servers go in[1] and out. The
client is always the same (=no work for its abusers) but servers vary.
Tor provides a list of ips at an instant able to reach your site. That's
which these extension uses.
It can also softblock or change the autoconfirmation status of people
with these ips... apart of hardblocking them.
Let each wiki choose its configuration, but don't leave it "entirely
off" as David Gerard proposes and then run sysop bots to mass block
their ips!

As for doing it for any open proxy, if you know how to do it, please
share it. I think it was proposed a long time ago to automatically scan
for open proxys. Don't know it if was really done, but it's certainly
impossible to do now.

enwikipedists are too blockist...


1-Bad, people will be able to bypass the blocks.
2-Also bad, innocents will be blocked.


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


Simetrical+wikilist at gmail

Jun 8, 2008, 2:08 PM

Post #53 of 58 (532 views)
Permalink
Re: TorBlock extension enabled [In reply to]

On Sun, Jun 8, 2008 at 4:26 PM, Platonides <Platonides [at] gmail> wrote:
> As for doing it for any open proxy, if you know how to do it, please
> share it. I think it was proposed a long time ago to automatically scan
> for open proxys. Don't know it if was really done, but it's certainly
> impossible to do now.

You just do a portscan. It's fairly straightforward. (Also not
*totally* reliable, but what is in life?) Wikimedia could then
maintain its own DNSBL, if it were feeling nice. Each view would
trigger a portscan on that IP, although no more than once every X
days. Any hit would be added to a table of proxies that would be
checked on edits, etc.

This would happen asynchronously, because portscans take time. That's
not really a problem effectiveness-wise; even on a fresh hit, at most
one quick edit should be able to get through before the IP gets
blocked.

This would all require a substantial amount of server setup, and would
be considerably more complicated than just writing an extension.
Probably the web servers are firewalled such that they can't portscan,
and even if not, people's firewalls would freak out and block them.
(Although that might not matter, since the actual traffic goes through
the Squids. Doesn't really matter if the Apaches get blocked.)

Of course, you could also use an existing DNSBL, but those aren't
necessarily reliable. An in-house solution might be a better idea
here.

> enwikipedists are too blockist...

Which says to me that vandalism handling needs to be made easier.

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


andrew at epstone

Jun 8, 2008, 4:35 PM

Post #54 of 58 (529 views)
Permalink
Re: TorBlock extension enabled [In reply to]

On Mon, Jun 9, 2008 at 7:08 AM, Simetrical
<Simetrical+wikilist [at] gmail> wrote:
> On Sun, Jun 8, 2008 at 4:26 PM, Platonides <Platonides [at] gmail> wrote:
>> As for doing it for any open proxy, if you know how to do it, please
>> share it. I think it was proposed a long time ago to automatically scan
>> for open proxys. Don't know it if was really done, but it's certainly
>> impossible to do now.
>
> You just do a portscan. It's fairly straightforward. (Also not
> *totally* reliable, but what is in life?) Wikimedia could then
> maintain its own DNSBL, if it were feeling nice. Each view would
> trigger a portscan on that IP, although no more than once every X
> days. Any hit would be added to a table of proxies that would be
> checked on edits, etc.
>

This exists in our codebase, but was turned off because very few ISPs,
nor our network admin Mark, liked our software portscanning ~20% of
the internet per day.

--
Andrew Garrett

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


andrew at epstone

Jun 8, 2008, 5:04 PM

Post #55 of 58 (527 views)
Permalink
Re: TorBlock extension enabled [In reply to]

On Mon, Jun 9, 2008 at 6:08 AM, David Gerard <dgerard [at] gmail> wrote:
> Yes, you are quite right that only the pro-TOR side of the picture was
> considered in implementing this extension.

Certainly, I see quite significant benefit in tor - more than most do.
However, I strongly object to your insinuation that my extension was
not written with the best interests of the Wikimedia projects at
heart.

The extension was not written for the tor people (although they were
quite happy when I spoke to them of my plans - as I needed their
technical co-operation to produce the list in software), and I reject
any insinuation that I am somehow writing code to benefit tor, rather
than the foundation.

I saw a problem - in this case, the fact that tor is now blocked using
a hodgepodge of blocks by various bots, scripts, and people, many of
which are no longer tor nodes, and many tor nodes are not blocked. It
is suboptimal that tor nodes are hard-blocked, and it was my
impression (perhaps mistaken?) that the general consensus is that
while we are loathe to hard-block tor, we are forced to do it by the
amount of nonsense that comes through it.

I recognised that a solution was possible - in-software handling of
tor exit nodes. I realised that I could kill two birds with one stone
here - both standardise the treatment of Tor by Wikimedia wikis, AND
remove the hard-blocks on Wikimedia wikis by instituting some kind of
special treatment of tor, which balances the needs of individuals who
require privacy, and Wikipedia as a whole, which needs to have this
sort of nonsense removed.

I must note that those checkusers who indicated that most of what
comes through tor is nonsense have the sample they're working with
skewed - they will only ever see the bad tor nodes, because (I hope)
they don't go running checkusers on random users to see if they're
using tor. I would imagine that we get quite a considerable amount of
good editing from tor, which goes unnoticed because we have some
semblance of a privacy policy.

Evidently, this is a situation requiring compromise, and I would like
to see some suggested compromises from those who still maintain that
hard-blocks are the only option. Remember that this is being
implemented in software (something FT2 indicated that he had not
realised), and therefore the sky's the limit. ANY special technical
handling of tor nodes is possible. Here are a few ideas to get
started:
* A special page listing all recent tor users/contributions/edits.
* Special marking in recentchanges, checkuser, contribs, diff pages.
* Allow disabling tor per-page or per-user.
* Allow temporary disabling of tor site-wide with good cause (through
a special page).
* Require a user to be autoconfirmed before using tor (causes a
catch-22 situation, though).

As I've stated before, ipblock-exempt or a similar process will be
ineffective unless torblock-unblocked is granted liberally, as a
catch-22 situation is produced.

--
Andrew Garrett

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


ft2.wiki at gmail

Jun 8, 2008, 6:36 PM

Post #56 of 58 (529 views)
Permalink
TorBlock extension enabled [In reply to]

Comments on several of today's posts:

"Every wiki is different" isn't a superficial thing. Major structures such
as sysop, arbcom, checkuser usage, and probably vandalism and abuse profiles
and so on, vary greatly between the WMF wikis. What's being discussed here
is an extension that affects those, and where checkusers on one wiki are
making representations that the extension's default setting, as mooted by
some, badly match the experienced needs and abuse profile of that wiki,
which would be better dealt with by hard blocking.

That shouldn't be a major contention. Checkusers are the ones who are aware
of these things, and the contention's not made that all wikis should do
this, just that the one wiki whose community of checkusers is strongly
representing that a hard block system is more needed and a soft block
approach a serious problem, should be listened to. The same users also point
out that they also have a tool in active use to allow bypassing for those
with genuine need, a process to make that reasonably available, and that
"not an experiment" applies here.

This is the reply to GerardM and Platonides - the tool may be WMF wide but
each project may (like many tools) have it individually configured. Nobody
here is saying "wikinews (or other projects) shouldn't do what they need".
They're just saying "don't force Wikinews' ideal solution on all wikis",
including those whose checkusers pretty much all see the problems and all
object.

Likewise the comment, "even our public figures, people living in the "free
world" are harassed, stalked, threatened...Rape, murder, the use of
sulphuric acid they are the kind of threats that are issued" ... in fact,
most en wiki checkusers are on its Arbitration Committee mailing list, and
see exactly the threats that go on. So they don't need to be advised what
can happen, or how to evaluate it; almost all enwiki checkusers are in a
position they can judge for themselves that need and balance, and how
(un)common. And yet, after knowing that, this is still the overwhelming view
of multiple independent checkusers for that project. That should make one
pause and think hard if maybe they know what they're saying, when they ask
for this one project to gain a specific tor handling. After all most enwiki
checkusers value freedom too, we're also one of the early adopters of IP
block exemption to specifically allow users with a need, to override hard
tor blocks.

For the record, so there is no misassumption, confirming Andrew's comment
that he has only the best interests of the project at heart. That was my
impression of his stance. Where we've not resolved things is more, that
Andrew hopes there is a "wriggle" that would mean tor wouldn't need hard
blocking on en wiki... and despite trying I've just not yet come close to
that view, nor a way that might bypass the need via software :-/ So I have
to stand and say I would still rather when TorBlock is configured, let the
config for en wiki be a hard block norm, not a soft block one. I have no
urge to propose what other projects might find individually best, or the
settings which may fit their profile of vandalism and experience, other than
to encourage them to choose based on their own project's needs too, which
they presumably will.

The en wiki preference (if a general stance can be drawn from this thread)
is a default to hard-block, plus exemption, rather than a default to
soft-block, plus retrospective abuse handling. Not a demand that any other
wiki does differently than what is best for them, or that all projects must
do so.

FT2




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


brion at wikimedia

Jun 9, 2008, 8:42 AM

Post #57 of 58 (521 views)
Permalink
Re: TorBlock extension enabled [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Gerard wrote:
> Indeed. This extension appears to be for the benefit of TOR and no-one
> else.

False!

> Why not all open proxies?

Because we have a list of TOR nodes, so that's a pretty easy place to start.

Stop being an ass, please.

- -- brion
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhNT1AACgkQwRnhpk1wk45gIwCgm12TTh7+y/eDlfR6ptaBr3+C
5+sAnivRHpRGfSzsUUPV1KT2wEfM14RZ
=/XBZ
-----END PGP SIGNATURE-----

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


Simetrical+wikilist at gmail

Jun 11, 2008, 2:14 PM

Post #58 of 58 (491 views)
Permalink
Re: TorBlock extension enabled [In reply to]

On Sun, Jun 8, 2008 at 7:35 PM, Andrew Garrett <andrew [at] epstone> wrote:
> This exists in our codebase, but was turned off because very few ISPs,
> nor our network admin Mark, liked our software portscanning ~20% of
> the internet per day.

ISPs don't care if you portscan as long as it's for legitimate
purposes. IRC networks, for instance, do it routinely. I doubt
you're going to have to portscan anywhere near 20% of the Internet,
even allowing for some hyperbole, given that scanning is only needed
on edit, and can be cached for a quite long time (say, a month) for
confirmed non-proxies. You could also manually skip ranges that are
known to be dynamic, which would kill a ton more of the load, in fact
quite possibly almost all of it.

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

First page Previous page 1 2 3 Next page Last page  View All Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.