Jump to content

Wikipedia talk:WikiProject on open proxies: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
SineBot (talk | contribs)
Bots
2,550,614 edits
m Signing comment by 2401:C900:1301:55:0:0:0:9 - "→‎Åben proxy: "
Line 405: Line 405:


Another missed proxy. <small class="autosigned">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/2401:C900:1301:55:0:0:0:9|2401:C900:1301:55:0:0:0:9]] ([[User talk:2401:C900:1301:55:0:0:0:9|talk]]) 22:57, 20 December 2015 (UTC)</small><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->
Another missed proxy. <small class="autosigned">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/2401:C900:1301:55:0:0:0:9|2401:C900:1301:55:0:0:0:9]] ([[User talk:2401:C900:1301:55:0:0:0:9|talk]]) 22:57, 20 December 2015 (UTC)</small><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->

Here. These all are hosted by [[f-secure]], some finnish avg company. It is true, there are many. if abuse occurs, probably should be reported to them and isp.

Revision as of 23:05, 20 December 2015

Shortcut

Mass project change proposal

Hey everyone, I've been looking around at the format of this project and it's not really running all that well. (in a flow/administrative point, not with the users), so I've got a few changes listed below and want to hear your opinions on them.

  • Archiving of the results and the standard request layout seems to be pretty arbitrary when we need one for open, one for closed, one for x...and it goes on. What if we just go to the standard archive style that boards like ANI have. It would create a better timeline and wouldn't need an arbitrary template to archive it to a section, we could just use {{proxycheckstatus|closed}}.
    • Including remerging of all the old results (I would sign up to do this task if no one else wants it).
Not doing...excessive list...
  • Requirements for proxy checks are pretty relaxed, making one I saw come in today pretty out there. What if we create the following requirements to list:
  • IP is requesting unblock.
  • IP is possibly a dedicated server (please bring such evidence at the time of posting)
  • IP has been used in a group of several other abusive IPs, but doesn't geolocate to the same area.
  • Per checkuser or SPI Clerk request or in relation to abusing multiple accounts.
  • There is specific evidence that a proxy may be involved. (Please see the "Not valid reasons section)
  • And a reasons not to request a proxy check (alone or together):
  • 1 offender vandalism
  • Being Blacklisted (on 1 or 10 different sites)
Note: I could just be overreacting on the need for this, but it just saves us time on checks that do already take a few minutes.
  • Revamp the verified users list. Any user on the list could add or request to add (because of the admin protection) another user, in a vouching form. Also create an inactive users section (if it's not already there) so that we don't "lose" anyone in a sense.
  • Wikipedia:WikiProject on open proxies seems to be an arbitrary name also. Maybe time for a rename with all this proposed change? Maybe even moving out of Wikiproject status?
  • Revamp the mainpage to look more visually appealing.

Comments? -- DQ (t) (e) 12:22, 6 December 2011 (UTC)[reply]

Hello. Some comments:
  • Suggestions for revamps or renames are always welcome, though I'm not particularly bothered by the WikiProject label. It seems relevant.
  • Archiving may as well go sequentially instead of by status. The only useful thing about the archives is that there are sometimes backlinks from IP talk pages (thanks for volunteering!).
  • Unnecessary reports are not a particular problem on this page, and I am not in favour of introducing restrictions for reporting them. Perhaps the instructions could be elaborated a bit, but it seems to me most people end up on this page for the right reasons, even if they're wrong.
  • Vouching (as well as an element of volunteering) for the verified users list is how it currently works. Requests for additions are simply rare. I have outlined some of the process at Wikipedia:WikiProject on open proxies/verification, but it don't see how any proposal would differ much.
-- zzuuzz (talk) 13:27, 6 December 2011 (UTC)[reply]
I think stuffing everything archived in a sequential list would be fine. The old way worked for a long time, but I agree with zzuuzz that there's not any particular reason to keep it. Speaking of changes, one that I contemplated but wanted others' thoughts on was adding noindex to the unchecked and requestunblock subpages. My justification for doing so is that Google seems to index us fairly quickly, and it makes proxy checking easier if our pages don't come up in google search results when checking proxies. I think it's not a problem for people to report things here that wind up being obviously not proxies, because that's the best way for them to actually learn what makes a proxy. In fact, I would argue that this venue isn't as well known as it should be. Sailsbystars (talk) 14:07, 6 December 2011 (UTC)[reply]
Ok. Scratch the requirements, we'll just see if we can explain it better. Zzuuzz, ok the one column for 'notes' seems to be a little vague on the verified checkers list. Can we maybe change that to something a little more appropriate? Maybe like user right? and who shall I consider inactive? The name, I don't have a particular proposal for yet...so we'll hold on that. Sailbystars, I agree with your noindex comment, but we'll wait for Zzuuzz to comment on that before I fire it in. -- DQ (t) (e) 22:53, 8 December 2011 (UTC)[reply]
Noindex makes sense to me. Verified users: they are all inactive around here, as far as I can tell, apart from us three. The list was last cleaned out 2½ years ago; there's a few diffs in the history showing how it was done last time. I am not immediately concerned about that column for active users as there will be nothing left in it. However, fill your boots. -- zzuuzz (talk) 23:13, 8 December 2011 (UTC)[reply]

Blocking of Webhosts

Amalthea was bringing up on the mainpage a question about why we block webhosts and how it fits under WP:PREVENTATIVE. I realize what I quoted was a misstep on wording, but my idea behind it is that were preventing abuse by sockpuppets most of the time that are going to come (for rangeblocks). Also webhosts have a seperate IP for a website, and if someone used this instead of their home IP, they are trying to evade detection and could be a reason why we don't find socks. Then there is also the spamming that comes from webhosts that are left unblocked or have a short duration. For all the rangeblocks currently in place, see Wikipedia:Database reports/Range blocks, there are webhost blocks there. Is there a better way to explain this? -- DQ (ʞlɐʇ) 21:26, 25 January 2012 (UTC)[reply]

While a small number of webhosts might have legitimate proxy servers... seeing abusive edits from a webhost is often a sign that the server farm has been compromised - so if we get abusive edits from IPs belonging to a webhost (especially more than one IP belonging to the same webhost), it isn't unreasonable to block the entire range belonging to that webhost.. --Versageek 21:43, 25 January 2012 (UTC)[reply]
I wouldn't dispute that of course, if the whole range is used for vandalism there is no question.
My question was whether we generally block IP ranges belonging to web hosters as a preventative measure, like we do with an open proxies, even if there never was vandalism. Amalthea 16:33, 26 January 2012 (UTC)[reply]
It has been done in the past, but I'd agree with you that it's not definitively preventative and blocking the whole range tends to cause collateral. Re: DeltaQuad, when you say "if someone used this instead of their home IP, they are trying to evade detection" I think you should say they may be trying to evade detection (obviously, it depends on the editor's behavior). I edit through my dedicated server about 80% of the time, because I'm on an insecure or a monitored network, and if I wasn't an admin I wouldn't be able to (without an IP block exemption as an editor) because my server host's whole range is blocked. — madman 16:40, 26 January 2012 (UTC)[reply]
@Amalthea - I actually usually do wait till it's brought up because of one reason or another, mostly socking or vandalism to block (like one the other day I blocked to help flush out a sock).
@Madman - yes you caught me in my English :) And I'm not saying there shouldn't be exemptions (hence IPBE) for legitimate editors like you. -- DQ (ʞlɐʇ) 23:08, 27 January 2012 (UTC)[reply]
Right. I'm just saying that I hope other admins are also only blocking upon socking/vandalism (though I've observed this isn't always the case) and that they're considering reasonable time ranges on their blocks (instead of indefinite blocks) so legitimate users aren't collaterally blocked long after the original offender got bored and wandered away. — madman 00:42, 28 January 2012 (UTC)[reply]

← I still don't quite get it. Is it consensus opinion that static IPs belonging to a webhost should be blocked without problematic edits coming from them? Cause blocking the whole range if one static IP is editing disruptively is still doing just that. Amalthea 12:27, 30 January 2012 (UTC)[reply]

I can't say, as I haven't been involved in any consensus discussions thus far and I'm sure consensus has changed in the time I've been away. But it's my opinion that that should not be the case (especially as you phrase it) and if that is consensus, it may be time to seek new consensus at WP:AN or WT:Blocking policy. I appreciate the concerns that we could be preventing whole ranges of open proxies to edit, but I haven't seen any indication that that's actually the case. — madman 16:53, 30 January 2012 (UTC)[reply]
I don't think we should pre-emptively block webhosts in one sense, but wide rangeblocks are often a necessary evil in order to block open proxies and keep them blocked. So we don't pro-actively look for webhosts to block, nor do we block an ip that edits solely for being a webhost. However, if an ip from a hosting provider turns out to be a proxy, then the whole range should be blocked from editing because a.) the proxy may be reassigned to a different host b.) where there's one, there are usually others (although the rangeblock can and will be narrowed to a subset of a hosting provider's IPs if there are constructive contributions from that provider). Keeping open proxies from editting is an uphill battle, but the rangeblocks are a highly effective tool. Whenever I've discovered a new proxy family, usually half or more of its proxy servers are already blocked thanks to the long-term rangeblocks on webhosts found to contain other proxies. If we didn't block these ranges, we would make it vastly easier for unwanted contributions to find there way on to wikipedia via open proxy. However, this is merely my opinion (although I think it's shared by all of those who are active on these pages) and not one for which I'm not sure consensus has ever been obtained from the general community, so if one wanted a discussion on AN or an RFC, I would not object, although I will not be able to actively participate in the next month or so. Sailsbystars (talk) 20:22, 30 January 2012 (UTC)[reply]
Open proxies would still be a special case of this wider question. The unblock request that spawned this discussion came from 216.17.107.51 (talk · contribs · WHOIS), where 216.17.104.0/21 had been indef range blocked (ACB) for the past 4.5 years, and is now blocked again for one more year. Should that range remain blocked with the sole reasoning that it is assigned to a hosting company and has no business editing?
Regarding your reasoning what may make range blocks in this context appropriate, a rented (virtual) server from a company like https://www.amerinoc.com doesn't simply get reassigned to a new IP, that would make it hard to use it as intended. As a customer you'd typically have to rent a new one to get a new IP. And in case of an open proxy, while there are sometimes further ones in the IP neighborhood, I would not at all say that this is "usually" the case. Certainly not for a whole /21.
And FWIW, I was only thinking of implicit consensus or even just what current practice is, I'm not at all asking for anything formal.
Amalthea 20:56, 30 January 2012 (UTC)[reply]
So with regard to the specific case you've pointed out, standard practice has not been to do indef. rangeblocks, but rather blocks of up to five years, at least as long as I've been on the project, in order to automatically give such ranges a second chance. I can't find any active proxies on the range or the specific IP at the moment so dropping the block might make sense (the indef was certainly overkill). However, at the first sign of another proxy, the rangeblock would be restored. Your point about dynamicism is a fair one, but proxy providers may purchase multiple servers on the same block, or alternately, may have compromised multiple servers running the same software from the same company. If you want to see my thinking in action on how to deal with several different types of hosting ranges, this would be a good example. Also, a /21 from a webhosting provider isn't really that big of a range, as based on a quick experiment I did [1]it would have the equivalent number of contributors to a /28 from an ISP. Sailsbystars (talk) 22:06, 30 January 2012 (UTC)[reply]
@Amalthea: You could have reminded me that I missed the factor about it being clear for two years of edits period. I dropped the block waiting for a new vandal to use it. But I think I should look over my webhost blocks and see if I can nuke off a few...but I don't have that kind of free time. I wouldn't mention all the millions of other IPs that are currently indef blocked by other admins... -- DQ (ʞlɐʇ) 02:26, 2 February 2012 (UTC)[reply]
I'm not sure what you mean, what two years? The range had been blocked for 4.5 years, and that was mentioned on the request page? Amalthea 11:30, 2 February 2012 (UTC)[reply]

I am the most active proxy blocker in Russian Wikipedia and I block any webhost range for 5 years as soon as I see one (using text from Template:OpenProxyBlock before it was replaced with redirect). There are just too many proxies there and for legitimate uses there is WP:IP block exemption. Just a few examples that are usable on enwiki right now (through certain FF extension): 108.59.4.203 / 108.59.4.202 / 108.59.4.206 (leaseweb.us), 46.21.145.170 / 149.255.38.228 / 149.154.154.32 (hosthatch.com), 31.193.133.161 (Simply Transit). — AlexSm 19:26, 21 February 2012 (UTC)[reply]

After now having witnessed two webhost ranges with quite extensive abuse I have to rethink my prior statements here ... Amalthea 20:22, 7 March 2012 (UTC)[reply]

Say, if anyone's looking for a great example of duckish webhost behavior (unconstructive edits that are more than run-of-the-mill vandalism) that indicates a proxy even though the exact mechanism is obscure, this would be a good one. (Although Alex says it is provable?) Sailsbystars (talk) 05:22, 9 March 2012 (UTC)[reply]

Tunnel proxies

I encounter more and more of "tunnel proxies" - in short, a proxy at IP xxx.xxx.xxx.xxx:port exiting at IP yyy.yyy.yyy.yyy. They are often volatile, with either x or y addresses changing within a month, and the y address is often a regular ISP. While the x address is usually Googleable, the y address is usually not, and this is a problem wiki-wise, as we start looking from the y end. Hash.es is helpful, but not always. A suspicion is that y is a result of a virus propagated by the owner of x. Does anyone have any information/links on this kind of proxies? Materialscientist (talk) 04:57, 7 February 2012 (UTC)[reply]

Per Wikipedia:WikiProject on open proxies#110.34.4.242, it seems most likely that these are infected/zombie computers. They can be used as a proxy, and traffic from them is routed as with any other customer of their ISP. — madman 02:49, 8 February 2012 (UTC)[reply]
I'll explain my concerns. Imagine this: a proxy injects trojans via some website/emails, then uses the infected PCs as exit ports, changing the entrance IP if it gets hit by the ISP. We go from the exit IP and can't see if it is a web or http proxy (unless someone nice identifies the entry:port for us :-). Thus if an infected PC falls within a web hosting range, we'd likely block that range, hard, per Google echoes, even if we don't actually locate the exact mechanism. Now imagine the proxy is run by a dedicated WP vandal. This is only to say that it would be nice to have more tools/information on such proxies. Materialscientist (talk) 03:27, 8 February 2012 (UTC)[reply]

Tor policy

I've started a discussion at Wikipedia talk:WikiProject on open proxies/Tor about the propriety of this idea. --Chris (talk) 16:34, 8 February 2012 (UTC)[reply]

http://www.wildtunnel.com/

This tunnel open proxy site (HTTP, port 80) offers a new IP address every day to its users, many of which (in my experience) are not blocked here. --He to Hecuba (talk) 16:55, 18 February 2012 (UTC)[reply]

Thanks. I've asked whether ProcseeBot can keep it blocked. Amalthea 21:26, 18 February 2012 (UTC)[reply]

unblocking

I see that the unblock subpage has been marked historical, but there's nothing there explaining what to do instead, so I'm posting this here. 24.184.232.55 (talk · contribs) has been blocked since July 2007, and a user there has requested unblock. Could it be checked out to see if it still an active open proxy? Beeblebrox (talk) 20:30, 25 March 2012 (UTC)[reply]

Was indefed back then, Google finds it on proxy lists back then, but it's no longer open on that port, so I unblocked it. Amalthea 20:38, 25 March 2012 (UTC)[reply]

Archiving bot

Could someone who knows how such things work get the requests archived by bot again? Thanks. -- zzuuzz (talk) 18:16, 13 April 2012 (UTC)[reply]

I'll code up one this week since I don't trust other bots to do it. -- DQ (ʞlɐʇ) 01:13, 25 April 2012 (UTC)[reply]

Lol

Geolocating tools are getting better and better: "country: anonymous Proxy". Materialscientist (talk) 10:29, 15 April 2012 (UTC)[reply]

Setting an edit filter for potential open proxies

Have a look here. Materialscientist (talk) 06:37, 10 May 2012 (UTC)[reply]

Testing an open proxy

Hi, I use http://proxy.org/ to get open proxies that are not recognized by wikipedia. Currently I use https://zacebook.com/ for editing this. You can just test it (it should be blocked!). 37.220.1.234 (talk) 22:30, 17 May 2012 (UTC)[reply]

Thanks, blocked 37.220.0.0/19. Materialscientist (talk) 22:38, 17 May 2012 (UTC)[reply]

IPv6 proxies?

See Wikipedia:Administrators'_noticeboard/Incidents#Blocking_IPv6s. In particular, 2607:F358:1:FED5:22:61B0:6B0A:BFC8 (talk · contribs), 2001:41D0:2:F3B8:0:0:0:15 (talk · contribs) appear as open proxies, as judged by addition of %2 symbols in their edits, but maybe it is just IPv6 misconfiguration? Materialscientist (talk) 06:39, 7 June 2012 (UTC)[reply]

No, IPv6 misconfiguration wouldn't cause that kind of URL encoding; that's pretty good evidence of a Web proxy, as is the changing of http to https (to avoid certain firewalls and Web filters). I have blocked 2607:F358:1:FED5::/64 and 2001:41D0:2:F3B8::/64 as Web hosting providers (FranTech Solutions and OVH, respectively). The former is actually a /48 range and the latter a /40, but MediaWiki won't allow us to block ranges that big. I can understand why (the OVH range covers some 79 octillion potential hosts, if my math is correct, and it's probably not), but that might need to be changed in the future, because ranges that big are being assigned. — madman 13:19, 7 June 2012 (UTC)[reply]
Interesting, but I must log off :-(. Have a look at 2607:F0D0:1003:B3:0:0:0:20 (talk · contribs) if you have time. Thanks. Materialscientist (talk) 13:29, 7 June 2012 (UTC)[reply]
Similarly blocked. — madman 14:02, 7 June 2012 (UTC)[reply]
Ughh, this is going to have be done on a duck basis for the most part for a while. Neither the latest versions of firefox nor chrome will treat ipv6 addresses as urls (so no looking for web proxies easily).... and standard tools like nmap require special flags to use with IPv6 too..... oy what a pain.... Sailsbystars (talk) 14:29, 7 June 2012 (UTC)[reply]
Actually, Firefox and Chrome both support IPv6 to the best of my knowledge. When you type in an IPv6 address, it's supposed to treat it as a URL (what else would it do?). But if you don't have IPv6 connectivity, you won't see the Web site at that address (and thus the Web proxy). I feel your pain; I don't have IPv6 connectivity either but I'm going to have to work on that. — madman 15:01, 7 June 2012 (UTC)[reply]
When I tried to type the above proxy ips into chrome or firefox, they both just went to a google search on the IP, rather than an error or attempting to load a webpage. I must not have the IPv6 connectivity, because I also couldn't ssh from my laptop to desktop using their respective ipv6 addys given by ifconfig.... which I now see are apparently all default addresses (fe80::).... Sailsbystars (talk) 15:47, 7 June 2012 (UTC)[reply]
Sounds like you don't have IPv6 connectivity, indeed. You can check here. If you want IPv6 connectivity to check these things out and your ISP won't yet provide it, you can do what I do at home and use the Hurricane Electric Free IPv6 Tunnel Broker. — madman 16:00, 7 June 2012 (UTC)[reply]

I now have full IPv6 connectivity and can test IPv6 proxies. Sailsbystars, you were correct in saying that by default Google Chrome does not do IPv6 DNS lookups; instructions to enable them are here. Cheers! — madman 14:20, 8 June 2012 (UTC)[reply]

That's if you have an older version, my version seems to have it on by default without an option to turn it off.--Jasper Deng (talk) 17:18, 8 June 2012 (UTC)[reply]
Oh, interesting. And I've just learned in getting IPv6 that Sailsbystars, the reason you get a Google Search when you put the IPv6 address directly in the address bar is that the standard way to do it is http://[address]:port. I should have figured that, as otherwise an address such as ::1 is interpreted as port 1 on :, which is an invalid address. Cheers, — madman 23:10, 9 June 2012 (UTC)[reply]
Yeah, I figured the bracket bit out... that trick should probably be added to our documentation somewhere. Also mention the necessity of installing miredo on linux boxen if there's not native ipv6 support on one's network. One other interesting ipv6 "feature" I've discovered is that even though I now can browse ipv6 addresses via teredo, websites with dual-stack dns entries default to connect via ipv4 and trying to change this default is a pain in the tuchus (I wasn't able to do it). Cheers, Sailsbystars (talk) 01:58, 10 June 2012 (UTC)[reply]
You'll have to make sure you also have an IPv6 DNS server set for your connection.--Jasper Deng (talk) 19:32, 24 October 2012 (UTC)[reply]

Teredo tunneling in general

Is Wikipedia blocking editing from 2001::/32? Tijfo098 (talk) 13:19, 19 October 2012 (UTC)[reply]

Not the whole range, but specific addresses and/or subranges may of course be blocked from time to time.--Jasper Deng (talk) 19:31, 24 October 2012 (UTC)[reply]

I'm down with it

We actually have a blue link for WP:OPP?  ;-) TCO (talk) 02:46, 24 February 2013 (UTC)[reply]

Sure, once you learn how to make links you can name them Anything You Want - case in point ;) draeath (talk) 18:57, 2 July 2013 (UTC)[reply]

VisualEditor is coming

The WP:VisualEditor is designed to let people edit without needing to learn wikitext syntax. The articles will look (nearly) the same in the new edit "window" as when you read them (aka WYSIWYG), and changes will show up as you type them, very much like writing a document in a modern word processor. The devs currently expect to deploy the VisualEditor as the new site-wide default editing system in early July 2013.

About 2,000 editors have tried out this early test version so far, and feedback overall has been positive. Right now, the VisualEditor is available only to registered users who opt-in, and it's a bit slow and limited in features. You can do all the basic things like writing or changing sentences, creating or changing section headings, and editing simple bulleted lists. It currently can't either add or remove templates (like fact tags), ref tags, images, categories, or tables (and it will not be turned on for new users until common reference styles and citation templates are supported). These more complex features are being worked on, and the code will be updated as things are worked out. Also, right now you can only use it for articles and user pages. When it's deployed in July, the old editor will still be available and, in fact, the old edit window will be the only option for talk pages (I believe that WP:Notifications (aka Echo) is ultimately supposed to deal with talk pages).

The developers are asking editors like you to join the alpha testing for the VisualEditor. Please go to Special:Preferences#mw-prefsection-editing and tick the box at the end of the page, where it says "Enable VisualEditor (only in the main namespace and the User namespace)". Save the preferences, and then try fixing a few typos or copyediting a few articles by using the new "Edit" tab instead of the section [Edit] buttons or the old editing window (which will still be present and still work for you, but which will be renamed "Edit source"). Fix a typo or make some changes, and then click the 'save and review' button (at the top of the page). See what works and what doesn't. We really need people who will try this out on 10 or 15 pages and then leave a note Wikipedia:VisualEditor/Feedback about their experiences, especially if something mission-critical isn't working and doesn't seem to be on anyone's radar.

Also, if any of you are involved in template maintenance or documentation about how to edit pages, the VisualEditor will require some extra attention. The devs want to incorporate things like citation templates directly into the editor, which means that they need to know what information goes in which fields. Obviously, the screenshots and instructions for basic editing will need to be completely updated. The old edit window is not going away, so help pages will likely need to cover both the old and the new.

If you have questions and can't find a better place to ask them, then please feel free to leave a message on my user talk page, and perhaps together we'll be able to figure it out. WhatamIdoing (talk) 01:11, 7 May 2013 (UTC)[reply]

Correction: Talk pages are being replaced by mw:Flow, not by Notifications/Echo. This may happen even sooner than the VisualEditor. WhatamIdoing (talk) 14:43, 7 May 2013 (UTC)[reply]

203.81.67.254, 203.81.67.249, and other hosts in Myanmar

Could somebody add something to zzuuzz’s posting at WP:Administrators' noticeboard/Incidents #Uninvolved review requested? Incnis Mrsi (talk) 18:38, 20 July 2013 (UTC)[reply]

I'll have a look..... Sailsbystars (talk) 19:31, 20 July 2013 (UTC)[reply]

IP 198.211.103.38 and other "open VPN" IPs

I wasn't sure whether to raise this here or elsewhere (where?). The host name for this IP indicates a VPN services provider. Does this mean that this editor is probably using VPN access via the named VPN service and the server should be treated like an open or anonymizing proxy? It looks as if this IP was used by a known community-banned sockmaster who does everything to evade the ban. Since the sockmaster is known to have created quite a few accounts and is learning from each sockpuppet investigation how to better avoid undeniable detection, it would be helpful if one could infer that the sockmaster concerned uses VPN access to conceal his location from checkusers (e.g. by a sockmaster in England appearing to be accessing Wikipedia from America).

This IP was also reported as a VPN-using vandalizer on the Administrators' noticeboard of French Wikipedia, here

  • (collapsed IP du deuxième VPN under heading "Blocage définitif"), following the text
  • "Les IP de ce VPN sont plus diversifiées et souvent mal identifiées, c'est plus compliqué à bloquer que les grosses plages de l'autre mais le VPN est quasi ouvert, il suffit de s'enregistrer avec une adresse e-mail pour avoir accès à toutes ces IP, j'en ai détecté 76 "
  • (The IPs of this VPN are more diverse and often not well identified; it is more complicated to block them than the large range of the other one but the VPN is quasi open, it is sufficient to register with an e-mail address to have access to all these IPs; I detected 76 of them).

The following IPs (collapsed) were therefore all blocked for 1 year as open proxies by French admin Akeron.

Detected IPs of known "open" VPN

Perhaps these IPs should also be blocked as open proxies on en Wikipedia as well. About 25 of them have already edited on en Wikipedia. Of the above IPs, the contributions of the following suggest that they may have also been made by the ban-evading sockmaster:

--Boson (talk) 00:00, 16 September 2013 (UTC)[reply]

Proposal to unblock indeffed IPs en masse

There is currently a proposal at AN which states "Any indefinitely blocked IP address whose block was made over five years ago, may be immediately unblocked." Discussion is here.
 — Berean Hunter (talk) 17:59, 19 December 2013 (UTC)[reply]

Review of indeffed IPs

OK, so that didn't work. I've done some sifting of the block logs and we can divide the IPs into the following:

Feel free to format the lists and start reviewing :) -- zzuuzz (talk) 07:57, 23 December 2013 (UTC)[reply]

If we're talking about 20,000 blocks, wouldn't it be easier to have a bot run through and generate a list of IPs that are putatively no longer open proxies / web hosts? Someguy1221 (talk) 09:05, 23 December 2013 (UTC)[reply]
This is not so easy to do. However it would be desirable use scripts to split them into lists of IPs which are range- or global-blocked, as well as dynamic IPs. There are about 1000 which have details (even if some of them are vague) to check, but the details may have changed while the proxy remains open so they would still require some other full check. -- zzuuzz (talk) 09:25, 23 December 2013 (UTC)[reply]
  • What are you opposing? This is not a proposal but a request for some teamwork in reviewing these blocks. Obviously unblocking without review (and other things) has been rejected, however there is no reason not to review and if appropriate unblock some of them en masse (instead of individually) after review. I'll quote three of the best indef block reasons I've seen so far (apart from the completely blank ones): "I thought I was done with this?", "{{blocked proxy}}: 5 years", and "If you have to know, my lab is on synthesis of benzoic acid via Grignard reagents". I haven't looked at those blocks in detail yet, but you know some of these blocks really should be reviewed. -- zzuuzz (talk) 07:31, 24 December 2013 (UTC)[reply]
  • I've removed the OTRS blocks from the lists, as they have been reviewed both by OTRS and me, and still look good. I have also removed several other "by request" blocks which still look credible. The miscellaneous list is now down to 240. -- zzuuzz (talk) 12:08, 24 December 2013 (UTC)[reply]
  • Oppose further action. Forum-shop much? This is a new variant: ignore universal consensus, alter the question slightly, then plow ahead with your original plan. Of course, you haven't justified in the slightest the point or purpose of this particular time-wasting exercise, either. --Calton | Talk 12:36, 24 December 2013 (UTC)[reply]
  • Let me quote some long standing policy. "Once closed, the IP address should be unblocked". I have looked at the consensus over the last year or so at the village pump and admin board. Indeed I've been unblocking some of these IP addresses for over five years. There are a lot of indefinitely blocked IP addresses, often outside of policy or under changed circumstances or with insufficient reason. There is nothing wrong with reviewing these blocks. -- zzuuzz (talk) 12:44, 24 December 2013 (UTC)[reply]
Let me quote a long-standing principle: "Wikipedia is not a bureaucracy". So, did you have an ACTUAL answer to "Why?" other than "Because!"? --Calton | Talk 05:42, 26 December 2013 (UTC)[reply]
Reading WP:BURO again, I fail to see how it applies here. However, there are two ways to deal with indefblocked IP addresses. The first option, which I put forward at WP:AN, very simple and lacking any bureaucracy, is to apply current policy/practice to the blocks, and generally limit them to about five years. Don't laugh, this kind of thing has often been suggested in consensus discussions (I'd also put money on any proposal to stop indefinite IP blocks altogether). This first option is so unbureaucratic you could get a bot to do it. It was rejected soundly when put to admins. The second and more bureaucratic option, which involves again applying current policy to the blocks, involves an element of review. With the help of some clever colleagues I'm sure we can efficiently divide off blocks which are more likely to deserve to remain blocked or unblocked, or at least ones where circumstances are likely to have changed or remain unchanged. One may suggest it is bureaucratic to review these blocks at all. You're right and do not have to participate. I have mentioned that this is within policy and that some of the blocks are outside of policy. There is the open proxy policy saying when closed they should be unblocked. We have the blocking policy talking about 'changed circumstances' blocks. We have arbs and checkusers and OTRS helping out magnificently, and a policy saying they are welcome to do it. Appropriately, there is at least one example of another reason for review on this very page. An IP blocked indefinitely years ago requesting unblock. These are common fodder around here - ask any volunteer at UTRS or CAT:RFU (or here). I could go on, but I won't. There is no policy based reason for opposing review. -- zzuuzz (talk) 16:05, 27 December 2013 (UTC)[reply]
  • Support. There exists no logical or policy reason to keep the 20k individual IPs blocked until times end (that is what indefinite means). Some of the IPs in question were blocked over half a decade ago, some never ever edited once and were blocked as a precaution. It is entirely possible that the IPs in question changed hands and may not even refer to the same country or even continent when they were enacted. Also mind that while 20,000 IPs may appear to be a large amount, a single /16 range represents 65,536 IPs. Also mind that we do not indefinitely block IPs even if they are the source of persistent disruption. IPs are given finite block periods which may extend months or years but never the less are finite. So I am curious for what possible reason are my peers opposing to this otherwise routine backlog of forgotten indef blocked IPs? Also for a formatted list of IPs please see m:User:とある白い猫/English Wikipedia open proxy candidates. -- A Certain White Cat chi? 13:12, 24 December 2013 (UTC)
  • I take the view that indefinite blocks are tolerable, if they are kept under review and released when circumstances change. Indefinite is not forever. Policy says as much. Some of these blocks are well outside policy. -- zzuuzz (talk) 14:20, 24 December 2013 (UTC)[reply]
    • We do not indef block casually. We prefer long term blocks even for the most notorious open proxies. Exceptions to this can be made but there should be very good reason to do so. So far no one has presented any reason as to why any single IP should remain blocked. -- A Certain White Cat chi? 15:23, 24 December 2013 (UTC)
      • You're right. However some of these should remain blocked as in the case of the OTRS blocks, which is often accepted as a valid reason in policy. Also, I bet I can prove some of them are still open proxies. -- zzuuzz (talk) 15:35, 24 December 2013 (UTC)[reply]
        • Are you verifying that all 20,000 of these IPs have OTRS verification? I will not acknowledge the claim that these are verifiable through OTRS unless the accompanying block specifies a ticket for it. Even then an indefinite block is unwarranted. A long term - say yearly - block would be in order at best. Such long term blocks would be reviewed every year. -- A Certain White Cat chi? 17:34, 24 December 2013 (UTC)
          • I've removed about 35 OTRS-type blocks from the lists, after being assured about the OTRS ones, and checking the ownership of both them and the other ones. Other blocks I know should probably remain include the famous 'hive of scum and villainy'. -- zzuuzz (talk) 17:41, 24 December 2013 (UTC)[reply]
            • Could you please restore them somewhere so we have a list of IPs and corresponding OTRS tickets? The IPs know they have been blocked but we need a way to keep track on when and why IPs get blocked for a longer term. -- A Certain White Cat chi? 03:42, 25 December 2013 (UTC)
  • Can we stop voting please. The proposal for unblock without review (after five years) was rejected. The case for review has long standing consensus. This review is under way. Fact. What we need are ideas for how best to review them, as well as competent reviews, either way. -- zzuuzz (talk) 13:16, 24 December 2013 (UTC)[reply]
    • The notion of review was also rejected as it would take over several years worth of man hours to check every IP. An open proxy check is non-trivial. This really should be a discussion with checkuser and arbitrator involvement but neither group is bothered to comment. Getting anything done without a lengthy (and ppointless) vote over trivial routine backlog would probably be a novelty... -- A Certain White Cat chi? 15:23, 24 December 2013 (UTC)
      • That reason for rejection is not valid if there are people to do it and enough time. I have asked checkusers to make a review, and arbcom know where to watch. They have no power to force anyone to unblock these IPs, or allow unblocks outside of policy. We can work on the others when better organised. -- zzuuzz (talk) 15:35, 24 December 2013 (UTC)[reply]
        • Problem is there aren't enough people with the technical knowledge to review 20,000 IPs properly even if everyone with the technical capability were willing. I really cant imagine what such a check would benefit all blocks before a certain cut off date, say 1 January 2011 which is from 2 years ago. We can go 3 years to 1 January 2010 if you like. We can unblock and reblock if they cause problems. As far as I can tell this is the best and only viable option at the moment. -- A Certain White Cat chi? 17:34, 24 December 2013 (UTC)
          • Well, it seems "A Certain White Cat" that nothing anyone can do will satisfy you. I did 20 random checks in half an hour tonight and unblocked a few, but some are still listed as "suspected open proxy" - and I was looking at 2004 blocks. It does seem that, at least back in the day, a fair number of "blocked proxies" were educational facilities, which I think can generally be lifted; we don't block those kinds of IPs as open proxies anymore, and haven't for years. Incidentally, I didn't need to use checkuser tools for these random checks; the links at the bottom of the IP userpages were sufficient in most cases, and there are lots of other administrators (and even other users) who can check to see if an IP is an open proxy. There is absolutely no need to involve the Arbitration Committee in this discussion; blocking/unblocking policy is entirely controlled by the community with the small exception of checkuser blocks. Risker (talk) 04:14, 25 December 2013 (UTC)[reply]
            • How much I am satisfied isn't relevant here. This isn't about me. The blocks do not affect me in any way. Please do not try to make this appear like a personal issue when it clearly isn't. This is not a matter of blocking policy. Sysops are very reluctant to want to get involved due to the magnitude of the work. For example a ruling by arbcom may state the following:
              • Acknowledging that there is a need of review of the 20,000+ indefinite blocked IPs that have been forgotten.
              • Asking community to treat indef IP blocks as a last resort and avoid them as much as possible. In practice this is the case but re-emphasis of this cannot hurt.
              • Establishing a cut-off date (say 1 January 2010) where indef blocks prior would be lifted (with exceptions if needed). There are only about 160 indef blocks since 1 January 2010.
            • Any unblocked IP causing problems would be promptly reblocked. The block log is there after all.
            • -- A Certain White Cat chi? 05:43, 25 December 2013 (UTC)
  • Can we stop voting please Nope. You got a universal rejection for your crusade, have failed to make even the most basic case other than pure bureaucracy, and seem to believe that game-playing and forum-shopping will allow you to get around that. That you don't want to hear anything is apparent, but you can't stop people from trying make you listen. --Calton | Talk 05:49, 26 December 2013 (UTC)[reply]
    You're right, I arguably did not introduce the topic properly to those unfamiliar with indefinitely blocking IP addresses. My crusade was a single post mentioning recent discussions (which are by others) but not providing any links. I will provide the links when I get a chance, unless someone else has some handy. There is one current discussion at the arb noticeboard. -- zzuuzz (talk) 17:06, 27 December 2013 (UTC)[reply]
  • Well been away for a bit, but I don't see why anyone can possibly oppose reviewing the blocks, other than out of sheer spite. Whether or not consensus exists for mass unblocking is a moot point, since in either case review should be undertaken to ascertain the current status of the previously blocked IP. I'll join the review effort soon myself. Sailsbystars (talk) 04:30, 27 December 2013 (UTC)[reply]
    • I oppose a review because I think it is a waste of time, that said if someone is willing to do it I would not object. After all it is their time that will be wasted. Please do not assume people want to wreck the project just because I voiced an opinion different from you. There isn't enough reason to indef block known open proxies let alone ancient ones. The IPs can be unblocked 1000 ips per day for example. That way we can transition in about a month and any problem would be more or less contained fairly quickly. -- A Certain White Cat chi? 15:38, 27 December 2013 (UTC)
Fair enough. And please don't take my comment to mean that I oppose mass unblocking outright. There's a fine balance between multiple practices i.e. not indef blocking ips and also not allowing edits from proxies etc. It would never get support, but one interesting possibility would be to take all of the indef blocks and convert them to definite blocks, but with random unblock times say between one month and 3 years. That way if there are still problem IPs, they won't all be unleashed at once and overwhelm the system (aka admins). Sailsbystars (talk) 16:28, 27 December 2013 (UTC)[reply]
I am glad we are more or less saying the same thing then. Might I remind you that we do not indef block known open proxies today. Must I also remind you that open proxies tend to be in ranges and not single IPs. Often "open proxy" means a webhost too. Also mind that open proxies are normally blocked by stewards from meta and local blocks do not make a whole lot of sense.
All but about 160 of them (the ones blocked since 2010) have remained blocked for over 3 years (since before 2010) and it does not make sense to me to convert them to a finite block at this point. Had they been blocked as open proxies today they would get blocks ranging from 6 months to a year under normal circumstances. My belief is that a bulk of these IPs were blocked as a precaution and they were never a problem even back then (when the site wasn't sure how to handle open proxies). It is best to unblock them now so that we can observe weather or not if these IPs are still a problem when our attention is on them rather than delay it another time period where the interest towards them is lost. Unblocking the IPs in groups of 1000 would allow us to observe a more orderly transition taking 21 days to complete. Mind that these IPs can be checked 1000 at a time at the same time too. Any problem with any one of them would be immediately addressed.
-- A Certain White Cat chi? 06:11, 29 December 2013 (UTC)
  • I'd like to hear any suggestions on ways to divide these IPs. I can suggest a few:
  • Global blocked
  • Range blocked
  • Dynamic IPs (we have a list in the archives here, or this can be done automatically)
  • Blocked within policy (no evidence of change of circumstances, mistakes, etc)
  • Blocks with questionable block reasons.
  • IPs with few edits (we can't expect recent edits if they have been blocked), or edits over a short period of time. Alternatively, IPs with lots of edits, or edits over a long period of time.
  • IPs blocked a very long time ago. Five years seems a good time to take a break.
  • Separated by admin, or admin's current activity status
  • Separated into server hosting ranges, educational institutions, etc
  • Arranged by CIDR and compared to others in the range for previous blocks and unblocks
  • Current geolocation. We do not have a history of it. Geolocation has a class called 'anonymous proxy'. We can also make guesses about geolocation near large data centres.
  • Divided into smaller pages if they are to be offered for human review.

There are suggestions currently at WT:ACN we might adopt. So far we have been removing from the lists IPs which have been reviewed. Some have been unblocked. Some have remained blocked. If you wish to know which ones and why see the page history. I hope that at some point you will only find in the Special: pages lists a list of blocks which were reviewed this year (or next year). To see the reason why you need not look far. It is the simplest way to get through a list like this instead of lots of people reading the same things over and over. -- zzuuzz (talk) 09:11, 28 December 2013 (UTC)[reply]

You are under the assumption that such information stays consistent. You need to understand the technical issues involved which prevents such generalizations. Furthermore such identification is hardly a trivial task. Even the act of gathering information on wikimedia databases such as global blocks and range blocks takes effort. I'd like to also note that even if with great effort all above information was indeed gathered for the 20,000 IPs involved, it doesn't begin to compare to the remaining 4,294,947,000 IPs we have practically no information about - and that is just IPv4 ranges. It is very easy to block the IPs back if they cause problems.
Three years is a sufficient break because that is about the time (2010) when the community decided indefinite blocks of IPs was causing more collateral damage than good. This is why in the past 3 years we had fewer than 200 indefinite blocks of IPs and that is including IPv6 ranges. Do you know how many IP blocks we have that last a solid three years?
Reviewing and unblocking (unless there is a reason not to) 1000 IPs per day for the next 21 days is a better way to handle this.
-- A Certain White Cat chi? 06:27, 29 December 2013 (UTC)
Is there an example what "unless there is a reason not to" would look like? My guess is that any systematic "unblock if no reason not to" would mean "unblock all". The community discussions that I noticed have rejected such an approach. Johnuniq (talk) 09:24, 29 December 2013 (UTC)[reply]
I have not seen a community discussion agree we continue indefinite blocks or enact them in the first place. Indefinite blocks of IPs should be decided by the community on a case by case basis. The community was not consulted or even informed of these 20,000 IP blocks as back then such a thing wasn't needed. Today each and every indefinite block should go through a community decision. Whenever this issue is brought up people line up to ask for checks whom do not understand that it would take years to run proper exhaustive checks. There is no reason for such paranoia. Even policies changed in the past 3 years let alone since 2004.
An IP blocked for being an open proxy alone more than 3 years ago would not be a sufficient reason for an indefinite block today. After all, we do not indefinitely block open proxies anymore. A block that is attributed to an OTRS ticket, an RfAR case or a checuser report could however be maintained. The unblocking admins judgement is good enough to me since that all it had taken to block these in the first place. Once the number of blocks are reduced we can review the remaining blocks with greater attention.
-- A Certain White Cat chi? 12:28, 29 December 2013 (UTC)
I'm aware of many many five year schoolblocks, and now see them going up to ten years. I've made ten year rangeblocks myself. These things can remain static this long and I'm sure much longer. I'm also aware of the size of the task of review - I've even calculated how many to do every week to get this done myself within the next four years. I am not proposing an nmap scan, without the -F flag, on each and every blocked proxy, but if we are to have a bunch to present for individual or mass unblock (or even reblock), with or without "the problem ones", I'm sure we can come up with a pick of lists which are relatively easy on the admin digestion. -- zzuuzz (talk) 06:15, 30 December 2013 (UTC)[reply]
I am not a fan of 5 or 10 year blocks but that is a separate matter. Point is none of the long term blocks are to prevent abuse from unknown users, the ranges targeted are well known and the blocks are tracked. Any block longer than a year should have some sort of community approval in my opinion. I am not blaming you. I do not want to give that impression. I just wish there is more structured handling of such long term blocks. But again that is a separate matter I'd rather not indulge here beyond this.
If you could list the type of scans I think it would clarify issues for everybody. The task of scanning the IPs should take no more than 1 month, certainly not 4 years. Perhaps you can list the tools and commands so that multiple people can work on the task distributing the workload. Mind that I am not talking about man hours, I just hope to see this issue resolved by February.
-- A Certain White Cat chi? 14:19, 30 December 2013 (UTC)
I'm at a loss why you think it should only take a month. It might, if every administrator who is active drops whatever they're active on and focuses their attention on this, but the net gain for the project is so minimal compared to other admin-related tasks that I'm really having a hard time trying to justify it. So far, since I started pecking away at this, about 1% of the IPs whose blocks I lifted have needed reblocking. That meant reinvestment of my time, investment of the time of others in addressing the inappropriate editing, and the inevitable frustration felt by active editors when something that appeared "solved" turns out not to be. Risker (talk) 15:30, 30 December 2013 (UTC)[reply]
I have been investing months of my time to bring this issue to the attention of the community. Coordination of efforts is most important for a task of this magnitude. It would be best if we decide on how to handle this task first. We still have not established a standard for these checks for example. If we are going to have checks at all, we must have a minimum standard or else there really is no point to it.
The reason why I suggested an arbitrary 1 month limit is because I just do not see the point of checks that are more detailed than necessary. It shouldn't be too hard to check 1000 IPs a day. That is 100 IPs for 10 people (does not have to be admins) a day for just 21 days.
Alternatively if we unblock 1000 IPs a day, 1% of that would be 10 IPs and 5% of that would be 50 IPs which can be handled by the community. I don't think that would frustrate anyone. Again the task would have to be coordinated. Mind that any RC patroller can watch the 1000 IPs for edits.
-- A Certain White Cat chi? 10:04, 31 December 2013 (UTC)
I'd suggest the miscellaneous list is dealt with first. There aren't that many, and probably not that many blocking admins to notify. If they remain standing and disputed after the admin's been notified, then they can be escalated as appropriate. The checkuser blocks are almost all reviewed. After they're done any indefinite checkuser, OTRS, or 'by request' block still standing will have been reviewed. My advice, and perhaps some policy, is to not undo these blocks. The others will not need scanning. For most of them a simple Google search or whois/rdns lookup will do. There is a guide linked at the bottom of the main project page. However I hate to say this, some of this is not for amateurs. That is why I hope to split them up into something easier to deal with. -- zzuuzz (talk) 10:55, 31 December 2013 (UTC)[reply]
I would propose the good blocks also be converted to lengthy but finite blocks. Particularly per request ones. Indefinite IP blocks should ideally be never used in principle - unless there is a very good reasons for an exception. Even then I would move such blocks to meta for global if possible. -- A Certain White Cat chi? 19:16, 31 December 2013 (UTC)
I believe one of the reasons you are getting resistance to the notion of sending those blocks over to Meta for global blocking is that the intention of global blocking is to block IPs and accounts that have caused (or are likely to cause) problems on more than one project. Absent evidence that this is a genuine risk (and in several of the cases we looked at from a CU perspective, there is no such risk), there's no reason to block the IP globally. Even open proxies are sometimes not blocked globally unless they've been shown to cause problems in more than one place, because some of our projects have a much more liberal perspective on them; in particular, those who have editors in politically repressive countries. (Indeed, the easiest way to get IPBE on enwiki is to send an email to ACC or make an edit that links the user to an IP in one of those countries.) I get what you are saying here, but it's quite inconsiderate to impose an enwiki perspective (and solution to a local problem) on the global Wikimedia community. Risker (talk) 06:57, 1 January 2014 (UTC)[reply]
I agree about the global blocks. These can be handy for spambot attacks, but not so good for long term stuff. Local proxy policy is quite different from other places. In some wikis they technically block all open proxies, but others are not bothered a bit.
One day all (or most) blocks will be finite, but until then the cat and I will probably disagree a bit. My standard for reviewing these blocks, I think, is whether they're good for another five or ten years. I know what an open proxy smells like, and they remain blocked. I also know what a five or ten year block looks like. There is no point converting them to finite blocks imo when you can leave it for someone else, probably a bot, to do later.
I have split the misc list into several others. These would appear easy to review, if you're prepared to offer them somewhere, probably some other page than this, for review. Most should remain standing though, imo, so I wouldn't argue for one year blocks or anything^W. I'd suggest the same method of simply removing them from the same list when reviewed. -- zzuuzz (talk) 07:19, 1 January 2014 (UTC)[reply]
My point is if something needs to be blocked until times end and is a threat to this project, it is most likely a problem for all projects - at least such a consideration should be made depending on the circumstances. Such problems tend to be well known public open proxy service providers of larger companies (such as amazon), spam bots etc that meta already handles quite well - it is possible that meta already blocked those. I am not giving out an order, in practically every statement I mention there can be exceptions depending on circumstances. I cannot acknowledge such circumstances exist until past & present evidence is presented but this really is a matter we will discuss at the end of dealing with all these IPs. I am not pushing for a formal hearing like ArbCom nor a negotiation we barter on. I am not trying to get problem IPs unblocked. If some IP is the source of a problem and if stewards choose not to block it on meta globally, the local block of course would be maintained. To be honest I do not expect us to have too many such IP addresses to deal with. This is one of the reasons why I want to reduce the individual IP blocks to more manageable numbers so that such problematic IPs are brought to greater attention - whatever they may be. -- A Certain White Cat chi? 10:42, 3 January 2014 (UTC)

Discussion on indefinitely blocked IP addresses

Hi, this message is sent to inform you that there is currently a discussion on the Village Pump located at Wikipedia:Village pump (policy)/Archive 112#RFC: Indefinitely blocked IP addresses which may affect the operations of this WikiProject. TeleComNasSprVen (talk • contribs) 20:51, 2 February 2014 (UTC)[reply]

Invitation to User Study

Would you be interested in participating in a user study? We are a team at University of Washington studying methods for finding collaborators within a Wikipedia community. We are looking for volunteers to evaluate a new visualization tool. All you need to do is to prepare for your laptop/desktop, web camera, and speaker for video communication with Google Hangout. We will provide you with a Amazon gift card in appreciation of your time and participation. For more information about this study, please visit our wiki page (http://meta.wikimedia.org/wiki/Research:Finding_a_Collaborator). If you would like to participate in our user study, please send me a message at Wkmaster (talk) 22:35, 24 February 2014 (UTC).[reply]

Leaflet For Wikiproject on open proxies At Wikimania 2014

Hi all,

My name is Adi Khajuria and I am helping out with Wikimania 2014 in London.

One of our initiatives is to create leaflets to increase the discoverability of various wikimedia projects, and showcase the breadth of activity within wikimedia. Any kind of project can have a physical paper leaflet designed - for free - as a tool to help recruit new contributors. These leaflets will be printed at Wikimania 2014, and the designs can be re-used in the future at other events and locations.

This is particularly aimed at highlighting less discoverable but successful projects, e.g:

• Active Wikiprojects: Wikiproject Medicine, WikiProject Video Games, Wikiproject Film

• Tech projects/Tools, which may be looking for either users or developers.

• Less known major projects: Wikinews, Wikidata, Wikivoyage, etc.

• Wiki Loves Parliaments, Wiki Loves Monuments, Wiki Loves ____

• Wikimedia thematic organisations, Wikiwomen’s Collaborative, The Signpost

For more information or to sign up for one for your project, go to:
Project leaflets
Adikhajuria (talk) 12:59, 13 June 2014 (UTC)[reply]

Comment on the WikiProject X proposal

Hello there! As you may already know, most WikiProjects here on Wikipedia struggle to stay active after they've been founded. I believe there is a lot of potential for WikiProjects to facilitate collaboration across subject areas, so I have submitted a grant proposal with the Wikimedia Foundation for the "WikiProject X" project. WikiProject X will study what makes WikiProjects succeed in retaining editors and then design a prototype WikiProject system that will recruit contributors to WikiProjects and help them run effectively. Please review the proposal here and leave feedback. If you have any questions, you can ask on the proposal page or leave a message on my talk page. Thank you for your time! (Also, sorry about the posting mistake earlier. If someone already moved my message to the talk page, feel free to remove this posting.) Harej (talk) 22:47, 1 October 2014 (UTC)[reply]

Google data compression proxies

It looks like Google is operating what are effectively open proxy farms for Chrome mobile users: these do not seem to be on the XFF list. For an example of such a proxy, see this: 66.249.93.191 (talk · contribs · WHOIS). I cannot find any list of these on the web, or any way of deriving that list other than brute-force techniques. See [2], [3] and this talk page for more details. Given that Chrome is a major browser, this could potentially become a major problem if not fixed. (Note: comment also copied to Meta-Wiki talk page) -- The Anome (talk) 17:02, 16 November 2014 (UTC)[reply]

WikiProject X is live!

Hello everyone!

You may have received a message from me earlier asking you to comment on my WikiProject X proposal. The good news is that WikiProject X is now live! In our first phase, we are focusing on research. At this time, we are looking for people to share their experiences with WikiProjects: good, bad, or neutral. We are also looking for WikiProjects that may be interested in trying out new tools and layouts that will make participating easier and projects easier to maintain. If you or your WikiProject are interested, check us out! Note that this is an opt-in program; no WikiProject will be required to change anything against its wishes. Please let me know if you have any questions. Thank you!

Note: To receive additional notifications about WikiProject X on this talk page, please add this page to Wikipedia:WikiProject X/Newsletter. Otherwise, this will be the last notification sent about WikiProject X.

Harej (talk) 16:56, 14 January 2015 (UTC)[reply]

Troll at Reference Desk

There is an anti-LGBT troll who posts at the the Reference Desk talk page, identifying what he or she thinks are the sexual orientations of some of the Reference Desk editors, through various IP addresses that geolocate to all over the world that appear to be open proxies. I will be reporting the addresses being used here. Each time that the troll posts, their posts are reverted, and then the Reference Desk talk page is semi-protected. When the semi-protection expires, the troll comes back, and it is whack-a-mole. Since the addresses are open proxies, they should qualify for long-term blocking because they could be used for other improper purposes also, such as vandalism or spam. Robert McClenon (talk) 17:22, 28 July 2015 (UTC)[reply]

Åben proxy

Det ar en åben proxy. Der må være mere. - Bruger på danske wiki — Preceding unsigned comment added by 2A02:9D0:100:3046:0:0:0:9A (talk) 01:17, 20 December 2015 (UTC)[reply]

Another missed proxy. — Preceding unsigned comment added by 2401:C900:1301:55:0:0:0:9 (talk) 22:57, 20 December 2015 (UTC)[reply]

Here. These all are hosted by f-secure, some finnish avg company. It is true, there are many. if abuse occurs, probably should be reported to them and isp.

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_on_open_proxies&oldid=696102843"