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
> Living in a Western democracy doesn't necessarily mean that you can surf
> the web or use internet services freely, look at all those blocks for
> Bittorrent, the dozens of blocks for Nazi hosters, and especially the
> German court decision about YouPorn, which actually led to >2 million
> websites being invisible by Arcor customers; they can only be helped
> through proxys (though I don't think watching porn via proxys is good).
>
> Marco
Most ISPs and indeed most places generally, even workplaces, don't block
Wikipedia. "Argumentum ad YouPorn" won't really apply.
FT2
> Andrew Garrett andrew at epstone.net
> Sat Jun 7 08:28:10 UTC 2008
>
> I had a discussion with FT2 on IRC a few hours ago. He said that he
> would be happy to have a soft-block, with these provisions:
> 1. A special page exists which allows the monitoring of recent tor
> edits. Perhaps Special:Recentchanges/tor?
> 2. A new protection level is added, which allows tor users to be
> prevented from editing an article, which, for instance, has concerns
> with regard to sockpuppeting and so on.
>
> What do others think of these?
>
> --
> Andrew Garrett
Apologies, I sadly need to correct this. We spoke at length. The topic was
Andrews question "what software or other measures might mean I would feel
able to change my current view and endorse a soft-block approach to tor".
We spoke at length exploring ideas, one of which was perhaps a way to
protect a page so that tor could not be used on it (unless a user who was
specifically IP block exempt). This was joint exploration of a difficult
problem, and the question was a good one. However about an hour into the
conversation I came to understand that TorBlock was not now going to be used
as I had thought, to require a long autoconfirm (many days + many edits).
Even with a long "autoconfirm" period I was not sure any solution below hard
blocking was possible. But we tried to see if we could find ideas anyway.
With my understanding corrected, and no "long extended period" I dead-ended.
With regret I therefore have to correct the mis-impression that I would be
"happy" to have a soft-block on these conditions. I tried hard, and both of
us talked for a long time, exploring many novel options, but I was not able
to find any that did the job short of hard blocking, even so :-/
I'm very very sorry if I had left Andrew with that incorrect impression. We
tried hard to brainstorm "what could be done in software that might make it
practicable to avoid ". We looked at many ideas, and did so positively and
constructively. But ultimately nothing came up that would actually fix the
main problem at all, other than hard blocking, and that remains therefore my
current view on it. Tor hard blocked + IP block exemption for those needing
it. We just get too much tor abuse (including quite sophisticated abuse) to
do less on this specific wiki, even if it is not that way on other wikis.
:-/
FT2
Password hashes were the hobby horse that first convinced me to get
involved in MediaWiki programming, back in 2003. Here's my outraged post:
http://marc.info/?l=wikitech-l&m=104904771815534&w=2
The relevant code was the first code I wrote for MediaWiki. Looking back
now, my immaturity as a programmer at the time shows through, and if
someone tried to submit something similarly naive today, I'd hope that
we'd have a few senior developers around (e.g. me) to point out its
problems and send it back for a rewrite.
The idea was to use md5($userId.'-'.md5($password)) as a hash. This has a
number of problems:
* There's no way to tell whether a hash is in the old style or the new
style. So migration is difficult and error-prone.
* The migration issues will be repeated every time we have to change hash
functions, which might be every decade or so due to improving
cryptanalysis and computing power.
* It links the password to the user ID, making it impossible to transfer
passwords from one user to another.
* The salt always has the same value on single-user wikis (1), so it's
insecure.
The obvious solution is to attach the salt to the hash. Luckily
user_password has been a tinyblob since the dawn of time, so we're not
space-constrained. We could store the salt in a different field (like
what's done in CentralAuth), but that wouldn't solve quite so many of the
problems listed above.
So I've committed a hash format change, so that salted hashes look like this:
:B:a2a5c3b9:44ebabb085ce78dd20c2d59c51e4080c
That is, a type "B" hash, with salt "a2a5c3b9" and MD5 hash
"44ebabb085ce78dd20c2d59c51e4080c". The way the salt and the password are
mixed together is the same as in the old system, so you can migrate to
this password format simply by prepending :B: and the user ID.
Unsalted hashes look like this:
:A:d41d8cd98f00b204e9800998ecf8427e
Password hashes will be migrated to the :A: or :B: style on upgrade, and
after that, you'll be able to switch $wgPasswordSalt on and off at will,
and all passwords will continue to work. Before upgrade, the software will
understand the old-style hashes, but it requires $wgPasswordSalt to be set
correctly.
When we eventually migrate from MD5 to Tiger/192 or whatever, we can
introduce a type "C" hash and then convert the old hashes at our leisure.
This change has been on my mind for a while, but the immediate motivation
is bug 14330.
-- Tim Starling
TorBlock is a bit to specific in what it does for how generic half the
code is. Part of what TorBlock does is the actual identification of Tor
exit nodes, however that's not something specific to TorBlock. There are
a lot of other uses like CheckUser identification, extensions to note
Tor usage in places in the UI, or even alternative things like
ConfirmEdit could require captcha from an anon Tor user rather than flat
blocking anon Tor users depending on local policy.
But basically what I'm saying is, just like how we have SimpleRegex
which is used by two or more of the Regex based extensions, It would be
nice if half of TorBlock was cut out into a SimpleTor extension which
would handle the basic parts of identifying Tor nodes. Then we could
make features in other extensions depend on SimpleTor and use it's
shared functionality to build those checks in.
--
~Daniel Friesen(Dantman) of:
-The Nadir-Point Group (http://nadir-point.com)
--It's Wiki-Tools subgroup (http://wiki-tools.com)
--Games-G.P.S. (http://ggps.org)
-And Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG)
Some notes on experience of tor, and IP block extension, and the use of
TorBlock on enwiki
TORBLOCK AND TOR USAGE:
Enwiki for some reason seems to get a lot of heavy duty sock usage and
editing abuse. Tor is highly abused, enough that tor has a "hard block on
sight" approach pretty much.
About a month ago, IP block extension was enabled on enwiki. This was rolled
out carefully on all sides, in view of past rollouts that had not gone
smoothly. It was a success. The developers did not enable it until there was
a clear communal consensus backed by a clear community policy. The community
created that policy and allowed it to stabilize. The issues were considered
carefully and a balanced approach created, which to date has worked very
well.
IP block exemption has broadly, two main uses -- a good-faith editor who
wishes to use their native IP, which is range-blocked for abuse prevention,
and an editor who is firewalled and cannot access WMF IP's safely other than
via an anonymizing proxy system such as Tor. Unfortunately IP block
exemption is also gold dust for account abusers - we have on enwiki regular
cases of extremely skilful sock-puppet abusers, including at least two
sock-masters who went as far as to get +sysop on a new account, specifically
in order to modify blocking of tor proxies, to enable their other socks to
edit in a manner that would defeated checkuser.
We resolved this by instigating an IP block exemption policy that was very
strict, to ensure admins wouldn't abuse the grant of the right (and could be
verified to have done so wrongly if needed) - those whose native IPs are
blocked can request IP exemption /provided/ they don't use it to edit via a
proxy (which means they remain low risk and any admin can handle granting
it), and any user wanting to edit via an anonymizing proxy has their request
discussed first by the community, to prevent admins quietly giving it to
their socks and making excuses later. So far it's worked well, a dozen or so
users on vandal ranges, two Chinese editors, a number of bots, and a user
who after discussion was agreed to be trusted not to sock, have all been
given IP block exemption.
What is relevant in all this, for TorBlock, is the communal agreement that
Tor (and other anonymizing proxies) are a special case, and that we treat
them on enwiki as ideally /not/ to be used other than under exceptional
conditions such as hard anti-vandal range blocks (if confirmed) and the
Chinese or other firewalls (subject to communal consensus). We haven't
mass-blocked them before simply because of the technical problems of doing
so.
I cannot speak for other wikis, but with IP block exemption working out so
well, we probably have no real need to keep tor open at all. The ability to
defeat CheckUser is an admin right, permits easy socking, and requires a
degree of communal trust. If there is a genuine need, then we have it in
place, now, that the request will be considered communally and if agreed,
granted. The strictness of the process has meant that this right can be
given when genuinely helpful, without major concerns over abuse.
All wikis differ, but on enwiki, the option I would expect most sensible,
would be hard blocking of all tor nodes for a reasonable time, or until they
have ceased to be tor nodes for a while. (I understand that other wikis may
find autoconfirmed or other settings more useful instead.) Enwiki checkusers
almost unanimously have a view that tor and other proxies are a major source
of disruptive editing. We have IP block exemption in place; tor seems to be
a preferred route for problem editing, and if someone does need to edit via
tor for a legitimate reason we can easily accommodate it via IP block
exemption.
MARKING OF EDITS
A second issue, the marking of edits
(revisions/diffs/contribs/history/checkuser/oversight) as having been made
via a tor node, would be extremely helpful. For enwiki, one option might be
to show this to admins or wider users, as well as checkusers. I've summed up
the emails covering this, below.
Best,
FT2
----- cu-list email #1
(Response to comment that there are many wikis with different needs)
Nobody is disputing that different wikis have different needs. The enwiki
project (as pointed out) has IP block exemption enabled, and has checkusers
who strongly feel that project would benefit from hard blocking tor in this
extension's use. Other projects (as you and others rightly point out) may
have completely different needs and views.
What I guess this means is, the tor extension needs to be per-wiki
configured, but that's hardly a surprise. Ie, same as settings for other
features that vary between projects.
----- Email #2
(Response re concern that tor is fluid)
As I understand it, the extension updates its cache of tor nodes every hour,
and edits are marked as "tor" if they come from a node that's currently
stated to be tor, not just "was a tor node some time in the last 2 months".
It's apparently very specific that at or within a very few hours of the edit
it was actively indexed as a tor exit node, hence its usefulness. Werdna has
confirmed.
----- Email #3 & #4
(Response on WMF privacy policy)
>From time to time, 1/ general information such as ISP/country are in fact
placed on-wiki during the course of a checkuser case, and 2/ this is
specifically endorsed by WMF guidance/help information for checkusers.
>From [[Meta:Help:Checkuser]], the main WMF guidance page, the full quote:
June 2008:
"Wikimedia privacy policy:
[...] The following information is commonly permissible. This list is not
comprehensive, and cannot replace the checkuser's judgment...
[...] the ISP edited from, if it is large enough that the information is not
personally identifiable; the country, which is generally not personally
identifiable."
The first versions of the WMF guidance/help page from October 2005 stated
the same:
Oct 2005:
"If they're on a large ISP (e.g. AOL, NTL, BT, Telstra), they're one of
millions and it's not personally identifiable."
"Revealing the country is generally not personally identifiable (e.g.
"User:Querulous is coming in from the UK, User:Sockpuppet is coming in from
Canada")."
http://meta.wikimedia.org/w/index.php?title=Help:CheckUser&oldid=226259
To support the statement that this is followed in practice as well as "on
paper", a quick search gave some specific case examples:
[[RFCU/Case/Cplot]] - "I have pinpointed a couple of Illinois Comcast
addresses" ... "The IPs come from Sprint PCS"
[[User:MER-C/Blu_Aardvark_RFCU]] - "Usual group of AOL and CenturyTel IPs"
[[RFCU/Case/JB196]] - "he has resorted to using anonymous AOL Proxies"
[[RFCU/Case/Tajik]] - "Unrelated. Anoshirawan is in the US."
If naming a country or (large) ISP would not be considered a privacy issue,
then a flag indicating "this edit was made via tor" is not a privacy issue
either. It in no way is personally identifying to say "this edit was made
via an anonymizer".
What does matter is the potential it has, for drawing attention to a user
and encouraging speculative or bad faith conclusions (eg: "they use tor so
they must be a sock/hiding something/up to no good/etc"). I'd be tempted to
limit it primarily for the latter reason rather than for privacy reasons. In
general it may not be a bad thing to let admins see that info in contribs,
diffs and edit histories, as admins do a lot of the initial multiple account
spotting for the project. Not making it public to all, and limiting it to
admins, will cut most of the problematic usage.
As privacy policy doesn't seem to be an apparent issue, the core question
about "who is safe to know" is much more about avoidance of unhelpful,
unfair, and often tenuous speculation. I think admins are probably safe on
the whole, to trust with that level of information. Worth trialling anyway;
and agreeing it may vary by wiki.
----- Email #5
(Response to impact of auto-tor blocking)
Noted that since anon IPs don't get even autoconfirmed, and Werdna's new
extension would block tor edits unless at a minimum autoconfirmed (and
optionally may hard block them on some projects), then under what
circumstances will unlogged-in IPs be able to make edits to WMF projects via
tor in future? Is the information that an anon edit was made via tor, likely
to arise, or actually be meaningful, in future?
----- Email #6
(Comment on publicity of TorBlock settings)
In any event, can we perhaps agree to keep private the exact requirements
for TorBlock extension to allow tor editing on projects, much as we do the
length of time that checkuser data is kept, for the same reason -- if it's
apparently "large", and a specific limit is not well known, then it won't be
so readily gamed.
Best,
FT2
brion(a)svn.wikimedia.org wrote:
> Revision: 35958
> Author: brion
> Date: 2008-06-05 23:58:28 +0000 (Thu, 05 Jun 2008)
>
> Log Message:
> -----------
> Revert r35928 for now:
> * cleanup formatting of timestamps:
> ** should convert to TS_MW (or decodeBlockExpiry) on input consistently
>
It consistently converts it initially by parseExpiryInput (in
Special:CentralAuth) and then stores it in TS_MW format by
Block::encodeExpiry before writing to the database.
> ** should output consistently direct to formatExpiry() or timeanddate()
>
translateBlockExpiry() and timeanddate() are different things. First can
be used only on raw expiries which are entered by users. We store them
only in logs. The second one is used to output time when the block will
expire (that's the only time we have in globalblock table). So I can't
see any inconsistency there.
> * cleanup form layout:
> ** use mw-label and mw-input classes instead of hardcoding left and right align
> * needs fuller UI for blocking:
> ** there's no display of expiry or blocker on Special:CentralAuth
>
Did you mean drop-down list for block expiry? There was an input box for
the expiry.
> ** no overall block list that i can find
>
I'll add Special:GlobalBlockList.
> ** how does this integrate or compete with GlobalBlocking extension?
>
It doesn't. GlobalBlocking blocks IPs, CentralAuthBlock blocks SUL accounts.
--VasilievVV
Russell Blau wrote:
> I've been testing my client code on test.wikipedia.org and having problems,
> but I can't tell whether it is a problem in my code, in the API, or on the
> testwiki server.
>
> I submitted an edit to a user page using the following body in the POST
> request to http://test.wikipedia.org/w/api.php (I've broken out the body
> into key=value pairs to make it somewhat more readable, but there were no
> line breaks in the body as submitted via http):
>
> maxlag=5&
> title=User%3AR%27n%27B%2Ftest&
> text=Further+test+of+page+revision+using+API.&
> format=json&
> recreate=&
> basetimestamp=2008-06-04T19%3A40%3A58Z&
> summary=test+revision+again&
> token=0a2b0e1b8d6cea730e7802b900476fa0%2B%5C&
> action=edit&
> minor=
>
> This request returned an HTTP 500 status code with an empty response body;
> however, the edit was successful on the wiki server. (See
> http://test.wikipedia.org/wiki/User:R%27n%27B/Test) Any ideas why I would be
> getting this 500 status code instead of the expected JSON response text?
>
> Russ Blau
>
>
> _______________________________________________
> Mediawiki-api mailing list
> Mediawiki-api(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Me, Bryan and another user (who I do not recall the name of, sorry) have
also encountered this problem. It was reported via the #wikimedia-tech
IRC channel, although I am unsure of whether it was noted or acted upon.
As far as I am aware no bugzilla entry was opened either. The edit
does still go through, although it is essential that data is returned
for any bot to be programmed in a reasonably effective way.
Forwarding this to wikitech-l for further investigation.
MinuteElectron.