git.schokokeks.org
Repositories
Help
Report an Issue
tor-webwml.git
Code
Commits
Branches
Tags
Suche
Strukturansicht:
094d67c9e
Branches
Tags
bridges
docs-debian
jobs
master
press-clips
tor-webwml.git
templates
projects
4-optional.lowbandwidth.pot
copy of the .pot files
Runa A. Sandvik
commited
094d67c9e
at 2009-08-15 15:34:12
4-optional.lowbandwidth.pot
Blame
History
Raw
# SOME DESCRIPTIVE TITLE # Copyright (C) YEAR The Tor Project, Inc. # This file is distributed under the same license as the PACKAGE package. # FIRST AUTHOR <EMAIL@ADDRESS>, YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "POT-Creation-Date: 2009-08-15 13:29+0300\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" "Language-Team: LANGUAGE <LL@li.org>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. type: Content of: <div><h2> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:11 msgid "NLnet Project: Tor for Low Bandwidth Clients" msgstr "" #. type: Content of: <div> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:12 msgid "<hr />" msgstr "" #. type: Content of: <div><p> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:15 msgid "" "The Tor anonymity system is currently only usable by internet users who have " "high-bandwidth connections. Upon the start of the Tor client, a large file " "with all Tor server descriptions is being downloaded. This file is the so-" "called Tor Directory and enables the client to choose from the available mix-" "servers in the Tor network. The download of the full Tor Directory is " "required by the current Tor protocol. This directory file is too large for " "users on modem lines or on mobile data networks like GPRS as the initial " "download that is triggered every time an user logs in takes 10 to 30 minutes " "over a slow line. As a result, Tor is not usable by modem and mobile users. " "One of the major goals of the Tor project is to provide secure anonymous " "internet access to users in dictatorships and repressive states. These " "locations often have very slow internet connections, either by modem or due " "to low-bandwidth links to the outside world. By enabling these users to use " "the Tor network, significant progress can be made towards free communication " "and information in these countries." msgstr "" #. type: Content of: <div><p> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:31 msgid "" "To make Tor usable also for users on low-bandwidth connections, an evolution " "of the Tor protocol is needed to reduce the initial download size. This new " "Tor protocol version should change the way a client receives the information " "for its Tor circuit setup in a way, that the initial download can be " "performed over a 14.4 kbps modem line in about three minutes. The work to be " "conducted under the proposal has the ultimate goal of getting the protocol " "change production ready and propagated to the Tor users within a timeframe " "of less then 12 months. The resulting software will be published under the 3-" "Clause BSD license, as all of the Tor code. All deliverables will be fully " "public." msgstr "" #. type: Content of: <div><p> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:42 msgid "This project is generously funded by:" msgstr "" #. type: Content of: <div><p> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:46 msgid "" "<a href=\"http://www.nlnet.nl/news/2008/20080514-awards.html\"> <img src=" "\"$(IMGROOT)/nlnet-160x60.png\" alt=\"The NLnet foundation\" /></a>" msgstr "" #. type: Content of: <div><table><thead><tr><th> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:53 msgid "<big>Project</big>" msgstr "" #. type: Content of: <div><table><thead><tr><th> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:54 msgid "<big>Due Date</big>" msgstr "" #. type: Content of: <div><table><tr><td> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:60 msgid "" "<b>Deliverable A:</b> Design and evaluation of the protocol change<br /> " "<small><em>This deliverable covers the detailed design and simulation-based " "evaluation of the necessary changes and design modifications to the current " "Tor protocol. The changes in protocol will be relatively substantial, so it " "requires a careful evaluation of possible repercussions for the security and " "anonymity of the Tor network. A two-month period is planned for this design " "and evaluation phase, which concludes with an extensive peer review. Part of " "Deliverable A will be a goal definition for performance for the " "implementation phase. The design goal is to shrink the Tor Directory size " "that needs to be downloaded to about 300 Kilobytes, which would enable an " "user on a 14.4 kbps line to download it in roughly three minutes. There may " "be deviations from this design goal if required to maintain anonymity and " "security, but this is the figure to aim for. </em></small>" msgstr "" #. type: Content of: <div><table><tr><td> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:75 msgid "July 15, 2008" msgstr "" #. type: Content of: <div><table><tr><td> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:81 msgid "" "<b>Deliverable B:</b>Implementation of protocol change<br /> " "<small><em>After design, evaluation and peer review the modifications need " "to be implemented and integrated with the current Tor code base. The actual " "implementation of the necessary changes will take approximately three " "months. </em></small>" msgstr "" #. type: Content of: <div><table><tr><td> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:88 msgid "October 15, 2008" msgstr "" #. type: Content of: <div><table><tr><td> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:94 msgid "" "<b>Deliverable C:</b>Testing<br /> <small><em>Since the modification is " "highly critical to the security and anonymity of the Tor network, it " "requires extensive testing and debugging in laboratory and real life " "conditions. A period of three months is projected for testing and debugging, " "where the responsible developer is committed to the testing effort with 1/3 " "of its time. Part of the testing phase will be a public beta period. </em></" "small>" msgstr "" #. type: Content of: <div><table><tr><td> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:103 msgid "January 15, 2009" msgstr "" #. type: Content of: <div><table><tr><td> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:109 msgid "" "<b>Deliverable D:</b>Rollout<br /> <small><em>The actual rollout to the Tor " "server network will be conducted in sync with the regular Tor release " "schedule. As this schedule is dependent on a number of external factors, " "like the completion of other software projects that should go into the same " "release, the actual release time and the time until this release has been " "accepted and installed by most Tor server operators can vary. From " "experience a period of three to four months can be expected. The rollout " "will be conducted as part of the regular Tor release process that is a " "persistent activity done by volunteers and by personal paid through other " "grants to the Tor project. </em></small>" msgstr "" #. type: Content of: <div><table><tr><td> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:122 msgid "April 15, 2009" msgstr "" #. type: Content of: <div> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:127 msgid "<br /> <a id=\"Reports\"></a>" msgstr "" #. type: Content of: <div><h2> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:130 msgid "<a class=\"anchor\" href=\"#Reports\">Monthly Status Reports</a>" msgstr "" #. type: Content of: <div><p> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:132 msgid "" "There will be in total eight monthly status reports beginning with the first " "deliverable on July 15, 2008 and ending with completion of implementation " "and testing work on January 15, 2009." msgstr "" #. type: Content of: <div><table><thead><tr><th> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:140 msgid "<big>Month,</big>" msgstr "" #. type: Content of: <div><table><thead><tr><th> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:141 msgid "<big>Status Report</big>" msgstr "" #. type: Content of: <div><table><tr><td> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:147 msgid "<a id=\"Jun08\"></a> <a class=\"anchor\" href=\"#Jun08\">Jun 08</a>" msgstr "" #. type: Content of: <div><table><tr><td> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:151 msgid "" "<small><em>We did some initial measuring of Tor clients bootstrapping. The " "results are not very surprising: a client fetches about 10KB of certs, one " "consensus for 140KB (now 90KB, see next paragraph), and about 1.5 megs of " "Server Descriptors (after half of which it starts building circuits).</em></" "small> <br /> <small><em><a href=\"https://svn.torproject.org/svn/tor/trunk/" "doc/spec/proposals/138-remove-down-routers-from-consensus.txt\">Proposal " "138</a> shrinks consensus documents by 30% to 40% and has already been " "implemented and merged into the spec. Implementation is part of the 0.2.1.x-" "alpha tree and the code will take effect once over two-thirds of the " "directory authorities (i.e. 5 out of 6) have upgraded.</em></small> <br /> " "<small><em><a href=\"https://svn.torproject.org/svn/tor/trunk/doc/spec/" "proposals/140-consensus-diffs.txt\">Proposal 140</a> does not directly " "relate to reducing initial download size, but instead tries to make " "subsequent downloads of new consensus documents use fewer bytes has also " "been written up and <a href=\"http://archives.seul.org/or/dev/Jun-2008/" "msg00013.html\">sent to or-dev</a>. There are some questions to be answered " "from other Tor developers first, but other than that I think it's fine and " "could be implemented.</em></small> <br /> <small><em>The Big Thing is making " "clients not download all 1.5 megs of server descriptors. <a href=\"https://" "svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt" "\">Proposal 141</a> has been <a href=\"http://archives.seul.org/or/dev/Jun-" "2008/msg00017.html\">sent to or-dev</a>. There are basically 3 things to it, " "as far as I can see at the moment: move load balancing info into the " "consensus (should not be hard), implement something so that Tor clients can " "fetch SDs on demand from routers along their circuit while they are building " "it (described in the draft), and deal with exit selection. We're still " "developing ideas for the last part; some possibilities are mentioned in the " "draft.</em></small>" msgstr "" #. type: Content of: <div><table><tr><td> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:189 msgid "<a id=\"Jul08\"></a> <a class=\"anchor\" href=\"#Jul08\">Jul 08</a>" msgstr "" #. type: Content of: <div><table><tr><td> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:193 msgid "" "<small><em>Work on <a href=\"https://svn.torproject.org/svn/tor/trunk/doc/" "spec/proposals/141-jit-sd-downloads.txt\">Proposal 141</a> is continuing: " "There are two basic ideas for how to move load balancing information into " "the consensus: One is the authorities generate the weights that clients " "should use and put that in the consensus, the other approach is to just put " "bandwidth information from the server descriptor there. The latter option " "is probably friendlier when one also considers <a href=\"https://svn." "torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt" "\">Proposal 140</a> since it avoids a having number of highly fluctuating " "numbers in the consensus.</em></small> <br /> <small><em>For handling exit " "policies <a href=\"http://archives.seul.org/or/dev/Jul-2008/msg00022.html" "\">a post on the or-dev mailinglist</a> suggests that a hash identifying a " "node's exit policy be added to the consensus document. The addition of " "another 160 high-entropy bits per node to the consensus might be a cause for " "concern but we think that since a lot of the exit policies are the same the " "consensus document will compress nicely. Measurements pending.</em></small>" msgstr "" #. type: Content of: <div><table><tr><td> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:218 msgid "<a id=\"Aug08\"></a> <a class=\"anchor\" href=\"#Aug08\">Aug 08</a>" msgstr "" #. type: Content of: <div><table><tr><td> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:222 msgid "" "<small><em>Directory authority voting documents, and their consensus forming " "algorithm have been changed to include bandwidth information and policy " "summaries as documented in Proposal 141. Once five of the six running " "authorities have upgraded to trunk at at least revision 16554 the consensus " "will start to include that information.</em></small>" msgstr "" #. type: Content of: <div><table><tr><td> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:233 msgid "<a id=\"Sep08\"></a> <a class=\"anchor\" href=\"#Sep08\">Sep 08</a>" msgstr "" #. type: Content of: <div><table><tr><td> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:237 msgid "<small><em>No updates for September.</em></small>" msgstr "" #. type: Content of: <div><table><tr><td> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:243 msgid "<a id=\"Oct08\"></a> <a class=\"anchor\" href=\"#Oct08\">Oct 08</a>" msgstr "" #. type: Content of: <div><table><tr><td><p> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:247 msgid "" "<small><em>We didn't hit our \"finish the implementation\" milestone for " "this month since the developer leading the project has too much on his " "plate. The good news there is that we've gotten quite a bit of the " "implementation work done, and it's been in for several months now (since the " "August milestone) so it's seen a lot of testing already. The remaining " "implementation steps are to teach relays how to receive requests for " "fetching a relay descriptor from inside a circuit (we probably want to use a " "new cell type specifically for this, so we cut out a round-trip), and then " "teach clients to do that when the relay they're using is running a recent " "enough version. These two steps are written in more detail in <a href=" "\"https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-" "downloads.txt\">Section 3.2 of proposal 141</a></em></small>" msgstr "" #. type: Content of: <div><table><tr><td><p> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:260 msgid "" "<small><em>Our new timing plan is to have both of these pieces in place by " "mid Nov, and if that starts looking less likely then we're going to do a " "more radical overhaul of our timing plan and maybe also the design.</em></" "small>" msgstr "" #. type: Content of: <div><table><tr><td><p> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:264 msgid "" "<small><em>There are several other components we'd like to get to after this " "piece of it -- one we've been thinking about a lot lately is downloading " "\"diffs\" of the latest consensus: <a href=\"https://svn.torproject.org/svn/" "tor/trunk/doc/spec/proposals/140-consensus-diffs.txt\">140-consensus-diffs." "txt</a>. First this could save bandwidth, which is always nice when " "multiplied by the total number of clients, but it also means that we can use " "this saved bandwidth to fetch the diffs more often than the current \"every " "3 to 4 hours\". If clients learn more up-to-date directory information, then " "they can build faster paths because they have better information for each " "relay's bandwidth (which ties into the first NLnet project above), but the " "key new idea is that it also means that we're better at taking advantage of " "transient relays: right now a relay needs to be up for 3 or 4 hours before " "it sees any users, and that rules out a lot of volunteers who want to run a " "relay but only want to be up a few hours at a time.</em></small>" msgstr "" #. type: Content of: <div><table><tr><td><p> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:278 msgid "" "<small><em>The next step is to get the implementation for proposal 141 " "finished so we can start putting it in front of users for testing. Soon, we " "hope!</em></small>" msgstr "" #. type: Content of: <div><table><tr><td> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:286 msgid "<a id=\"Nov08\"></a> <a class=\"anchor\" href=\"#Nov08\">Nov 08</a>" msgstr "" #. type: Content of: <div><table><tr><td><p> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:290 msgid "" "<small><em>It looks like the original plan we had for the last development " "piece was both a) way harder than we hoped, and b) hopefully overkill " "compared to what we need.</em></small>" msgstr "" #. type: Content of: <div><table><tr><td><p> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:294 msgid "" "<small><em> Roger restarted the design discussion on or-dev: <a href=" "\"http://archives.seul.org/or/dev/Nov-2008/threads.html\">http://archives." "seul.org/or/dev/Nov-2008/threads.html</a>.</em></small>" msgstr "" #. type: Content of: <div><table><tr><td><p> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:297 msgid "" "<small><em>I think we now have a better handle on the options and tradeoffs: " "<a href=\"http://archives.seul.org/or/dev/Nov-2008/msg00007.html\">http://" "archives.seul.org/or/dev/Nov-2008/msg00007.html</a>.</em></small>" msgstr "" #. type: Content of: <div><table><tr><td><p> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:300 msgid "" "<small><em>Nick has been buried in other development projects (hopefully " "starting to wrap up this month-ish), and I want to get his opinion on how to " "proceed; I am hoping we'll pick one of the more simple approaches.</em></" "small>" msgstr "" #. type: Content of: <div><table><tr><td><p> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:304 msgid "" "<small><em>Alas, the really simple approaches provide less scalability. But " "I think they will be good stopgaps until later -- and when 'later' arrives, " "who knows what else will have changed.</em></small>" msgstr "" #. type: Content of: <div><table><tr><td> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:312 msgid "<a id=\"Jan09\"></a> <a class=\"anchor\" href=\"#Jan09\">Jan 09</a>" msgstr "" #. type: Content of: <div><table><tr><td><p> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:316 msgid "" "<small><em> I wrote up the more detailed version of our new design idea, as " "<a href=\"https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/158-" "microdescriptors.txt\">Tor proposal #158</a>, and discussion has started at " "<a href=\"http://archives.seul.org/or/dev/Jan-2009/msg00010.html\">http://" "archives.seul.org/or/dev/Jan-2009/msg00010.html</a>.</em></small>" msgstr "" #. type: Content of: <div><table><tr><td><p> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:322 msgid "" "<small><em> I think this is finally the one! (Well, once I finish folding in " "all the comments.) </em></small>" msgstr "" #. type: Content of: <div><table><tr><td><p> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:327 msgid "" "<small><em> One of the big reasons why the project isn't on its original " "schedule is that a main conclusion from <a href=\"<page projects/hidserv>" "\">Karsten's NLnet project on hidden service performance</a> was that it's " "the circuit extension that's the main killer. Yet this project had proposed " "to add more round-trips and complexity into exactly that step. So we needed " "to build a better plan to achieve the original goal without screwing up " "performance even more. </em></small>" msgstr "" #. type: Content of: <div><table><tr><td><p> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:337 msgid "" "<small><em>We've been revising the design proposal over the past weeks, and " "I think we'll be ready soon to start implementing. Note that since we have a " "bunch of development items we're hoping to land in mid Feb already, it's " "likely that this implementation won't land until late Feb or March. This " "time for sure!</em></small>" msgstr "" #. type: Content of: <div> #: /home/runa/tor/website/projects/en/lowbandwidth.wml:346 msgid "<br />" msgstr ""
