I think that's an excellent idea and very much aligned with our commitment to provide free information also for those who are living under unfavorable conditions. I personally endorse it. Thanks Cristian for suggesting it. Regards, Micru On Jun 5, 2017 19:11, "Cristian Consonni" <cristian(a)balist.es> wrote:

enabling read access via Tor shouldn't be an issue, however editing should not be allowed due to high volume of known abuse from that vector. On Mon, Jun 5, 2017 at 1:43 PM, David Gerard <dgerard(a)gmail.com> wrote:

Im not going to violate BEANS, but even allowing accounts to edit without further hurdles isn't going to work. Because of the anonymity that tor provides its fairly easy to cause widespread issues. When the vandals start actually using tactics the flood gates of TOR will cause massive issues cross wiki that requires steward level intervention on a regular basis. On Mon, Jun 5, 2017 at 2:53 PM, Gabriel Thullen <gabriel(a)thullen.com> wrote:

Nope. Tor users needs `ip block exempt` or `global ip block exempt` to edit. https://en.wikipedia.org/wiki/Wikipedia:IP_block_exemption seem to say so too. ("In highly exceptional circumstances, an editor may be permitted to edit anonymously, via Tor or another anonymizing proxy.") -- Yongmin Sent from my iPhone https://wp.revi.blog Please note that this address is list-only address and any non-mailing list mails will be treated as spam. Please use https://encrypt.to/0x947f156f16250de39788c3c35b625da5beff197a. 2017. 6. 6. 03:53 Gabriel Thullen <gabriel(a)thullen.com> 작성:

On 05/06/2017 19:43, David Gerard wrote: On 05/06/2017 19:47, John wrote: On 05/06/2017 21:01, John wrote: start Allow me to reiterate that I am not proposing any change to the current policies regarding editing via Tor or other open proxies. Even with an onion service, anonymous editing will still be blocked and registered users will still need to apply for IP block exemption before being able to edit. I have read several discussions on the topic (going back to 2006) and what I have understood from those is that the biggest issue with editing via Tor is sockpuppeting. Vandals and spammer could be handled (and blocked), sockpuppets would be much harder to identify. The problem is hard because it solving it requires to have a way to identify that two accounts with different IPs are related to the same real person without at the same time destroying the anonymity provided by Tor. There has been research on the topic (see, for example, Nymble[1]) but at the very least it would require some additional technical setup and testing. With this proposal I am not trying to solve that problem. I am just pointing out that: 1. having an onion service would increase the privacy of our readers and the (very few) people who are already allowed to edit via Tor. 2. is harder to block access to an onion service than to wikipedia.org (you basically need to block all accesses to Tor, but there are ways to circumvent that, too[2]). 3. supporting privacy-enhancing technology is good and people may need it or maybe they will start using Tor more. As it stands now, the biggest impact of this project (if it is successful) would be on operations and analytics. Cristian [1]: https://cgi.soic.indiana.edu/~kapadia/nymble/overview.php [2]: https://www.torproject.org/docs/pluggable-transports

On 05/06/2017 22:19, Todd Allen wrote: On 05/06/2017 22:34, Gabriel Thullen wrote: right now sockpuppeteers I understand your point of view and I am sympathetic to it. I also would like to find a solution to this problem right now, but what I have seen reading the past discussions is that in the last 10+ years our community has not been able to find a shared, workable proposal for allowing editing over Tor for everybody. In the end, I trust the opinion of those who have participated in the past discussions (with many very experienced users participating in them) to be better informed than myself on the topic of fighting sockpuppeteers, vandals and spammers. At the same time, what I am proposing is dealing with a single problem at a time, and also a different thing. An onion service would be good regardless of the fact that it can be used just for reading or for reading and writing. To the best of my knowledge, the current proposal shouldn't cause any disruption to the projects with our current policies (and, please, you are invited point out any issues you may see with it). Also, if we see that this service is used then we may have an additional data point to reason about the opportunity of allowing editing over Tor. In other words, if we have many readers maybe we could have some editors, too, and it would be more justified to put some resources towards trying to solve this much harder problem. Cristian

Cristian Consonni wrote: This Phabricator comment you found seems pretty useful: <https://phabricator.wikimedia.org/T71333#728636>. And Faidon posted in November 2014 about the establishment of a Tor relay: https://lists.wikimedia.org/pipermail/wikitech-l/2014-November/079392.html How does your proposal interact (if at all) with the existing Tor relay set up in late 2014? It's unclear to me whether "Tor onion service" in this context is equivalent to a Tor exit node. I'm fairly sure setting up the latter has been discussed previously on wikimedia-l and/or wikitech-l. MZMcBride

By the way a certain degree of accountability is needed. There cannot be any privacy for "wikingers" or people bringing cyberbulling to wiki. Vito 2017-06-06 2:10 GMT+02:00 Risker &lt;risker.wp(a)gmail.com&gt;om>:

On 06/06/2017 02:10, Risker wrote: Let me put it this way, I am sure that the WMF will always do its best to protect the privacy of our readers and editors. Alas, I am much more concerned by third parties trying to snoop on our users. We also know that this kind of surveillance happened and that's also why the WMF is currently engaged in a lawsuit against the NSA. Using Tor to visit (i.e. read) wikipedia.org provides additional privacy and users can also circumvent blocks in their country, if necessary. Having an onion service gives similar benefits. Furthermore, I think it is very important that major Internet websites provide themselves as an onion service. Even Facebook did it (at https://www.facebookcorewwwi.onion/) and there are good privacy and censorship-circumventing reasons for this[1]. I think that the least difference between the "privacy enhanced" (aka dark) net and the regular internet there is the more people will consider to use Tor. I think this is a good thing. Frankly, I hate it when I hear Tor and onion services nominated by newspapers and newscasts only when talking about illegal activities. Then I remind myself that Snowden used Tor extensively and without it we probably would have not know about the NSA mass surveillance. I think that having an onion service may be useful, but I also think that we could have it just because we should. I understand the difficulties. Again, I don't think we should conflate the idea of providing Wikipedia as an onion service with the issues related to editing Wikipedia over Tor or open proxies. [1]: https://blog.torproject.org/blog/facebook-hidden-services-and-https-certs

Quick update, as this story went on Motherboard https://motherboard.vice.com/en_us/article/wikipedians-want-to-to-put-wikip… ;-) Aubrey On Tue, Jun 6, 2017 at 12:22 PM, Cristian Consonni &lt;cristian(a)balist.es&gt; wrote:

Apposite, but defective in a number of respects; also, explicitly advocacy for Tor editing without really addressing the objections to it (that it's 99+% a firehose of garbage). Rather than me reading through several pages to pick out what you might mean, could you please quote the bits you consider particularly make a relevant point? - d. On 10 June 2017 at 15:30, Cristian Consonni &lt;cristian(a)balist.es&gt; wrote:

06.06.2017, 01:11, "Risker" &lt;risker.wp(a)gmail.com&gt;om>: Risker, example of "pure unadulterated trash" edits on Wikipedia, or are we just to take your word for it? You know, how about two examples? Trillium Corsage

FYI: Editing through tor is blocked for logged in users too, unless you have `ipblock-exempt`. (It's included in admins and IP Block Exemptions.) On 2017-06-13 18:26, Dariusz Jemielniak wrote: -- Yongmin Hong https://wp.revi.blog Please note that this address is list-only address and any non-mailing list mails will be treated as spam. Please use https://encrypt.to/0x947f156f16250de39788c3c35b625da5beff197a

Now that we have ascertained (again) that wikimedia-l is a ​poor channel for focused discussions about tech proposals, can we move this to Phabricator?

This conversation has gone in multiple directions. It started with reading Wikipedia through a hidden service. I am interested only in talking about editing Wikipedia with Tor. I feel that the negativity in this thread against Tor is unwarranted and ignorant. I can confirm that Wikipedia needs its defense and should not open pathways to let problematic users vandalize Wikipedia. I dispute that there is any reason to believe that having a safe process for granting editing rights to certain vetted Tor users should be problematic. In fact, block exemptions are not granted in a reasonable way. In discussions about Tor often I feel like users become wild and accusatory. When I hear harsh accusations, I often feel that they are coming from people who do not understand the proposals that have come in over the years for allowing Tor access to certain users. The big recurring idea is that users with registered accounts can request review for their wiki editing, or new accounts could be watched or sponsored by established users. If they pass review, they get to edit from Tor. If they do not pass review, then they cannot. Anyone who says, "No Tor, it would create a flood of bad edits" is probably unaware of what Tor advocates are requesting, or at least, I have never heard from anyone who has this view and who could have a conversation. Here are some stories I have heard from established Wikipedia editors who want to edit with Tor: - A well known LGBT+ activist and contributor to projects in the open movement lives in a country where being LGBT+ is a serious crime. - A person who is in the witness protection <https://en.wikipedia.org/wiki/witness_protection> program of their country and is willing to share government provided proof of their need for privacy has made a request for an en:Wikipedia:IP block exemption <https://en.wikipedia.org/wiki/Wikipedia:IP_block_exemption>, and was denied and cannot edit with Tor. - A major international conference in the open movement hosted a speaker and presenter who claimed to be a refugee from their own country and expected never to return, and claimed that editing Wikipedia was the primary factor in their government's persecution of them. Restricting these kinds of users is sad and unnecessary. On-wiki and by email are not paths to reasonable conversation on this topic. If anyone wants to have conversation I would talk by phone or video chat. I also posted a lot about this on-wiki, but it is a lot to take in. More reading - RfC: Grant exemptions to users in good standing on request < https://en.wikipedia.org/wiki/Wikipedia_talk:IP_block_exemption#RfC:_Grant_… Partnership between Wikimedia community and Tor community < https://meta.wikimedia.org/wiki/Grants:IdeaLab/Partnership_between_Wikimedi… On Tue, Jun 13, 2017 at 4:34 PM, John Erling Blad &lt;jeblad(a)gmail.com&gt; wrote: > Blocking a registered user on TOR is not different from blocking a > registered user outside TOR. > 5. jun. 2017 21.02 skrev "John" &lt;phoenixoverride(a)gmail.com&gt;om>: > > Im not going to violate BEANS, but even allowing accounts to edit without > > further hurdles isn't going to work. Because of the anonymity that tor > > provides its fairly easy to cause widespread issues. When the vandals > start > > actually using tactics the flood gates of TOR will cause massive issues > > cross wiki that requires steward level intervention on a regular basis. > > > On Mon, Jun 5, 2017 at 2:53 PM, Gabriel Thullen &lt;gabriel(a)thullen.com> > wrote: > > > > I imagine registered users could edit through TOR. That is how it works > > > with my school IP: anonymous edits are blocked, account creation as > well, > > > but you can sign in an edit. > > > > > On Mon, Jun 5, 2017 at 7:47 PM, John &lt;phoenixoverride(a)gmail.com> wrote: > > > > > > enabling read access via Tor shouldn't be an issue, however editing > > > should > > > > not be allowed due to high volume of known abuse from that vector. > > > > > > > On Mon, Jun 5, 2017 at 1:43 PM, David Gerard &lt;dgerard(a)gmail.com> > wrote: > > > > > > > > Editing may be a tricky one, particularly on en:wp, which has found > > > > > Tor exit points to overwhelmingly be fountains of garbage, and > > > > > automatically blocks them. > > > > > > > > > > > > > - d. > > > > > > > > > > > > > On 5 June 2017 at 18:30, David Cuenca Tudela &lt;dacuetu(a)gmail.com> > > wrote: > > > > > > I think that's an excellent idea and very much aligned with our > > > > > commitment > > > > > > to provide free information also for those who are living under > > > > > unfavorable > > > > > > conditions. > > > > > > > > > > > I personally endorse it. > > > > > > > > > > > Thanks Cristian for suggesting it. > > > > > > > > > > > Regards, > > > > > > Micru > > > > > > > > > > > On Jun 5, 2017 19:11, "Cristian Consonni" &lt;cristian(a)balist.es> > > wrote: > > > > > > > > > > >> Hi, > > > > > >> > > > > >> I have written a proposal about setting up an onion (hidden) > > service > > > > to > > > > > >> serve Wikipedia over Tor: > > > > > >> > > > > >> https://meta.wikimedia.org/wiki/Grants:IdeaLab/A_Tor_ > > > > > >> Onion_Service_for_Wikipedia > > > > > >> > > > > >> I was thinking about this and I also discovered that the > Internet > > > > > >> Archive is experimenting with a very similar idea: > > > > > >> www.hackerfactor.com/blog/index.php?/archives/750- > > > > > >> Freedom-of-Information.html > > > > > >> > > > > >> I would like to have some feedback on this, I am also in contact > > > with > > > > > >> the author of the aforementioned proxy which could be able to > give > > > > some > > > > > >> help in setting it up. > > > > > >> > > > > >> Thank you. > > > > > >> > > > > >> 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(a)lists.wikimedia.org > > > > > >> Unsubscribe: https://lists.wikimedia.org/ > > > mailman/listinfo/wikimedia-l > > > > , > > > > > >> <mailto:wikimedia-l-request@lists.wikimedia.org?subject= > > > unsubscribe> > > > > > _______________________________________________ > > > > > > 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(a)lists.wikimedia.org > > > > > > Unsubscribe: https://lists.wikimedia.org/ > > > mailman/listinfo/wikimedia-l, > > > > > <mailto:wikimedia-l-request@lists.wikimedia.org?subject= > unsubscribe> > > > > > > > > _______________________________________________ > > > > > 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(a)lists.wikimedia.org > > > > > Unsubscribe: https://lists.wikimedia.org/ > > mailman/listinfo/wikimedia-l, > > > > > <mailto:wikimedia-l-request@lists.wikimedia.org?subject= > unsubscribe> > > > > > > > _______________________________________________ > > > > 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(a)lists.wikimedia.org > > > > Unsubscribe: https://lists.wikimedia.org/ > mailman/listinfo/wikimedia-l, > > > > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe> > > > > > _______________________________________________ > > > 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(a)lists.wikimedia.org > > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > > > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe> > > > _______________________________________________ > > 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(a)lists.wikimedia.org > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe> _______________________________________________ > 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(a)lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe -- Lane Rasberry user:bluerasberry on Wikipedia 206.801.0814 lane(a)bluerasberry.com

On 07/06/2017 20:24, Alec Muffett wrote: 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 [1]: https://www.youtube.com/watch?v=HNJaMNVCb-U

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:

hi Faidon, On Wed, Jun 14, 2017 at 4:57 PM, Faidon Liambotis &lt;faidon(a)wikimedia.org&gt; wrote: the reason to think about some use of Tor for me, considering the mixed feelings about the technology in our community, would be in the app, and just for reading. If our app used Tor by default, all users in Turkey would magically find Wikipedia to work on their phones :) Facebook app allows Tor, but not by default (because it kills notifications). I believe that such a use of Tor would possibly be neutral to many people who otherwise oppose allowing editing through Tor. dj

On Tue, Jun 13, 2017 at 7:12 PM, Risker &lt;risker.wp(a)gmail.com&gt; wrote: ​My entire experience with Tor has been through human rights activists who fear for their lives. It is unclear to me how allowing people, who have legitimate security concerns, to read and contribute to open knowledge, is "actively supporting the dark web". ​At least on TV, the "dark web" is a very loaded term. The proposal (as I understand it) would not allow any Tor user to do anything other than access our projects. That's different from setting up a general Tor entry or exit node, which would facilitate other uses. ​Kevin​

On 14 June 2017 at 16:08, Brad Jorsch (Anomie) &lt;bjorsch(a)wikimedia.org&gt; wrote: This is basically what we did at Facebook; architecture and other tips are published at https://storify.com/AlecMuffett/tor-tips The only real "gotcha" with such an approach is to only "onionify" links which are in the process of being rendered to go to the user's browser; if your software stack also makes site-internal fetches (eg: for database access) in order to render a page, then onionifying *those* will result in badness. The other nice thing to bear in mind is that onionification is generally best done with 1:1 mappings between onion addresses and DNS domains, and that consistency is beneficial; in other words: foo.com <-> aaaa1111.onion bar.com <-> bbbb2222.onion ...and even if you are rendering a page for foo.com/aaaa1111, you'll get a nicer experience by also fixing-up the bar.com/bbbb2222 HREFs, should you happen to generate any. This is one point where EOTK wins-out, because it operates after-the-fact of content generation & site caching, so has a marginally easier time; the demo EOTK config for a Wikipedia onion currently performs 11 simultaneous mappings, as documented at: https://github.com/alecmuffett/eotk/blob/master/demo.d/wikipedia.tconf - alec -- http://dropsafe.crypticide.com/aboutalecm

Hi Faidon, On 16/06/2017 20:12, Faidon Liambotis wrote: Question: would it be possible to activate it for specific projects, say Italian Wikipedia?(*). I don't see major technical obstacles in doing just one project - i.e. one subdomain - at a time, besides the fact that the value of having just one project as an onion service would be much less (for the obvious reason that any time that the user would go to Commons, Wikidata or another language it would exit the service). Of course this route would make the "resource balance" even worse at the beginning, but on the other hand it would be a nice test. For what is worth, it.wiki was also one of the first projects to opt-in for Wikidata interwiki transfer, if we want to follow the "test on small projects first" logic, so I hope to leverage the little (but proud :P) tradition with testing new features at scale of the it.wiki community. Cristian (*) I would also love to mention Turkish Wikipedia, but I don't speak Turkish and I would not be able to reach out to that community, at least not enough to start and follow a discussion on such a proposal.

I quite agree that Phabricator is not suitable for these discussions. Perhaps Tim would like to say where and how discussions between the Community and Foundation staff about the need for, and desirability of, projects like this should be held. After all, we all want projects to go ahead on the basis of Community input, don't we? On Mon, Jun 19, 2017 at 6:09 AM, Tim Starling &lt;tstarling(a)wikimedia.org&gt; wrote:

On Mon, Jun 19, 2017 at 09:35:10PM +1000, Tim Starling wrote: If Tor users are valueable to us enough to justify maintaining (small pieces of) code and infrastructure to support them, then surely that means that the Tor network itself is valueable too, doesn't it? In other words, if we decide to embark on this project or another Tor-focused project (like Tor support in our mobile apps), we'd do because we recognize that it is of benefit to a particular segment of users who are unable to access us due to censorship (or worse), not for a handful of security-conscious users. In my view, this automatically means that we value the Tor network, as a medium, for enabling this kind of use, and putting a small amount of resources to strengthen it is justified and mission-aligned. Not entirely different than what we do with other pieces of infrastructure as good Internet and Linux citizens. The flip side of this is to argue that the Tor network is predominantly used for illegimate, ethically bad uses, like the ones you mentioned. In that case, I don't see why we would want to spend any of our resources on it whatsoever and go anywhere near it. I obviously don't believe that, but that would be a consistent PoV that I'd happy to argue against and eventually oblige to, if that was the consensus we came to. Regards, Faidon

Tim, I'm taking your response as a rather lengthy way of saying that there is no convenient central location for discussions of the sort that ought to be taking place around this and other projects. Is that correct? "Rogol" On Mon, Jun 19, 2017 at 12:35 PM, Tim Starling &lt;tstarling(a)wikimedia.org&gt; wrote:

Hi, On 19/06/2017 13:35, Tim Starling wrote: On 19/06/2017 14:39, Faidon Liambotis wrote: This is an interesting discussion and as Tor relay operator I have asked myself questions along this lines more than once. Here's some of my opinions on the matter. There is a "mechanistic" view for which Tor is just a tool, as computers themselves, which can be used for good and bad. In other words, Tor is just a technological stack that provides end-to-end encryption for computers[1]. In this view, Tor is not much different from your modem and a node operator is not much different from your ISP or a provider of other internet services. Having been in the position of arguing with a VPS provider about running a Tor node on their network I have asked them why in their contract they can decline any responsibility with respect of the service they use and I can't do the same with respect to the user of the Tor network. In short, since Tor is a tool it can be used for good or bad and every user is responsible for her own use of the network. On the other hand, I think that some people (myself included) decide to contribute to Tor because they see some inherent value in it and not just because it is a fun tool, freely available to use. To be fair, the Tor legal FAQs say this explicitly[2a]: --- Should I use Tor or encourage the use of Tor for illegal purposes? No. Tor has been developed to be a tool for free expression, privacy, and human rights. It is not a tool designed or intended to be used to break the law, either by Tor users or Tor relay operators. --- As Faidon points out the flip side of this argument is that you need also to consider the bad uses of the network. You could use an utilitarian approach and try to weigh the goods against the bad. This is in general very difficult and probably varies very much from person to person. In addition to that there is the fact that it is difficult to obtain data about the usage of Tor, here some sources: * a blog post from the Tor project "Some statistics about onions"[2b], which reports that (as of early 2015) "hidden service traffic is about 3.4% of total Tor traffic." * This talk from 31C3 (the Chaos Communication Congress of 2014) titled "Tor: Hidden Services and Deanonymisation"[2c] by Dr Gareth Owen of University of Portsmouth that conducted a survey of hidden services. service traffic is by far child pornography. It may depend on the fact that there are association and public agencies that monitor this sites * This paper: "Content and popularity analysis of Tor hidden services."[2d] by Biryukov et al. A relevant quote: «We discovered a huge number of hidden services that are part of the “Skynet” botnet [...]. The number of hidden services with illegal content or devoted to illegal activities and the number of other hidden services (devoted to human rights, freedom of speech, anonymity, security, etc.) is almost the same;» Instead, you can have a more proactive vision of your actions (or your community's actions) and think that you can try to get things better for the measure that you are able to do it. This is also coherent with what Faidon says that we contribute to the greater ecosystem of software to be "good Internet and Linux citizens". Personally, the latter is the vision I relate the most and the reason for which I started contributing to the Tor network as a node operator. Cristian [1]: https://medium.com/@alecmuffett/tor-is-end-to-end-encryption-for-computers-… [2a]: https://www.torproject.org/eff/tor-legal-faq.html.en [2b]: https://blog.torproject.org/blog/some-statistics-about-onions [2c]: https://media.ccc.de/v/31c3_-_6112_-_en_-_saal_2_-_201412301715_-_tor_hidde… [2d]: Biryukov, Alex, et al. "Content and popularity analysis of Tor hidden services." Distributed Computing Systems Workshops (ICDCSW), 2014 IEEE 34th International Conference on. IEEE, 2014.

On Wed, Jun 21, 2017 at 11:46:11PM +0100, Alec Muffett wrote: Cipher suites can be found here: https://phabricator.wikimedia.org/source/operations-puppet/browse/productio… The "type" argument specifies, essentially, the compatibility level depends on the endpoint we're securing -- we can be more aggressive for e.g. developer tools, where we don't expect old browsers or operating systems. For the main websites, the level right now is "compat". The list of ciphers is constantly evolving, as old browsers drop below certain thresholds and become unsupported. For example, there is work underway to phase out DES-CBC3-SHA, breaking IE8-on-Windows-XP, cf. https://phabricator.wikimedia.org/T147199. The rest of the HTTPS nginx config can be found at: https://phabricator.wikimedia.org/source/operations-puppet/browse/productio… (note that wikimedia-l attracts a wider audience, not just engineers, so the above may be something that's not to everyone's interest here; wikitech-l would probably be more appropriate if you have further questions or input around technical matters :) It would be and yes, typically each language/project combination (but note: language, not geography) operate separately/independently. There is https://meta.wikimedia.org/ for broader/global community decisions, though. Plus a few other exceptions, too :) Best, Faidon -- Faidon Liambotis Principal Engineer, Technical Operations Wikimedia Foundation