Blogs

Tor Browser 3.6 is released

The Tor Browser Team is proud to announce the first stable release of the 3.6 series. Packages are available from the Tor Browser Project page and also from our distribution directory.

For users upgrading from Tor Browser 3.5.x, the 3.6 series features fully integrated Pluggable Transport support, including an improved Tor Launcher UI for configuring Pluggable Transport bridges. The Pluggable Transport code is also fully disabled for users who do not configure them. The 3.6 series also changes the MacOS archive format from zip to DMG, which should improve installation usability for Mac users.

This release also includes important security updates to Firefox.

Please see the TBB FAQ listing for any issues you may have before contacting support or filing tickets. In particular, the TBB 3.x section lists common issues specific to the Tor Browser 3.x series. We also maintain a list of frequently encountered known issues in our bugtracker.

Here is the complete changelog since TBB 3.5.4:

  • All Platforms

    • Update Firefox to 24.5.0esr
    • Include Pluggable Transports by default:
      • Obfsproxy3 0.2.4, Flashproxy 1.6, and FTE 0.2.13 are now included
    • Bug 11586: Include license files for component software in Docs directory.
    • Bug 9010: Add Turkish language support.
    • Bug 9387 testing: Disable JS JIT, type inference, asmjs, and ion.
    • Update NoScript to 2.6.8.20
    • Update Tor Launcher to 0.2.5.4
      • Bug 9665: Localize Tor's unreachable bridges bootstrap error
      • Bug 10418: Provide UI configuration for Pluggable Transports
      • Bug 10604: Allow Tor status & error messages to be translated
      • Bug 10894: Make bridge UI clear that helpdesk is a last resort for bridges
      • Bug 10610: Clarify wizard UI text describing obstacles/blocking
      • Bug 11074: Support Tails use case (XULRunner and optional customizations)
      • Bug 11482: Hide bridge settings prompt if no default bridges.
      • Bug 11484: Show help button even if no default bridges.
    • Update Torbutton to 1.6.9.0:
      • Bug 11242: Fix improper "update needed" message after in-place upgrade.
      • Bug 10398: Ease translation of about:tor page elements
      • Bug 9901: Fix browser freeze due to content type sniffing
      • Bug 10611: Add Swedish (sv) to extra locales to update
      • Bug 7439: Improve download warning dialog text.
      • Bug 11384: Completely remove hidden toggle menu item.
    • Backport Pending Tor Patches:
      • Bug 9665: Report a bootstrap error if all bridges are unreachable
      • Bug 11200: Prevent spurious error message prior to enabling network.
      • Bug 5018: Don't launch Pluggable Transport helpers if not in use
      • Bug 9229: Eliminate 60 second stall during bootstrap with some PTs
      • Bug 11069: Detect and report Pluggable Transport bootstrap failures
      • Bug 11156: Prevent spurious warning about missing pluggable transports
  • Mac:

    • Bug 4261: Use DMG instead of ZIP for Mac packages
    • Bug 9308: Prevent install path from leaking in some JS exceptions on Mac and Windows
  • Linux:

    • Bug 11190: Switch linux PT build process to python2
    • Bug 10383: Enable NIST P224 and P256 accel support for 64bit builds.
  • Windows:
    • Bug 9308: Prevent install path from leaking in some JS exceptions on Mac and Windows

Here is the changelog since the 3.6-beta-2:

  • All Platforms
    • Update Firefox to 24.5.0esr
    • Update Tor Launcher to 0.2.5.4
      • Bug 11482: Hide bridge settings prompt if no default bridges.
      • Bug 11484: Show help button even if no default bridges.
    • Update Torbutton to 1.6.9.0
      • Bug 7439: Improve download warning dialog text.
      • Bug 11384: Completely remove hidden toggle menu item.
    • Update NoScript to 2.6.8.20
    • Update fte transport to 0.2.13
    • Backport Pending Tor Patches:
      • Bug 11156: Additional obfsproxy startup error message fixes
    • Bug 11586: Include license files for component software in Docs directory.
  • Windows and Mac:
    • Bug 9308: Prevent install path from leaking in some JS exceptions on Mac and Windows builds

Tor Summer 2014 Dev Meeting Hosted by Mozilla

We are excited to announce our Summer 2014 Dev meeting will be held in Paris, France June 29 - July 4.

Thank you to Mozilla for hosting us at their Paris offices and for their continued support of Tor!

Further details regarding public events will be announced very soon - stay tuned!

Tails 1.0 is out

Tails, The Amnesic Incognito Live System, version 1.0, is out.

All users must upgrade as soon as possible: this release fixes numerous security issues.

For more information about what the 1.0 release means for Tails, and about its future, see the full announcement.

Changes

Notable user-visible changes include:

  • Security fixes
    • Upgrade the web browser to 24.5.0esr-0+tails1~bpo60+1 (Firefox 24.5.0esr + Iceweasel patches + Torbrowser patches).
    • Upgrade Tor to 0.2.4.21-1+tails1~d60.squeeze+1:
      • Based on 0.2.4.21-1~d60.squeeze+1.
      • Backport the fix for bug #11464 on Tor Project's Trac. It adds client-side blacklists for all Tor directory authority keys that was vulnerable to Heartbleed. This protects clients in case attackers were able to compromise a majority of the authority signing and identity keys.
  • Bugfixes
    • Disable inbound I2P connections. Tails already restricts incoming connections, but this change tells I2P about it.
    • Fix link to the system requirements documentation page in the Tails Upgrader error shown when too little RAM is available.
  • Minor improvements
    • Upgrade I2P to 0.9.12-2~deb6u+1.
    • Import TorBrowser profile. This was forgotten in Tails 0.23 and even though we didn't explicitly set those preferences in that release they defaulted to the same values. This future-proofs us in case the defaults would ever change.
    • Import new custom version of Tor Launcher:
    • Integrate the new Tails logo into various places:
      • The website
      • The boot splash
      • The "About Tails" dialog

See the online Changelog for technical details.

Known issues

I want to try it or to upgrade!

Go to the download page.

As no software is ever perfect, we maintain a list of problems that affects the last release of Tails.

What's coming up?

The next Tails release is scheduled for June 10.

Have a look to our roadmap to see where we are heading to.

Would you want to help? There are many ways you can contribute to Tails. If you want to help, come talk to us!

Support and feedback

For support and feedback, visit the Support section on the Tails website.

Tor Weekly News — April 23rd, 2014

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

Cutting out relays running version 0.2.2.x

Tor relays running the now ancient Tor 0.2.2.x are scheduled to be removed from the consensus. The change has already been merged in the master branch and will be out with the next Tor 0.2.5 alpha.

Even if most relay operators have been warned, the change has not yet been widely announced. But as three directory authorities are already not voting for the deprecated versions, the downtime of two others while cleaning up after the OpenSSL “Heartbleed” issue was sufficient to get these relays removed from the consensus for a couple of days, as Roger Dingledine explained.

Eventually relays running versions prior to 0.2.3.16-alpha might also be removed from the consensus. “I think 0.2.3.16-alpha’s fix of #6033 makes that one a plausible ’not below this one’ cutoff”, Roger writes in the relevant Trac entry.

Relay operators should always make sure to run a recommended Tor version. The Tor Weather service can be used by relay operators to get email notifications if an outdated version is detected.

Miscellaneous news

Nathan Freitas announced the third (and probably final) release candidate for Orbot 13.0.6: “The big improvements in this build are a fix for the disconnected UI/activity (Tor is on, but UI shows off), and improvements to the transparent proxying iptables scripts”.

The Tails developers put out two calls for testing: the first is for the first release candidate of Tails 1.0; while the second is for UEFI support, which “allows you to start Tails using a USB stick on recent hardware, and especially on Mac”. “Test wildly”, and report any bugs you find!

Andrea Shepard sent a list of 1777 fingerprints for relays “which have ever turned up as potentially exposed by Heartbleed”. It appears that enough directory authority operators now reject relays known to be problematic: sssheep reported that the still-vulnerable section of the network was down to 0.01% of the consensus weight.

Mick drew attention to the fact that in its current state, arm — the command-line relay status monitor — wrongly advises relay operators to run it with the same user as Tor, in order to access information about the relay’s connections. This is in fact a very bad idea, and a ticket is already open to address this issue. Lunar detailed the correct method of doing this, which is also explained in the ticket.

On the tor-relays mailing list, David Stainton mentioned his Tor role for the Ansible automation tool. David hoped that “relay operators will find this useful for deploying and maintaining large numbers of Tor relays and bridges”. The documentation specifies that it currently works with Debian and Ubuntu systems, and contains several configuration examples.

David Fifield continued his progress on meek, a pluggable transport “that routes your traffic through a third-party web service in a way that should be difficult to block”. David sent a call for wider testing of experimental Tor Browser builds and a call for reviews of the code. “There are a lot of components that make up the meek transport […] This is your chance to get in on the ground floor of a new transport!”

Ximin Luo raised several points regarding how “indirect” pluggable transports like flashproxy or meek are currently handled by Tor. Whereas obfs3 or ScrambleSuit connect directly to the specified peer, transforming the data flow along the way, Ximin describes meek and flashproxy as providing “the metaphor of connecting to a global homogeneous service”. The latter being “incompatible with the metaphor of connecting to a specific endpoint”. Solutions on how to make the design, code, and configuration better are up for discussion.

Nicolas Vigier submitted his status report for March.

Philipp Winter relayed the call for papers for the 4th USENIX Workshop on Free and Open Communications on the Internet. The workshop will be held on August 18th, and should bring together the wider community of researchers and practitioners interested in Tor and other ways to study, detect, or circumvent censorship. Papers have to be submitted before May 13th.

Fabio Pietrosanti wondered whether anyone had “ever tried to start Tor from a Python application using Ctypes”, making it possible to “sandbox the Python application using AppArmor without enabling any kind of execve() call”.

Tor help desk roundup

Many people email the Tor Help Desk from behind restrictive university firewalls that require them to connect using a proxy. Often these firewalls, Cyberoam and Fortiguard are two examples, use Deep Packet Inspection and block Tor traffic. Unfortunately Tor Browser users can’t use a proxy to connect to the internet and also use a pluggable transport. The Tor Browser team plans to include this capability in a future release.


This issue of Tor Weekly News has been assembled by Lunar, harmony, Matt Pagan, and an anonymous contributor.

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!

Call for papers: FOCI'14 workshop

The 4th USENIX Workshop on Free and Open Communications on the Internet is calling for papers. The workshop will be held on August 18, 2014 and seeks to bring together researchers and practitioners working on means to study, detect, or circumvent Internet censorship.

Past iterations of the workshop featured a number of great Tor research papers including a proposal for cloud-based onion routing, our OONI design paper, an analysis of how the GFW blocks Tor, a censorship analyzer for Tor, and a proposal for latency reduction in Tor circuits.

Given the past success of the FOCI series, we are looking forward to another round of great Tor papers.

Paper submissions are due on Tuesday, May 13, 2014, 11:59 p.m. PDT.

Tor Weekly News — April 16th, 2014

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

New beta version of Tor Browser 3.6

The second beta version of the next major Tor Browser release is out. Version 3.6 main highlight is the seamless integration of pluggable transports in the browser.

The update is important to users already using version 3.6-beta1 as it contains an updated OpenSSL to address potential client-side vectors for CVE-2014-0160 (also known as “Heartbleed”).

The new beta also features “a Turkish language bundle, experimental Javascript hardening options, fixes for pluggable transport issues, and a fix for improper update notification while extracting the bundle over an already existing copy.”

Jump to the release announcement to know more. Enjoy the update and report any bug you may find.

Key rotation at every level

The “Heartbleed” issue forces system administrators to consider private keys of network-facing applications affected by the bug as compromised. As Tor has no shortage of private keys in its design, a serious number of new keys has to be generated.

Roger Dingledine prompted relay operators to get new identity keys, “especially from the big relays, and we’ll be happier tolerating a couple of bumpy days while the network recovers”. Switching to a new relay identity key means that the relay is seen as new to the authorities again: they will lose their Guard status and bandwidth measurement. It seems that a number of operators followed the advice, as the network lost around 1 Gbit/s of advertised capacity between April 7th and April 10th.

For a brighter future if such massive RSA1024 relay key migration is ever again in order, Nick Mathewson wrote proposal 230. The proposal describes a mechanism for relays to advertise their old identity to directory authorities and clients.

Directory authorities can currently tie a relay’s nickname to its identity key with the Named flag. That feature proved to be less helpful than it seemed, and can subject its users to impersonation attacks. As relays switch to new identity keys, those who keep the same name will lose their Named flag for the next six months. So now seems a good time to “throw out the Named and Unnamed flags entirely”. Sebastian Hahn acted on the idea and started a draft proposal.

How should potentially compromised relays which have not switched to a new key be handled? On April 8th, grarpamp observed that more than 3000 relays had been restarted — hopefully to use the fixed version of OpenSSL. It is unknown how many of those relays have switched to a new key since. Andrea Shepard has been working on a survey to identify them. What is known though are relays that are unfortunately still vulnerable. Sina Rabbani has set up a visible list for guards and exits. To protect Tor users, directory authority operators have started to reject descriptors for vulnerable relays.

The identity keys for directory authorities are kept offline. But they are used to certify medium-term signing keys. Roger Dingledine’s
analysis reports “two (moria1 and urras) of the directory authorities were unaffected by the openssl bug, and seven were affected”.

At the time of writing, five of the seven affected authorities had new signing keys. In the meantime, Nick and Andrea have been busy writing code to prevent the old keys from being accepted by Tor clients.

Changing the relay identity keys of the directory authorities has not been done so far “because current clients expect them to be at their current IP:port:fingerprint and would scream in their logs and refuse to connect if the relay identity key changes”. The specification of the missing piece of code to allow a smoother transition has been written by Nick Mathewson in proposal 231.

Finally, hidden service operators are also generating new keys. Unfortunately, this forces every user of the service to update the address in their bookmarks or configuration.

As Roger summarized it: “fun times”.

More monthly status reports for March 2014

The wave of regular monthly reports from Tor project members for the month of March continued, with submissions from Andrew Lewman, Roger Dingledine, and Kelley Misata.

Roger also sent out the report for SponsorF, and the Tails team reported on its progress.

Miscellaneous news

CVE-2014-0160 prompted Anthony Basile to release version 20140409 of Tor-ramdisk. OpenSSL has been updated and so has the kernel. Upgrading is strongly recommended.

David Fifield released new browser bundles configured to use the meek transport automatically. These bundles “use a web browser extension to make the HTTPS requests, so that the TLS layer looks like Firefox” — because it is Firefox. Meek is a promising censorship circumvention solution, so please try them!

The Tails developers announced that Tchou’s proposal is the winner of the recent Tails logo contest: “in the coming days we will keep on fine-tuning it and integrating it in time for Tails 1.0. So don’t hesitate to comment on it.”

Andrew Lewman reported on his week in Stockholm for the Civil Rights Defender’s Defender’s Days where he trained activists and “learned more about the situation in Moldova, Transnistria, Burma, Vietnam, and Bahrain”.

Andrew also updated the instructions for mirror operators wishing to have their sites listed on the Tor Project website. Thanks to Andreas Reich, Sebastian M. Bobrecki, and Jeremy L. Gaddis  for running new mirrors!

Arlo Breault announced the release of Bulb, a Tor relay web status dashboard. “There’s not much to it yet, but I thought I’d share […] Contributions welcome!”

Alan Shreve requested feedback on “Shroud”, a proposal for “a new system to provide public hidden services […] whose network location cannot be determined (like Tor hidden services) but are accessible by any client on the internet”.

Tor help desk roundup

Users often ask for steps they can take to maximize their anonymity while using Tor. Tips for staying anonymous when using Tor are visible on the download page.

News from Tor StackExchange

Jack Gundo uses Windows 7 with the built-in firewall and wants to block all traffic except Tor traffic. Guest suggested that on a closed-source system one can never be sure that all traffic really is blocked, so the original poster might be better off using a router which does the job. Another possible solution is PeerBlock, which also allows you to block all traffic from a machine.

Broot uses obfs3 to route OpenVPN traffic and can’t get obfsproxy running because the latest version only implements SOCKS4. Yawning Angel answered that version 0.2.7 of obfsproxy uses SOCKS5 and works with OpenVPN. However there is a bug that needs to be worked around.


This issue of Tor Weekly News has been assembled by Lunar, harmony, Matt Pagan, qbi, Roger Dingledine, Karsten Loesing and the Tails team.

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 Browser 3.6-beta-2 is released

The Tor Browser Team is proud to announce the second beta in the 3.6 series. Packages are available from the Tor Browser Project page and also from our distribution directory.

This release is an important security update over 3.6-beta-1. This release updates OpenSSL to version 1.0.1g, to address potential client-side vectors for CVE-2014-0160.

The browser itself does not use OpenSSL, and is not vulnerable to this CVE. However, this release is still considered an important security update, because it is theoretically possible to extract sensitive information from the Tor client sub-process.

This beta also features a Turkish language bundle, experimental Javascript hardening options, fixes for pluggable transport issues, and a fix for improper update notification while extracting the bundle over an already existing copy.

Here is the complete changelog since 3.6-beta-1:

  • All Platforms
    • Update OpenSSL to 1.0.1g
    • Bug 9010: Add Turkish language support.
    • Bug 9387 testing: Disable JS JIT, type inference, asmjs, and ion.
    • Update fte transport to 0.2.12
    • Update NoScript to 2.6.8.19
    • Update Torbutton to 1.6.8.1
      • Bug 11242: Fix improper "update needed" message after in-place upgrade.
      • Bug 10398: Ease translation of about:tor page elements
    • Update Tor Launcher to 0.2.5.3
      • Bug 9665: Localize Tor's unreachable bridges bootstrap error
    • Backport Pending Tor Patches:
      • Bug 9665: Report a bootstrap error if all bridges are unreachable
      • Bug 11200: Prevent spurious error message prior to enabling network.
  • Linux:
    • Bug 11190: Switch linux PT build process to python2
    • Bug 10383: Enable NIST P224 and P256 accel support for 64bit builds.
  • Windows:
    • Bug 11286: Fix fte transport launch error


A list of frequently encountered known issues with the Tor Browser can be found on our bugtracker. Please check that list and help us diagnose and arrive at solutions for those issues before contacting support.

Tor Weekly News — April 9th, 2014

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

The Heartbleed Bug and Tor

OpenSSL bug CVE-2014-0160, also known as the Heartbleed bug, “allows anyone on the Internet to read the memory of systems protected by the vulnerable versions of the OpenSSL software”, potentially enabling the compromise of information including “user names and passwords, instant messages, emails, and business critical documents and communication”. Tor is one of the very many networking programs that use OpenSSL to communicate over the Internet, so within a few hours of the bug’s disclosure Roger Dingledine posted a security advisory describing how it affects different areas of the Tor ecosystem.

“The short version is: upgrade your openssl”. Tor Browser users should upgrade as soon as possible to the new 3.5.4 release, which includes OpenSSL 1.0.1g, fixing the vulnerability. “The browser itself does not use OpenSSL…however, this release is still considered an important security update, because it is theoretically possible to extract sensitive information from the Tor client sub-process”, wrote Mike Perry.

Those using a system Tor should upgrade their OpenSSL version and manually restart their Tor process. For relay operators, “best practice would be to update your OpenSSL package, discard all the files in keys/ in your DataDirectory, and restart your Tor to generate new keys”, and for hidden service administrators, “to move to a new hidden-service address at your convenience”. Clients, relays, and services using an older version of OpenSSL, including Tails, are not affected by this bug.

For mobile devices, Nathan Freitas called for immediate testing of Orbot 13.0.6-beta-3, which not only upgrades OpenSSL but also contains a fix for the transproxy leak described by Mike Perry two weeks ago, in addition to smaller fixes and improvements from 13.0.6-beta-1 and subsequently. You can obtain a copy of the .apk file directly from the Guardian Project’s distribution page.

Ultimately, “if you need strong anonymity or privacy on the Internet, you might want to stay away from the Internet entirely for the next few days while things settle.” Be sure to read Roger’s post in full for a more detailed explanation if you are unsure what this bug might mean for you.

A hall of Tor mirrors

Users the world over are increasingly aware of Tor’s leading reputation as a well-researched and -developed censorship circumvention tool — and, regrettably, so are censorship authorities. Events such as last month’s (short-lived) disruption of access to the main Tor Project website from some Turkish internet connections have reaffirmed the need for multiple distribution channels that users can turn to during a censorship event in order to acquire a copy of the Tor Browser, secure their browsing, and beat the censors. One of the simplest ways of ensuring this is to make a copy of the entire website and put it somewhere else.

Recent days have seen the establishment of a large number of new Tor website mirrors, for which thanks must go to Max Jakob Maass, Ahmad Zoughbi, Darren Meyer, Piratenpartei Bayern, Bernd Fix, Florian Walther, the Electronic Frontier Foundation (on a subdomain formerly housing the Tor Project’s official site), the Freedom of the Press Foundation, Caleb Xu, George Kargiotakis, and Tobias Markus, as well as to all the mirror operators of longer standing.

If you’d like to participate in the effort to render blocking of the Tor website even more futile, please see the instructions for running a mirror, and then come to the tor-mirrors mailing list to notify the community!

Mission Impossible: Hardening Android for Security and Privacy

On the Tor Blog, Mike Perry posted another large and comprehensive hacking guide, this time describing “the installation and configuration of a prototype of a secure, full-featured, Android telecommunications device with full Tor support, individual application firewalling, true cell network baseband isolation, and optional ZRTP encrypted voice and video support.” The walkthrough covers hardware selection and setup, recommended software, Google-free backups, and disabling the built-in microphone of a Nexus 7 tablet (with a screwdriver).

As it stands, following this guide may require a certain level of patience, but as Mike wrote, “it is our hope that this work can be replicated and eventually fully automated, given a good UI, and rolled into a single ROM or ROM addon package for ease of use. Ultimately, there is no reason why this system could not become a full fledged off the shelf product, given proper hardware support and good UI for the more technical bits.”

Mike has already added to and improved parts of the guide following contributions from users in the comments beneath the post. If you would like to work (or already are working) at the cutting-edge of research into mobile device security and usability, take a look at Mike’s suggestions for future work at the bottom of the guide, and please share your ideas with the community.

More monthly status reports for March 2014

The wave of regular monthly reports from Tor project members for the month of March continued, with submissions from Arlo Breault, Colin Childs, George Kadianakis, Michael Schloh von Bennewitz, Philipp Winter, and Kevin Dyer.

Arturo Filastò reported on behalf of the OONI team, while Mike Perry did likewise for the Tor Browser team.

Miscellaneous news

David Goulet announced the seventh release candidate for Torsocks 2.0.0, the updated version of the wrapper for safely using network applications with Tor. “Nothing major, fixes and some code refactoring went in”, said David. Please review, test, and report any issues you find.

Nathan Freitas posted a brief analysis of the role played by Orbot in the recent Turkish internet service disruption: “it might be good to think about Turkey’s Twitter block as a “censorship-lite” event, not unlike the UK or Indonesia, and then figure out how we can encourage more adoption.”

Jann Horn drew attention to a potential issue caused by some Tor relays sending out globally-sequential IP IDs. Roger Dingledine linked to an academic paper connected with the same question, while Daniel Bilik suggested one method of preventing this from happening on FreeBSD. Exactly how significant this issue is (or is not) for the Tor network is very much an open question; further research into which operating systems it affects, and how it might be related to known attacks against anonymity, would be very welcome.

As part of their current campaign to fund usable encryption tools (including Tor) for journalists, the Freedom of the Press Foundation published a blog post on the “little-known” Tails operating system, featuring quotes from three of the journalists most prominently associated with the recent Snowden disclosures (Laura Poitras, Glenn Greenwald, and Barton Gellman) attesting to the important role Tails has played in their ability to carry out their work. If you’re impressed by what you read, please donate to the campaign — or become a Tails contributor!

Two Tor-affiliated projects — the Open Observatory of Network Interference and Tails — have each submitted a proposal to this year’s Knight News Challenge. The OONI proposal involves further developing the ooni-probe software suite and deploying it in countries around the world, as well as working on analysis and visualization of the data gathered, in collaboration with the Chokepoint Project; while Tails’ submission proposes to “improve Tails to limit the impact of security flaws, isolate critical applications, and provide same-day security updates”. Voting is limited to the Knight Foundation’s trustees, but feel free to read each submission and leave your comments for the developers.

Robert posted a short proposal for “a prototype of a next-generation Tor control interface, aiming to combine the strengths of both the present control protocol and the state-of-the-art libraries”. The idea was originally destined for this year’s GSoC season, but in the end Robert opted instead to “get some feedback and let the idea evolve.”

After the end of the Tails logo contest last week, sajolida announced that the winner will be declared by April 9th, after a week of voting by the most active Tails contributors.

Following last week’s progress on the Tor website redesign campaign, William Papper presented a functioning beta version of the new download page that he and a team of contributors have been building. Have a look, and let the www-team list know what works and what doesn’t!

Michael Schloh von Bennewitz began work on a guide to configuring a virtual machine for building the Tor Browser Bundle, and another to building with Gitian.

Tor help desk roundup

Tor Browser users often try to set a proxy when they don’t need to. Many users think they can circumvent website bans or get additional security by doing this. Discussion on clarifying the tor-launcher interface is taking place on the bug tracker.

News from Tor StackExchange

Tor’s StackExchange did its second site self-evaluation . Users were asked to review ten questions and their respective answers. This should help to improve the site's overall quality.

The question “Why does GnuPG show the signature of Erinn Clark as not trusted?” got the best rating. When a user verified the downloaded copy of Tor Browser Bundle, GnuPG showed Erinn’s signature as not-trusted. Jens Kubieziel explained the trust model of GnuPG in his answer, and gapz referred to the handbook.

The following questions need better answers: “How to validate certificates?”; “Why does Atlas sometimes show a different IP address from https://check.torproject.org?”; “Site login does not persist”; and “My Atlas page is blank”.

If you know good answers to these questions, please help the users of Tor StackExchange.


This issue of Tor Weekly News has been assembled by harmony, Matt Pagan, qbi, Lunar, Roger Dingledine, 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!

Syndicate content Syndicate content