Wikipedia talk:WikiProject on closed proxies

WP:WPCP

WikiProject on closed proxies

Main – Talk – Servers – Usage instructions – Apache setup

Good idea

I agree that this is a good idea, but wouldn't requiring any user coming from a tor exit node to have an account for editng achieve the same results (to allow anonmous edits from highly restrictive places whilst discouraging vandalism)? 71.87.112.153 (talk) 23:28, 8 April 2008 (UTC)[reply]

Yes, but Tor nodes are usually blocked due to vandalism, but these proxies are not. Atyndall93 | talk 01:37, 15 May 2008 (UTC)[reply]

Closed proxies and IP block exemption

With the activation of IP block exemption, some discussion also went on about closed proxies. In brief the following points came up:

A major difference between closed proxies and exemption is that a user gets exemption on one specific account, but if they have a proxy login, they can then edit from any accounts they wish. (Although not necessarily create accounts.)
Socking and abuse reduction were considered as part of exemption, but aren't visibly taken into account in the proxy WikiProject. To limit socking, we can require that proxies be soft-blocked and forward an XFF header so access can be revoked if necessary.
WikiProject proxies would have direct involvement of a proxy owner, more than most third party open proxies. So a recommended "pre-built" proxy setup might be possible that anyone with a server could use, or lessons learned could be adopted by all closed proxies, or if particular provisions were needed then these can be discussed and agreed.

WP:IPEXEMPT and its talk page cover the various concerns over socking, and reasonable provisions to reduce the scope for abuse of these powerful tools. A brief discussion with ST47 suggests some good ideas for the closed proxies of this wikiproject:

Allow each specific user to log into the proxy from only their specified IP range(s). Reduces risk of proxy abue via chaining, ensures some degree of sock-reduction is possible.
Include the source IP and proxy account ID within the XFF string, to allow checkuser identification of the logged in user account, in case of sock puppet abuse. This also allows checkusers to easily find all wikipedia accounts linked to a certain proxy account.
Soft-block closed proxies to ensure they must be operated logged in (prevents the proxy IP being all over the wiki, or the same IP being shared by many users for posting. Allows users to edit if logged in.)
Grant closed proxy access the same way that IP block exemption for anonymous proxy usage would be granted (no need to re-invent the wheel, this is intended to keep it simple yet reduce abuse of an admin level tool).

Last, is there any benefit from agreeing some kind of common code/norms for Wiki closed proxies... ie, some common features and some common operating norms?

FT2 ^{(Talk | email)} 22:14, 11 May 2008 (UTC)[reply]

It would be possible, I think, to use mod_rewrite to prevent people from logging in using any account not linked to their proxy username (mod_rewrite can scan and intercept information from the proxy, and is used to block certain pages, e.g. register user). Policies can be implemented to check user's applying for use of the proxy for a history of vandalism, socks and other bad information, I did consider myself requesting a softblock from the proxy, I will check up on policy on that today. I do not have knowledge on how to foward XFF headers but if information was provided it could be implemented. In regards to the proxy owner's involement in the proxy, a tutorial on how to setup the proxy in the way required by the project can be found here. A system would have to be implemented (possibly a bot) that checks for any block messages/warnings periodically on the user's talk page/logs, watches to see if they use a account not allowed by the project and possibly revoking access if bad behaviour is detected. An IP range detection could be implemented, but this would require the user to disclose private information. Again, XFF headers could be implemented if I can work out how. Proxy access would be granted on a case-by-case nature, reviewing the cases just like IP exempt. I think the main advantage of using the closed proxies over IP exempt and Tor/other proxy would be the security (we are going to implement User to Proxy and Proxy to Wikipedia SSL) and speed (there wouldn't be many other user's using the proxy, this may change), thou I have a feeling I am still forgetting something. And about your last point, currently the common code for the proxies is a Windows/Linux/Unix server using Apache, mod_proxy, mod_ssl and mod_rewrite, *(outlined at here) this could be more specific. Atyndall93 | talk 02:51, 15 May 2008 (UTC)[reply]

I haven't tried to verify this with a sniffer like WireShark yet, but the docs on mod_proxy_http claim that X-Forwarded-For headers are included when used in a reverse proxy configuration. Presumably including this module as well as mod_proxy should do this automatically.

It appears from the list of headers in the mod_rewrite docs that we can create rewrite rules based on cookies supplied by the client. I'm a little rusty on the exact cookies that MediaWiki sends/receives, but I think that they include the user's account name. If we asked all proxy users to have their proxy username be the same as their Wikipedia username, then we could easily force all proxy users to use their given account.

As for the account ID being included in the XFF headers, it looks like the mod_headers module could do this. From what I've read, it looks like we can take the user's account name and insert it into the XFF headers when we make the request.

This is all speculation, though. I'll experiment with Apache later to make sure that this works properly. Shadow1 (talk) 16:29, 15 May 2008 (UTC)[reply]

Policy suggestions

I think we need to write a policy on how to handle vandals using the proxy, how proxies must be setup etc, I am proposing the following things:

Proxies must be softblocked with account creation disabled or this must be implemented in proxy software.
Proxies must use SSL on their end and connect to https://secure.wikimedia.org/wikipedia/en/ instead of http://en.wikipedia.org/ for security.
~~Proxies must display the newly made {{closedproxy}} template message on their IP talk page, alerting admins not to block the IP address and that is is a closed proxy.~~Maybe not wise.
Proxies should implement some mechanism to stop user's from logging into more than one account, to prevent vandalism, socks etc.
Proxies need to forward XFF headers with the IP address of actual user.

I also suggest, if possible, implementing:

A central user/password database that all proxies update from regularly, possibly a password-protected file hosted on a separate server that is accessed via cron, allowing user's to use any proxy they wish if one server stops working.
A gateway webpage (on a different site) that contains usage statistics on each individual proxy and directs people who access that page to the proxy currently experiencing the lowest usage.

Any other suggestions are welcome, I am also open to changes/suggestions. Atyndall93 | talk 12:57, 19 May 2008 (UTC)[reply]

Such a major change requires the attention of broader community input. Either post this to another page or make an announcement at community portal. OhanaUnited^{Talk page} 16:43, 19 May 2008 (UTC)[reply]

I don't quite follow you, I want the project to have policy on their proxies, not creating an official Wikipedia policy about all closed proxies. If its only the project's policy, do we require full community consensus? Atyndall93 | talk 23:32, 19 May 2008 (UTC)[reply]

You might also want to note that the Chinese government does seem to be keeping an eye on the project. When I first set up a proxy and created accounts for users, testing confirmed that my IP address had suddenly become blacklisted in China (presumably because someone noticed the project and banned me). Placing the {{closedproxy}} template on closed proxies' pages may only serve to help the Chinese government keep better track of which servers they need to ban. Shadow1 (talk) 19:08, 19 May 2008 (UTC)[reply]

Yes, I see your point, I've removed it from my proxy's page, are you fine with the other suggestions? Perhaps creating WP:WikiProject on closed proxies/Policy and putting ideas there. Atyndall93 | talk 23:32, 19 May 2008 (UTC)[reply]

I'm fine with the other ideas (not that I'm the sole authority of this project). Especially with the XFF headers, the current setup already has the ability to perform a lot of these functions. Apache does update the XFF headers automatically, but the problem is that proxies downstream might not honor XFF.

Meaning, users might be connecting through an open proxy to connect to the closed proxy. We would then report the open proxy to Wikipedia's servers as the user's real IP, and I don't think checkusers would be particularly happy about that. We definitely need a way to restrict users to particular address ranges, and we should also be actively scanning those ranges before granting access to ensure that there are no open proxies in the range.

On the subject of the central database: it's definitely possible to have all the proxy servers update their authentication files from a central server (it's really as easy as a simple wget-based script), but we would still need to have a central server and a secure method of updating so that the users' information is not leaked in the process. cfengine is one solution that comes to mind. Shadow1 (talk) 12:37, 20 May 2008 (UTC)[reply]