diff options
| -rw-r--r-- | doc/design-paper/roadmap-future.tex | 690 |
1 files changed, 690 insertions, 0 deletions
diff --git a/doc/design-paper/roadmap-future.tex b/doc/design-paper/roadmap-future.tex new file mode 100644 index 000000000..cebe4a590 --- /dev/null +++ b/doc/design-paper/roadmap-future.tex @@ -0,0 +1,690 @@ +\documentclass{article} + +\usepackage{url} + +\newenvironment{tightlist}{\begin{list}{$\bullet$}{ + \setlength{\itemsep}{0mm} + \setlength{\parsep}{0mm} + % \setlength{\labelsep}{0mm} + % \setlength{\labelwidth}{0mm} + % \setlength{\topsep}{0mm} + }}{\end{list}} +\newcommand{\tmp}[1]{{\bf #1} [......] \\} +\newcommand{\plan}[1]{ {\bf (#1)}} + +\begin{document} + +\title{Tor Development Roadmap: Wishlist for Nov 2006--Dec 2007} +\author{Roger Dingledine \and Nick Mathewson \and Shava Nerad} + +\maketitle +\pagestyle{plain} + +% TO DO: +% add cites +% add time estimates + + +\section{Introduction} +%Hi, Roger! Hi, Shava. This paragraph should get deleted soon. Right now, +%this document goes into about as much detail as I'd like to go into for a +%technical audience, since that's the audience I know best. It doesn't have +%time estimates everywhere. It isn't well prioritized, and it doesn't +%distinguish well between things that need lots of research and things that +%don't. The breakdowns don't all make sense. There are lots of things where +%I don't make it clear how they fit into larger goals, and lots of larger +%goals that don't break down into little things. It isn't all stuff we can do +%for sure, and it isn't even all stuff we can do for sure in 2007. The +%tmp\{\} macro indicates stuff I haven't said enough about. That said, here +%plangoes... + +Tor (the software) and Tor (the overall software/network/support/document +suite) are now experiencing all the crises of success. Over the next year, +we're probably going to grow more in terms of users, developers, and funding +than before. This gives us the opportunity to perform long-neglected +maintenance tasks. + +\section{Code and design infrastructure} + +\subsection{Protocol revision} +To maintain backward compatibility, we've postponed major protocol +changes and redesigns for a long time. Because of this, there are a number +of sensible revisions we've been putting off until we could deploy several of +them at once. To do each of these, we first need to discuss design +alternatives with other cryptographers and outside collaborators to +make sure that our choices are secure. + +First of all, our protocol needs better {\bf versioning support} so that we +can make backward-incompatible changes to our core protocol. There are +difficult anonymity issues here, since many naive designs would make it easy +to tell clients apart (and then track them) based on their supported versions. + +With protocol versioning support would come the ability to {\bf future-proof + our ciphersuites}. For example, not only our OR protocol, but also our +directory protocol, is pretty firmly tied to the SHA-1 hash function, which +though not yet known to be insecure for our purposes, has begun to show +its age. We should +remove assumptions throughout our design based on the assumption that public +keys, secret keys, or digests will remain any particular size indefinitely. + +Our OR {\bf authentication protocol}, though provably +secure\cite{tap:pet2006}, relies more on particular aspects of RSA and our +implementation thereof than we had initially believed. To future-proof +against changes, we should replace it with a less delicate approach. + +\plan{For all the above: 2 person-months to specify, spread over several + months with time for interaction with external participants. One + person-month to implement. Start specifying in early 2007.} + +We might design a {\bf stream migration} feature so that streams tunneled +over Tor could be more resilient to dropped connections and changed IPs. +\plan{Not in 2007.} + +A new protocol could support {\bf multiple cell sizes}. Right now, all data +passes through the Tor network divided into 512-byte cells. This is +efficient for high-bandwidth protocols, but inefficient for protocols +like SSH or AIM that send information in small chunks. Of course, we need to +investigate the extent to which multiple sizes could make it easier for an +adversary to fingerprint a traffic pattern. \plan{Not in 2007.} + +As a part of our design, we should investigate possible {\bf cipher modes} +other than counter mode. For example, a mode with built-in integrity +checking, error propagation, and random access could simplify our protocol +significantly. Sadly, many of these are patented and unavailable for us. +\plan{Not in 2007.} + +\subsection{Scalability} + +\subsubsection{Improved directory efficiency} +Right now, clients download a statement of the {\bf network status} made by +each directory authority. We could reduce network bandwidth significantly by +having the authorities jointly sign a statement reflecting their vote on the +current network status. This would save clients up to 160K per hour, and +make their view of the network more uniform. Of course, we'd need to make +sure the voting process was secure and resilient to failures in the +network.\plan{Must do; specify in 2006. 2 weeks to specify, 3-4 weeks to + implement.} + +We should {\bf shorten router descriptors}, since the current format includes +a great deal of information that's only of interest to the directory +authorities, and not of interest to clients. We can do this by having each +router upload a short-form and a long-form signed descriptor, and having +clients download only the short form. Even a naive version of this would +save about 40\% of the bandwidth currently spent by clients downloading +descriptors.\plan{Must do; specify in 2006. 3-4 weeks.} + +We should {\bf have routers upload their descriptors even less often}, so +that clients do not need to download replacements every 18 hours whether any +information has changed or not. (As of Tor 0.1.2.3-alpha, clients tolerate +routers that don't upload often, but routers still upload at least every 18 +hours to support older clients.) \plan{Must do, but not until 0.1.1.x is +deprecated in mid 2007. 1 week.} + +\subsubsection{Non-clique topology} +Our current network design achieves a certain amount of its anonymity by +making clients act like each other through the simple expedient of making +sure that all clients know all servers, and that any server can talk to any +other server. But as the number of servers increases to serve an +ever-greater number of clients, these assumptions become impractical. + +At worst, if these scalability issues become troubling before a solution is +found, we can design and build a solution to {\bf split the network into +multiple slices} until a better solution comes along. This is not ideal, +since rather than looking like all other users from a point of view of path +selection, users would ``only'' look like 200,000--300,000 other +users.\plan{Not unless needed.} + +We are in the process of designing {\bf improved schemes for network + scalability}. Some approaches focus on limiting what an adversary can know +about what a user knows; others focus on reducing the extent to which an +adversary can exploit this knowledge. These are currently in their infancy, +and will probably not be needed in 2007, but they must be designed in 2007 if +they are to be deployed in 2008.\plan{Design in 2007; unknown difficulty. + Write a paper.} + +\subsubsection{Relay incentives} +To support more users on the network, we need to get more servers. So far, +we've relied on volunteerism to attract server operators, and so far it's +served us well. But in the long run, we need to {\bf design incentives for + users to run servers} and relay traffic for others. Most obviously, we +could try to build the network so that servers offered improved service for +other servers, but we would need to do so without weakening anonymity and +making it obvious which connections originate from users running servers. We +have some preliminary designs~\cite{incentives-txt,tor-challenges}, +but need to perform +some more research to make sure they would be safe and effective.\plan{Write + a draft paper; 2 person-months.} + +\subsection{Portability} +Our {\bf Windows implementation}, though much improved, continues to lag +behind Unix and Mac OS X, especially when running as a server. We hope to +merge promising patches from Mike Chiussi to address this point, and bring +Windows performance on par with other platforms.\plan{Do in 2007; 1.5 months + to integrate not counting Mike's work.} + +We should have {\bf better support for portable devices}, including modes of +operation that require less RAM, and that write to disk less frequently (to +avoid wearing out flash RAM).\plan{Optional; 2 weeks.} + +We should {\bf stop using socketpair on Windows}; instead, we can use +in-memory structures to communicate between cpuworkers and the main thread, +and between connections.\plan{Optional; 1 week.} + +\subsection{Performance: resource usage} +We've been working on {\bf using less RAM}, especially on servers. This has +paid off a lot for directory caches in the 0.1.2, which in some cases are +using 90\% less memory than they used to require. But we can do better, +especially in the area around our buffer management algorithms, by using an +approach more like the BSD and Linux kernels use instead of our current ring +buffer approach. (For OR connections, we can just use queues of cell-sized +chunks produced with a specialized allocator.) This could potentially save +around 25 to 50\% of the memory currently allocated for network buffers, and +make Tor a more attractive proposition for restricted-memory environments +like old computers, mobile devices, and the like.\plan{Do in 2007; 2-3 weeks + plus one week measurement.} + +We should improve our {\bf bandwidth limiting}. The current system has been +crucial in making users willing to run servers: nobody is willing to run a +server if it might use an unbounded amount of bandwidth, especially if they +are charged for their usage. We can make our system better by letting users +configure bandwidth limits independently for their own traffic and traffic +relayed for others; and by adding write limits for users running directory +servers.\plan{Do in 2006; 2-3 weeks.} + +On many hosts, sockets are still in short supply, and will be until we can +migrate our protocol to UDP. We can {\bf use fewer sockets} by making our +self-to-self connections happen internally to the code rather than involving +the operating system's socket implementation.\plan{Optional; 1 week.} + +\subsection{Performance: network usage} +We know too little about how well our current path +selection algorithms actually spread traffic around the network in practice. +We should {\bf research the efficacy of our traffic allocation} and either +assure ourselves that it is close enough to optimal as to need no improvement +(unlikely) or {\bf identify ways to improve network usage}, and get more +users' traffic delivered faster. Performing this research will require +careful thought about anonymity implications. + +We should also {\bf examine the efficacy of our congestion control + algorithm}, and see whether we can improve client performance in the +presence of a congested network through dynamic `sendme' window sizes or +other means. This will have anonymity implications too if we aren't careful. + +\plan{For both of the above: research, design and write + a measurement tool in 2007: 1 month. See if we can interest a graduate + student.} + +We should work on making Tor's cell-based protocol perform better on +networks with low bandwidth +and high packet loss.\plan{Do in 2007 if we're funded to do it; 4-6 weeks.} + +\subsection{Performance scenario: one Tor client, many users} +We should {\bf improve Tor's performance when a single Tor handles many + clients}. Many organizations want to manage a single Tor client on their +firewall for many users, rather than having each user install a separate +Tor client. We haven't optimized for this scenario, and it is likely that +there are some code paths in the current implementation that become +inefficient when a single Tor is servicing hundreds or thousands of client +connections. (Additionally, it is likely that such clients have interesting +anonymity requirements the we should investigate.) We should profile Tor +under appropriate loads, identify bottlenecks, and fix them.\plan{Do in 2007 + if we're funded to do it; 4-8 weeks.} + +\subsection{Tor servers on asymmetric bandwidth} + +Tor should work better on servers that have asymmetric connections like cable +or DSL. Because Tor has separate TCP connections between each +hop, if the incoming bytes are arriving just fine and the outgoing bytes are +all getting dropped on the floor, the TCP push-back mechanisms don't really +transmit this information back to the incoming streams.\plan{Do in 2007 since + related to bandwidth limiting. 3-4 weeks.} + +\subsection{Running Tor as both client and server} + +Many performance tradeoffs and balances that might need more attention. +We first need to track and fix whatever bottlenecks emerge; but we also +need to invent good algorithms for prioritizing the client's traffic +without starving the server's traffic too much.\plan{No idea; try +profiling and improving things in 2007.} + +\subsection{Protocol redesign for UDP} +Tor has relayed only TCP traffic since its first versions, and has used +TLS-over-TCP to do so. This approach has proved reliable and flexible, but +in the long term we will need to allow UDP traffic on the network, and switch +some or all of the network to using a UDP transport. {\bf Supporting UDP + traffic} will make Tor more suitable for protocols that require UDP, such +as many VOIP protocols. {\bf Using a UDP transport} could greatly reduce +resource limitations on servers, and make the network far less interruptible +by lossy connections. Either of these protocol changes would require a great +deal of design work, however. We hope to be able to enlist the aid of a few +talented graduate students to assist with the initial design and +specification, but the actual implementation will require significant testing +of different reliable transport approaches.\plan{Maybe do a design in 2007 if +we find an interested academic. Ian or Ben L might be good partners here.} + +\section{Blocking resistance} + +\subsection{Design for blocking resistance} +We have written a design document explaining our general approach to blocking +resistance. We should workshop it with other experts in the field to get +their ideas about how we can improve Tor's efficacy as an anti-censorship +tool. + +\subsection{Implementation: client-side and bridges-side} + +Our anticensorship design calls for some nodes to act as ``bridges'' +that are outside a national firewall, and others inside the firewall to +act as pure clients. This part of the design is quite clear-cut; we're +probably ready to begin implementing it. To {\bf implement bridges}, we +need to have servers publish themselves as limited-availability relays +to a special bridge authority if they judge they'd make good servers. +We will also need to help provide documentation for port forwarding, +and an easy configuration tool for running as a bridge. + +To {\bf implement clients}, we need to provide a flexible interface to +learn about bridges and to act on knowledge of bridges. We also need +to teach them how to know to use bridges as their first hop, and how to +fetch directory information from both classes of directory authority. + +Clients also need to {\bf use the encrypted directory variant} added in Tor +0.1.2.3-alpha. This will let them retrieve directory information over Tor +once they've got their initial bridges. We may want to get the rest of the +Tor user base to begin using this encrypted directory variant too, to +provide cover. + +Bridges will want to be able to {\bf listen on multiple addresses and ports} +if they can, to give the adversary more ports to block. + +\subsection{Research: anonymity implications from becoming a bridge} + +\subsection{Implementation: bridge authority} + +The design here is also reasonably clear-cut: we need to run some +directory authorities with a slightly modified protocol that doesn't leak +the entire list of bridges. Thus users can learn up-to-date information +for bridges they already know about, but they can't learn about arbitrary +new bridges. + +\subsection{Normalizing the Tor protocol on the wire} +Additionally, we should {\bf resist content-based filters}. Though an +adversary can't see what users are saying, some aspects of our protocol are +easy to fingerprint {\em as} Tor. We should correct this where possible. + +Look like Firefox; or look like nothing? +Future research: investigate timing similarities with other protocols. + +\subsection{Access control for bridges} +Design/impl: password-protecting bridges, in light of above. +And/or more general access control. + +\subsection{Research: scanning-resistance} + +\subsection{Research/Design/Impl: how users discover bridges} +Our design anticipates an arms race between discovery methods and censors. +We need to begin the infrastructure on our side quickly, preferably in a +flexible language like Python, so we can adapt quickly to censorship. + +phase one: personal bridges +phase two: families of personal bridges +phase three: more structured social network +phase four: bag of tricks +Research: phase five... + +Integration with Psiphon, etc? + +\subsection{Document best practices for users} +Document best practices for various activities common among +blocked users (e.g. WordPress use). + +\subsection{Research: how to know if a bridge has been blocked?} + +\subsection{GeoIP maintenance, and "private" user statistics} +How to know if the whole idea is working? + +\subsection{Research: hiding whether the user is reading or publishing?} + +\subsection{Research: how many bridges do you need to know to maintain +reachability?} + +\subsection{Resisting censorship of the Tor website, docs, and mirrors} + +We should take some effort to consider {\bf initial distribution of Tor and + related information} in countries where the Tor website and mirrors are +censored. (Right now, most countries that block access to Tor block only the +main website and leave mirrors and the network itself untouched.) Falling +back on word-of-mouth is always a good last resort, but we should also take +steps to make sure it's relatively easy for users to get ahold of a copy. + +\section{Security} + +\subsection{Security research projects} + +We should investigate approaches with some promise to help Tor resist +end-to-end traffic correlation attacks. It's an open research question +whether (and to what extent) {\bf mixed-latency} networks, {\bf low-volume + long-distance padding}, or other approaches can resist these attacks, which +are currently some of the most effective against careful Tor users. We +should research these questions and perform simulations to identify +opportunities for strengthening our design without dropping performance to +unacceptable levels. %Cite something +\plan{Start doing this in 2007; write a paper. 8-16 weeks.} + +We've got some preliminary results suggesting that {\bf a topology-aware + routing algorithm}~\cite{feamster:wpes2004} could reduce Tor users' +vulnerability against local or ISP-level adversaries, by ensuring that they +are never in a position to watch both ends of a connection. We need to +examine the effects of this approach in more detail and consider side-effects +on anonymity against other kinds of adversaries. If the approach still looks +promising, we should investigate ways for clients to implement it (or an +approximation of it) without having to download routing tables for the whole +Internet. \plan{Not in 2007 unless a graduate student wants to do it.} + +%\tmp{defenses against end-to-end correlation} We don't expect any to work +%right now, but it would be useful to learn that one did. Alternatively, +%proving that one didn't would free up researchers in the field to go work on +%other things. +% +% See above; I think I got this. + +We should research the efficacy of {\bf website fingerprinting} attacks, +wherein an adversary tries to match the distinctive traffic and timing +pattern of the resources constituting a given website to the traffic pattern +of a user's client. These attacks work great in simulations, but in +practice we hear they don't work nearly as well. We should get some actual +numbers to investigate the issue, and figure out what's going on. If we +resist these attacks, or can improve our design to resist them, we should. +% add cites +\plan{Possibly part of end-to-end correlation paper. Otherwise, not in 2007 + unless a graduate student is interested.} + +\subsection{Implementation security} +Right now, each Tor node stores its keys unencrypted. We should {\bf encrypt + more Tor keys} so that Tor authorities can require a startup password. We +should look into adding intermediary medium-term ``signing keys'' between +identity keys and onion keys, so that a password could be required to replace +a signing key, but not to start Tor. This would improve Tor's long-term +security, especially in its directory authority infrastructure.\plan{Design this + as a part of the revised ``v2.1'' directory protocol; implement it in + 2007. 3-4 weeks.} + +We should also {\bf mark RAM that holds key material as non-swappable} so +that there is no risk of recovering key material from a hard disk +compromise. This would require submitting patches upstream to OpenSSL, where +support for marking memory as sensitive is currently in a very preliminary +state.\plan{Nice to do, but not in immediate Tor scope.} + +There are numerous tools for identifying trouble spots in code (such as +Coverity or even VS2005's code analysis tool) and we should convince somebody +to run some of them against the Tor codebase. Ideally, we could figure out a +way to get our code checked periodically rather than just once.\plan{Almost + no time once we talk somebody into it.} + +We should try {\bf protocol fuzzing} to identify errors in our +implementation.\plan{Not in 2007 unless we find a grad student or + undergraduate who wants to try.} + +Our guard nodes help prevent an attacker from being able to become a chosen +client's entry point by having each client choose a few favorite entry points +as ``guards'' and stick to them. We should implement a {\bf directory + guards} feature to keep adversaries from enumerating Tor users by acting as +a directory cache.\plan{Do in 2007; 2 weeks.} + +\subsection{Detect corrupt exits and other servers} +With the success of our network, we've attracted servers in many locations, +operated by many kinds of people. Unfortunately, some of these locations +have compromised or defective networks, and some of these people are +untrustworthy or incompetent. Our current design relies on authority +administrators to identify bad nodes and mark them as nonfunctioning. We +should {\bf automate the process of identifying malfunctioning nodes} as +follows: + +We should create a generic {\bf feedback mechanism for add-on tools} like +Mike Perry's ``Snakes on a Tor'' to report failing nodes to authorities. +\plan{Do in 2006; 1-2 weeks.} + +We should write tools to {\bf detect more kinds of innocent node failure}, +such as nodes whose network providers intercept SSL, nodes whose network +providers censor popular websites, and so on. We should also try to detect +{\bf routers that snoop traffic}; we could do this by launching connections +to throwaway accounts, and seeing which accounts get used.\plan{Do in 2007; + ask Mike Perry if he's interested. 4-6 weeks.} + +We should add {\bf an efficient way for authorities to mark a set of servers + as probably collaborating} though not necessarily otherwise dishonest. +This happens when an administrator starts multiple routers, but doesn't mark +them as belonging to the same family.\plan{Do during v2.1 directory protocol + redesign; 1-2 weeks to implement.} + +To avoid attacks where an adversary claims good performance in order to +attract traffic, we should {\bf have authorities measure node performance} +(including stability and bandwidth) themselves, and not simply believe what +they're told. Measuring stability can be done by tracking MTBF. Measuring +bandwidth can be tricky, since it's hard to distinguish between a server with +low capacity, and a high-capacity server with most of its capacity in +use.\plan{Do ``Stable'' in 2007; 2-3 weeks. ``Fast'' will be harder; do it + if we can interest a grad student.} + +{\bf Operating a directory authority should be easier.} We rely on authority +operators to keep the network running well, but right now their job involves +too much busywork and administrative overhead. A better interface for them +to use could free their time to work on exception cases rather than on +adding named nodes to the network.\plan{Do in 2007; 4-5 weeks.} + +\subsection{Protocol security} + +In addition to other protocol changes discussed above, +% And should we move some of them down here? -NM +we should add {\bf hooks for denial-of-service resistance}; we have some +preliminary designs, but we shouldn't postpone them until we really need them. +If somebody tries a DDoS attack against the Tor network, we won't want to +wait for all the servers and clients to upgrade to a new +version.\plan{Research project; do this in 2007 if funded.} + +\section{Development infrastructure} + +\subsection{Build farm} +We've begun to deploy a cross-platform distributed build farm of hosts +that build and test the Tor source every time it changes in our development +repository. + +We need to {\bf get more participants}, so that we can test a larger variety +of platforms. (Previously, we've only found out when our code had broken on +obscure platforms when somebody got around to building it.) + +We need also to {\bf add our dependencies} to the build farm, so that we can +ensure that libraries we need (especially libevent) do not stop working on +any important platform between one release and the next. + +\plan{This is ongoing as more buildbots arrive.} + +\subsection{Improved testing harness} +Currently, our {\bf unit tests} cover only about 20\% of the code base. This +is uncomfortably low; we should write more and switch to a more flexible +testing framework.\plan{Ongoing basis, time permitting.} + +We should also write flexible {\bf automated single-host deployment tests} so +we can more easily verify that the current codebase works with the +network.\plan{Worthwhile in 2007; would save lots of time. 2-4 weeks.} + +We should build automated {\bf stress testing} frameworks so we can see which +realistic loads cause Tor to perform badly, and regularly profile Tor against +these loads. This would give us {\it in vitro} performance values to +supplement our deployment experience.\plan{Worthwhile in 2007; 2-6 weeks.} + +We should improve our memory profiling code.\plan{...} + + +\subsection{Centralized build system} +We currently rely on a separate packager to maintain the packaging system and +to build Tor on each platform for which we distribute binaries. Separate +package maintainers is sensible, but separate package builders has meant +long turnaround times between source releases and package releases. We +should create the necessary infrastructure for us to produce binaries for all +major packages within an hour or so of source release.\plan{We should + brainstorm this at least in 2007.} + +\subsection{Improved metrics} +We need a way to {\bf measure the network's health, capacity, and degree of + utilization}. Our current means for doing this are ad hoc and not +completely accurate + +We need better ways to {\bf tell which countries are users are coming from, + and how many there are}. A good perspective of the network helps us +allocate resources and identify trouble spots, but our current approaches +will work less and less well as we make it harder for adversaries to +enumerate users. We'll probably want to shift to a smarter, statistical +approach rather than our current ``count and extrapolate'' method. + +\plan{All of this in 2007 if funded; 4-8 weeks} + +% \tmp{We'd like to know how much of the network is getting used.} +% I think this is covered above -NM + +\subsection{Controller library} +We've done lots of design and development on our controller interface, which +allows UI applications and other tools to interact with Tor. We could +encourage the development of more such tools by releasing a {\bf + general-purpose controller library}, ideally with API support for several +popular programming languages.\plan{2006 or 2007; 1-2 weeks.} + +\section{User experience} + +\subsection{Get blocked less, get blocked less broadly} +Right now, some services block connections from the Tor network because +they don't have a better +way to keep vandals from abusing them than blocking IP addresses associated +with vandalism. Our approach so far has been to educate them about better +solutions that currently exist, but we should also {\bf create better +solutions for limiting vandalism by anonymous users} like credential and +blind-signature based implementations, and encourage their use. Other +promising starting points including writing a patch and explanation for +Wikipedia, and helping Freenode to document, maintain, and expand its +current Tor-friendly position.\plan{Do a writeup here in 2007; 1-2 weeks.} + +Those who do block Tor users also block overbroadly, sometimes blacklisting +operators of Tor servers that do not permit exit to their services. We could +obviate innocent reasons for doing so by designing a {\bf narrowly-targeted Tor + RBL service} so that those who wanted to overblock Tor could no longer +plead incompetence.\plan{Possibly in 2007 if we decide it's a good idea; 3 + weeks.} + +\subsection{All-in-one bundle} +We need a well-tested, well-documented bundle of Tor and supporting +applications configured to use it correctly. We have an initial +implementation well under way, but it will need additional work in +identifying requisite Firefox extensions, identifying security threats, +improving user experience, and so on. This will need significantly more work +before it's ready for a general public release. + +\subsection{LiveCD Tor} +We need a nice bootable livecd containing a minimal OS and a few applications +configured to use it correctly. The Anonym.OS project demonstrated that this +is quite feasible, but their project is not currently maintained. + +\subsection{A Tor client in a VM} +\tmp{a.k.a JanusVM} which is quite related to the firewall-level deployment +section below. JanusVM is a Linux kernel running in VMWare. It gets an IP +address from the network, and serves as a DHCP server for its host Windows +machine. It intercepts all outgoing traffic and redirects it into Privoxy, +Tor, etc. This Linux-in-Windows approach may help us with scalability in +the short term, and it may also be a good long-term solution rather than +accepting all security risks in Windows. + +%\subsection{Interface improvements} +%\tmp{Allow controllers to manipulate server status.} +% (Why is this in the User Experience section?) -RD +% I think it's better left to a generic ``make controller iface better'' item. + +\subsection{Firewall-level deployment} +Another useful deployment mode for some users is using {\bf Tor in a firewall + configuration}, and directing all their traffic through Tor. This can be a +little tricky to set up currently, but it's an effective way to make sure no +traffic leaves the host un-anonymized. To achieve this, we need to {\bf + improve and port our new TransPort} feature which allows Tor to be used +without SOCKS support; to {\bf add an anonymizing DNS proxy} feature to Tor; +and to {\bf construct a recommended set of firewall configurations} to redirect +traffic to Tor. + +This is an area where {\bf deployment via a livecd}, or an installation +targeted at specialized home routing hardware, could be useful. + +\subsection{Assess software and configurations for anonymity risks} +Right now, users and packagers are more or less on their own when selecting +Firefox extensions. We should {\bf assemble a recommended list of browser + extensions} through experiment, and include this in the application bundles +we distribute. + +We should also describe {\bf best practices for using Tor with each class of + application}. For example, Ethan Zuckerman has written a detailed +tutorial on how to use Tor, Firefox, GMail, and Wordpress to blog with +improved safety. There are many other cases on the Internet where anonymity +would be helpful, and there are a lot of ways to screw up using Tor. + +The Foxtor and Torbutton extensions serve similar purposes; we should pick a +favorite, and merge in the useful features of the other. + +%\tmp{clean up our own bundled software: +%E.g. Merge the good features of Foxtor into Torbutton} +% +% What else did you have in mind? -NM + +\subsection{Localization} +Right now, most of our user-facing code is internationalized. We need to +internationalize the last few hold-outs (like the Tor expert installer), and get +more translations for the parts that are already internationalized. + +Also, we should look into a {\bf unified translator's solution}. Currently, +since different tools have been internationalized using the +framework-appropriate method, different tools require translators to localize +them via different interfaces. Inasmuch as possible, we should make +translators only need to use a single tool to translate the whole Tor suite. + +\section{Support} + +It would be nice to set up some {\bf user support infrastructure} and +{\bf contributor support infrastructure}, especially focusing on server +operators and on coordinating volunteers. + +This includes intuitive and easy ticket systems for bug reports and +feature suggestions (not just mailing lists with a half dozen people +and no clear roles for who answers what), but it also includes a more +personalized and efficient framework for interaction so we keep the +attention and interest of the contributors, and so we make them feel +helpful and wanted. + +\section{Documentation} + +\subsection{Unified documentation scheme} + +We need to {\bf inventory our documentation.} Our documentation so far has +been mostly produced on an {\it ad hoc} basis, in response to particular +needs and requests. We should figure out what documentation we have, which of +it (if any) should get priority, and whether we can't put it all into a +single format. + +We could {\bf unify the docs} into a single book-like thing. This will also +help us identify what sections of the ``book'' are missing. + +\subsection{Missing technical documentation} + +We should {\bf revise our design paper} to reflect the new decisions and +research we've made since it was published in 2004. This will help other +researchers evaluate and suggest improvements to Tor's current design. + +Other projects sometimes implement the client side of our protocol. We +encourage this, but we should write {\bf a document about how to avoid +excessive resource use}, so we don't need to worry that they will do so +without regard to the effect of their choices on server resources. + +\subsection{Missing user documentation} + +Our documentation falls into two broad categories: some is `discoursive' and +explains in detail why users should take certain actions, and other +documentation is `comprehensive' and describes all of Tor's features. Right +now, we have no document that is both deep, readable, and thorough. We +should correct this by identifying missing spots in our design. + +\bibliographystyle{plain} \bibliography{tor-design} + +\end{document} + |