Blogs

Guest Post: The Library Freedom Project: Bringing privacy and anonymity to libraries

Hi, Tor community! My name is Alison, and I'm the founder of the Library Freedom Project, an initiative that aims to make real the promise of intellectual freedom in libraries. It's a partnership among librarians, technologists, attorneys, and privacy advocates to teach librarians about surveillance threats, privacy rights, and privacy-protecting technology tools. So far, we've been all over Massachusetts and parts of New England, and we have been awarded a generous grant from the Knight Foundation to bring privacy training to libraries across the United States.

We teach librarians three things. Kade Crockford of the ACLU of Massachusetts teaches the current state of digital surveillance. Jessie Rossman, an attorney and surveillance law expert also from the ACLU of Massachusetts, offers a privacy-focused “know your rights” training. I teach technology tools – like Tor and Tails .

Libraries have historically been staunch defenders of privacy, taking public stands against surveillance initiatives like the USA PATRIOT Act. Libraries offer public internet terminals, and librarians like me teach free computer classes to the public. Our patrons come from all walks of life, but we tend to serve communities particularly vulnerable to surveillance (including immigrants, Muslim Americans, people of color, people who are homeless, and those who have been incarcerated) in higher numbers than in the general population. For all of these reasons, libraries are an obvious place to promote and protect online privacy and anonymity and fight against digital censorship and surveillance – that's why I started the Library Freedom Project.

While we focus on US libraries, we are eager to speak to our colleagues in other countries, since privacy is a right for everyone in every country (and privacy is threatened everywhere).

In the tech part of my trainings, I teach tools like the Tor Browser, Tails, HTTPS Everywhere, and DuckDuckGo. I show librarians how to install these on public PCs, and provide curricula for librarians who want to teach privacy-focused computer classes. I help library staff configure Tor relays and set their library websites to run on HTTPS by default. They are thrilled to learn about these tools – as I said, librarians as a profession have always valued privacy, but the development of mass surveillance technologies has outpaced their technical ability. They want to protect their patrons, but they don't know where to start. Thanks to the tools developed by folks in the Tor community, I've been able to teach librarians the skills they need to take anti-surveillance tools to the public. Librarians whom I've trained have started teaching their own classes to library patrons, and the public response has been overwhelmingly positive and moving – these classes make a real difference in the lives of everyday people who are desperate to learn practical ways to take back their digital privacy. The work of the Tor community makes it possible for me and other librarians to help them do this.

So please allow me to express my heartfelt thanks for all that you do. Without tools developed by the Tor community, my work would not be possible. On a personal level, I'm awed by how welcoming and helpful this community has been to me. Tor community folks have offered me feedback, encouragement, and assistance at every turn. Tor Project core member Nima Fatemi even helped build my website (thanks again Nima, I owe you big time!). Now that I run the Library Freedom Project full time, I look forward to working even more closely with folks from the Tor community, and I'd love to give back to your community the way you've given to mine. One specific way that librarians can help the Tor Project is with usability issues – we have lots of experience helping ordinary users with common usability problems. I'd like to introduce developers to librarians who've installed anonymity tools and other free software in their libraries. Librarians can also run dev sprints, help update documentation, and generally advocate for tools that help safeguard privacy and anonymity.

With Knight funding, our goal is to conduct 100 librarian trainings in two years, and build a website of resources for librarians who want to teach their communities how to protect themselves against online surveillance. I'll be traveling all over the US to do this, so please get in touch with me to see if I'm coming to your city! I'd love to bring Tor community members with me to my trainings and help develop a partnership between our two communities.

For more information about the Library Freedom Project, to get involved in the fight for digital civil liberties in libraries, or to offer your own ideas for how this project can move forward, visit our website or contact me.

Tor design proposals: how we make changes to our protocol

(This post is likely to be interesting for folks who want to know how the Tor software is made.)

At the core of the Tor software lies the network protocol that Tor relays and clients use to talk to each other. We try to make sure we have a good set of specification documents for the protocol at all times, so that other people can write compatible software that interoperates with Tor.

Once upon a time, we used to change these specification documents whenever we changed the software's behavior. That didn't go well. We would have changes in the spec that we had forgotten to make in the software, and tons of inline comments where we argued about whether a particular paragraph was a good idea.

So back in 2007, we introduced a lightweight change-proposal process: to make a change to the Tor protocol, you write up a little design document, and send it to the tor-dev mailing list. Once it meets editorial quality, it can go into the proposals repository. Once it's implemented, it can be merged into the spec.

There are a lot of proposals to look at, though. The current set of open proposals has almost 100,000 words in it! (That's almost half again as long as the Tor specs themselves.)

To help people navigate through this pile of design proposals, I started to write a regular "proposal status" email to explain what all of the open proposals are about. Last year, however, I fell out of the habit. Tonight, I've tried to fall back in: here's the latest proposal status writeup.

Below the cut, my summaries of the still-open proposals that have been added in the past couple of year -- and thanks to all the busy designers who have been working to think of ways to improve Tor! read more »

Tor Weekly News — February 4th, 2015

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

Mozilla’s Tor relays go live

Late last year, Mozilla announced its partnership with the Tor Project in the Polaris Privacy Initiative, a program aimed at “giving users more control, awareness and protection in their Web experiences”. One of the two Tor-related “experiments” Mozilla planned to carry out was the operation of several high-capacity middle relays, and last week Mozilla’s Network Engineering team announced that the new nodes had been running for several weeks, in a blog post that explores the technical decisions and challenges they faced in setting them up.

The team discussed the hardware and infrastructure chosen for the relays, configuration management using Ansible (publishing their playbook at the same time), and security practices, as well as announcing their intention to continue posting about their experiences and findings during the experiment.

Thanks to Mozilla for this contribution to the Tor network!

Monthly status reports for January 2015

The wave of regular monthly reports from Tor project members for the month of January has begun. Juha Nurmi released his report first, followed by reports from Philipp Winter, Damian Johnson, Sherief Alaa, Georg Koppen, and David Goulet.

Miscellaneous news

meejah announced version 0.12.0 of txtorcon, the Tor controller client in Twisted; please see the announcement for a full list of improvements.

Nick Mathewson submitted a draft of proposal 241, which aims to protect users against adversaries who are able to attack their connectivity to the Tor network and force them to use malicious guard nodes. Roger Dingledine offered some further thoughts.

Nick also set out the schedule for the Tor 0.2.6 feature freeze.

After reports from users that Tor Browser’s default obfs4 bridges are no longer usable in China, David Fifield estimated the time it takes for the “Great Firewall” to react to new circumvention systems as lying “between 2 and 10 weeks”, and asked for additional data to narrow the range further.

Isis Lovecruft “would be super stoked if we could make it as easy and seamless as possible for the bridge operators who are still running obfs2 (!!) to move to supporting better, newer pluggable transports”, such as obfs4, and wondered how to make it possible for operators running Debian stable to get the necessary dependencies onto their system without extensive backporting: “If someone has done this, or has another simple solution, would you mind writing up some short how-to on the steps you took, please?”

The Tails team continued to discuss the advantages and disadvantages of removing AdBlock Plus from Tails’ version of Tor Browser.

Sadia Afroz compiled a timeline of Tor blocking events, and shared it with the ooni-dev mailing list, along with a request for missing data points; Collin Anderson responded with some additional information.

Patrick Schleizer announced that the Whonix team is looking for “a sponsor who is willing to donate a suitable sized virtual or root server”, and gave a list of planned requirements. If you can meet this need, please see Patrick’s message for next steps.

Konstantin Müller shared a report written as part of a Master’s degree, offering an introduction to “the past, present, and future” of Tor hidden services.

News from Tor StackExchange

Windy wanted to know how often a client fetches consensus data from a directory server. Jens Kubieziel provided some information by walking through the source code, and concluded: “every minute it is checked if the consensus document is too old. If it is older than the current time a new one will be fetched.”


This issue of Tor Weekly News has been assembled by 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 — January 28th, 2015

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

The future of Private Browsing Mode

Mozilla Firefox, on which Tor Browser is based, offers users a “Private Browsing Mode” that aims solely to prevent browsing information from being saved locally. As Georg Koppen pointed out, “The question is now how to treat the other privacy-relevant areas like cross-origin linkability or fingerprinting?”

Georg proposed a “Private Browsing Mode+”, which would integrate the disk-avoidance, anti-tracking, anti-fingerprinting, and location-concealing elements of a privacy-preserving browser in a more logical way.

Miscellaneous news

After a “pretty big overhaul”, Damian Johnson announced that Stem, the Tor controller library, now “lazy-loads” descriptors, resulting in a considerable speed increase when reading network documents. “Note that descriptor validation is now opt-in rather than opt-out, so if you’d prefer validation over performance you’ll now need to include ‘validate = True’.”

The Tails team set out the release schedule for Tails 1.3, and also published its Code of Conduct.

Arturo Filastò reported on OONI-related activities at the Nexa Center’s NNTools2015 event.

Patrick Schleizer wondered how Tor Browser could be made to act more like a “system tor”, and sketched out a possible plan: “What do you think about this proposal in general?”


This issue of Tor Weekly News has been assembled by 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 — January 21st, 2015

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

Tor Browser 4.0.3 and 4.5a3 are out

Georg Koppen announced two new releases by the Tor Browser team. Version 4.0.3 of the privacy-preserving browser is based on Firefox 31.4.0esr, and also contains updates to NoScript, meek, and Tor Launcher.

The third release in the 4.5-alpha series allows the secure in-browser update mechanism to handle signed update files, and will reject unsigned ones from now on. It also restores functionality for meek, which was broken in previous 4.5-alpha releases, and offers other improvements and bugfixes — please see Georg’s announcement for the full changelog.

These releases contain important security updates, so users of both the stable and alpha series should upgrade as soon as possible. Furthermore, Tor Browser 4.5a3 is signed by a new Tor Browser Developers signing key rather than the personal key of an individual developer. If you want to verify your download of the new alpha (and you should!), you will need to retrieve the new key (fingerprint EF6E 286D DA85 EA2A 4BA7 DE68 4E2C 6E87 9329 8290) from a keyserver before doing so.

Miscellaneous news

Anthony G. Basile announced version 20150114 of Tor-ramdisk, the uClibc-based micro Linux distribution whose only purpose is to host a Tor relay in an environment that maximizes security and privacy. This release includes updates to Tor, Libevent, and other key software.

Nik announced oppy, an onion proxy implemented in Python: “oppy works like a regular Tor client”, though “there are a number of simplifications made, with the major ones primarily centering around circuit management/build logic and how and when network status documents are collected”. Nik also asked for suggestions on how to take the project forward: “Whether or not I continue hacking on oppy to make it a solid piece of software (rather than just a prototype) or just leave it as is as a reference depends on whether or not the Tor development community sees any real uses or future potential for the project”.

meejah announced a new one-to-one encrypted and anonymous voice chat feature for “carml”, the command-line Tor control utility: “ [It] essentially cross-connects the mic + speakers of each side via an Opus + OGG stream over a single Tor TCP connection.” As meejah warns, it is “NOT FOR REAL USE at all yet”, but if you have experience with gstreamer and/or OGG then please see meejah’s message for some unresolved questions.

Following suggestions from Sebastian Urbach and grarpamp, Karsten Loesing altered the main unit of data rate measurement for the Tor Metrics portal from MiB/s (mebibytes per second) to the more common Gbit/s (gigabits per second).

Philipp Winter published preliminary statistics and analysis obtained by running a Go implementation of Doctor’s sybil-hunting script over archived consensuses: “I’ll have a more detailed analysis at some point in the future.”

The Tails team published instructions for running an nginx webserver as a hidden service using a copy of Tails: “Feedback is welcome!”

Thanks to Frédéric Cornu for running a mirror of the Tor Project’s website and software!

This week in Tor history

A year ago this week, the “Spoiled Onions” project published its preliminary technical report. The goal of the project was to monitor Tor exit relays in order to “expose, document, and thwart malicious or misconfigured relays”; the researchers turned up 65 such relays over the course of their investigation, with the culprits engaging in attacks such as “SSH and HTTPS MitM, HTML injection, SSL stripping, and traffic sniffing”, or unintentionally interfering with traffic as a result of upstream censorship.

Events such as the RELAY_EARLY traffic confirmation attack and the sybil attacks late last year have only highlighted the importance of monitoring for malicious relays in the Tor network. The bad-relays mailing list serves as a reporting channel for Tor community members who believe particular relays are up to no good (messages sent to the list are not publicly visible, for various reasons); David Fifield has been experimenting with data visualizations of significant network events; and Philipp Winter, a “Spoiled Onions” co-author, has been working on additional tools (such as the above-mentioned Go sybil hunter and “zoossh”, a speedy Tor network document parser) to make these checks more efficient — to give only a few examples of recent work by the community on this issue.


This issue of Tor Weekly News has been assembled by 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 Browser 4.5a3 is released

The third alpha release of the 4.5 series is available from the extended downloads page and also from our distribution directory.

Note: The individual bundles of the alpha series are signed by one of the subkeys of the Tor Browser Developers signing key from now on. You can find its fingerprint on the Signing Keys page. It is:

pub   4096R/0x4E2C6E8793298290 2014-12-15
      Key fingerprint = EF6E 286D DA85 EA2A 4BA7
                        DE68 4E2C 6E87 9329 8290


Tor Browser 4.5a3 is based on Firefox ESR 31.4.0, which features important security updates to Firefox. Its updater now contains the code for verifying signed update files and does not accept unsigned ones anymore. Moreover, this release includes an updated Tor, 0.2.6.2-alpha, an updated meek, 0.15, which is now working again, and a bunch of additional improvements and bugfixes.

Here is the changelog since 4.5-alpha-2:

  • All Platforms
    • Update Firefox to 31.4.0esr
    • Update Tor to 0.2.6.2-alpha
    • Update NoScript to 2.6.9.10
    • Update HTTPS Everywhere to 5.0developement.2
    • Update meek to 0.15
    • Update Torbutton to 1.8.1.3
      • Bug 13998: Handle changes in NoScript 2.6.9.8+
      • Bug 14100: Option to hide NetworkSettings menuitem
      • Bug 13079: Option to skip control port verification
      • Bug 13835: Option to change default Tor Browser homepage
      • Bug 11449: Fix new identity error if NoScript is not enabled
      • Bug 13881: Localize strings for tor circuit display
      • Bug 9387: Incorporate user feedback
      • Bug 13671: Fixup for circuit display if bridges are used
      • Translation updates
    • Update Tor Launcher 0.2.7.1
      • Bug 14122: Hide logo if TOR_HIDE_BROWSER_LOGO set
      • Translation updates
    • Bug 13379: Sign our MAR files
    • Bug 13788: Fix broken meek in 4.5-alpha series
    • Bug 13439: No canvas prompt for content callers

Tor Weekly News — January 14th, 2015

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

What to do if meek gets blocked

Regular readers of Tor Weekly News will be familiar with meek, the pluggable transport developed by David Fifield. Where most existing transports work by connecting clients to “bridge” relays that are difficult for the adversary to discover (or identify as relays), meek makes all of a client’s Tor traffic appear as though it is destined for a domain that is “too big to block” — in other words, web platforms so popular that a censor cannot prevent access to them without disrupting lots of unrelated Internet activity in its sphere of control — when in fact the traffic is sent to meek servers running on those platforms, which in turn relay it into the regular Tor network. Google, Amazon, and Microsoft are some of the services whose domain names currently work as disguises for meek.

Unfortunately, that doesn’t mean meek is unblockable. As David wrote to the tor-talk mailing list, “that’s the wrong way to think about the problem”. “It is designed to be difficult and expensive to block […] but suppose a censor makes that call, and blocks Google/Amazon/whatever. What then?”

Two easy solutions are selecting a different backend (meek-amazon instead of meek-google, for example) or using a different DNS server: “The most common way to block a domain name is by DNS poisoning; i.e., the IP address behind the name is accessible, but the local DNS server gives you a false address. Try a public DNS server such as 8.8.8.8. But if that works, be aware that it’s probably only a temporary fix, as censors have historically figured out the alternate-DNS trick pretty fast.”

“What you really want to do”, David suggested, “if the easy things don’t work, is choose a different front domain.” Please see David’s message for a fuller explanation of the difference between the backend and the “front domain”, and a guide to configuring new domains — as well as one to setting up your own meek web app, if all else fails.

Miscellaneous news

sycamoreone announced orc, a Go library that implements parts of Tor’s control protocol. “I do have some ideas for a higher-level interface, but no fixed plan yet. The next step will probably be to add net/http-like handlerFuncs to handle (asynchronous) replies from the onion router.”

taxakis linked to “Post-Quantum Secure Onion Routing” by Satrajit Ghosh and Aniket Kate, a new paper proposing a successor to the currently-used ntor handshake protocol that would be “resilient against quantum attacks, but also at the same time allow OR nodes to use the current DH public keys, and consequently require no modification to the current Tor public key infrastructure.” Nick Mathewson wondered whether “anybody around here has the cryptographic background to comment on the PQ part of their scheme?”, and compared it to Yawning Angel’s experimental “basket” protocol.

Nick also sent out a draft of proposal 240, describing “a simple way for directory authorities to perform signing key revocation”.

Daniel Forster asked for advice on proposed research into splitting traffic over multiple entry guards in combination with traffic padding: “Is the approach heading in a not so great direction w.r.t. the Tor Project’s ‘only one entry node’ decision?”

Karsten Loesing submitted his status report for December, and George Kadianakis sent out the report for SponsorR.

“After CCC I have a list of people that I have given raspberry pi’s with ooniprobe, and I would like to start coordinating with them via a mailing list”, wrote Arturo Filastò, and the result is the ooni-operators mailing list. If you regularly run ooniprobe, or want to start, be sure to sign up!

Aleksejs Popovs shared with the ooni-dev mailing list the results of an OONI investigation into Latvian internet censorship, conducted using ooniprobe.

Dan O’Huiginn started a conversation about how to ensure users are informed of the possible consequences of running OONI tests.

Thanks to John Knoll and Monsieur Tino for running mirrors of the Tor Project’s website and software archive!

“How do we prevent a website mirror admin from tampering with the served files?”, wondered Frédéric Cornu. Christian Krbusek clarified that “in fact, you can’t prevent that, but you are also mirroring the signature files. So anybody downloading from any mirror — even the original host — should verify the downloads”. Andrew Lewman added that “the binaries are signed by well-known keys of tor packagers and developers. The mirror update script randomly selects a binary and verifies it each time it runs. If the binaries don't match, the mirror is removed from the public list.”


This issue of Tor Weekly News has been assembled by 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 Browser 4.0.3 is released

A new release for the stable Tor Browser is available from the Tor Browser Project page and also from our distribution directory.

Tor Browser 4.0.3 is based on Firefox ESR 31.4.0, which features important security updates to Firefox. Additionally, it contains updates to meek, NoScript and Tor Launcher.

Here is the changelog since 4.0.2:

  • All Platforms
    • Update Firefox to 31.4.0esr
    • Update NoScript to 2.6.9.10
    • Update meek to 0.15
    • Update Tor Launcher to 0.2.7.0.2
      • Translation updates only
Syndicate content Syndicate content