Friday, June 12, 2015

Tor Weekly News — November 12th, 2014

Welcome to the forty-fifth issue in 2014 of Tor Weekly News, the weekly newsletter that covers what’s happening in the Tor community.

Mozilla announces Polaris Privacy Initiative

Mozilla, makers of the Firefox browser upon which Tor Browser is based, announced a series of projects to “accelerate pragmatic and user-focused advances in privacy technology for the Web, giving users more control, awareness and protection in their Web experiences”. The Tor Project is one of Mozilla’s two partners in this Polaris Privacy Initiative, and the collaboration will involve looking at the Firefox codebase to see if its relationship to Tor Browser and the Tor development process can be made more efficient, giving Tor engineers more time to focus on other important issues. Mozilla also stated their intention to run several high-capacity Tor middle relays, contributing to a faster and more stable Tor network.
As Andrew Lewman wrote on the Tor blog, “the Tor Browser is one of the best ways to protect privacy on the web and this partnership is a huge step in advancing people’s right to freedom of expression online”. Watch for more announcements as work on these two fronts continues.

Tor and Operation Onymous

An international coalition of law enforcement authorities announced the seizure of over 400 Tor hidden services allegedly engaging in illegal activity. Once the desired headlines had been written, something approaching the facts began to emerge, with the claimed number of seized services dropping sharply to 27; more troublingly, several high-capacity Tor relays with no apparent connection to the hidden services were also seized. However, in contrast to the last major takedown of hidden services, which involved one shared hidden service hosting platform, there was no obvious single feature linking all of the seized sites, leading to concern in the Tor community that an exploit against the Tor network may have been responsible for their discovery.
It could be that these services were deanonymized individually over a period of months using a variety of means, then all seized at once for maximum effect: as Andrew Lewman and others wrote in a response posted to the Tor blog, these methods could include operational security mistakes by service operators, exploitation of flaws in poorly-written website code, or attacks on the Bitcoin cryptocurrency that is widely used on hidden service marketplaces. On the other hand, if an attack on the Tor network itself is at play, it may be a variant of the class of attack known as “traffic confirmation”, like the oneobserved earlier this year. “Unfortunately,” as the blog post notes, ”the authorities did not specify how they managed to locate the hidden services”; even if they had, recent disclosures concerning “parallel construction” in law enforcement mean that the public would not necessarily be able to trust their explanation.
“Hidden services need some love” has become a familiar refrain in recent months, and even though the story behind these seizures may remain unknown, they have reinvigorated some long-running threads on improvements to the security of this important technology. George Kadianakis coded a patch that allows hidden service operators to “specify a set of nodes that will be pinned as middle nodes in hidden service rendezvous circuits”, while the theory behind this continues to be discussed, as does the hidden service authorization feature and how widely it is used in practice.
“The attention hidden services have received is minimal compared to their social value and compared to the size and determination of their adversaries.” If you are a hidden service operator concerned by these seizures, or you want to help ensure the possibility of free and uncensorable publishing online, see the group blog post for more details, and feel free to join in with the discussions on the tor-dev mailing list.

More monthly status reports for October 2014

The wave of regular monthly reports from Tor project members for the month of October continued, with reports from Isis LovecruftNicolas VigierDamian Johnson, and Karsten Loesing.
Roger Dingledine sent out the report for SponsorF.

Miscellaneous news

Arturo Filastò reported on OONI’s ongoing study of Tor bridge reachability in different countries, and the recent hackfest on the same topic.
Karsten Loesing offered an update on developments in the world of Onionoo, including new mirrors and search improvements.

Help desk round up

The help desk has been asked how to run Tor Browser on a Chromebook. ChromeOS does not allow any programs to be executed except Google Chrome, including other browsers like Tor Browser. The workaround for this is to install a Debian or Ubuntu environment within ChromeOS using crouton. Once crouton is ready, Tor Browser for Linux can be downloaded and installed in the Debian or Ubuntu environment. Crouton users should seek support from the crouton team and not from the Tor help desk.

This issue of Tor Weekly News has been assembled by Harmony, Matt Pagan, Karsten Loesing, and Lunar.
Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page, write down your name and subscribe to the team mailing list if you want to get involved!

Tor Weekly News — November 5th, 2014

Welcome to the forty-fourth issue in 2014 of Tor Weekly News, the weekly newsletter that covers what’s happening in the Tor community.

Tor 0.2.6.1-alpha is out

Following last week’s stabilization of Tor 0.2.5.x, Nick Mathewson announced the first alpha release in the Tor 0.2.6.x series. Quoting the changelog, this version “includes numerous code cleanups and new tests, and fixes a large number of annoying bugs. Out-of-memory conditions are handled better than in 0.2.5, pluggable transports have improved proxy support, and clients now use optimistic data for contacting hidden services.” Support for some very old compilers that do not understand the C99 programming standard, systems without threading support, and the Windows CE operating system has also been dropped.
“This is the first alpha release in a new series, so expect there to be bugs.” If you want to test it out, you can find the source code in the distribution directory.

Tor Browser 4.0.1 is out

Mike Perry announced a bugfix release by the Tor Browser team. This version disablesDirectShow, which was causing the Windows build of Tor Browser to crash when visiting many websites. This is not a security release, but Windows users who have experienced this issue should upgrade.
Please see Mike’s post for the changelog, and download your copy from the project page.

Facebook, hidden services, and HTTPS certificates

Facebook, one of the world’s most popular websites, surprised the Internet by becoming the most prominent group so far to set up a Tor hidden service. Rather than connecting through an exit relay, Facebook users can now interact with the social network without their traffic leaving the Tor network at all until it reaches its destination.
Soon after the service was announced, some in the Tor community expressed concern over the implications of its unusually memorable .onion address. Had Facebook somehow mustered the computing power to brute-force hidden service keys at will? Alec Muffett, one of the lead engineers behind the project, clarified that in fact “we just did the same thing as everyone else: generated a bunch of keys with a fixed lead prefix (‘facebook’) and then went fishing looking for good ones”, getting “tremendous lucky” in the process. Those concerned by how easy this seems, added Nick Mathewson, “might want to jump in on reviewing and improving proposal 224, which includes a brand-new, even less usable, but far more secure, name format”.
“Why would you want to use Facebook over Tor?” remains a frequently-asked (and -misunderstood) question, so Roger Dingledine took to the Tor blog to address this and related issues. “The key point here is that anonymity isn’t just about hiding from your destination. There’s no reason to let your ISP know when or whether you’re visiting Facebook. There’s no reason for Facebook’s upstream ISP, or some agency that surveils the Internet, to learn when and whether you use Facebook. And if you do choose to tell Facebook something about you, there’s still no reason to let them automatically discover what city you’re in today while you do it.” Not only that, but Facebook is now taking advantage of the special security properties that hidden services provide, including strong authentication (letting users be confident that they are talking to the right server, and not to an impostor) and end-to-end encryption of their data.
This last point generated some confusion, since Facebook have also acquired an HTTPS certificate for their hidden service, which might seem like an unnecessary belt-and-suspenders approach to security. This has been the subject of “feisty discussions” in the Internet security community, with many points for and against: on the one hand, users have been taught that “https is necessary and http is scary, so it makes sense that users want to see the string “https” in front of” URLs, while on the other, “by encouraging people to pay Digicert we’re reinforcing the certificate authority business model when maybe we should be continuing to demonstrate an alternative.”
Please see Roger’s post for a fuller discussion of all these points and more, and feel free to contribute your own thoughts on the tor-talk mailing list. If you experience problems with the service, please contact Facebook support rather than the Tor help desk; as Alec wrote in the announcement, “we expect the service to be of an evolutionary and slightly flaky nature”, as it is an “experiment” — hopefully an experiment that will, as Roger suggested, “help to continue opening people’s minds about why they might want to offer a hidden service, and help other people think of further novel uses for hidden services.”

Monthly status reports for October 2014

The wave of regular monthly reports from Tor project members for the month of October has begun. Juha Nurmi released his report first, followed by reports from Georg Koppen,Sherief AlaaPearl CrescentLunarHarmonySukhbir SinghColin C.Leiah Jansen,Nick MathewsonArlo BreaultNoel Torres, and George Kadianakis.
Lunar reported on behalf of the help desk, Arturo Filastò for the OONI team, and Mike Perry for the Tor Browser team.

Miscellaneous news

Mike Perry updated the Tor Browser design document to cover Tor Browser version 4.0 — “Feedback welcome! Patches are even more welcomer!”
Israel Leiva sent out an update on the progress of the GetTor redevelopment project.
David Fifield distributed a graph of “the number of simultaneous relay users for every country, one country per row”.
David also sent out a summary of the costs incurred by the meek pluggable transport, which have increased significantly following its incorporation into the latest stable Tor Browser and the consequent “explosion” in use.
Esfandiar Mohammadi announced the MATor project and accompanying paper. MATor is a tool that “assesses the influence of Tor’s path selection on a user’s anonymity”; “since MATor is an ongoing project, we would appreciate your opinion about the approach in general.”

Tor help desk roundup

The help desk has been asked if Tor Browser acts as a relay by default. Tor Browser’s Tor by default acts only as a client, and not as a bridge relay, exit relay, or relay. Additionally, this is unlikely to change in the future.

This issue of Tor Weekly News has been assembled by Lunar, Matt Pagan, Karsten Loesing, and Harmony.
Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page, write down your name and subscribe to the team mailing list if you want to get involved!

Tor Weekly News — October 29th, 2014

Welcome to the forty-third issue in 2014 of Tor Weekly News, the weekly newsletter that covers what’s happening in the Tor community.

Tor 0.2.5.10 is out

The 0.2.5.x branch of the core Tor software hit stable, with the release of 0.2.5.10. As Nick Mathewson explained, there have been no changes since last week’s 0.2.5.9-rc release, and the new features will be familiar to readers of Tor Weekly News over the past year of development, but highlights include “improved denial-of-service resistance for relays, new compiler hardening options, and a system-call sandbox for hardened installations on Linux”, as well as improvements to transparent proxying, building and testing, pluggable transport usability, and much more.
This release means that Tor versions in the 0.2.3.x series, which has “received no patches or attention for some while” and “accumulated many known flaws”, are now deprecated. Relay operators running these versions must upgrade as soon as possible, or risk having their relays rejected from the network in the near future.
Please see Nick’s release announcement for the full changelog, and download your copy of the 0.2.5.10 source code from the distribution directory or a prebuilt package from your usual repositories.

Miscellaneous news

Jacob Appelbaum announced version 0.1.3 of TorBirdy, a torifying extension for the Thunderbird email client. Among other things, this release fixes the recently-reported“wrote:” bug, disables the automatic downloading of messages from POP3 accounts, and ensures that draft messages for IMAP accounts are stored on the local system rather than sent over the network. However, as Jacob wrote, “it’s still experimental”, so “use at your own risk”. See the release announcement for a full changelog.
Anthony G. Basile announced version 20141022 of tor-ramdisk, the micro Linux distribution whose only purpose is to host a Tor server in an environment that maximizes security and privacy. This release addresses the recent POODLE attack with updates to Tor and OpenSSL, and also upgrades the Linux kernel.
Yawning Angel called for testing of the revamped tor-fw-helper, a tool that automates the port forwarding required (for example) by the flash proxy pluggable transport. Please see Yawning’s message for full testing instructions and other important information: “Questions, Comments, Feedback appreciated”.
On the Tor blog, Andrew Lewman responded to the abuse of Tor by creators of so-called “ransomware”, or malware that tries to restrict access to users’ files unless a ransom is paid; these extortionists sometimes ask their victims to install Tor software in order to communicate with them over a hidden service, leading users to the mistaken belief that The Tor Project is somehow involved. As Andrew wrote, this software “is unrelated to The Tor Project. We didn’t produce it, and we didn’t ask to be included in the criminal infection of any computer.” Users may find the information provided by the BBC and Bleeping Computer to be helpful in resolving the problem.
Josh Pitts posted an analysis of apparently malicious behavior by a Tor relay that was modifying binary files downloaded over Tor circuits in which it was the exit node. As Roger Dingledine responded, “we’ve now set the BadExit flag on this relay, so others won’t accidentally run across it”.
David Fifield pointed out “an apparent negative correlation between obfs3 users and vanilla users” in the Tor Metrics portal’s bridge user graphs and wondered what might be causing it.

News from Tor StackExchange

Dodo wants to run several hidden services (HTTP, XMPP, SSH etc.), but use just one onion address. Jobiwan explained that one can forward each port to a different service. Further information can be found at the configuration page for hidden services.
Rodney Hester proxies the DirPort of his relay and saw lots of requests to nonexistent URLs, of which the most prominent is the URL /tor/status/all.z, and asks where they are coming from. Do you have an answer? If so, please share it at Tor’s StackExchange site.

This issue of Tor Weekly News has been assembled by Lunar, qbi, Roger Dingledine, and Harmony.
Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page, write down your name and subscribe to the team mailing list if you want to get involved!

Tor Weekly News — October 22nd, 2014

Welcome to the forty-second issue in 2014 of Tor Weekly News, the weekly newsletterthat covers what’s happening in the Tor community.

Tor 0.2.5.9-rc is out

Nick Mathewson announced what is hopefully the final release candidate in the Tor 0.2.5 series. It contains two enhancements in response to the recent POODLE attack on OpenSSL, “even though POODLE does not affect Tor”, as well as a number of other miscellaneous improvements.
Upgrading is especially important for relay operators, as a remote crash is possible when older Tor versions are used with a version of OpenSSL released last week that was built with the “no-ssl3” flag.
As ever, you can download the source code from the distribution directory and packages should follow shortly.

Tor Browser 4.0 is out

Mike Perry announced a major release by the Tor Browser team. Version 4.0 of the secure and anonymous web browser brings several exciting new features to the stable series, including the meek censorship-circumvention tool, the secure updater, and a simplified Javascript enabling/disabling process in NoScript, all based on a customized Firefox ESR31. SSLv3 is also disabled, in response to the recent POODLE attack.
This release contains important security fixes, and all users should upgrade as soon as possible. Please note that the new directory structure means users cannot simply extract the new Tor Browser over their existing 3.6.6 directory, and must instead delete the old version entirely. The secure updater still requires manual activation in the “About Tor Browser” menu option, as its security will depend “on the specific CA that issued thewww.torproject.org HTTPS certificate (Digicert)” until site-specific certificate pinning andsigned update files are implemented. Furthermore, “we still need to improve meek’s performance to match other transports”, wrote Mike, “so adjust your expectations accordingly”.
See Mike’s post for further details and a full changelog, and get your copy of Tor Browser 4.0 from the distribution directory or the download page.

Tails 1.2 is out

The Tails team put out version 1.2 of the anonymizing live operating system. This release replaces the Iceweasel browser with “most of” the regular Tor Browser, and confines several important applications with AppArmor.
I2P will now, like Tor, be started upon network connection if activated with the “i2p” boot parameter, and must be used with the new dedicated I2P Browser. This is also the last Tails release to ship with the now-unmaintained TrueCrypt tool, but the Tails team has already documented the method for opening TrueCrypt volumes with cryptsetup. See the team’s announcement for a full list of changes in the new version.
This is an important security release and all users should upgrade as soon as possible. If you have a running Tails, you should be able to use the incremental updater; if your Tails drive was manually created, or you are a new user, head to the download page for more information.

Miscellaneous news

tagnaq warned users of TorBirdy, the torifying extension for the Thunderbird mail client, that a change in Thunderbird 31’s handling of the “reply_header_authorwrote” header means that the word “wrote”, translated into the user’s system language, may be inserted before quoted text when replying to emails, leaking the system language to recipients of replies if not removed. Jacob Appelbaum responded that a new release of TorBirdy addressing this and other issues was imminent.
Arturo Filastò announced the release of ooniprobe 1.1.2, containing “two new report entry keys, test_start_time and test_runtime”, and a fix for a bug that “led to ooniresources not working properly”.
evilaliv3 announced version 3.1.20 of tor2web, an HTTP proxy that enables access to hidden services without a Tor client, for users who do not require strong anonymity. As well as “some networking bugfixing and optimizations”, this release adds a “replace” mode for remotely-fetched blocklists in addition to “merge”, and a feature that allows different hostnames to be mapped to specific hidden services.
Karsten Loesing gave users of Onionoo a “one-month heads-up” that on or after November 15th, a change to the protocol will let the search parameter “accept base64-encoded fingerprints in addition to hex-encoded fingerprints, nicknames, and IP addresses.” These searches will also return relays whose base64-encoded fingerprints are a partial match for the search string. “If you’re fine with that, feel free to ignore this message and do nothing”, but if not, “you’ll have to filter out those relays locally”.
Following updates to the Tor Project’s website, Sebastian Hahn drew attention to a change in the steps necessary to run a website mirror. “Please ask if you run into any trouble, and thanks for providing a mirror!”
Inspired by “the Directory Authorities, the crappy experiment leading up to Black Hat, and the promise that one can recreate the Tor network in the event of some catastrophe”, Tom Ritter sent out a detailed report of issues he encountered while setting up his own Tor network using “full-featured independent tor daemons”, rather than a network simulatorlike Shadow or Chutney.
Cthulhu asked for assistance in overhauling the GoodBadISP page, which is the starting point for many relay operators around the world. If you have some time to spare, or know some ISPs not yet on the list, it would be greatly appreciated if they could be added to the page. This new effort to reach out to hosting providers could be of great value after years of what Roger Dingledine has described as a “slash and burn” agriculture model of operating Tor nodes.
Vladimir Martyanov started a discussion on the question of whether Tor developers should ensure that tor can still be built using compilers that do not support the C99 programming language standard, such as older versions of Microsoft Visual Studio.

This issue of Tor Weekly News has been assembled by Lunar, Cthulhu, Roger Dingledine, Karsten Loesing, and Harmony.
Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page, write down your name and subscribe to the team mailing list if you want to get involved!

Tor Weekly News — October 15th, 2014

Welcome to the forty-first issue in 2014 of Tor Weekly News, the weekly newsletter that covers what’s happening in the Tor community.

Academic research into Tor: four recent studies

Major contributions to the development and security of Tor are often made by academic researchers, either in a laboratory setting using network simulators like Shadow, or through measurement and analysis of the live network itself (taking care not to harm the security or anonymity of clients and services). Different aspects of Tor’s networking and security, from path selection to theoretical attacks, have been analysed in three recently-published studies.
Otto Huhta’s MSc thesis investigates the possibility that an adversary in control of a non-exit relay could link two or more Tor circuits back to the same client based on nothing more than timing information. As Otto explained, “this is mainly the result of the fixed 10 minute circuit lifetime and the fact that the transition to using a new circuit is quite sharp.” With the help of a machine classifier, and the fact that any one client will build its circuits through a fixed set of entry guards, the study suggested that such an adversary “can focus only on circuits built through these specific nodes and quite efficiently determine if two circuits belong to the same user.” There is no suggestion that this knowledge alone poses a serious deanonymization risk to clients; however, wrote Otto, “our goal was not to ultimately break the anonymity of any real user but instead to expose a previously unknown threat so that it can be mitigated before anyone actually devises an attack around it.”
Steven Murdoch published a paper on the optimization of Tor’s node selection probabilities showing, in Steven’s words, “that what Tor used to do (distributing traffic to nodes in proportion to their contribution to network capacity) is not the best approach.” Prior to publication of the study, “Tor moved to actively measuring the network performance and manipulating the consensus weights in response to changes. This seems to have ended up with roughly the same outcome. […] However, the disadvantage is that it can only react slowly to changes in network characteristics.”
Sebastian Urbach shared a link to “Defending Tor from Network Adversaries: A Case Study of Network Path Prediction”, in which the researchers analyze the effect of network features like autonomous systems and Internet exchanges on the security of Tor’s path selection, finding that “AS and IX path prediction significantly overestimates the threat of vulnerability to such adversaries”, and that “the use of active path measurement, rather than AS path models” would be preferable “in further study of Tor vulnerability to AS- and IX-level adversaries and development of practical defenses.”
Meanwhile, Philipp Winter took to the Tor blog to summarize some new findings concerning the the way in which the Chinese state Internet censorship system (the “Great Firewall of China”) acts upon blocked connections, like those trying to reach Tor, as detailed in a recent project to which he contributed. Searching for spatial and temporal patterns in Chinese censorship activity, the researchers found that “many IP addresses inside the China Education and Research Network (CERNET) are able to connect” to Tor in certain instances, while the filtering of other networks — centrally conducted at the level of Internet exchanges — “seems to be quite effective despite occasional country-wide downtimes”.
Each of these studies is up for discussion on the tor-dev mailing list, so feel free to join in there with questions and comments for the researchers!

Miscellaneous news

Michael Rogers submitted patches against tor and jtorctl, making two improvements to the performance of mobile hidden services: one “avoids a problem where we’d try to build introduction circuits immediately, all the circuits would fail, and we’d wait for 5 minutes before trying again”, and the other “[adds] a command to the control protocol to purge any cached state relating to a specified hidden service”.
Karsten Loesing published a “non-functional” mock-up of a possible redesign for the Tor Metrics portal, with notes on design decisions: “Feedback much appreciated. This is the perfect time to consider your ideas.”
Jeremy Gillula analyzed data relating to Tor node churn found in Tor consensuses for September 2014, and found that “on average, 0.003% of nodes switch from being relay nodes to exit nodes in any given 1-hour period, and 0.002% switch from being exit nodes to relay nodes”.
Noel Torres and Andrew Lewman sent their status reports for September. Roger Dingledine also sent out the report for SponsorF.
Greg Norcie wondered why the interval at which Tor switches to using a new circuit was set at ten minutes, and Nick Mathewson responded that after the original period of thirty seconds was found to be unworkable, the new number was selected in 2005 “more or less intuitively”. Paul Syverson added that the choice was “an informed one”, taken after “a bunch of discussions concerning the trade-offs between the overhead of the public-key operations of circuit building and the pseudonymous profiling occurring at an exit”.
Both Tor and Tails received their first cinematic credits with the première of “CITIZENFOUR”, a documentary film concerning the recent disclosure of intelligence documents by Edward Snowden. Eagle-eyed viewers might spot a well-known hostname in the film’s trailer
WhonixQubes reported on progress in many areas of the Whonix+Qubes project, which as the name implies is a combination of the Whonix and Qubes operating systems. Among other things, the system now supports Whonix 9, a community forum has been set up, and greater upstream integration is being discussed.

News from Tor StackExchange

"What happens when Tor always chooses the same path?" asks Mark and wants to know which weaknesses this exposes. User194 believes that this would prevent a “predecessor attack” and make the system stronger, while Lisbeth writes: “This makes your entire traffic highly fingerprintable as compared to a standard random path. If your connections always used A, B, and C nodes, it is statistically unlikely that many other people are consistently using that same path, therefore it’s very easy to correlate your traffic to your originating IP.”
Muncher visited a website which asked to add HidServAuth into the torrc and wants to know if it is safe to do so. Jeff recommended that this is safe because it doesn’t divulge anything about the identity of a user. Mirimir furthermore referred to a question where adrelanos looks for documentation.

This issue of Tor Weekly News has been assembled by Lunar, qbi, and Harmony.
Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page, write down your name and subscribe to the team mailing list if you want to get involved!

Tor Weekly News — October 8th, 2014

Welcome to the fortieth issue in 2014 of Tor Weekly News, the weekly newsletter that covers what is happening in the Tor community.

Setup ooniprobe in five minutes

New versions of the Open Observatory of Network Interference (OONI) tools are out. On October 1st, Arturo Filastò announced ooniprobe 1.2.0 and oonibackend 1.1.4.
“One of the most interesting new features that are now part of ooniprobe is the ability to generate test decks for the country you are in a way that is much easier than before”, wrote Arturo.
He added: “As a matter of fact to start contributing useful measurements it’s just a matter of 5 minutes of setup.” So don’t be shy about adding your measurements to the project!

Monthly status reports for September 2014

The wave of regular monthly reports from Tor project members for the month of September has begun. Juha Nurmi released his report first, followed by reports fromGeorg KoppenDamian JohnsonGeorge KadianakisMatt PaganLunarSherief Alaa,Leiah JansenHarmonyPearl CrescentNick MathewsonKarsten LoesingSukhbir SinghNicolas Vigier (in addition to July and August), Arlo BreaultJ. Todaro, and Colin C.
Lunar also reported on Tor help desk, Mike Perry for the Tor Browser team, and Arturo Filastò for OONI.

Miscellaneous news

Orbot users should rejoice at the news that orWall 1.0.0 has been released! orWall will force selected applications through Tor while preventing unauthorized applications to have any network access. “Any feedback from Tor/Orbot users interests me in order to improve orWall. I think the current release is pretty good, but as the main dev I’m maybe not that neutral regarding this statement” joked CJ.
The OONI project has been “developing a test that allows probes in censored countries to test which bridges are blocked and which are not”. George Kadianakis is seeking help to create interesting visualization of the resulting data. He shared a sketch about countries and pluggable transports and another one showing time before blocks happened.
Nick Mathewson announced the release of Trunnel 1.3. Trunnel is a code generator for binary encoders/decoders. Nick adds: “Some code that it has generated has been merged into the Tor master branch for the 0.2.6 release series, though that code is not yet in active use.“
David Fifield sent a summary of the costs incurred by the meek pluggable transport for the month of September 2014. More details are included in the email, but costs are currently very low: “$3.85 for App Engine, $4.59 for Amazon, $0.00 for Azure”.
Virgil Griffith shared a yet unpublished tech report on Tor growth. To pick just one finding, the Tor network’s bandwidth has been doubling every 13–14 months so far.
The Knight Foundation is going to fund projects for “the future of libraries”. The Library Freedom Project wants to teach “librarians about privacy rights, law, and tech tools to protect patrons from dragnet surveillance”. It’s based on their previous experiencepromoting Tor and other privacy tools in Massachusetts libraries. Show them support!
The US National Science Foundation is seeking input to lay out a future Privacy Research Strategy. The deadline being October 17th, Roger Dingledine suggests: “if anybody here has partially written ideas that they want to put together into a submission, please do!”
Thanks to opi for running a new mirror of the Tor Project’s website and software.

Easy development tasks to get involved with

oonibackend is used by ooni, the Open Observatory of Network Interference, to run in the background and perform tasks like discovering addresses of test helpers and performing measurements that require a backend system to talk to. When oonibackend was changed to fix compatibility with Twisted 13.1 it lost its ability to start tor and then drop privileges. Arturo suspects that the correct way of doing this is to place the logic for starting tor inside of preApplication or startService. But from a quick research he suspects that Twisted does not support returning Deferreds in there. He also points to two relevant Twisted tickets (12). If you have experience with Twisted and want to help debug or even solve this problem, be sure to post your thoughts or patches to the ticket.

This issue of Tor Weekly News has been assembled by Lunar, harmony, and Karsten Loesing.
Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page, write down your name and subscribe to the team mailing list if you want to get involved!

Tor Weekly News — October 1st, 2014

Welcome to the thirty-ninth issue in 2014 of Tor Weekly News, the weekly newsletter that covers what’s happening in the Tor community.

Tor 0.2.4.24 and 0.2.5.8-rc are out

Roger Dingledine announced new releases in both the stable and the alpha branches of the core Tor software. Clients accessing hidden services should experience faster and more robust connections as they will now send the correct rendezvous point address. “They used to send the wrong address, which would still work some of the time because they also sent the identity digest of the rendezvous point, and if the hidden service happened to try connecting to the rendezvous point from a relay that already had a connection open to it, the relay would reuse that connection”. This fix also prevents theendianness of the client’s system from being leaked to the hidden service.
The only other changes in these releases are an update of the geoip databases and the location of the gabelmoo directory authority. As usual, you can download the source code from the Tor distribution directory.

Tor Browser 3.6.6 and 4.0-alpha-3 are out

Mike Perry announced two new releases by the Tor Browser team. Tor Browser 3.6.6includes a workaround for the bug that has sometimes been preventing the browser window from opening after an apparently successful connection to the Tor network; it also stops intermediate SSL certificates from being written to disk. In addition to these fixes,Tor Browser 4.0-alpha-3 resolves a number of issues to do with the upcoming Tor Browser updater, including the mistaken upgrade of non-English Tor Browsers to the English-language version. As this bug is only fixed in the new release, users upgrading from 4.0-alpha-2 will still experience this issue during the process. Furthermore, “meek transport users will need to restart their browser a second time after upgrade if they use the in-browser updater. We are still trying to get to the bottom of this issue”, wrote Mike.
Both releases also include important Firefox security updates, so all users should upgrade as soon as possible. See Mike’s announcements for full details, and get your copy from the project page or the distribution directory.

Tails 1.1.2 is out

The second point release in the Tails 1.1.x series was put out by the Tails team, “mainly to fix a serious flaw in the Network Security Services (NSS) library used by Firefox and other products that allows attackers to create forged RSA certificates. Before this release, users on a compromised network could be directed to sites using a fraudulent certificate and mistake them for legitimate sites.”
Other packages affected by recently-disclosed security flaws and updated in this version include APT, bash, and GnuPG, so all Tails users should make sure to upgrade as soon as possible. If you have a running copy of Tails, you can make use of the incremental upgrades system; otherwise, head to the download page for more information.

obfs4 is ready for general deployment: bridge operators needed!

Pluggable transports, the circumvention techniques which allow users to access the Tor network from censored areas by disguising the fact that the Tor protocol is being used, are about to take another step forward with the release of obfs4, and Yawning Angel sent out a brief discussion of this new protocol.
obfs4 offers a number of developments over the obfs3 and ScrambleSuit protocols, until now the most sophisticated pluggable transports in use on the Tor network. Like ScrambleSuit, obfs4 improves on obfs3 to “provide resilience against active attackers and to disguise flow signatures”, while a safer and more efficient key-exchange process than ScrambleSuit’s should make it impossible for attackers to launch man-in-the-middle attacks based on the client/bridge shared secret.
Like its predecessors in the obfsproxy series, obfs4 is a bridge-based transport, meaning that volunteers are needed to operate relays running an implementation of the new protocol before users can take advantage of it. The current implementation, obfs4proxy, is now available to download either as source code or as a package from Debian’sunstable repositories. Those who want to try browsing over the new protocol can download Yawning’s experimental Tor Browsers, and if you’re willing to run an obfs4 bridge, please see Yawning’s message for all the relevant details — “questions, comments, and bridges appreciated”!

Miscellaneous news

Anthony G. Basile announced the release of version 20140925 of tor-ramdisk, the micro Linux distribution whose only purpose is to host a Tor server in an environment that maximizes security and privacy. This release includes updates to Tor, BusyBox, OpenSSL, and the Linux kernel.
As part of the current push to better understand hidden services and their use on the Tor network, Roger Dingledine asked relay operators who are “comfortable compiling Tor from git” and who “want to help investigate what fraction of Tor network load comes from hidden service use” to check out the new hs-stats git branch. This version “will collect per-thirty-minute statistics about number of circuits and number of cells your relay sees that have to do with exiting, with hidden services, with circuits where you're not the final hop, and a fourth none-of-the-above category”, which can then be posted to the appropriate ticket on the bug tracker or sent to Roger directly.
Yawning Angel sent a “friendly reminder” to ScrambleSuit bridge operators, asking them to upgrade to tor-0.2.5.x if they haven’t already: “If you are running a ScrambleSuit bridge with tor-0.2.4.x, it is useless. Users that happen to be served your ScrambleSuit bridge will not be able to connect, because the password is missing”.
Mike Perry asked relay operators, particularly those running exit relays, to contribute information about the “hardware, CPU cores, and uplink” of their servers, and how much these cost per month, in order to “put together some estimates on bounds of the current value and cost of the capacity of the Tor network as it is, and use that to generate some rough guestimates on what it would cost to grow it”.
In response to the possible integration of Tor as a “private browsing mode” by a major browser vendor, Andrew Lewman kicked off a discussion of ways in which the Tor network might be scaled up to accommodate “hundreds of millions” of extra users.

Tor help desk roundup

In Firefox, it is possible to drag a URL from the Navigation Toolbar to the Desktop in order to create a shortcut to a website, and the help desk has been asked why this functionality is disabled in Tor Browser. A Desktop shortcut to a URL, when clicked, would be opened by the operating system’s default browser, not by Tor Browser. Permitting this behavior would open the door to confusion as to whether or not a user was visiting a link over Tor, and would violate the “Proxy Obedience” requirement of the Tor Browser design.

News from Tor StackExchange

Tor StackExchange has started its site self-evaluation for September 2014. Ten questions were selected and you’re asked to review them. Are they good or is there room for improvement? Please have a look at the questions and rate them.
Jens Kubieziel noted that users mix up the terms Tor, Tor Browser and torbrowser-launcher, so he explained each of them to users of the Q&A page.

This issue of Tor Weekly News has been assembled by harmony, qbi, Lunar, Matt Pagan, dope457, and Yawning Angel.
Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page, write down your name and subscribe to the team mailing list if you want to get involved!

Tor Weekly News — September 24th, 2014

Welcome to the thirty-eighth issue in 2014 of Tor Weekly News, the weekly newsletterthat covers what’s happening in the Tor community.

The EFF concludes its 2014 Tor Challenge

As Tor Weekly News reported in June, over the last few months the Electronic Frontier Foundation has been holding its second Tor Challenge to improve the strength and diversity of the Tor network by inspiring people to run Tor relays. The 2014 Challenge is now over, and Rainey Reitman of the EFF posted some thoughts on the campaign and its outcome.
1635 Tor relays (including 326 exit relays) were started up or had their capacity increased as part of the 2014 Tor Challenge, compared to 549 at the end of the last campaign in 2011. As Rainey wrote, this number “far exceeded our hopes”; the success can be attributed to a coordinated promotional effort by the EFF, the Free Software Foundation, the Freedom of the Press Foundation, and the Tor Project, as well as to “the 1,000 individuals who cared enough to help contribute bandwidth to the Tor network.” Thanks to everyone who participated!
It’s important to remember, though, that new relays only benefit Tor users as long as they stay running. Advice and support from experienced relay operators can always be found on the #tor IRC channel or the tor-relays mailing list; if you missed out on the Tor Challenge this year but still want to contribute to a stronger, more stable Tor network, take a look at the Tor website for advice on how to get started.

Guardiness and Tor’s directory authorities

When a Tor relay is first assigned the Guard flag by the directory authorities (or “dirauths”) it sees a dip in the amount of traffic passing through it, because Guard capacity is a scarce resource on the Tor network and, as Roger Dingledine explained last year, “all the rest of the clients back off from using you for their middle hops, because when they see the Guard flag, they assume that you have plenty of load already from clients using you as their first hop”, an assumption which is only correct after clients have had enough opportunity to select the new guard. With the recent move to single entry guards, an even longer period of time may pass before a young guard can be selected as a first hop by old clients.
“Guardiness”, or GuardFraction, is a proposed measurement to let dirauths, and therefore clients, work out how much of a relay’s capacity is being used for first hops by clients, and how much for second and third hops, by finding the fraction of recent consensuses in which the relay has been given the Guard flag; the “dead period” following the assignment of the flag can then be avoided. George Kadianakis published an analysis of ways in which dirauths’ votes could be extended to include this guardiness measurement, taking into account the time and effort required to parse large numbers of Tor consensuses very quickly. The initial proposal was to ask dirauths to run a script each hour that would extract the data required for parsing into “summary files”: Sebastian Hahn asked how this measure might fail in different situations, and Peter Palfrader suggested that loading every consensus into a database for later querying might be more efficient.
“This feature is by far the trickiest part of prop236 (guard node security) and I wanted to inform all dirauths of our plan and ask for feedback on the deployment procedure”, wrote George. If you have any comments to add to the discussion so far, please send them to the tor-dev mailing list.

Miscellaneous news

The Tails team wants to make sure that all the Debian packages on which Tails relies are “in good shape” before Jessie, the next Debian release, is frozen on 5th November. To that end, the team called for testing both of the software itself and its translations — if you’d like to help, find full instructions and links to the “barely-working” experimental disk images in the announcements.
meek, the pluggable transport that routes Tor traffic through platforms which are “too big to block”, now works with Microsoft Azure in addition to the already-supported Google App Engine and Amazon Web Services. David Fifield posted the announcement, which contains instructions for those who want to start using the new front domain.
Sebastian Hahn announced that gabelmoo, the Tor directory authority which he administers, has moved to a new IP address. “You should not notice any kind of disturbance from this, and everything should continue to work as normal.”
Released in December 2013, the SafePlug is a $49 router that promises its users “complete security and anonymity” online by sending all of their traffic through Tor. Annie Edmundson from Princeton University released a summary of research presented during FOCI’14 in which the authors point out several security problems in the implementation of the SafePlug administration interface, and also highlight other structural issues. “The most crucial problem with a torifying proxy is that it uses a bring-your-own-browser system, as opposed to a hardened browser, and therefore is susceptible to browser-based privacy leaks. This is why it’s better to use the Tor Browser Bundle […]”, wrote Annie.
The upcoming Tor Messenger is based on Instantbird. One key feature that was identified as missing in the latter is support for Off-the-Record encryption. After months of discussions and reviews to determine the right programming interface, Arlo Breault got the necessary core modifications merged.
Roger Dingledine wrote up a walkthrough of the controller events you might see when accessing Tor hidden services. “In theory the controller events should help you understand how far we got at reaching a hidden service when the connection fails. In practice it’s a bit overwhelming”.
In the first message posted to the recently-created onionoo-announce mailing list, Karsten Loesing explained a minor improvement that should allow Onionoo clients to determine when they need to be upgraded to a new protocol version.
Leiah, whose design work has featured on many of Tor’s company publications, posted a mock-up of a possible new look for the Tor blog.
Patrick Schleizer announced the release of version 9 of Whonix, the anonymous operating system based on Tor, Debian, and security-by-isolation.

Tor help desk roundup

The help desk has been asked how to configure a VPN to prevent a website from learning that a user is using Tor. We consider positioning a VPN between one’s exit node and the destination site to be totally unsafe, and not much more anonymous than using a VPN without Tor. By design, Tor allows the destination site to know that a visitor is using Tor. The better solution is to email the website owner and ask them to stop blocking Tor. The longer-term solution is that Tor needs someone willing to coordinate with websites to design engagement solutions that work for Tor users and for big websites.

News from Tor StackExchange

Jobiwan has a machine on their network which should act as a SOCKS proxy. When Tor Browser is configured to use this proxy, it complains that Tor is not working in this browser. However, Jobiwan is able to visit hidden services with these settings, and wants to know why this message is printed and if it is safe to use Tor Browser this way. Do you know a good answer to this question? If so, please share your thoughts.
Andy Smith asks if slow relays are useful for the Tor network. Roya suggests that a large number of slow relays is better than a small number of fast relays, at least anonymity-wise, because this helps to grow diversity in the network and makes it harder for an attacker to deanonymize users. On the other hand, user194 and Relay Operator write that a slow relay does not provide much benefit for the network. They recommend spending a few dollars more to rent a fast virtual server.

Easy development tasks to get involved with

The tor daemon has a SafeLogging configuration option that removes all potentially sensitive parts of log messages and replaces them with “[scrubbed]”. However, this option does not cover hidden services operated by the tor daemon. Extending this option involves scanning through some code, but Nick says it could be some interesting code; if you’re up to reading and patching some C code and then reading some (hopefully scrubbed) logs, this ticket may be for you. Be sure to post your branch for review on theticket.

This issue of Tor Weekly News has been assembled by harmony, Lunar, qbi, Matt Pagan, Karsten Loesing, Arlo Breault, and Roger Dingledine.
Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page project page, write down your name and subscribe to the team mailing list if you want to get involved!

Tor Weekly News — September 17th, 2014

Welcome to the thirty-seventh issue in 2014 of Tor Weekly News, the weekly newsletterthat covers what’s happening in the community around Tor, the anonymity network that makes full use of its library card.

tor 0.2.5.7-rc is out

Nick Mathewson announced the first release candidate in tor’s 0.2.5.x series. This version “fixes several regressions from earlier in the 0.2.5.x release series, and some long-standing bugs related to ORPort reachability testing and failure to send CREATE cells”; relay operators running it will also receive a warning if they try to configure a hidden service on the same process as their relay, as the public nature of much information about Tor relays can help identify services running on the same machine. As ever, you can read the full list of improvements and fixes in Nick’s announcement, and download the source code from the Tor Project’s distribution directory.

Tor protects library patrons’ right to privacy

April Glaser and Alison Macrina published an article for BoingBoing on efforts by Massachusetts librarians to guarantee their patrons’ right to access information without fear of surveillance or censorship. Macrina and her colleagues, in partnership with the ACLU of Massachusetts, have been giving workshops on the use of privacy-preserving technologies to other librarians, and spreading the word about the risk that pervasive surveillance poses to freedom of thought and intellectual inquiry.
As the authors remark, “it’s no secret that libraries are among our most democratic institutions. Libraries provide access to information and protect patrons’ right to explore new ideas, no matter how controversial or subversive […] and protecting unfettered access to information is important whether that research is done using physical books or online search engines. But now it has become common knowledge that governments and corporations are tracking our digital lives, and that surveillance means our right to freely research information is in jeopardy”.
Tor and Tails are a natural fit for any response to this problem, and BoingBoing reports that not only have “multiple Massachusetts libraries […] installed the Tor browser on all of their public PCs” following the workshops, some have even “set up Tor middle relays on their libraries’ networks”.
It would be a shame, however, if these exciting developments were restricted to the state of Massachusetts. If you are a library user concerned about this issue, share the article with your local librarians. If you work in a library, contact the authors of the article at the addresses they provide to find out how you can offer privacy workshops and tools to your own community!

Hidden service enumeration and how to prevent it

When a Tor user wants to connect to a hidden service, their client makes a request over the Tor network to a relay acting as a “hidden service directory”, or HSDir. In return, the client receives a hidden service “descriptor” containing the information necessary for a connection to be made, including the set of Introduction Points that the hidden service is currently using.
Hidden services would ideally not be discoverable unless the address is public or has been shared directly, but one of the weaknesses of the current protocol is that hidden service directories know which services they are serving descriptors for; this same shortcoming was an element of the “RELAY_EARLY” traffic confirmation attackdiscovered in July. Although the full set of descriptors is not published to all directories at once — at any given time, six directories are responsible for a service’s descriptor — the list is rotated frequently, so it would not be hard for an adversary to run a relay stable enough to gain the HSDir flag, and harvest hidden service addresses as they are uploaded to it in turn.
Fabio Pietrosanti informed the tor-talk mailing list of an experiment designed to detect this enumeration of hidden services: he set up thirty new hidden services, keeping their addresses secret, with each service running a script to report any attempts at access from outside. As the existence of these services was not disclosed to anyone, any requests to the service could only come from a client that had obtained the address from a directory which had previously held the descriptor, possibly “a malicious Tor relay acting as a TorHS directory, with Tor’s code modified to dump from the RAM memory the TorHS list, then harvest them with an http client/script/crawler”. After approximately a month, according to Fabio’s message, a client did indeed try to access one of the “honeypot” services.
Regular readers of Tor Weekly News will know that the hidden service protocol is being fully redesigned, and this “next-generation” proposal already suggests defenses against this kind of attack, but (as ever) more eyes are needed. If you’re interested, see George Kadianakis’ introduction to the issues facing hidden services; those familiar with cryptography in C are welcome to review the discussion of this particular issue on the bug tracker.

Miscellaneous news

Nathan Freitas announced version 14.0.8.1 of Orbot, the Tor client for Android. The highlights of this release are an upgrade to tor 0.2.5.7-rc (see above), which solves an issue with the “airplane mode” feature, as well as a number of improvements to do with transparent proxying. Find the full changelog and download links in Nathan’s message.
Juha Nurmi described the current state of ahmia.fi, the search engine for hidden services, following a successful Google Summer of Code project. The post includes notes on the design, content statistics, and plans for future work.
David Fifield called for a volunteer operating a “big fast bridge” to take over the running of the meek pluggable transport: “I want to do this both to diffuse trust, so that I don’t run all the infrastructure, and because my bridge is not especially fast and I’m not especially adept at performance tuning”.
David also wondered why the number of FTE users appeared to dip in late August, and explored possible reasons behind the correlation in usage statistics for meek and Flashproxy, whose backends both run on the same bridge. Karsten Loesing suggestedthat the latter was because “we’re counting consensuses downloaded from a bridge via any supported transport, and then we’re attributing those downloads to specific transports based on what fraction of IPs connected per transport”.
Tim reported on progress made towards a “fuzzer” for Tor, based on the Tor research framework previously announced by Gareth Owen, including a draft design for the process and a list of patches against Tor made during development.
Matt Pagan submitted his status report for August, while Roger Dingledine sent out the report for SponsorF.
Karsten Loesing posted the minutes of last week’s Globe/Atlas developer IRC meeting.

This issue of Tor Weekly News has been assembled by harmony, Lunar, Roger Dingledine, George Kadianakis, and special.
Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page, write down your name and subscribe to the team mailing list if you want to get involved!

Tor Weekly News — September 10th, 2014

Welcome to the thirty-sixth issue in 2014 of Tor Weekly News, the weekly newsletter that covers what is happening in the Tor community.

More monthly status reports for August 2014

The wave of regular monthly reports from Tor project members for the month of August continued, with reports from Yawning AngelGeorge KadianakisIsis LovecruftColin C., and Griffin Boyce.
Arturo Filastò reported on behalf of the OONI team.

Miscellaneous news

Nathan Freitas announced the release of Orbot 14.0.8, containing “some fixes for people who like to fiddle with transproxy/iptables settings, which can lead to the device getting into a bad network state”, as well as for “a common freak crash that was occuring on app exit in some cases.” See Nathan’s message for a full changelog and download links.
Mike Perry asked for comments on his proposal to drop Tor Browser support for Mac OS X 10.6, which is no longer receiving security updates from Apple. This means that the Tor Browser team would only have to distribute standard-sized 64-bit builds for Mac OS X rather than the oversized 32+64-bit set. Users who are unable to upgrade their operating system would still be able to use Tails for their Tor browsing needs.
Hartmut Haase reported that Tor Browser occasionally fails to open, despite a successful connection being made to the Tor network; several other users confirmed that they are also experiencing this problem. Georg Koppen suggested that the issue is the one covered by bug ticket #10804: “Solving this is high on the priority list, but alas not as high as getting everything ready for the switch to ESR31.”
Thanks to Peter Ludikovsky and goll for running mirrors of the Tor Project website and software archive!
Andrew Lewman published the results of a test he ran to answer the question “Why not just use CloudFlare for mirrors of the Tor Project website?”: “The results are that using CloudFlare doesn’t offload the binaries, which are what make up the bulk of traffic on the mirror […] I’ve started to look at CDN providers to see if there are affordable services which can offload the entire site itself.”
As part of an ongoing effort to rescue the Tor blog from rot and ruin caused by broken Drupal code, ultrasandwich set up an unofficial preview of a possible blog based on the Jekyll static site generator. If you want to contribute to the revamp of the Tor Project website, including the blog, the www-team mailing list awaits your comments and ideas!

Tor help desk roundup

Users want to know if their personal information is safe when they use Tor Browser. Personal accounts are no less secure using Tor Browser than they are using the web without Tor: the problem of authenticating websites and preventing eavesdropping has been addressed outside of the Tor context through HTTPS. That’s why the Tor Browser ships with the HTTPS-Everywhere browser extension — for every website you visit, HTTPS-Everywhere checks whether or not that website is known to have an HTTPS version, and if so it connects to the site using HTTPS instead of HTTP. Tor + HTTPS provides full end-to-end encryption when visiting any site that offers its content via HTTPS. Using HTTPS with Tor helps keep users’ web accounts secure.

Easy development tasks to get involved with

If a single human or organization runs more than one relay, they should configure all their relays to be in the same “family”, the goal being to prevent clients from using more than one of these relays in the same circuit. However, the config option used for this, MyFamily, only accepts relay fingerprints that are preceeded by $, unlike most other config options. It would be great if this option accepted fingerprints preceeded by $, as well as without it. Nick Mathewson says this ticket would be pretty easy, so why not give it a try? It does sound like some fun C hacking. Be sure to post your patch to the ticket.
Back in the day, the tor daemon, which is the core of the Tor network, compiled and ran on Windows 98. But that’s history, and aren’t we all glad? Somebody should identify and drop support code for all Windows versions prior to Windows XP. Nick says “this is mainly going to be a matter of identifying cases where we use LoadLibrary and GetProcAddress to find always-present-functions in always-present DLLs.” If the previous sentence made any sense to you, maybe you’re a good person to help with this! Be sure to comment on the ticket if you have a branch to review.

This issue of Tor Weekly News has been assembled by harmony, Matt Pagan, Karsten Loesing, and Lunar.
Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page, write down your name and subscribe to the team mailing list if you want to get involved!

No comments:

Post a Comment