Jump to content

Wikipedia talk:WikiProject on open proxies/Archive 4

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4

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)

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)
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)
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)
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)

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)

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)
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)
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)
@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)
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)

← 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)

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)
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)
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)
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)
@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)
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)

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)

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)

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)

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)

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)
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)

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)

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)

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

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)

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)

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)

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)

Lol

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

Setting an edit filter for potential open proxies

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

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)

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

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)

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)
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)
Similarly blocked. — madman 14:02, 7 June 2012 (UTC)
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)
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)
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)
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)

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)

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)
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)
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)
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)

Teredo tunneling in general

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

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)

I'm down with it

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

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)

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)

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)

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)

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

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)

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)

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)

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)
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)
  • 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)
  • 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)
  • 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)
  • 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)
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)
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)
  • 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)
    • 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)
        • 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)
            • 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)
    • 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)
        • 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)
            • 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)
    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)
  • 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)
    • 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)
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)

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)
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)
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)
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)
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)
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)
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)

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).

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)

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)

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)

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)

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)

Å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)

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

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. — Preceding unsigned comment added by 2401:C900:1001:2E:0:0:0:5 (talk) 23:05, 20 December 2015 (UTC)

Another, was used maliciously. Not surprised. I will stop for now, I don´t want to spam and not sure how helpful I am being. — Preceding unsigned comment added by 2A00:11C0:5:794:0:0:0:6 (talk) 23:10, 20 December 2015 (UTC)

Archive

It doesn't look like the page is getting archived as seen here. --Terra (talk) 21:42, 20 August 2016 (UTC)

Yes, that's a bit of WP:OP humour. Archiving was automatic once upon a time (2009-2011), but there were problems with it. It's currently done manually. Maybe someone would be interested in trying to set it up again. -- zzuuzz (talk) 21:54, 20 August 2016 (UTC)
 Done This should work. Mlpearc (open channel) 22:07, 20 August 2016 (UTC)
Thanks, but it's more the requests page which needs some work (see link above). -- zzuuzz (talk) 22:16, 20 August 2016 (UTC)
@Zzuuzz: OMG :P I'll clean the page out and see if I can get auto-archiving working. Thanx, Mlpearc (open channel) 22:26, 20 August 2016 (UTC)
On closer inspection, this is above my skill set, I believe. Mlpearc (open channel) 22:31, 20 August 2016 (UTC)
Understandable, above many I would think. It's also a bit of a historical mess. -- zzuuzz (talk) 22:33, 20 August 2016 (UTC)

190.10.8.213

An IP tagged 190.10.8.213 (talk · contribs) as an open proxy but that was removed by another editor stating it wasn't currently blocked. It's been blocked on another Wikipedia[4][5]. That's the only evidence that I can find that it's an open proxy. So, do nothing? Doug Weller talk 10:18, 5 November 2016 (UTC)

Judging by the geolocation, the subject matter, the open ports, and the colo ISP, I would say it's a VPN. It doesn't appear 'open', but 'anonymising' almost certainly. -- zzuuzz (talk) 15:39, 5 November 2016 (UTC)
Thanks. So block only for vandalism I guess. Doug Weller talk 11:38, 6 November 2016 (UTC)

Tor or not?

Does the hostname xxxx.tor.primus.ca indicate that it is a Tor node? ☆ Bri (talk) 17:02, 17 August 2017 (UTC)

A more systematic approach

It is very easy to find an unblocked proxy server using one of the myriad services out there. I ran a quick test using one of them, FlyVPN, and found that just half of their IP addresses are blocked (see User:Rentier/VPN_editing). As far as I can tell, services such as this one can identify each of those IPs as a proxy. Has there been any thought given to creating a detection mechanism, say Extension:VPNBlock, similar to the TorBlock extension? Rentier (talk) 02:15, 7 January 2018 (UTC)

This has been proposed before, though I can't remember where at this time. My view is that the accuracy (and quota) provided by free services is usually insufficient. I would want to see some real data showing both false positives and false negatives. -- zzuuzz (talk) 16:42, 7 January 2018 (UTC)
I think free services are a no go for the reasons you mentioned. I'm thinking about paid ones. For example, MaxMind offers a downloadable database (updated daily), which gets rid of the quota problem. I will try to obtain data on the accuracy. The project would need a buy-in from the WMF, of course. Rentier (talk) 19:51, 7 January 2018 (UTC)
I don't think I could do an extension right now - I haven't written a MW extension in years. However, I've written a tool that at least allows you to do one-off queries against a few providers like this. I've had to limit it to certain users due to limits on requests. Feel free to email me if you require access, or would like the source code in order to run your own. SQLQuery me! 03:35, 22 January 2018 (UTC)

ISP Rangefinder

This is something I've generated manually in my own userspace for a long time to block ISP's wholesale (e.g. DigitalOcean, Amazon AWS, Linode, etc). I've made it a tool now. toolforge:isprangefinder. Note that it can take a LONG time to run (1-5 mins). Remember that you are responsible for your own blocks. I've left links to HE and Whois so you can verify my findings. Hope it helps someone else. SQLQuery me! 04:16, 22 July 2018 (UTC)

8/20 update

I've updated the ISP Rangefinder.

  • It now uses whois to verify that the host is still owned by the same org (maxmind's stuff can be a little outdated).
  • It can also (somewhat) find false positives.
  • I've moved the backend from SQLite to MySQL, which has made the tool much faster
  • I've made some backend changes so the tool still will return full results while it's updating

TODO:

Feedback is always appreciated! SQLQuery me! 02:45, 21 August 2018 (UTC)

Is 27.34.50.11 an open proxy

@SQL: I've tried this which doesn't help much although can be very useful, and this[6]. Doug Weller talk 07:40, 16 October 2018 (UTC)

Also [7] who suddenly showed up at Kevin MacDonald (evolutionary psychologist) (edit | talk | history | protect | delete | links | watch | logs | views) (looks like someone logged out as the range, which has quite a bit of vandalism, hasn't edited this article before).Doug Weller talk 07:44, 16 October 2018 (UTC)

Hola VPN Node checker

I've added a Hola VPN Node checker to ipcheck, which is included in the results there - or can be used independently at toollabs:/ipcheck/checkhola.php. I can't really go into the nuts and bolts of how it works per WP:BEANS, but there are two tests run. If either comes up positive - it is very likely to be a hola node. Example 2-confirmation positive: https://tools.wmflabs.org/ipcheck/checkhola.php?ip=198.211.96.91 (also, a webhost / digitalocean). If anyone's interested in the specifics of how it works, feel free to shoot me an email, or pm me on IRC. SQLQuery me! 08:01, 19 November 2018 (UTC)

A new newsletter directory is out!

A new Newsletter directory has been created to replace the old, out-of-date one. If your WikiProject and its taskforces have newsletters (even inactive ones), or if you know of a missing newsletter (including from sister projects like WikiSpecies), please include it in the directory! The template can be a bit tricky, so if you need help, just post the newsletter on the template's talk page and someone will add it for you.

– Sent on behalf of Headbomb. 03:11, 11 April 2019 (UTC)

User:SQL/Non-blocked compute hosts

FYI for anyone interested User:SQL/Non-blocked compute hosts exists, and I've added a link to it from the main page here. SQL and I are the main/only people following it now, but more eyes would always be appreciated. TonyBallioni (talk) 03:27, 11 July 2019 (UTC)

Happy to keep an eye on this though I don’t normally touch hosting providers or data centers. Are they blocked routinely or do we wait for troublesome behaviour from users? --Malcolmxl5 (talk) 11:14, 11 July 2019 (UTC)
Based on the global policy and local one, we usually hard block open proxies once we become aware of them, even if we can’t see visible edits. The main benefit is that it prevents spambots from running and makes life more difficult UPE spammers and other LTAs. SQLBot is now automating the discovery of these ranges, but a human admin implements it to check for false positives, etc. For Azure, Digital Ocean, and AWS, I’ve done enough blocks based on it, that I’m generally comfortable spot-checking a few of the WHOIS reports. For the ones labeled experimental I’m much more cautious in checking the bot. TonyBallioni (talk) 15:12, 11 July 2019 (UTC)

IP Editing: Privacy Enhancement and Abuse Mitigation project

Hello all,

I’m writing to let you know about a new project, IP Editing: Privacy Enhancement and Abuse Mitigation, that the Wikimedia Foundation is starting.

Because people in general are increasingly technically advanced and privacy conscious, our users are now more aware of the collection and use of their personal information, and how its misuse may lead to harassment or abuse. The Foundation is starting a project to re-evaluate and enhance protections for user privacy through technical improvement to the projects. As part of this work, we will also be looking at our existing anti-vandalism and anti-abuse tools and making sure our wikis have access to the same (or better) tools to protect themselves.

The project page is on Meta. This project is currently in very early phases of discussions and we don’t have a concrete plan for it yet. We’d like your input. And please share with other people who you think would be interested. SPoore (WMF), Strategist, Community health initiative (talk) 18:12, 1 August 2019 (UTC)

Is anonymous editing through VPNs allowed?

Sorry to ask what's probably a dumb question, but I have looked around on policy pages and noticeboard archives, and couldn't find a succinct answer. Thanks! ☆ Bri (talk) 02:51, 7 November 2019 (UTC)

tl;dr: editing via proxy is allowed, until it gets blocked.
Wikipedia doesn't have a policy about VPNs per se, but about proxy servers. So the question is, a VPN to where? You're probably thinking about companies that offer an anonymizing proxy service, that you connect to using a VPN, which often have "VPN" as part of their names.
If you work at ACME Widgets Inc., and use a VPN to connect from your home to their corporate network, and then edit Wikipedia from there, it's not a problem. It's just the same as if you were editing at work. In that case it's not an "open proxy" because it's not available to the general public.
On the other hand, if you pay for an account at ACME*VPN, a company that advertises "privacy4all on the Interwebs", and use VPN software to connect to their servers, and then edit Wikipedia from there, that would fall under the definition of "publicly available proxies (including paid proxies)" found at https://meta.wikimedia.org/wiki/No_open_proxies. However, despite the policy being titled "No open proxies", the policy doesn't actually prohibit anonymous editing through open proxies - it only says that they may be blocked at any time, which usually happens when a problem such as sockpuppetry or vandalism is found. Disclaimer: IamNot a Wikilawyer... --IamNotU (talk) 04:48, 7 November 2019 (UTC)
Okay thanks for the explanation. The IP that I was concerned about was blocked without any question after I reported it to WP:WPOP. Maybe that is my answer in itself. ☆ Bri (talk) 16:11, 7 November 2019 (UTC)
I think it's expected when making a report that you've found some evidence of abuse - normally an intent to avoid or evade blocks. The bar of "suspicious edits" is fairly low. But an IP user who is editing generally in good faith, i.e. they believe they're helping to improve Wikipedia even if they're annoying or break a lot of rules - probably shouldn't be reported simply because they appear to be using a VPN/proxy service. Again, that's my understanding of the policy, maybe the admins who actually do the blocking have a different one. --IamNotU (talk) 17:46, 7 November 2019 (UTC)
That's probably a fair summary. There are two key phrases in the local policy: "open or anonymising" and "may be blocked". If you're using even a private proxy for the purpose of avoiding scrutiny, admins will usually weigh up whether it's possibly a breach of the WP:BADSOCK policy. And we might just block it because we can realistically expect some abuse from the network in the future - this is the case for most commercial or public VPN services. But I think it's fair to say we also knowingly tolerate some open proxy usage. Like most admin boards on Wikipedia, one thing we don't really want is for every open proxy which ever existed to be reported here, because volunteers are generally busy people. -- zzuuzz (talk) 20:04, 7 November 2019 (UTC)
  • It is not allowed by default, but is allowed through request, but the request requires certain conditions, and there is not sufficient documentation for anyone to take advantage of the request system. The next step for progress is making a centralized page, listing all the many guide pages on meta and English Wikipedia, additionally listing the locations of the discussions which established consensus but which happened elsewhere (pumps and central forums), then writing the consensus. I think this is like a 20 hour project and it requires wiki policy editing skill. If we did this then Wikimedia could have much better relations with the Tor volunteer community. I could join in doing this but not lead. Blue Rasberry (talk) 19:35, 7 November 2019 (UTC)

IRC

For those who do IRC, I've created an open channel at #wikipedia-en-openproxies connect - thought it might be nice to have a place to ask questions and such in real time. GeneralNotability (talk) 18:13, 16 October 2020 (UTC)

Reboot

Hi all,

It's pretty clear that this project is in rough shape right now: aside from Mdaniels being added to the verified list a couple months ago, that list hasn't changed since 2016, a lot of people on the verified users list and proxies are sitting on the list unchecked for weeks at a time. I suggest we try giving the project a reboot:

  1. Clear out the "active" lists of anyone who hasn't edited the requests page in, say, six months or so (to get a clean slate)
  2. Recruit new people - I'll put a notification at VPT for this, but it would probably help to find other recruits.
  3. Do some training - we have some fairly experienced folks around (SQL and zzuzz spring to mind), some kind of a knowledge dump would be nice.
  4. Look into automating what we can, both in terms of listing possibly abusive open proxies and identifying reported proxies which look open. I know a lot of proxy checking is impossible-to-script experience and knowledge, but it would be nice to autoclerk in some way.

I'll be sending out a mass message to active editors on the verified list and other people who have edited here in the past six months to notify them of this discussion. GeneralNotability (talk) 13:58, 12 October 2020 (UTC)

The other big question: "how can we make this project useful to the general editing community?" Right now it's a fairly niche technical topic and I don't think people really know about it or when to post here. GeneralNotability (talk) 14:13, 12 October 2020 (UTC)
@GeneralNotability: Besides the actual function of this page, there are some big social issues which the general wiki editing community could discuss. I think that the typical user of this page would not interact directly with it, but want to get cultural information about what our policy is for open proxies and why it matters. If we got the story right then that would connect Wikipedia to big social issues like supporting individual right to privacy, such as for the Wikipedia editors who face harassment, and also developing our response to attacks, including routine spam but also funded propaganda. This is also an area where English policy has outsized influence on what other languages do, so this is a more global issue than most.
There are lots of documentation pages here and on Meta which need reconciliation. I think there is not even a clear list of all the documentation and major discussion. If there were actually interest in this, then as a first step, I would join others in making a list of every place this issue is discussed so that we can gather together what we already have then plan to centralize the discussion. Blue Rasberry (talk) 15:04, 12 October 2020 (UTC)
Bluerasberry, I think that's a very useful thing to do under the umbrella of this project. GeneralNotability (talk) 16:26, 12 October 2020 (UTC)
  • It would be good to know what the ground rules are wrt volunteering. Are there tools that require training? Do they require a WMF confidentiality agreement/NDA? Real-name disclosure and so forth? Is this akin to checkuser or more of a checkuser lite? ☆ Bri (talk) 14:15, 12 October 2020 (UTC)
    I laid out some guidelines some time ago at Wikipedia:WikiProject on open proxies/verification. Personally I run a little quiz for applicants, along with a little training, to assess skills (etc). There are no real privacy aspects involved, and no involvement with the WMF. There's some crossover with what checkusers sometimes do, but there's no real relationship. This is akin to a clerking role, in that it is hoped that admins (and checkusers) can rely on what the verified user says and admin appropriately. I think this kind of role (and assessment) is still necessary, as it's so easy to be wrong about proxies. -- zzuuzz (talk) 14:29, 12 October 2020 (UTC)
  • I've noticed this in the past but haven't really had the time nor energy to work on it, I'd be more than happy to join if it does end up getting revived. Kb03 (talk) 03:48, 13 October 2020 (UTC)
  • I have submitted complaints at WP:OP in the past but have not been active recently. It would be useful for an editor to be able to run whatever algorithm is employed by User:ProcseeBot to detect proxies. My own efforts to activate a suspected proxy would often fail, not necessarily because it wasn't a proxy, but because my approach was missing some technical detail. EdJohnston (talk) 16:12, 21 October 2020 (UTC)
  • ProcseeBot isn't exactly what you think it is though. Besides the fact that the source code won't be released, it's goal is to "It seeds information from public proxy lists and checks to make sure the proxy is open and usable, and if so, proceeds to block it." So it's basically equivalent to a human going to a proxy list, trying every proxy, and if it works it gets blocked then. -- Amanda (aka DQ) 20:19, 21 October 2020 (UTC)
I had supposed it used the web-visible proxy lists, but it is the proxy activation that I have trouble with. There must be some tricks of the trade. I’m also unclear on whether users who manually check proxies ever use nmap. EdJohnston (talk) 03:42, 22 October 2020 (UTC)
EdJohnston, if you haven't seen it, Wikipedia:WikiProject_on_open_proxies/Guide_to_checking_open_proxies has some tips and tricks. GeneralNotability (talk) 12:41, 22 October 2020 (UTC)

Potentially useful userscript

For those who use MoreMenu, I've thrown together User:GeneralNotability/moremenu-proxy.js - adds links to shodan, stalktoy, and spur to the "IP lookup" menu under "User". GeneralNotability (talk) 04:15, 28 February 2021 (UTC)

Useful indeed! Thanks. Blablubbs|talk 15:25, 28 February 2021 (UTC)

Is en-wiki still relying on the open/zombie link?

[[8]]

It's one of the links at the bottom of the page but doesn't seem to have been updated in 13 years... is there a more relevant page it should be linking to? Or just a zombie link that can be removed?? Slywriter (talk) 14:48, 22 February 2021 (UTC)

Slywriter, I've removed the link, it's pointless. Maybe someone else knows where the full list can retrieved. MarioGom (talk) 23:49, 9 March 2021 (UTC)

Template changes

Currently, {{proxyip4}} links to IPQS, which is in my experience by far the least reliable proxy checking API out there – I usually ignore its results entirely when checking. Would there be any objections to me editing the template to link to spur's context API instead (example)? It's the API I have the highest confidence in (the VPN identification is impressively accurate) and it's not currently included in the ipcheck toolforge tool. Blablubbs|talk 14:49, 19 February 2021 (UTC)

Additionally, I'd propose getting rid of the ipinfo link, which just redirects here, and adding rangeblock finder. Blablubbs|talk 11:31, 20 February 2021 (UTC)
Blablubbs, makes sense to me, the spur API is definitely the best one for VPNs. I prepared a more specific proposal at {{Proxyip4/sandbox}} with the following changes:
  • Added rangeblock finder for individual IPs.
  • Added spur for individual IPs (not supported for CIDR, neither was IPQS): best VPN identification.
  • Added shodan for individual IPs. This gives a lot of useful information: accurate geolocation, ISP, cached portscan, served SSL certificate. It removes the need of using nmap, so it's more convenient, and also less intrusive. Support for CIDR search requires login, so I didn't include it.
  • Removed IPQS since it's not so accurate and it's quite redundant with spur and shodan.
  • Removed HTTP link. It's redundant with shodan.
  • Removed Google link. Is anyone actually using it?
  • Removed talk page link for CIDR ranges, since it was not valid.
  • Removed ipinfo link, since it looks like the tool is decomissioned?
  • Removed ipcheck link, since it's deprecated, and redundant with others.
  • Kept Robtex (useful to get a list of domains, in particular for CIDR) and WHOIS.
The sandbox currently has one example for an individual IP (SurfShark VPN) and one example for CIDR to compare. --MarioGom (talk) 11:35, 20 February 2021 (UTC)
@MarioGom I quite strongly oppose removing the Google and ipcheck links. Googling the IP is part of my proxy check routine (and often very useful), and while IPcheck isn't being actively maintained, it works well and is a good way to see who's flagging and why – the SBL/CBL lookup alone make it worthwhile, and while not all of the APIs are super accurate, seeing that a bunch of them are flagging is a strong indicator that something is up. I also oppose removing the http link – figuring out that something is hosting a website in a single click is also fairly useful. I also think adding geolocation lookup to the template would be useful – I've taken the liberty to add it to the proposed new version. Blablubbs|talk 11:46, 20 February 2021 (UTC)
Blablubbs, ok, added Google, HTTP and ipcheck back. If they are actually used, then I have no reason to propose removal. Some issues: 1) the line for individual IPs is too long, is there anything we can abbreviate? 2) shodan returns 404 for IPs it has no records for, which may be confusing, here's an example of a good result. The proposal for shodan may be a bit premature, but it would be nice for proxy checkers to try it and see if it's useful. --MarioGom (talk) 12:16, 20 February 2021 (UTC)
@MarioGom, I'd argue that "current blocks" is not needed given that active blocks show up both on the contribs page and rangeblock finder is included – that would shorten the template, but not sufficiently for everything to fit on one line. We could of course abbreviate more stuff, but I think that may be more confusing than helpful. The only other option I see is to mess with the text size, but I personally don't mind too much if the template is a little long – for me, the "stalk" link already shows up on a separate line (might be a new vector thing, not sure). Blablubbs|talk 12:25, 20 February 2021 (UTC)
Blablubbs, removed "current blocks", let's see if someone needs it or not. Also abbreviated "geolocation" to "geo", which is still descriptive enough. It fits on my screen. ​​​​​​​​​​​​​​​​​​​​​​​​​ Pinging admins and active users listed at Wikipedia:WikiProject on open proxies/verified users. --MarioGom (talk) 13:14, 20 February 2021 (UTC)
Sidenote: I checked: The two-line thing is indeed skin-specific – the limited text block width of new vector forces the template to wrap. Blablubbs|talk 13:20, 20 February 2021 (UTC)
I like it. Also changed "edits" to "contribs" since pretty much every similar template says "contribs". GeneralNotability (talk) 17:17, 20 February 2021 (UTC)
So long as we're messing with the templates - switching from the whois tool, to ST47's whois-referral tool would be nice. I like that it follows referrals, and links to isprangefinder's ASN hint page. SQLQuery me! 17:52, 21 February 2021 (UTC)
Good idea, I switched out the URLs. Blablubbs|talk 18:06, 21 February 2021 (UTC)
I've pushed the current sandbox to the live template. GeneralNotability (talk) 14:11, 24 February 2021 (UTC)

Implemented similar changes for {{proxyip6}}. --MarioGom (talk) 08:34, 16 March 2021 (UTC)

Simplifying Proxyip templates

I have opened a proposal at Template talk:Proxyip § Align with Proxyip4 and Proxyip6. The idea is modifying {{Proxyip}} so that it automatically selects {{Proxyip4}} or {{Proxyip6}} based on its input. After that change, we could change the report templates to simplify the user experience. MarioGom (talk) 18:41, 18 March 2021 (UTC)

VPNs

Quick PSA: Since actually open proxies seem to be going out of fashion and the proxy bots are doing brilliant work, VPN services now make up a substantial chunk of WPOP requests. MarioGom and I have taken some time to look for fingerprints and other verification methods for some of them – we have started to compile a list at User:Blablubbs/VPN Verification that may be of interest to others; please feel free to add. This is mostly intended for scenarios where providers like spur are flagging, but verification is needed. If others think this is a worthwhile effort, we could also consider moving it to a WPOP subpage. Best, Blablubbs|talk 16:54, 12 March 2021 (UTC)

Ping ST47 (proxy bots) and RonaldB (WP:OPD). MarioGom (talk) 17:00, 12 March 2021 (UTC)
I do support moving it to WP:WPOP, as well as linking it from instructions for proxy checkers. MarioGom (talk) 18:42, 18 March 2021 (UTC)

Signpost interview

Hi all, I hope that you're well during this crazy COVID-19 period. I would like to try my hand at being an interviewer for the now inactive WikiProject Report on the Signpost and saw this very interesting project that hasn't yet featured. Would anyone around be interested in being interviewed? It is a great way to educate others about your project and perhaps get help if you need it. I will create a page for questions at User:Tom (LT)/sandbox/WikiProject on open proxies interview and invite anyone interested to contribute.

Ping to some editors I have seen in the archives active in the past year: MarioGom, GeneralNotability, Blablubbs, Malcolmxl5, EdJohnston, Bri.public (apologies if I have left anyone out), please feel free to contribute and answer any questions that interest you.

Looking forward to hearing from you! Tom (LT) (talk) 06:54, 28 May 2021 (UTC)

Tom (LT): Sounds good, I'll participate. CC SQL who has been handling some of the blocks too. MarioGom (talk) 07:08, 28 May 2021 (UTC)
Thanks for the heads up, MarioGom. I'll look at those in a bit, and consider replying! !ɘM γɿɘυϘ⅃ϘƧ 11:39, 28 May 2021 (UTC)
Hello User:Tom (LT). See the list of verified users in: Wikipedia:WikiProject on open proxies/verified users, that is, the people who are considered qualified to close the open proxy reports. Consider leaving pings for any of the verified users who have been recently active. EdJohnston (talk) 16:35, 28 May 2021 (UTC)
Great idea, thanks. Ping also to Tawker, AmandaNP, Cobi, Bsadowski1, AGK, Zzuuzz, TigerShark, Sailsbystars, UY Scuti, and Crazytales. That's enough pings to sink a ship!
P.S. EdJohnston the following editors appear to be barely active, inactive or are marked as retired. If you have time you can have a look and update your members list. Those editors are: Aaron Schulz, Crazycomputers, Kanonkas, OverlordQ, Prodego, JJJJust, MichaelBillington, Winhunter, Adrian, Madman. Cheers Tom (LT) (talk) 22:42, 28 May 2021 (UTC)
I’m just someone who occasionally lends a hand with the admin tools when a proxy checker has requested administrator assistance. --Malcolmxl5 (talk) 12:12, 29 May 2021 (UTC)
I've always viewed this project as a loose collaboration of people who don't necessarily describe themselves as members, so I'm sure your views would be as welcome as anyone's, if you have any. To my knowledge we don't have the usual things like member categories, userboxes, or talk page tags. User:Tom (LT) I'm happy to chip in... I have a request for clarification about where you want the replies. BTW if you ask ten different users what this project is, you'll probably get ten different answers. -- zzuuzz (talk) 12:39, 29 May 2021 (UTC)
Zzuuzz, Oh, man. I was thinking of joining, but if I'm not going to get a userbox, why should I bother? Isn't there at least a special colored fez or something? -- RoySmith (talk) 12:43, 29 May 2021 (UTC)
RoySmith: I offer a numbered limited edition userbox for admins willing to help ;-) MarioGom (talk) 13:38, 29 May 2021 (UTC)
Thanks everyone. I've put some questions on the sandbox page so anyone interested can contribute. A WikiProject consists of all sorts of wikipedians - active, inactive, admin, volunteer, regular and infrequent contributor, and I think it's great to have multiple different opinions, so if you're interested please select whatever questions you'd like and respond to them on the sandbox page (User:Tom (LT)/sandbox/WikiProject on open proxies interview) :). Tom (LT) (talk) 22:36, 29 May 2021 (UTC)

Further Proxyip templates improvements

I would like to do some further improvements to {{Proxyip4}}, {{Proxyip6}} and {{Proxyip}}. The changes would be as follows

  • Avoid indentation in {{Proxyip4}} and {{Proxyip6}}. Built-in indentation is not present in other similar templates, and it is very inconvenient when adding further indentation or using them inline. This change would also require a small fix through the archives to avoid breaking previous formatting. I would just add a colon before each occurrence of the template in the archives.
  • Make {{Proxyip}} the main template, automatically selecting {{Proxyip4}} or {{Proxyip6}} depending on the input. See previous thread. I have this change ready in a sandbox.

Wikipedia:WikiProject on open proxies/Example would be changed to something like this:

* {{Proxyip|<!-- Place IP you are reporting here -->}}

What do you think? MarioGom (talk) 17:54, 7 June 2021 (UTC)

Pinging active(-ish) users for input: Blablubbs, Malcolmxl5, GeneralNotability, SQL, zzuuzz, TheresNoTime. MarioGom (talk) 16:55, 10 July 2021 (UTC)
@MarioGom: Sounds good to me, reasonable and tested changes - TheresNoTime 😺 17:37, 10 July 2021 (UTC)

 In progress. MarioGom (talk) 19:56, 15 July 2021 (UTC)

 Done. MarioGom (talk) 21:32, 15 July 2021 (UTC)

Bullseye grant proposal

Good afternoon all, I have submitted a Rapid Grant proposal for bullseye, a tool I have been working on to consolidate detailed information about IP addresses into a single view. It is primarily targeted at checkusers and stewards, but is usable by all editors. At the suggestion of one of the grant coordinators, I am informing potentially interested communities about this proposal. I welcome any and all feedback on the proposal. Best, GeneralNotability (talk) 17:06, 15 October 2021 (UTC)

RfC notice

Wikipedia:Village_pump_(policy)#Should_editing_on_Wikipedia_be_limited_to_accounts_only? - Notice about a discussion asking whether editing on Wikipedia should be limited to accounts only? - jc37 15:47, 18 May 2023 (UTC)

Are the proxies used by this IP ok to use?

[9] LUMINATI_PROXY and OXYLABS_PROXY. I assume they are as proxy checker seems to think the IP is ok. Thanks Doug Weller talk 13:44, 7 April 2024 (UTC)

Corporate VPNs

We have been quite inconsistent with blocks on corporate VPNs like McAfee WGCS or Zscaler. Sometimes they are blocked, sometimes they are not. I wonder what are your thoguths on this? I think a few of the options would be:

  • Block all of them.
  • Block all of them, anon. only.
  • Block only when abused.

The rationale for treating them in a different way is that these are sometimes the default connection option at some workplaces, and their usage is beyond control by the user when they are connecting from that location, so I think hardblocks might be undersirable. I would lean towards blocking all of them as anon. only if we have regularly seen them abused, but I'm not sure that happened. MarioGom (talk) 22:51, 25 September 2023 (UTC)

If we're to block em, my preference would be to softblock. It reduces the risk of disruptive edits by anon editors, while still allowing established accounts to edit from the same connection. I also think it would be beneficial to have some consistency here. I know the corporate VPN providers like Zscaler have a lower risk when compared against other more consumer oriented services, but there is still disruption that occurs there. 165.225.192.0/18 has a few recent examples of disruptive edits from individual IPs within the range, despite first being reported here back in May 2023. Sideswipe9th (talk) 00:32, 19 December 2023 (UTC)
I think softblocks where there has been disruption is the way to go, which will permit logged-in editors to edit using a corporate gateway while preventing disruptive edits from anons. Malcolmxl5 (talk) 01:08, 25 April 2024 (UTC)

Help with Teahouse/Help desk abuse

For the past two days, we've had to temporarily semi-protect the Teahouse and Help desk due to a proxy-hopping vandal. My savviest approach has been to block the proxy IPs and implement one-hour protection. We'd generally prefer to not protect those pages, since they're places for new and unregistered users to get support. Can those with more know-how suggest a better approach? List of IPs in the collapsed section below.

Extended content
  • 108.188.145.113
  • 14.54.233.128
  • 49.228.177.11
  • 119.229.16.50
  • 58.187.25.244
  • 14.36.196.175
  • 182.235.231.66
  • 77.34.250.60
  • 119.192.208.114
  • 112.71.247.70
  • 76.82.175.66
  • 118.69.162.170
  • 79.132.13.234
  • 124.158.125.196
  • 42.113.126.166
  • 187.126.28.93
  • 23.93.101.181
  • 81.2.17.144
  • 27.82.8.78
  • 184.22.106.75

Firefangledfeathers (talk / contribs) 15:06, 28 June 2024 (UTC)

Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia_talk:WikiProject_on_open_proxies/Archive_4&oldid=1241686108"