Have read BCronwall's response in T330024.

The team's limited capacity prevents the maintenance work required to provide such a solution. Were this a permanent solution then we'd be happy to oblige; However, implementing these measures would only provide temporary relief before more restrictions follow.

Surely depending Wikipedia accessibility on limited, unblocked IPs seems to be an impermanent solution, but I can say it's really a long-term solution: as my referred two similar apps above, one of them added such domain fronting feature in middle 2019, one added in late 2020, upon now, 2023, none of them seems be further limited or blocked. I think it's worth a try for even 3-5 years' accessibility.

Thanks for creating this task its a valid request. Our team can't prioritize it right now but its on our radar.

Domain fronting takes the advantage of collateral freedom, but unfortunately I cannot see much damage for the government to block Wikimedia IPs. Yes, for a medium term this is a feasible approach, but it costs nearly nothing for the government to block an IP, but changing one costs a considerable amount of resource. What should we do if all IPs are blocked in the future?

Another solution is to combine domain fronting with large 3rd party network infrastructure (like Azure, AWS, etc., and Signal uses this approach), but this is likely to be blocked by WMF privacy policy.

In T327286#8747600, @Diskdance wrote:

Domain fronting takes the advantage of collateral freedom, but unfortunately I cannot see much damage for the government to block Wikimedia IPs. Yes, for a medium term this is a feasible approach, but it costs nearly nothing for the government to block an IP, but changing one costs a considerable amount of resource. What should we do if all IPs are blocked in the future?

Probably I used a wrong word? I cannot find a more appropriate word than 'domain fronting' to describe SNI field manipulation, but the word 'domain fronting' is usually connected with the use of clouds and CDNs.

In my experience, blocking IPs is the last method than DNS poisoning or DPI, probably because of this: IP blocking does cost something, for routers have very limited storage for saving both normal routing table and manually added blackhole routing table.

...but the word 'domain fronting' is usually connected with the use of clouds and CDNs.

Then WMF's privacy policy may be an obstacle -- I don't think it allows a third party to know users' IP addresses, I may be wrong, though.

In my experience, blocking IPs is the last method than DNS poisoning or DPI, probably because of this: IP blocking does cost something, for routers have very limited storage for saving both normal routing table and manually added blackhole routing table.

Theoretically the censorship system acts like a black box to us. Blocking IPs may not be cost free but still costs far less than changing IPs on a limited budget (which is the case for WMF, unfortunately.)

Another potential risk is that integrating censorship evading measures may cause the iOS app to be removed from China App Store. I'm not saying we should not add this -- censorship poses a risk to us all and we should resist, but I'd rather be cautious and think about wise and lasting solutions, so it won't be a waste of money.

Hahha, yes, they can remove any apps from China App Store as they want. We have to consider this.

@Diskdance , I saw you added exmaple of Signal and ProtonVPN, that in China, neither works.

Signal hides "censorship circumvention" switch deeply in "Advanced settings", and it seems to try obfuscating traffic as like connecting to Google, but domains of Google itself are blocked.

ProtonVPN' censorship circumvention doesn't work too. Probably the domains of DoH servers are blocked?

That list is just for everyone's reference. They may not work in China currently, but we can possibly leverage their technique.

I recently read this proposal: Streamline the sign-up process for new editors from China.

It made a total of 3 plans:

1. Automate the IPBE applying process. I am very supportive of this.
2. Create an official, censored mirror of Wikipedia. I disagree with this.
3. Let the Wikimedia Foundation spend money to provide VPNs to Chinese users. It must be kidding.

These are all targeted on WWW version of Wikipedia, but in Wikipedia app, it already has a sign up feature, users can take advantage of this if app's domain fronting feature is added.

@Diskdance Ah, I remembered another thing. I don't think we need to worry about the Wikipedia app being removed from the China App Store at all. Because: Wikipedia is blocked in China, on iOS if people want to access it they have to have a VPN, and if he has a VPN, he must have a foreign Apple ID before, because, you know, Almost all VPN apps were removed in China App Store in 2017. So we don't have to worry about users not having an Apple ID outside the region to download the Wikipedia app.

EDIT: If the Wikipedia app is taken down, it won't matter to old users, who already have Apple IDs in other regions. But we might lose some new users who don't have a VPN and don't have an foreign Apple ID. Helpless.

Is the Wikipedia app is available on Apple's App Store? (My iPad region is US so I cannot check it out.) Google Play is blocked. And I don't think the app exists on the app stores Android phone manufacturers provides us with.

In T327286#8936603, @ZauberViolino wrote:

Is the Wikipedia app is available on Apple's App Store? (My iPad region is US so I cannot check it out.) Google Play is blocked. And I don't think the app exists on the app stores Android phone manufacturers provides us with.

Sure, the Wikipedia app is available for iOS on the Apple app store.

And for Android, if you are unable to use the Google Play Store, you may install the app from F-Droid, or if all else fails, download and install the latest APK directly.

I checked my friend's App Store and to my surprise the Wikipedia app do exist on China store. F-Droid is not blocked, at least not in my region.

For everyone's info, F-droid has been blocked in China now.

Changed description due to this following:

1. WMF knows how their servers are blocked
2. Hardcoding IPs are not feasible because IPs can be blocked as well, and WMF rejected the proposal to rotate IPs due to its unsustainability
3. Needed to emphasize why this is important, and why it's better than other solutions

I've already implemented it for Android.
https://github.com/wikimedia/apps-android-wikipedia/pull/4989

Recent days, WMF somehow changed their GeoDNS so that requests from China would get a not yet blocked IPv4 address.

I have to mention that on Oct 1 WMF projects were resolved back to the blocked servers in San Francisco (ulsfo) with the IPv4 address 198.35.26.96.

@Naruse_shiroha Thank you for the patch. But to make this functionality as robust as possible, I believe someone should work with the SRE team to discuss which path and strategy to choose.

If this is implemented ahead of that, I'm afraid there exists the possibility that a simple change from WMF or the GFW will stop it from working.

a simple change from WMF...will stop it from working

You mean the IP change? Emmm, it doesn't stop it from working for the IPv6 stack. IP blocking is always frustrating, though; the author of fqrouter stopped all of his work disappointedly because of it, and Wikimedia doesn't have so many IPs like Google.

Another patch for storing a list of available IPs? I don't think it's necessary (currently at least). See here.

The challenges, to name a few:

1. The GFW can easily stop @Naruse_shiroha's PR from working by blocking all IPv4s and IPv6s from the WMF ASN. They can do this whenever they want and it's as easy as adding a few entries in their blocklist but much harder for WMF to circumvent.
2. To fully mitigate 1, a large third party network provider (blocking which causes collateral damage) must be involved, and this has potential privacy and legal issues.
3. Although WMF servers currently ignores SNI, this is not explicitly guaranteed by WMF. A breaking change can cause the PR to stop working. This is where discussion is needed.

In T327286#10194390, @ZauberViolino wrote:

Recent days, WMF somehow changed their GeoDNS so that requests from China would get a not yet blocked IPv4 address.

I have to mention that on Oct 1 WMF projects were resolved back to the blocked servers in San Francisco (ulsfo) with the IPv4 address 198.35.26.96.

This temporary change of IPs was incidental due to operational failover because of hardware failure. If we tried this as a strategy, we have limited public IPs we own and they'd just block them all over time. We do have long-term aims to mitigate these censorship issues properly, even for the browser users rather than just the app, but those plans take time, and we can't discuss them in public so far ahead of implementation.

In T327286#10220994, @BBlack wrote:

In T327286#10194390, @ZauberViolino wrote:

Recent days, WMF somehow changed their GeoDNS so that requests from China would get a not yet blocked IPv4 address.

I have to mention that on Oct 1 WMF projects were resolved back to the blocked servers in San Francisco (ulsfo) with the IPv4 address 198.35.26.96.

This temporary change of IPs was incidental due to operational failover because of hardware failure. If we tried this as a strategy, we have limited public IPs we own and they'd just block them all over time. We do have long-term aims to mitigate these censorship issues properly, even for the browser users rather than just the app, but those plans take time, and we can't discuss them in public so far ahead of implementation.

Ah so this IP change is caused by WMF instead of GFW then?

instead of GFW then?

GFW is an injector, it cannot stop or change the authoritative server's packet, it also has no direct control of ISP's recursive resolver.

In T327286#10223423, @Naruse_shiroha wrote:

GFW is an injector, it cannot stop or change the authoritative server's packet, it also has no direct control of ISP's recursive resolver.

I only noticed the resolve result change in mainland China so I just assumed that GFW changed the target IP of DNS spoofing. So it was just a temporary change by WMF due to hardware failure in late September? I'm writing the relative section of the annual report for my unrecognized user group and I would like to get this incident staight.