Forum:Can we be more proxy-friendly?

From Uncyclomedia, the UnMeta-wiki
Jump to navigation Jump to search
Forum: Can we be more proxy-friendly?
Note: This topic has been unedited for 80 days. It is considered archived - the discussion is over. Do not add to unless it really needs a response.
Error 1005.jpg

Well, due to some political issues in Hong Kong, there's an increasing demand of accessing the Internet from Hong Kong with proxies. More than that, the Great Firewall seems to started establishing in Hong Kong, thus encouraging even more people to start using proxies to access the Internet. (and there may be a medium-to-high possibly for Uncyclopedia getting blocked in Hong Kong) However, the current Uncyclopedia server systems seems not be proxy-friendly, and I received reports that certain proxies and Tor outbound nodes are blocked by Cloudflare, and display the error 1005 message on the right. (and some users even report that they lost their edits due to this issue) Is it possible to adjust the blocking rules so that Uncyclopedia (at least for some branches/languages) can be more proxy-friendly?--Abcabc2 (talk) 17:31, 8 January 2021 (UTC)

I will contact Carlb on this subject. Rhubella selo-02.pngRhubella Marie, the rat sockpreppie 3,434 preppieditsRhubella selo-01.png 20:19, 10 January 2021 (UTC)
I don't remember it well but I don't know if the Taiwan version is independent or an alternative version. If you are independent, could you tell me if you have the same problem as in the Hong Kong version? Rhubella selo-02.pngRhubella Marie, the rat sockpreppie 3,434 preppieditsRhubella selo-01.png 20:29, 10 January 2021 (UTC)
The .tw and .hk domains point to the same wiki, not to separate projects. Carlb (talk) 07:39, 11 January 2021 (UTC)

No response again? There's a list on my user page which lists the status of all topic I've initiated or participated.--Abcabc2 (talk) 16:40, 15 January 2021 (UTC)

I am sorry for the inconvenience but I was active exclusively at UnCommons due to vandalism attacks and I stayed away from all other activities in the other wikis. I forwarded an email to Carlb about the problem. Rhubella selo-02.pngRhubella Marie, the rat sockpreppie 3,434 preppieditsRhubella selo-01.png 04:46, 16 January 2021 (UTC)

Some users express concerns about the .hk domain will be taken down due to HKIRC is establishing new regulations on domain registrations, and the content of the site is violating the national security law of Hong Kong. Will any action be taken on this? Also, some of our users are using Tor to view and edit the zh-tw/zh-hk Uncyclopedia and suggests we giving an .onion domain in order to make our site be more Tor-friendly.

As I know, there are at least five domains pointing to this partiular Uncyclopedia (not sure if some of them are official or not):

And I know at least two domains exist for the inactive Cantonese Uncyclopedia:

Just to clear things a little bit, are all these domains official? Are there still any existing domains which I do not know yet?--Abcabc2 (talk) 12:26, 16 January 2021 (UTC)

I think that only Carlb can answer him but I am also obliged to question whether, in case the National Security Law has been causing problems, have you accessed some of these domains without falling into a state blockade? Rhubella selo-02.pngRhubella Marie, the rat sockpreppie 3,434 preppieditsRhubella selo-01.png 06:09, 17 January 2021 (UTC)

All of our domains is still accessible directly by now, but some users report that some proxies and some Tor outbound nodes are blocked by Uncyclopedia. (the proxy I'm using is currently not affected though)--Abcabc2 (talk) 14:10, 17 January 2021 (UTC)
Well, as I remember the current official domains for small wikis are the ones that have ".info" because that's what all the small wikis have in a reform decided by Carlb since keeping more than 50 small wikis and many of them inactive with the ".org" domain cost a lot. That in theory. I am checking the interlink bar on my source wiki and I can assure you that Desgalipedia has 3 recognized interlinks. Those already mentioned:


I believe that other foreign wikis were instructed to have these interlinks to access their wiki. Yes, exactly. the Portuguese version that calls itself the largest of all recognizes the first two commented wikis ( and Despite this, I am not an ideal person to guide which domain is the official one. By indication, the system says that the domain would be the one with .info or ".org" domain, which in your case would be the first option. However, as you mentioned, all domains are at risk of being censored by the Chinese central government or Taiwan's security law due to the political problems I follow. Thus, if I myself claim that the official domain is the one I said, nothing prevents a greater concentration of users in a single domain to prevent it from becoming a preferential target of censorship. Rhubella selo-02.pngRhubella Marie, the rat sockpreppie 3,434 preppieditsRhubella selo-01.png 20:43, 17 January 2021 (UTC)



That particular user who is using Tor to participating our sites recently report that now he has to complete a captcha whenever changing the Tor outbound node (base on the way Tor works, Tor changes its relays 10 minutes or so), and some other users report that the captcha is quite hard pass though. This is still discouraging users to participating our sites via Tor and this user claims to left Uncyclopedia for a while because of this issue. If this is done intensionally, you are driving away friendly users and welcoming vandalisms.--Abcabc2 (talk) 02:59, 19 January 2021 (UTC)

It was not from us, no wiki has a captcha with this power to change. His charge against UnMeta is unfounded. Find out if this change was made by the aforementioned security forces. Rhubella selo-02.pngRhubella Marie, the rat sockpreppie 3,434 preppieditsRhubella selo-01.png 17:51, 19 January 2021 (UTC)
Cloudflare uses hCaptcha. Carlb (talk) 02:34, 20 January 2021 (UTC)
But we have a problem here, as it is being commented that there is a restriction on entry on the wiki. And it was commented that the captcha reappears every 10 minutes due to the relay change of the tor. Either someone lies, or the captcha has an error. The only wiki that has registered restriction problems so far has been Malucopédia, and this is due to an abuse filter activated restricting editions of new users. Rhubella selo-02.pngRhubella Marie, the rat sockpreppie 3,434 preppieditsRhubella selo-01.png 15:40, 20 January 2021 (UTC)
I believe that it would be best to disable the captcha momentarily until the political situation in the country normalizes. Even if it leads to the flood of vandals accessing the wiki. Rhubella selo-02.pngRhubella Marie, the rat sockpreppie 3,434 preppieditsRhubella selo-01.png 15:52, 20 January 2021 (UTC)
Unfortunately, these sort of things happen because of abuse - for one example, AhrefsBot is running on AS12876 (Online SAS) and was consuming an inordinate amount of bandwidth. The previous datacentre was charging me C$0.10/Gb for that bandwidth, even though AhrefsBot, SemrushBot, PetalBot and the like are doing more harm than good. Block AS12876 and any Tor exit nodes on the same server farm with the same AS will get the captcha or get blocked.
It is possible to create an address like zh.univgipdk3c2ebf2fjkxzzzeke66ny23gaoaicisvfqd2zbaiixqhhad.onion which only works in Tor's browser - but even then, there's the longstanding issue that MediaWiki identifies anonymous users by their IP address. Use .onion for a site, and their IP will always show up as (the Tor client running on the server) - which some admin will inevitably block the first time it gets used and abused for vadnalismLOL. Not too sure what happens from there. I suppose the .onion address could be limited to existing, logged-in users but beyond that? I dunno. Carlb (talk) 18:07, 21 January 2021 (UTC)
The two main enquiries are highlighted above. The problems are caused by the Cloudflare layer, not by the authoritarian regimes. However, some other users said that it's totally fine to browse Uncyclopedia via Tor, neither get blocked nor get captcha. I'm currently discusing with some friends who are more familiar on network than me to find a solution for this issue. Currently I've personally come up with these solutions below:
  • Do nothing, and causing more and more users to leave Uncyclopedia because of this issue.
  • Restrict edits from suspicious IPs, but that way I would have to have the ability to give IP block exempt permissions to individual users, just like what Wikipedia does.
  • Build a customized network and provide it to some trustworthy users who has the need to connect to Uncyclopedia via blocked proxies.
Could you give a better solution in order to prevent both user lost and bandwidth abuse?--Abcabc2 (talk) 09:02, 22 January 2021 (UTC)
They told me a solution to solve the problem: Set a custom loopback address, then set the Onion service with that loopback.--Abcabc2 (talk) 18:11, 22 January 2021 (UTC)
What would that accomplish? Going into /etc/tor/torrc on the server and changing this pesky line:
HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80
HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80
is a custom loopback address, but that just makes all anon-IP edits to the .onion site appear to be coming from for every Tor user, instead of It does not provide a different address for each user. The first time someone uses that address to vandalise the wiki, it gets blocked and we're right back to the same issue.
I'm not saying that ".onion available" can't work for existing logged-in users. The problems arise with new registrations and with edits made without logging in. MediaWiki identifies those users by their IPv4 address. Force (or, or whatever) in there for every .onion user, and that model is broken.
A similar issue exists with the Tor exit nodes. They're a shared address. Sooner or later, someone will do something (which might not even involve Tor) that causes one or more of those addresses to be blocked.
Wikipedia has already analysed this question to death; see wikipedia:meta:No_open_proxies#Exceptions, wikipedia:meta:Editing with Tor, Wikipedia:project:Advice to users using Tor to bypass the Great Firewall / Wikipedia:project:Advice to users using Tor and Wikipedia:project:Request an account. Carlb (talk) 19:34, 22 January 2021 (UTC)
Is it possible to restrict unlogged-in edits and allow registration and logged-in edits in the .onion domain? Furthermore, my friend asks me to check if there is a cookie based or device credentials based device distinction method.--Abcabc2 (talk) 09:03, 23 January 2021 (UTC)
Logged-in editing can be supported, anon-IP editing cannot (as an .onion user has no identifiable IP address). New registration could be a problem, as it could be used to create multiple accounts in bulk to post spam. Other than that, dunno. Most likely device "fingerprinting" is blocked as far as possible in Tor's browser, for privacy reasons. Carlb (talk) 07:24, 26 January 2021 (UTC)

Uh, the Tor user told me that the current .onion domain becomes unusable, and should be upgraded from v2 to v3.--Abcabc2 (talk) 09:33, 2 July 2021 (UTC)