Tails, The Amnesic Incognito Live System, version 0.16, is out.
All users must upgrade as soon as possible.
Notable user-visible changes include:
- Minor improvements
- Replace the too-easy-to-misclick shutdown button with a better "Shutdown Helper" applet.
~/Persistentin GNOME Places and Gtk file chooser.
- Install dictionaries for a few languages.
- Set Unsafe Browser's window title to "Unsafe Browser".
- Install ekeyd to support the EntropyKey.
- Install font for Sinhala script.
- Update Poedit to 1.5.4.
- Expose Vidalia's "broken onion" icon less.
- Hide the persistence setup launchers in kiosk mode.
- Disable IPv6 on all network interfaces. This is a workaround for the IPv6 link-local multicast leak that was recently discovered.
- Tails may previously have been able to list GPT partitions labelled "TailsData" on hard drives (!) as valid persistence volumes... this is now fixed.
- Fix SCIM in the autostarted web browser.
- Talk of DVD, not of CD, in the shutdown messages.
- Make tordate work in bridge mode with an incorrect clock.
- Update iceweasel to 10.0.12esr-1+tails1.
- Set the homepage to the news section on the Tails website.
- Hide the iceweasel add-on bar by default.
- Don't hide the AdBlock-Plus button in the add-on bar anymore.
- Don't install xul-ext-monkeysphere anymore.
- tails-greeter: add German translation, update Portuguese (Brasil) and Russian ones.
- tails-persistence-setup: update French, German and Italian translations.
Plus the usual bunch of bug reports and minor improvements.
See the online changelog for technical details.
Want to try it or upgrade?
See the Getting started page.
As no software is ever perfect, we maintain a list of problems that affects the last release of Tails.
What's coming up?
See the release schedule for Tails 0.17.
Have a look to our roadmap to see where we are heading to.
Would you want to help? As explained in our "how to contribute" documentation, there are many ways you can contribute to Tails. If you want to help, come talk to us!
The talk went well, but we were in the smaller room, and we and the conference organizers had failed to communicate that it was meant to be more of a workshopy atmosphere. We had a lot of people there who just wanted to see the sequel to our spectacle last year, and it meant we turned away many hundred Tor enthusiasts. Live and learn I guess. I did end up holding a post-talk Tor Q&A session that lasted for seven hours.
Some other highlights from Congress:
- Be sure to watch the DoJ/NSA whistleblower talk (blurb).
- We talked to Christian Grothoff about NAT piercing for Flash Proxy. One of the main deficiencies in the current Flash Proxy design is that the censored user needs to be reachable on the Internet (i.e. not behind a firewall or NAT). While we can't expect the flash proxy bridge running in a browser to be able to craft arbitrary packets (required for most NAT piercing tricks), Peter Palfrader pointed out that we *can* expect the Flash Proxy facilitator to be able to send such packets on behalf of each volunteer bridge. Cute trick — wonder if it'll work.
- I introduced Harry Halpin (W3C) to David Fifield (Flash Proxy). Web browsers are trying to catch up to Skype in terms of real-time media interactions. That means UDP flows, NAT piercing, link encryption, and more, all in the browser. Flash Proxy could sure make use of all that. And the folks working on the WebRTC specifications could use some broader use cases.
- I met several great people from Bits of Freedom, the Dutch NGO that is a sort of hybrid EFF/ACLU for the Netherlands. It seems like only a few years ago that we were lamenting that Europe has too few advocacy organizations to challenge bad laws and policies — data retention, ACTA, etc. That's changing!
- I talked to Linus Nordberg, who runs several fast exits in Sweden as part of DFRI and has been pondering running a bunch of bridges too. The question is: what are the tradeoffs between running both the bridges and exits on the same network (more centralization) vs partitioning them so they run on distinct netblocks? Counterintuitively, due to the "no more than one node on a given /16" rule in Tor's path selection strategy, centralizing the bridges and exits on the same netblock actually improves safety against some adversaries. My recommendation to him was that having more bridges and exits is still better than not, even though the diversity issues remain open and complex research questions.
- I also talked to Linus about what we should do with relays whose exit policies only allow ports commonly used for plaintext traffic. Is that a hint that they're set up by jerks to sniff traffic? Or did the operator not even think about that issue? Should we set the BadExit flag for them? It seems that's a tough arms race for us to win, since they could just choose to exit to a few more ports and suddenly they blend back in. Ultimately I think we need to work harder to establish relationships with all the fast exit relays. We're doing pretty well in terms of knowing the operators of the CCC relays, the Torservers.net relays, the Akamai relays, etc. Will we eventually get to the point where we can cap the bandwidth weights for relays that we haven't met personally? Perhaps we can even bring back the Named or Valid flags for real? In any case, the short-term answer is "send them mail and start a conversation".
- I talked to trams about sandboxing Flash. It would be great to ship the Tor Browser Bundle with some wrappers that prevent Flash from doing scary things. (Ok, it would be even better to wrap the whole OS, but let's not get hasty.) He has a set of protection wrappers that work on OS X, but his next question is what behaviors to allow? I suggested that to start, we should pick exactly the behaviors Youtube uses — then we'll make a lot of Tor users happier while still not opening the attack surface too much. Next messy steps include "that's nice for OS X users, but what about Windows users?" and "How does this relate to FF17's new plugin-container notion?"
- I met with the Wau Holland Foundation board about having WHF be our European coordinator for exit relay funding. It's tricky to get everything organized in a way that's compatible with non-profit laws in both the US and Germany, and also in a way where the community understands how the relationships work. We're getting closer.
- I met with Andy Isaacson of Noisebridge, which operates several fast exits in the US under its Noisetor project. I'd like to sign Noisebridge up to be a US-based coordinator for exit relay funding. But Andy quite reasonably worries that once we start giving Noisetor money for exits, the individual contributions they get to run their exits will disappear. One resolution might be to do one of those "matching funding" deals, where we offer to match every dollar they raise up to some amount. Ultimately, I hope they work with their community to make a plan that lets them either grow the capacity or diversity of the relays they run, or extend the lifetime of their existing relays.
- I talked to bunnie about the open laptop he's working on. Over in Torouter land, we've had a series of experiences where we pick what looks like a fine architecture for a tiny Tor relay. We work with the vendor, help everything go smoothly, and then at the last minute it seems like the vendor goes sideways with some for-profit proprietary alternate plan. :( I really want to live in a world where a fully open platform exists — hardware design and documentation, firmware, device drivers, software, everything. If you can do anything to help bunnie succeed, please do!
In December I attended the award ceremony for the 2012 Access Innovation Awards. Their finalists included three projects that Tor maintains or co-maintains: OONI (a framework for writing open network censorship measurement tests, and for making the results available in an open way; see its git repo), Flash Proxy (a creative way to let people run Tor bridges in their browser just by visiting a website; see its git repo), and HTTPS Everywhere (a Firefox extension to force https connections for websites that support https but don't use it by default; see its git repo). Of these, OONI and Flash Proxy ended up being winners in their respective categories.
(The Access Innovation Prize gave $100,000 across 5 categories to individuals, organizations and networks who submitted "the best actionable ideas on how to use information technology to promote and enable human rights and deliver social good.")
I'm happy that people are recognizing some of the cool projects that Tor works on. But more than that, it's interesting to watch how our projects are integrating into the broader community. The HTTPS Everywhere website is hosted by EFF, and the tool is co-developed by EFF and The Tor Project. The Flash Proxy submission was actually submitted by the New America Foundation's OTI group, where they plan to work on integrating the Flash Proxy badge into a Facebook app (don't worry, they're splitting the prize money with David Fifield, the main Flash Proxy developer). We (Tor) wouldn't be able to have this reach if we didn't have these other organizations working on our topics too.
More generally, the line around what counts as a Tor project has been getting blurrier over the years. We're a community based around free software and transparent design and development, and when we encounter somebody else who is "doing it right", we embrace them and offer whatever resources we can to help them succeed. One nice example is Nathan Freitas of Guardian — he started maintaining an Android version of Tor, and we liked how he was doing it, so we called him a Tor developer. When Nathan uses his Tor affiliation to get funders to listen to him about mobile security issues, everybody wins. Similarly, while David Fifield spends most of his time being a Stanford grad student, he's made such progress on Flash Proxy that we're paying a second Flash Proxy developer to help him with Windows deployment. It's great that OTI is working in this pluggable transport space too. There's no shortage of hard problems and development tasks to go around.
I'm glad I attended the awards evening. I confess that I was worried it would be full of media hype, with journalists lined up to write hasty and shallow articles. (I suppose I'm jaded by being followed around at hacker conferences by journalists with quotas and deadlines. But I was particularly worried this time because both OONI and Flash Proxy are young projects, and we'd be wisest to make some real progress before drawing mainstream media attention to them.) Instead, the attendees were a variety of enthusiastic, not-very-technical New York City residents. Most of them hadn't heard of Tor and had only a very general understanding of Internet privacy and censorship issues; so I had my work cut out for me in terms of advocacy and awareness-building. Highlights included conversations with people from Committee to Protect Journalists, Human Rights Watch, and several similar organizations — these are exactly the sort of orgs that needs the neutral censorship measurement results that OONI aims to provide.
TURKTRUST, a certificate authority in Mozilla’s root program, mis-issued two intermediate certificates to customers. TURKTRUST has scanned their certificate database and log files and confirmed that the mistake was made for only two certificates.
This is not a Firefox-specific issue. Nevertheless, we are concerned that at least one of the mis-issued intermediate certificates was used for man-in-the-middle (MITM) traffic management of domain names that the customer did not legitimately own or control. We are also concerned that the private keys for these certificates were not kept as secure as would be expected for intermediate certificates.
All users are strongly encouraged to upgrade.
There was also a new Tor 0.2.4.7-alpha release and all alpha packages have been updated with that.
A note about the Vidalia bundles:
The plain Vidalia bundles have been discontinued. We apologize for any confusion or inconvenience that this has caused for our users. In order to continue to use the Vidalia bundle as a client, download one of the available bundles, go into the Vidalia "Settings" menu and click "Run as a client only".
Tor Browser Bundle (2.3.25-2)
- Update Firefox to 10.0.12esr
- Update Libevent to 2.0.21-stable
- Update HTTPS Everywhere to 3.1.2
- Update NoScript to 188.8.131.52
Tor Browser Bundle (2.4.7-alpha-1)
- Update Firefox to 10.0.12esr
- Update Tor to 0.2.4.7-alpha
- Update Libevent to 2.0.21-stable
- Update HTTPS Everywhere to 4.0development.4
- Update NoScript to 184.108.40.206
In September, Karen and I attended a conference at the German Foreign Office to help
them decide what role Germany and the EU should have at regulating the sale of censorship and surveillance tools to dictators:
- I liked Eric King (from Privacy International)'s suggestion that when companies are submitting their tools for export evaluation, they should be required to submit their brochures too. Some of these companies are just shameless in terms of how they pitch their tool in terms of number of bloggers you can round up per unit time. He convinced me that controlling "the worst of the worst" in terms of how they can present their product will influence how these products spread.
- That said, these were all (foreign) policy experts, not technologists. They all seemed to take it for granted that you could draw a line between "bad" products and acceptable / dual-use products. I tried to hold back from saying "every time you people try to come up with legal phrasings about what technologies are ok, you end up putting tools like mine on the wrong side of the line." In retrospect, I should have said it more loudly.
- They were really proud to have Tor representatives there. Having us there let them show the world that they had "real technologists" at their meeting. There were several cases where the whole breakout session turned to me and wanted to know what Tor thought about the given question.
- I met a nice man who worked for a telco/DPI company that deploys its products in the Middle East. He raised a compelling argument: "Look, you folks are the ones that mandated backdoors in the telco equipment we produce, using the term 'lawful intercept'. And now you're surprised and upset when bad people use these same backdoors? You made us build it that way!" It certainly is easier for officials in countries like Germany to think of the world as divided between "good" places and "bad" places, but it sure isn't that simple.
Hi all. Just a friendly heads up concerning a couple things going on in our python controller space.
The first is that Mike and I have decided to deprecate TorCtl and make it a part of TorFlow (the framework used to support the Bandwidth Authorities and SoaT). The TorCtl codebase has largely been frozen for years out of concern for the stability of the Bandwidth Authorities (which lack any tests).
If you're writing scripts or controller applications for Tor then you're encouraged to move to either...
Library with a similar design to TorCtl, but friendlier APIs and documentation. This has reached feature parity with TorCtl and is still being actively developed, so if there's something it can do to better suit your needs then please let me know!
Twisted controller library written by Meejah, and used in projects like Ooni Probe.
Both of these libraries have extensive test suites and are being very actively maintained.
The second part are my plans regarding Stem. As of early December we've reached feature completion, covering just about everything in the control-spec and dir-spec.
Next up is migrating our controllers. So far we've moved arm (the largest python controller we have) and the consensus-tracker. Other controllers we have queued up to move are TorBEL, Tor Weather, and the control interpretor.
I've avoided making an initial release announcement for stem because until we have actual users of the library we won't be sure that we nailed a nice, intuitive API (and hence, can't promise that it'll be frozen).
On reflection this is letting the perfect be the enemy of the good. Stem's API is unlikely to change substantially, and holding off on an initial release poses a chicken-and-egg situation. Users want a frozen API before using stem, but we need users before feeling confident enough to lock down the API.
So here's what I propose. For the next couple months stem will have an open beta. If you'd like to have input on the future of our python controller space then please give Stem a try and tell me the following...
What pain points did you encounter? Is there anything that you'd like to see changed or that we're missing?
If your project is public then please tell me where I can find your code. I'll review it, both to suggest improvements and see how we can tweak stem to better suit your needs.
In the unlikely event we make a backward incompatible change I'll check with the beta participants to be sure we don't break anyone (and submit fixes if we do).
Cheers! -Damian (atagar on irc)
PS. Many thanks to Ravi, Sean, Eoin, Beck, Erik, Megan, Sathyanarayanan, and everyone else who has helped stem get to this point. Happy New Year!
Rob just tagged Shadow v1.6.1, and added a link on the download page. This is really more like a pre-1.7.0 release, but he wanted to get out some exciting new support for running multi-threaded simulations earlier!
This release includes:
- Support for running multi-threaded simulations! (use the “-w” flag to specify the number of worker threads)
- A few bugfixes
In preliminary testing, the biggest improvements have been seen when using between 4 and 8 worker threads. Happy simulating!
This January the Tor Project is supporting the Central America Domestic Violence Hackathon. The goal of this effort is to address the challenge of domestic violence by building technology solutions to assist agencies that work to support victims and advance efforts to bring perpetrators to justice.
This is being done by supporting communities on the ground in six Central America countries and Washington, DC. Already some of the organizations involved, including SecondMuse and the World Bank, have worked with these communities to define problems with potential for technical solutions. Next, these problems will be refined and then hacked on at a series of coordinated hackathons on January 26th and 27th, 2013.
We want to invite the Tor community to join us in this process. How can you help? There are two ways:
- Join the collaboration around defining strong problems. You can do this by reading the problem definitions and adding your comments, questions, and ideas. These problems have been generated primarily by non-technical organizations and your insight from a technical perspective can be invaluable. This includes feasibility, use cases, privacy and security concerns, existing solutions, and more.
- Join us on January 26th and 27th in one of the seven locations: Guatemala, El Salvador, Honduras, Nicaragua, Costa Rica, Panama, or Washington, DC.
We believe we can make a difference on domestic violence, and we need you.
Finally, if you'd like to get involved on a deeper level by organizing a problem refinement event, meeting with organizations in these locations, helping organize a hackathon, or more - contact the team running this project at firstname.lastname@example.org.