Hi Cristian,
[ I didn't see this email from Alec on the thread, was it off-list? ]
I've been in touch with Alec and other Tor project members on emails, in-person Tor project meetings and videoconferences on multiple occasions in the past couple of years (the last one being a couple of months ago), so I can speak a little bit about this idea in general, as well as EOTK specifically.
The EOTK stuff are interesting but not really an option for us -- they rely on a edge (nginx) server performing content manipulation blindly, which is a bad idea for many reasons, security amongst them.
It is possible and feasible to actually do it properly, by making some modifications across our stack (MediaWiki, Varnish/nginx). Just to mention a couple of issues: one of them is that we need MediaWiki to emit different URLs for e.g. upload.wikimedia.org resources to point to the onion address that we will designate for media. For other resources (like gadgets) it may be even more complicated or even impossible. Another challenge would be to make Extension:TorBlock aware of the Onion connections, so that they can be appropriately blocked, as well as figure out what to log as the users' IP address when they edit, if they are pre-approved to do so.
Overall, it's not a super complicated project but not a trivial one either. Maybe a couple of months time for a motivated individual, who is already familiar with our stack.
If it wasn't obvious from the above, I have put quite a bit of thought into it and that's because I share your sentiments about how this is an important feature we should support and provide to our users, in alignment with our mission.
However, it hasn't been a priority for me or my team for these reasons: - As long as communities feel so-and-so about Tor overall, and e.g. block edits from Tor users, it's hard to justify us in the Foundation investing more time into it, at the expense of other projects. It feels at odds with our communities' wishes a little bit.
- Accessing our sites over the Tor network *is* possible, regardless of whether we provide an Onion service or not, via exit nodes. An Onion service is more of a security and performance optimization and, perhaps more importantly, a statement of support. Making a statement of support while at the same time communities continue blocking edits over Tor and we keep maintaining Extension:TorBlock, would be a little hypocritical of us, the Wikimedia movement, IMHO.
- Looking at it more broadly, Foundation-wide, if we had to invest resources into our Tor support, I think adding Tor support to our mobile apps would be a better use of our limited resources.
Hope this helps. Happy to help you move this forward if there are ways to do so.
Best regards, Faidon -- Faidon Liambotis Principal Engineer, Technical Operations Wikimedia Foundation
On Wed, Jun 14, 2017 at 04:27:12PM +0200, Cristian Consonni wrote:
On 07/06/2017 20:24, Alec Muffett wrote:
If it helps, I built an betatest onion for Wikipedia and all(?) the Wikimedia Foundation websites using EOTK* a few months ago, and documented the build process at:
https://github.com/alecmuffett/eotk/blob/master/docs.d/RUNBOOK.md
A basic test onion takes about 5..10 minutes to set up on Ubuntu or OSX/Homebrew.
A scalable full production loadbalanced deployment on some kind of cloud orse server(s) should take a day or two, plus time to buy an Onion SSL Certificate where appropriate.
Thanks Alec.
I would also point out the offer you made in a tutorial video for EOTK[1]:
"If anyone from Wikipedia or Wikimedia is watching this video I would gladly help you guys set one of this up officially because it is really cool"
It is. It also useful, mission-aligned, and important.
So, please read my proposal as "Take this offer from Alec Muffett"
Cristian
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe