Version 49 (modified by traumschule, 8 months ago) (diff)

link current milestones

Website team communication channels

Mailing list:


  • #tor-www on OFTC (


Start with #21222 and main site redesign


Tor Website 3 Milestone website redesign

Project tickets

Ticket Summary Owner Component Milestone
#11569 Consider making donations part of the download process Webpages/Website WebsiteV3

The re-designed download-easy page ( has resulted in a 2x increase in monthly donations since deployment. Some thoughts to consider:

  1. move the donations button closer to the download button.
  2. Rework the page so the donations button is first, with a nice reason why donations are needed, but clearly state downloads are still free, and click the download button to skip a donation process
  3. Change the page flow so that downloads go to a donation request page first, and then after 10 seconds of no action, redirect to the download-easy page.
#27132 find Tor-friendly payment site Community WebsiteV3

From parent #11569

it seems the clear next step is to find one not-totally-unusable payment site that doesn't hate Tor users, and drive all the traffic there.

All website tickets

See all tickets related to the website, sorted by status.

How to contribute ideas

This wiki should be seen as a record of concrete proposals. As such, here is a loose procedure to follow if you would like to suggest new ideas:

  1. Write a proposal on the wiki
  2. Start a discussion on the www-team with a copy of the proposal
  3. Build a consensus and refine the wiki
  4. Repeat!
  5. Implement


The current website is powered by WML. Switching to a more recent engine supporting lighter syntax (like Markdown) is probably worthwhile.

Technical requirements

  • Generate static web pages that can work offline as well. That means self-contained and zero 3rd party requests. No mandatory client-side JavaScript either.
  • Content should be kept in Git.
  • Support for the “Don't Repeat Yourself” principle, e.g. the latest version of the Tor Browser Bundle needs to be kept at a single place but used at different places in the website.
  • Support translations. A changes in a single paragraph should be easily to propagate to translators and to then to translations.


The following projects look like potential candidates:


Pelican is a static site generator, written in Python. Documentation


Jekyll is a simple, blog-aware, static site generator, written in Ruby. Website


Middleman is a static site generator using all the shortcuts and tools in modern web development, written in Ruby. Website


Nikola is a Static Site and Blog Generator. Website

How to build the current website

Some commands than can be used on a Debian Wheezy system to build the current website:

    apt install wml
    apt install --no-install-recommends asciidoc
    git clone
    git clone
    echo "export TORGIT=$(pwd)/tor/.git" > webwml/Makefile.local
    cd webwml/

This should only be required if structural changes are necessary, typically you should push a branch with changes somewhere and ask for a pull by opening a ticket in the website component here.


Some notes from a discussion that happened during 30C3 gathering ideas on how to structure the website.

Proposed new information architecture

  • Understand
    • For: Everyone and journalists
  • Use
    • Howto
  • Research
    • Whitepapers
    • Papers
    • Tech Docs
    • Anonweb
  • Contribute
    • Finance
    • Outreach Materials Ideas Stuff
  • Subproject - List
  • FAQ
  • Blog
    • Localized blog? E.g. contains information specific to a given location. Do the same for de, mx, or other places?
  • Press


The Student

The Student has recently heard about Tor and would like to discover more about it. Particularly he has heard from a friend that it could be used to protect his web browsing whilst using the university campus public wifi.

The Journalist

The Journalist has been writing about online privacy for the past year and would like to write a feature about Tor. Although she has previously experimented with Tor's browser bundle she would like further information of how the Tor infrastructure functions and the technical details behind how it enables online anonymity.

The Researcher

The Researcher works for a think tank. She has been a user of Tor since December 2011 and is a strong proponent for an open web. Since finding out about Tor, Stephanie has become involved in the Tor community contributing fixes and features to the Tor code base and engaging with other Tor contributers using the mailing lists and IRC.

The Donor

The Donor has read about Tor in the local newspaper and would very much like to make a donation.

The Engineer

The Engineer has been a Tor Relay Operator for a little over a year and has encouraged two of his colleagues to do the same.

The Activist

The Activist would like to comment anonymously on the Internet and not link her personal accounts to her activism work. She would like to use Tor to achieve this.

The Dissident

The Dissident lives under an oppressive regime which heavily filters the internet. He is very aware of the consequences to himself and his family if he is discovered. He is hesitant to use Tor without knowledge of how it works and what its limitations are (ie. an adversary that monitors Internet connections).

Technical Requirements

  • Debian native citizen
  • Static Site Generator
  • Easy to use for whole staff
  • Internationalization

Useful base concepts

  • Direct each user quickly to the right part
  • If graphic redesign, think about the whole project, general 'CI'
  • Communicate basic concepts with communication department
  • Primary target: never deliver software without education


User Education

  • Educate before download
  • Educate on browser startup

How to contribute

The following was brainstormed at the Berlin dev. meeting in September 2015.

Sebastian will be the main gatekeeper of the website. Changes should be proposed using tickets on Trac with the “website” component. Ideally the ticket should contain a pull request or a patch. For people who are not able to modify the code or don't want to, we have a team of people willing to act as integrator.

A “staging” website will be built automatically. When a substantial change is merged, a call for review should be sent to the www-team mailing list. A clear deadline for reviews should be announced in the call. Once that deadline is past and either there was not problems or they have been solved, the result is pushed in production.

For language changes, we might not want to push changes in production right away but rather gives a heads-up to translators. This would not be a blocker, but just a couple of days to give the chance to have more translations in sync.

To make a language available, the 85% of the website needs to be translated and the language should have a designated reviewer. That person would send pull requests once they have vouched a translation as correct. They would also be the point of contact when bugs are reported for a given translation.

Contact people

  • Sebastian
  • Isabela