Wikipedia:Administrators' noticeboard/2008 IWF action

Latest news (last updated 2009-01-07 21:26 UTC) As of 7 January 2009, UK Internet Service Providers (ISPs) have ceased proxying their connections to Wikipedia through a limited number of Internet addresses, however it appears to be resuming again on some ISPs, TalkTalk and Be Unlimited seem re-affected at the moment. A decision to reverse the image blacklist was released by the IWF on 9 December 2008 at 18:30 UTC, See #Official statements for the IWF and Wikimedia Foundation's statements. See also #How to check if you are being proxied when visiting Wikipedia.

Before posting ...is your message more appropriate for the talk page?

This article's factual accuracy may be compromised because of out-of-date information. Please help talk page.

Contents 1 Introduction 2 Issues 2.1 Ethical 2.2 Technical 3 Official statements 3.1 Internet Watch Foundation 3.2 Wikimedia 3.3 Virgin Media 3.4 Plusnet 3.5 Be Broadband 4 Media coverage 5 Censoring information per ISP 5.1 IP addresses of the proxies 5.2 Notes 5.3 Current status and editor reports per ISP 5.3.1 Be Unlimited 5.3.2 TalkTalk 6 Block message 7 Technical details of transparent proxy 7.1 Access to the CleanFeed list 7.2 Technical presentation about CleanFeed 7.3 Eclipse 8 Filter IPs unblocked (to editing) 8.1 New news?? 8.2 Filter IPs still active 9 How to check if you are being proxied when visiting Wikipedia 10 See also 11 References 12 External links

Archives Archive 1 Archive 2 Archive 3

[edit] Introduction

On 5 December 2008, the UK-based Internet Watch Foundation blacklisted the article Virgin Killer and the page of a related image, considering them to be potentially illegal in the United Kingdom. Several large Internet Service Providers (ISPs) that cooperate with the IWF subsequently blocked them from being viewed, affecting an estimated 95% of residential Internet users in the UK.^{proxies), users from the affected ISPs shared a small number of IP addresses. This meant that a user vandalising Wikipedia could not be distinguished from all the other people on the same ISP. Unfortunately, the result of this was that all unregistered users from the affected ISPs were temporarily blocked from editing Wikipedia.}

[edit] Issues

This is a summary, not a discussion, of the problems that Wikipedians have with this censorship action and especially the method of its implementation. It is not an official list that has been approved by the Wikimedia Foundation, but a summary of discussion on this page and its talk page, created by several editors. We urge all parties to discuss these points and try to solve those that can be resolved locally.

[edit] Ethical

• ISP issue: Users of several ISPs are receiving fake 404 or 403 error messages when visiting the article Virgin Killer, with wording such as "Not Found. The requested URL en.wikipedia.org was not found on this server". It is necessary for tolerated censorship that people are made aware of when they are being censored, and the reasons why this is occurring.
• IWF issue: Albums bearing the image are currently on sale in the UK and have been for many years. The image is readily available on the internet for everyone. This clearly did not factor into the decision of the IWF. They say they act only on the individual reports they receive. This case shows how shortsighted such an approach can be.
• IWF issue: The IWF blocked the text of the article that includes the image. This is an encyclopedia text that discusses amongst other things, the controversy surrounding this image, which is meant to put the image into context, in an academic way, and to educate its readers.
• IWF issue: The image is not certain to be illegal. In the IWFs own words the image was judged to be "potentially illegal indecent image of a child under the age of 18, but hosted outside the UK". The album has been for sale in many countries with this cover for over 30 years. No one has ever been prosecuted over the image as far as is known. The FBI investigated a report of this album cover in spring 2008 and decided to take no action. The Wikimedia Foundation has not been requested by the FBI or any other law enforcement agency to remove the image and has certainly not been charged over it. The ultimate arbiter of whether an image is illegal is a court of law, in particular a jury, and not a self-selecting group, however well-intentioned their motives.
• IWF issue: The IWF blocked access to a page on one of the world's most-visited websites without informing its owners. We understand that their policy is not to contact any of the hosts they block, but commonsense should have told them that blocking such a website might have unforeseen consequences. In particular, they failed to understand that whereas a block of the article itself may well amount to restraint on the guaranteed freedom to receive and impart information, the image itself is uploaded from a different URL which could have been separately blocked by the ISPs with whom they are in partnership; in this way, they demonstrate a complete lack of understanding of how websites work, which is chilling in the extreme for a supposed Internet Watchdog.
• IWF issue: It is well documented that actions such as the IWF's frequently have the opposite effect to that intended, something known as the Streisand effect. The Virgin Killer article show that even with the block in effect, the page received 200 times as much traffic as usual in one day. In fact, curiosity has generated almost half a million more visitors than the page would normally receive. Googling for 'wikipedia', 'Internet Watch foundation' or 'IWF' now, under their 'news results' section (3rd result down), has a link (complete with inline-picture) to a news article about this event, complete with the 'potentially illegal' image, whilst the BBC news article links to the Scorpions' website (again, complete with 'potentially illegal' picture), thus maximising peoples' likelihood of being 'accidentally exposed to potentially illegal content', entirely the opposite of the IWF's goals, and as could have been predicted if the IWF had a modicum of understanding of the social aspects of the internet (and as wouldn't have resulted from a take-down notice).
• IWF issue: Does filtering represent an appropriate use of resources to combat child sexual abuse? The creation of images of child sexual abuse is recognized worldwide as a serious crime, and the best course of action is to prosecute producers, hosters and publishers of illegal material. Filtering by IWF may be merely sweeping the problem under the carpet. It neither stops actual child abuse, nor does it prevent criminals from copying images to another site with minimal effort. The money spent on filtering infrastructure may be better spent on real law enforcement and international coordination.
• IWF issue: Online filtering creates a situation based on presumption of guilt. In the past, removal of illegal online content was handled by takedown notices such as the DMCA. Takedown notices gave the host of the content under challenge a choice of whether to comply with or to ignore the notice. If the host believed the notice to be in error, he could ignore it. When this occurred, the plaintiff had to escalate the case to a court and prove that the content was illegal. This kept the system in balance, because incorrect or abusive takedown notices would incur no costs for the host. Online filtering, however, creates a dangerous precedent of presumption of guilt, since it introduces a duty to prove content legality (innocence) instead of the duty to prove illegality (guilt). This removes proper checks and balances from the system, and violates the legal principle of presumption of innocence, stated in law as Ei incumbit probatio qui dicit (the burden of proof rests on who asserts, not on who denies). This is another reason why it has been suggested by some editors the Internet Watch Foundation block on Virgin Killer is in itself potentially illegal under Article 10 of the European Convention on Human Rights.
• Scorpions issue: Most Wikipedia editors think that the image, to put it mildly, is not really making their individual "Top 10 of tasteful images".
• Wikipedia community: Though Wikipedia policy is that we do not censor unless something is illegal in the US, either as a breach of copyright, defamatory, or illegal in itself, the community exercises collective editorial control on grounds of relevance to the purpose of its articles. Some editors feel that this image has no place here, while others believe the discussion in the article justifies and explains the presence of the image itself. Though the image has been discussed at length ([2] [3] [4] [5] [6]) even before the UK censoring, so far there is no consensus among the community to remove the image.
• Wikipedia community: Questions have been raised as to why Wikipedia is putting so much effort into this censorship case, compared to Chinese, Iranian and Syrian censorship cases. The reason is that our influence in the UK is much greater. If we cannot deal with these kinds of problems in the UK, then we will definitely not succeed in China. This case also establishes an important precedent, because unlike Chinese, Iranian or Syrian internet filtering, UK internet filtering can serve as an example for other democratic countries. The EU and Australia have plans for mandatory internet filtering. The outcome of this case can influence how internet filtering is implemented in other countries.
• Wikipedia community: Wikipedia is able to work around blocked pages by directing users to the secure (https) server. Are technical countermeasures against censorship morally appropriate?
• Wikipedia community: If the blocking is indeed found to be inappropriate, does liability for damages come into play? The blocking imposed by the IWF caused disruption of Wikipedia operations. The damages include, but are not limited to: work of administrators and engineers to diagnose the network problem caused by connection hijacking, work to implement workaround for registration, etc. If a large online retailer like Amazon was subject to blocking, damages would be much higher. Are ISPs and/or the IWF liable for damages caused by inappropriate blocking?

[edit] Technical

• ISP issue: Several ISPs seemed to be unprepared for the amount of traffic that Wikipedia generates. Their filters act slowly and sometimes simply error out on the load. This is an avoidable effect of routing through a single transparent proxy and is arguably a breach of the ISPs terms and conditions to provide connectivity.
• ISP issue: Several ISPs are using proxies that route all Wikimedia traffic through a single IP address. This makes it much more difficult for Wikipedia to administer the website, because thousands of users are all sharing the same identifier. Because of this and a small number of vandals amongst the thousands, these IP addresses are blocked from editing anonymously; this harms both the project itself and UK users' experience of it. The net effect is to negate one major principle of the Wikipedia project, that anyone can contribute to the "sum total of human knowledge".
• ISP issue: At least some of the proxying ISPs (TalkTalk, Virgin Media/Tesco, Be/O2/Telefonica) do not add X-Forwarded-For headers to their HTTP requests. This effectively anonymizes all the remaining requests to Wikipedia, making it more difficult to handle any other case of illegal activity from an anonymous contributor behind the proxy.
• ISP issue: At least one of the proxying ISPs, Virgin Media, ran an entire suite of over 200 interception proxy HTTP servers for approximately seven years, all of which added X-Forwarded-For headers to their HTTP requests and gave Wikipedia no problem for much of that time. See Virgin Media#Proxy servers and the articles listed immediately below. This technical know-how has either been lost by this ISP, or was not communicated from the group that used to manage the old proxy servers to the group that managed the new proxy servers.
  • Robin Walker (2006-04-23). 2008-12-10. 
  • Ben Cheetham (2008-10-19). 2008-12-10. 
• IWF issue: The IWFs decision has been carried out very ineffectively. Two URLs—the article and the description page of the image—were blocked. This unnecessarily censored the text of the article and the image's description page while leaving the image itself easily accessible by varying the URL slightly or using a direct link to Wikimedia's image server, upload.wikimedia.org. The IWFs actions have thus greatly inconvenienced thousands of contributors who have never even heard of Virgin Killer, while doing nothing to prevent anyone wishing to view the image for whatever reason from doing so. A more appropriate course of action, from a purely technical point of view, would have been to block the image file itself and the directory in which generated thumbnails reside, rather than two pages that happen to contain it, thus actually blocking the image whilst causing no collateral censorship. Had the IWF contacted the Wikimedia Foundation before acting, this could have been explained to them.
• ISP issue: Users of several ISPs are being served fake 404 or 403 errors when attempting to visit the article. This is technically incorrect, and unhelpful.
• ISP issue: Use of a simple sweep-ping script as described by Guardian here in 2005 allows to discover all IP addresses in the CleanFeed list. Thus, the blacklist can be misused as an "index" of illegal pornography.
• Wikimedia issue: Because there are many types of proxies in the world, and because X-Forwarded-For headers are forgeable, Wikimedia only allows X-Forwarded-For of proxies that it 'trusts'. To detect this and add this to our list takes time. See the details of the techniques used for X-Forwarded-For proxies here.
• Wikimedia issue: Wikimedia provides secure, encrypted access to Wikipedia via https. This secure access reliably bypasses any ISP's filtering and logging facilities. Should Wikipedia inform users of this possibility? Should pages have links to switch to secure mode? Does the secure server have enough capacity? Is it possible that the IWF, unable to filter individual pages when users connect via https, will demand blocking of secure access to Wikipedia altogether?

[edit] Official statements

[edit] Internet Watch Foundation

A statement was originally posted to [1]. The appeals process is described on the IWF website. According to the IWF's Sarah Robertson, she is not aware of the appeals procedure having ever previously been used.

At 18:30 UTC on 9 December 2008, the IWF [2]

[edit] Wikimedia

Press release available at wmf:Press releases/Censorship of WP in the UK Dec 2008. See also wmf:Censorship of WP in the UK Dec 2008QA.

The Wikimedia Foundation released a followup press release after the blacklisting was reversed.

[edit] Virgin Media

Official statement (9 Dec) [7]

[edit] Plusnet

Official statement (9 Dec) [8]

[edit] Be Broadband

"Be Broadband's Social Media Press Office: Be's response to concerns over Wikipedia" linked from Be's News releases page:

[edit] Media coverage

[edit] Censoring information per ISP

This is the information that was gathered based on editor reports. It reflects our current understanding of the ISPs that adhere to IWF blocking, and their methodology.

ISPs that were apparently not following the IWF blacklisting.

• Tiscali UK
• AOL UK
• Zen Internet
• JANET — UK Universities' network
• UK Military

[edit] IP addresses of the proxies

[edit] Notes

• Where possible Wikimedia has added these providers to their whitelist of trusted proxies. Customers of these ISPs will no longer appear as a single IP address soon after 14:50, 8 December 2008 (UTC). That means that they will be able to edit anonymously under their own IP address. They will not be able to view the IWF blocked pages and they might still experience slowdowns on Wikipedia due to insufficient capacity of some of the filter systems of their ISP. The ISPs that do not provide X-Forwarded-For HTTP headers are however still trapped behind a single IP. We urge TalkTalk, Virgin Media, Tesco, Telefonica O2, Be Unlimited and BT Internet to add these headers to their proxy systems to alleviate the problems from these blocks. When ISPs have added these headers, they can request to be added to the same list of "trusted" proxies.
• Any ISP appearing on this list could potentially have been affected.
• The (English Wikipedia) Virgin Killer article was briefly censored on a Sonera proxy in Finland, after the ISP had implemented IWF's blacklist by mistake.
• Most (but not all) computers in UK military bases do not appear to be affected.

[edit] Current status and editor reports per ISP

The boxes detail the information that is currently known to Wikipedia administrators. It is not guaranteed to be correct. People should urge ISPs that proxy and do not provide XFF headers, to add them.

[edit] Be Unlimited

1. Be's been beproxied since 14:29, 5 January 2009. --89.167.221.131 (talk) 00:13, 8 January 2009 (UTC)

Be is no longer using the proxy for Wikipedia since 13:27, 8 January 2009.

[edit] TalkTalk

1. Been filtering me since this morning - Wikipedia dog slow and Special:Mytalk showing proxy IP. ~~ [ジャム]^[t - c] 21:55, 7 January 2009 (UTC)

No longer proxying as of now. ~~ [ジャム]^[t - c] 16:06, 12 January 2009 (UTC)

[edit] Block message

Users attempting to edit anonymously from the affected ISPs will see a specifically designed block template. Administrators who block IP addresses believed to be impacted by this filtering are asked to use {{User:Lucasbfr/UKBlock}} rather than default block notice and to enable account creation (and block only anonymous access). Do not hardblock these addresses. If you are blocked, you will see a message like this:

Anonymous editing from your Internet Provider is disabled. Please log in. Wikipedia has apparently been added to a UK website blacklist and your Internet service provider has decided to block part of your access. Unfortunately, the blocking method they are using makes it impossible for Wikipedia to differentiate between legitimate users and those abusing the site. As a result, we have been forced to block several IP addresses from editing Wikipedia. Registered users are still able to edit. If you are currently blocked from creating an account, use our account creation tool to request an account with details of your block as explained below. Alternatively, you may wish to try editing through our secure server which may not be affected. You may wish to contact your Internet service provider to inquire about this issue. We apologise for any inconvenience this may cause.

In order to make it simpler for everyone (some the blocks reasons and durations did not match), I have changed the block settings of all these IPs after a quick brain check:

• Settings: anon only, ACC enabled (not that it will do much good), talk page edit enabled
• Duration: until 0:00 8 December (Tuesday), the situation being unlikely to change before that indef (which is NOT infinite)
• Reason: {{User:Lucasbfr/UKBlock}}:

-- lucasbfr ^talk 20:43, 6 December 2008 (UTC)

Shouldn't still be block from editing due to them being proxies? — Dispenser 20:55, 6 December 2008 (UTC)

Only open proxies are blocked in such a manner, Dispenser. -Jéské v^_^v) 20:58, 6 December 2008 (UTC)

We have some precedent from flawed AOL proxy software. — Dispenser 01:02, 7 December 2008 (UTC)

• I noticed my IP was the shared 62.30.* one as well, surprising, as my normal IP didn't show. AC --Sunstar NW XP (talk) 22:54, 6 December 2008 (UTC)

My normal IP showed up in the Leuksman header PHP file, but surprisingly when I was editing my own wiki, it showed my regular IP. I assume this is due to my MediaWiki being version 1.13, and yours being the latest SVN build. Over at my wiki, go to Special:Mytalk and see what your IP is: it may not be the 62.30.* one that you get editing here, unless I'm wrong. AC --Sunstar NW XP (talk) 23:45, 6 December 2008 (UTC)

Sorry to disappoint, but this is a deliberate filtering from your ISP :) There's not much we can do beside complain. -- lucasbfr ^talk 23:51, 6 December 2008 (UTC)

[edit] Technical details of transparent proxy

The diagnosis discussion "Major UK ISPs reduced to using 2 IP addresses" has been moved to Wikipedia talk:Administrators' noticeboard/2008 IWF action/Archive 2 by Protonk (talk). Please retain this note as links still exist to the old location.

On Be Unlimited/O2/Telefonica, all HTTP traffic to the European Wikimedia Squid frontend rr.knams.wikimedia.org is routed through the transparent proxy. Traffic to other Wikimedia Squid frontends or Wikimedia sites hosted on their own servers is not rerouted or filtered, even if it's directed to the English Wikipedia. Have other ISPs done the transparent proxy for one IP only, too? --Ticram (talk) 17:21, 7 December 2008 (UTC)

Wanted to ask, do they set the “X-Forwarded-For” header? Niczar ⏎ 18:27, 7 December 2008 (UTC)

Apparently they found out over at Bugzilla that they don't. Which is the problem. Calvin 1998 ^{(t·[Special:Contributions/Calvin 1998|c]])} 18:29, 7 December 2008 (UTC)

We can't tell, since the headers people have been pasting on Bugzilla are from leuksman.com, which is not hosted on that IP. Would it be possible to set a similar php on http://test.wikipedia.org or something, to see the headers that actually have come through the transparent proxy? --Ticram (talk) 18:53, 7 December 2008 (UTC)

I think they looked at the server logs directly. Apparently not all versions of Wikipedia are blocked, test.wikipedia might be unblocked :/ -- lucasbfr ^talk 19:21, 7 December 2008 (UTC)

They may have, though it doesn't say on bugzilla. For me test.wikipedia.org is not blocked but goes through the proxy: affected users can test http://test.wikipedia.org/wiki/Special:Mytalk and see one of the IPs listed at the top of this page. http://wikimediafoundation.org/wiki/Special:Mytalk however shows people's real IP. I think that's because test.wikipedia.org resolves to rr.knams.wikimedia.org (the Amsterdam cluster), while wikimediafoundation.org resolves to rr.pmtpa.wikimedia.org (the Tampa cluster). --Ticram (talk) 19:39, 7 December 2008 (UTC)

I'd expect they're using DNS assisted URL filtering, as in, a "suspicious domains" list is provided to the ISP, and requests for resources on those domains are redirected to the "transparent proxies". In normal operation, the client connects to the ISPs DNS to get the IP of the destination machine. Then the client connects to that IP address:

If the domain is in the "suspicious" list, the request is redirected over to the proxy which masquerades as the actual web site (which is why SSL may work, but regular HTTP doesn't), provided the specific URL isn't the problem URL.

If the URL is in fact the problem URL, then the call to the actual web server doesn't happen - and the client gets the generated warning message.

This means that the ISP needn't maintain a list of all the URLs that are "bad", just a list of domains that may have "bad" content. It also means that the whole domain needn't be blocked if "bad" content has been found on it. However, it does mean that the web server sees only a small set of IPs. Mr. Bene (talk) 05:57, 8 December 2008 (UTC)

• that diagnosis would fit the situation being described pretty well. Protonk (talk) 06:35, 8 December 2008 (UTC)
  • This was amazingly helpful. Thumbs up to Mr. Bene.--Tznkai (talk) 07:35, 8 December 2008 (UTC)
    • Found a more informed explanation, directly from an implementing ISP, referenced at The Nock Blog. There is no dependency on DNS - the "suspicious" list provided to ISPs is of IP addresses only, and the ISPs routers handle re-routing traffic to the proxy. The three conditions are effectively the same. Mr. Bene (talk) 08:07, 8 December 2008 (UTC)

Mr. Bene, good effort, however it is however incorrect! The self-appointed IWF provide their list of naughty URLs (which are low-quality, badly formatted, and might include things like PHP_SESSION_IDs making them ineffectual). To [try to] avoid blocking content on shared hosting systems, specific /32 routes are inserted by the ISPs into their networks to move traffic to suspect IPs to a transparent proxy. The transparent proxy then looks at the host: www.example.com and GET /some/where ... headers and either regenerates the request, or returns a 403/fake 404/warning: blocked message. Think of the IP redirect as a fast hash, and the naughty list as the fine-grained filter. —Sladen (talk) 08:48, 8 December 2008 (UTC)

It doesn't look like there's a set of IWF maintained proxies, or that "your request is passed to the IWF proxies", but indeed that the ISPs are running proxies of their own, with a list of URLs and possibly IWF provided software. The configuration seems to differ however, since people have reported different 404 messages, ISP statements of the situation, outright closed connections or inconsistent blocking of the two pages. So people who experience performance issues should blame their ISP's implementation of the filtering, where the added load of all Wikimedia sites is probably considerable. --Ticram (talk) 09:02, 8 December 2008 (UTC)

BBC: "I've also spoken to one of the ISPs which is blocking the Wikipedia page. A spokesman made it clear that the process was automatic - the ISP just takes the list and implements its own blocking procedures."

See also [9] and Cleanfeed (content blocking system) (that article definitely needs some work, though). Regards, HaeB (talk) 08:52, 8 December 2008 (UTC)

Re:Cleanfeed and the IWF - according to this article [10] it is possible (for people who know anawful lot more about computing than most of us) to find out what is on the IWF list. DuncanHill (talk) 10:58, 8 December 2008 (UTC)

DuncanHill, the Guardian article mangles the meaning of the results of Richard Clayton's research (7.6.2, p. 140 of [11]). One can determine the IP addresses of hosts that are on the IWF 'suspect list', but those hosts may host multiple entirely separate websites. Thankfully, there appears to be no way to determine what those sites may be, nor the paths to offending material within those sites.

"Maybe". ...At least one ISP appeared to have a (badly secured) proxy-server that allowed accesses to cache_object: URIs, detailing the contents of the proxy's DNS cache (the actual URLs accessed/blocked lately) and other information. —Sladen (talk) 04:05, 13 December 2008 (UTC)

[edit] Access to the CleanFeed list

I went googling a bit and a I found this item on how PlusNet implements the IWF filtering [12] [13]. I guess some of you will find it interesting (ie they don't have an easy access to the full list, and don't plan to tamper it even if they disagree). -- lucasbfr ^talk 13:28, 8 December 2008 (UTC)

Yep, there is this stunt where ISPs think they can evade legal liability if they contractually obligate themselves to not know what is on the list and to not make exceptions. I hope some court eventually rules on it and tells them that the court is not amused by such stunts. All the more reason to complain to your ISP. You break their "we can't be at fault because we don't know about it" by telling them about blocks which have impacted you. --Gmaxwell (talk) 16:25, 8 December 2008 (UTC)

Swamp IWF with Freedom of Information Act 2000 requests. As they seem to see themselves fit to decide what is or isn't suitable for discerning adults to see, they are effectively fulfilling a public function. The Department of Constitutional Affairs has guidance on this somewhere that states that bodies which aren't strictly public authorities but do fulfil a public function are subject to it. The worst that happens is that they get bogged down in correspondence. 217.33.218.200 (talk) 17:33, 9 December 2008 (UTC)

The IWF is not a public body listed in Schedule 1 of the FoI act, neither as originally listed in the act nor the current version on the DCA website, and therefore is not covered by it. This is because it is effectively a charity funded by the ISPs, not a public body funded by the government. Modest Genius ^talk 20:22, 9 December 2008 (UTC)

[edit] Technical presentation about CleanFeed

A technical, in-depth presentation about CleanFeed functioning and countries implementing it is available here. Slideshare permits downloads of the presentation as PDFs.

[edit] Eclipse

For the article, Eclipse Internet return these http response headers:

Server: squid/2.6.STABLE15
Date: Mon, 08 Dec 2008 09:19:52 GMT
Content-Type: text/html
Content-Length: 304
Expires: Mon, 08 Dec 2008 09:19:52 GMT
X-Squid-Error: ERR_ACCESS_DENIED 0
X-Cache: MISS from wensleydale.karoo.lan
Via: 1.0 wensleydale.karoo.lan:3128 (squid/2.6.STABLE15)
Connection: close

403 Forbidden

and a page containing the text:

HTTP Error 404
404 Not Found

The Web server cannot find the file or script you asked for.
Please check the URL to ensure that the path is correct.

Please contact the server's administrator if this problem persist

Note the disparity between these two.

[edit] Filter IPs unblocked (to editing)

I have unblocked all of the blocked transparent proxies. Some were no longer a problem, due to the XFF headers, and all the rest seem to be inactive now, with the exception of 89.167.221.3 and 62.24.251.240. I may have to reblock those. Prodego ^talk 17:21, 10 December 2008 (UTC)

I reblocked .240. The others seem ok. Prodego ^talk 17:26, 10 December 2008 (UTC)

BT was fine yesterday but now seems to be back to routing thru 194.72.9.25, which has been blocked again this afternoon. The Virgin Killer article is back to a 404 error message.--Newentry8 (talk) 16:29, 12 December 2008 (UTC)

[edit] New news??

As you may be aware, the block is still in place. Does anyone have any new news about this?? Or perhaps suggest means of contacting BT within the UK (rather than via Tech. Support in Bangalore)?? (Kreb (talk) 16:30, 13 December 2008 (UTC))

• As of 12:30 15 Dec 08 (UK time) I'm now OK again through BT (no block, no rerouting through 194.72.9.25). 86.150.100.97 (talk) 12:43, 15 December 2008 (UTC).

• BT may be marked as resolved if this is the case. TalkTalk is still rerouting through just two proxies, causing high levels of HTTP 404 messages and a block due to vandalism from one of the IPs involved. Some pressure from TalkTalk customers may be needed here.--♦IanMacM♦ ^{(talk to me)} 13:05, 15 December 2008 (UTC)

[edit] Filter IPs still active

[edit] How to check if you are being proxied when visiting Wikipedia

• Visit a site that reads your IP address, eg showip.net.
• Log out from Wikipedia if you are logged in, and go to Special:MyTalk. This shows how your IP address is appearing at Wikipedia.
• If the two IP addresses given do not match, then your Internet service provider is probably still proxying the connection to Wikipedia.

Please contact your ISP's help desk if this is occurring.

[edit] See also

• Virgin Killer
• Internet Watch Foundation and Wikipedia
• Internet Watch Foundation
• WP:NOTCENSORED
• Internet service provider

[edit] References

[edit] External links

• Internet Watch Foundation
• Open Rights Group

Quicklinks:

7.2 Technical presentation about CleanFeed