I'd be all for implementing Orbot to our app, ideally in a way that would by default route through Tor if content does not load normally (so, by default - automatic second attempt at loading), and also give a choice to default to Orbot. Still, automatic second attempt is important, as users are often not technically conscious, and this solution would effectively work around e.g. country-specific blocks.

As I understand it we first need a Tor service which is tracked by T168218

In T163747#3787900, @hashar wrote:

As I understand it we first need a Tor service which is tracked by T168218

No, this can be implemented without the hidden service.

I second what Legoktm is saying: adding the option (or default) of using Orbot to route the traffic of the Wikipedia is completely independent of creating a Tor hidden service.

Using Orbot in the app would be like using the Tor browser on the desktop to visit wikipedia.org.

Two things are being conflated in this ticket, which i think should be separate:

• using tor to provide privacy (specificly, to prevent a local [in the sense of monitors only a part of the network. Not in the sense of necessarily near the end user] passive adversary from determining which domain the user is visiting): this does make sense, but we would have to be careful about how we talk about this to users. In some cases using tor will make you stick out more.
• provide censorship resitence: I suspect this what most people who are discussing this bug want. However its also where this bug stops making sense. Tor can be blocked just as easily as wikipedia. Is the assumption here that tor is to obscure to be blocked (seems unlikely. Particularly if we add it to the app for the express purpose of getting around censorship)? Is the assumption that the app will come preloaded with a secret and unique (to each app install) set of bridges? (Seems impossible). Is the assumption that users will find and enter bridge info themselves (do-able, but that assumes a really advanced user who probably wouldnt need tor included in the app)?

Anyways, goals, assumptions and threat models for this ticket really ought to be clarified.

Change 411493 had a related patch set uploaded (by Arlolra; owner: Arlolra):
[apps/android/wikipedia@master] [WIP] Orbot integration

https://gerrit.wikimedia.org/r/411493

Change 411493 abandoned by Arlolra:
Orbot integration

https://gerrit.wikimedia.org/r/411493

I am not a developer, but I created an account to express my support for this feature request. I have a tendency to write long issue tracker comments, so fair warning:

In T163747#3791349, @Bawolff wrote:

Two things are being conflated in this ticket, which i think should be separate:

• using tor to provide privacy (specificly, to prevent a local […] passive adversary from determining which domain the user is visiting) […]
• provide censorship resitence: […]

Anyways, goals, assumptions and threat models for this ticket really ought to be clarified.

My vote to prioritize censorship circumvention. Wikipedia censorship is of course a huge issue, so I think making the app more easily accessible better aligns with Wikipedia’s mission and values. I assume the app uses an encrypted/secure connection (someone please tell me that’s the case) which should be enough for most users.

However, I don’t see how catering to both users hardening their privacy and users blocked from Wikipedia would *not* be possible.

A simple switch or checkbox in Settings to enable Orbot, which is the conventional way it’s implemented in apps, meets the needs of both. Though I recognize that more can be done for users under censorship, especially those who could be helped by user discovery and education aides, to make the process of using connecting via Orbot friendlier for even the least technologically-savvy users.

For fun, here are UX examples for discovery and education aides. The existing “Cannot connect to internet” error message could have a small link like this:

│  						│
│  						│
│	   Cannot connect to internet		│
│		    {RETRY}			│
│  						│
│  						│
│       _Are you blocked from Wikipedia?_	│
│  						│
│  						│

│  						│
│  						│
│ ┌ 					      ┐ │
│ │ Connect via Tor			      │ │
│ │ ————————————————————————————————————————— │ │
│ │ If you suspect that your network is       │ │
│ │ censoring or blocking Wikipedia, you can  │ │
│ │ use Orbot to connect via Tor. _Learn more_│ │
│ │ 					      │ │
│ │ 			  {CANCEL}  {CONNECT} │ │
│ └ 					      ┘ │
│  						│
│  						│

The same modal could pop up when enabling Orbot in Settings, should someone discover the option there. The “learn more” link could be a short intro/tutorial describing Tor and how to use Orbot. Perhaps it would be best to include this intro/tutorial in-app instead of a web page, should it also be blocked.

There could also be an option to only temporarily enable Orbot (e.g. until app restart), for users like a student who is blocked when using his school’s network but not at home.

Lastly, in my honest option I don’t think @Pundit’s proposal (T163747#3785913) of using Orbot automatically is optimal, at least by default. App behavior should be transparent to mitigate any user confusion. Additionally, connecting to Tor should always be a deliberate act – not only because of Tor’s sensitive nature, but especially since Wikipedia blocks Tor users from editing. It would be frustrating for a user editing an article to tap Publish only to find they are blocked, merely because their flaky connection triggered the app to switch to Orbot.

That’s it for my ideas. I’m actually a “privacy hardening” use case – like library records of patrons’ checkout history, I’d like my Wikipedia usage to be private. However if we have to choose one approach, I think implementing Tor/Orbot for those under censorship would make a bigger impact.

Disclaimer: I am not a developer, so if I’ve made any assumptions about ease of development or proposed something too difficult to implement, my apologies in advance.