Brion Vibber wrote:
> On Mar 20, 2004, at 11:29, Walter Vermeir wrote:
>
>> I have discovered there is now a robot active on I believe all
>> Wikipedias whit the name "Proxy blocker".
>>
>> It blocks automaticly all users who are using a open proxy server.
>>
>> It looks like a action form the English Wikipedia.
>
>
> Tim plugged this experimentally into the wiki in response to a massive
> spambot attack a few days ago that worked through open proxies. It's not
> a vigilante robot, but an automated part of the wiki that runs a check
> when a given IP address first makes an edit. (This should have been
> announced; if it wasn't, I hope Tim will remember to do so next time.)
To implement a proxy scanner/blocker was an idea I had in early February
some time, when I saw simple vandals using anonymous proxies to evade
bans. I raised the idea of systematically blocking anonymous proxies on
wikien-l in mid-February, under the subject "Anonymous proxies", to
discuss the ethical issues. Jimbo was behind the idea. I wasn't even
sure if I was going to write it at that stage, I just wanted to make
sure there was no reason I couldn't do it. But events in early March
inspired me to get on with it and quickly push it into service. I'm
sorry I forgot to announce it in the rush. I did mention it on IRC a few
times, and I wrote some documentation at:
http://en.wikipedia.org/wiki/User:Proxy_blocker
Neil Harris wrote:
> A suggestion: instead of blocking auto-detected open proxies
> indefinitely, they should only be blocked for a limited period such as
> one week.
Done.
-- Tim Starling
On Mar 20, 2004, at 11:29, Walter Vermeir wrote:
> I have discovered there is now a robot active on I believe all
> Wikipedias whit the name "Proxy blocker".
>
> It blocks automaticly all users who are using a open proxy server.
>
> It looks like a action form the English Wikipedia.
Tim plugged this experimentally into the wiki in response to a massive
spambot attack a few days ago that worked through open proxies. It's
not a vigilante robot, but an automated part of the wiki that runs a
check when a given IP address first makes an edit. (This should have
been announced; if it wasn't, I hope Tim will remember to do so next
time.)
Of course if any wikis decide they don't want this, we'll be happy to
disable it for you.
I should point out that _proxies_ are not a problem, but _open proxies_
are often a serious security risk. They are usually simply
misconfigured, and like open mail relays are taken advantage of by
spammers and malware to disguise their attack vector. A proxy meant as
a firewall but left completely open may also allow external attackers
to get at internal servers which were intended to be better secured.
> This is likely a violation of the blocking policy on most Wikipedias
> so inform your users about this and discuss it.
>
> To trigger the Proxy Blocker go to http://www.publicproxyservers.com
> and use a "transparent" proxy.
-- brion vibber (brion @ pobox.com)
Tim Starling wrote:
>To implement a proxy scanner/blocker was an idea I had in early February
>some time, when I saw simple vandals using anonymous proxies to evade
>bans.
What code are you using to detect open proxies? Could you post it, or
email it to me privately?
--Sheldon Rampton
I've poked an exception for the validator's bot into the squid's
user-agent blocking. Rejoice! Now we may again check the validity of
our markup.
-- brion vibber (brion @ pobox.com)
We experienced some sort of network outage around 7:07-7:17pm (PST);
connections couldn't be opened to our subnet (including the power
controller). Tim had a shell remain open during this time, but nobody
else could connect...
Things seem back in order, but mysterious 10-minute network dropouts
kinda suck. :(
-- brion vibber (brion @ pobox.com)
In WP-de you can read if you try editing an article:
Sonderzeichen: Ä Ö Ü ä ö ü ß * [ | ] { }
Please, disable this "help" now; there is already much to much clutter
all over the (edit) pages. As a long time user, I know about the
license stuff; I do not want to read it again and again and esp., do not
yell at me using bold text.
Software or interface changes must not happen on a day-by-day base -
every 6 months is enough. I asked for such a cooperation some weeks
ago, but it was refused. Can we work a policey that fits for the more
conservative users, too?
--
| ,__o
| _-\_<,
http://www.gnu.franken.de/ke/ | (*)/'(*)
As most of you know, the MediaWiki namespace is quickly becoming a generic
template system with parameters. Currently it only supports unnamed
parameters, e.g. {{country|Germany|82 million}}, but it is my
understanding that named parameters, e.g.
{{country|name=Germany|population=82 million}}, are firmly planned.
What this particular query would do is use the "Template:Country" page,
which would be the box which is currently manually entered for each
country article on Wikipedia, and replace certain variables in it ($name,
$population) with the assigned parameters.
>From named parameters it is a relatively small step to searchable
metadata.
I am thinking of a new table called METADATA
| template_name | parameter_name | parameter_value | page_id |
|------------------------------------------------------------|
| country | name | Germany | 23923 |
| country | population | 82 million | 23923 |
| country | name | United States | 4834 |
| country | population | 290 million | 4834 |
What this means:
The page 23923 ([[Germany]]) includes the text
{{country|name=Germany|population=82 million}}
The page 4834 ([[United States]]) includes the text
{{country|name=United States|population=290 million}}
Upon saving a page, all template calls would be parsed, and the METADATA
table would be updated accordingly.
Lastly, we would need a page Special:MetadataSearch, which would include a
search form like this:
-----------------------------------------
Template : [country.......^]
Parameter : [ ]
Value : [equals ^] [ ]
AND (*) OR ( ) AND NOT ( )
Parameter : [ ]
Value : [equals ^] [ ]
AND ( ) OR ( ) AND NOT ( )
etc.
ORDER BY : [numerical value ^]
SORT ORDER: [ascending ^]
-----------------------------------------
It would of course run the appropriate query on the METADATA table. In
most cases I believe this would be fairly fast as most templates would
only appear on hundreds of pages, limiting the search space dramatically.
Now we could do things like:
* Show me all countries with a population larger than X
* Show me the country with the top-level domain .FR
* Show me all countries that use the US dollar as currency, but do not
speak English as an official language
etc., of course generically for all kinds of templates.
As an extra bonus, it would be neat to be able to transclude the results
of these queries dynamically on a page, so I could have
[[List of countries by population]]
which would be dynamically generated from such a query.
Advantages of this system:
* Metadata is entered naturally, immediately associated with visible
output
* Very high flexibility
We can theoretically extend this relatively easily to allow for invisible
metadata that is not directly associated with a template:
{{data:person|firstname=Alfred|lastname=Wallace|birthyear=1823}}
Whether we want to do this is another question. I am leaning against it
because I feel it violates basic wiki principles -- cause and effect
should be visible to the user. But if we establish the metadata and
article separation I alluded to in an earlier post we may reconsider this.
This proposal is directly relevant to the image copyright tagging problem,
which can now be solved relatively easily:
{{
image
license=[[GNU Free Documentation License]] |
source=photograph taken by [[User:Dogmaster3000]]
}}
This text could be auto-inserted into the page based on form data during
upload (don't forget to update the METADATA table as well). Now we can
query for images under a specific license, uploaded by a specific user
etc.
There is of course some overlap with the category system here, but I feel
it is minimal. On the other hand, I think that in terms of implementation,
the strategies needed here are similar to those for keeping the LINKS
tables up to date, so maybe a shared implementation makes sense.
Let me know what you think. I'd be especially interested in Tim's opinion
as he is the main developer behind the template system.
I feel there is still a lot of potential in templates, and basic
programmability should also be considered. Having stuff like optional
parameters and loops would open a whole new range of possibilities. For
the typical user, things will become easier, not harder, as they now just
have to speak one syntax - {{template|foo=bar}} - and can use it to
influence data in very complex dynamic layouts.
All best,
Erik
Hi,
I have just committed a trivial change to Parser.php. We replace "~~~"
with [[User:Username|Username]], and "~~~~" with that, followed by the
date/time. Now, "~~~~~" inserts just the date/time, without the username.
I got the idea from
http://en.wikipedia.org/w/wiki.phtml?title=Wikipedia:WikiMoney&diff=2852328…
Greetings,
Timwi