tor-webwml.git

1) ## translation metadata
2) # Based-On-Revision: 10723
3) # Last-Translator: solutions@janwoning.com
4) 
5) #include "head.wmi" TITLE="Volunteer"
6) 
7) <div class="main-column">
8) 
9) <!-- PUT CONTENT AFTER THIS TAG -->
10) <h2>Drie dingen die iedereen nu kan doen:</h2>
11) <ol>
12) <li>Overweeg a.u.b. <a href="<page docs/tor-doc-server>">een Tor server te
13) draaien</a> om het Tor netwerk te helpen groeien.</li>
14) <li>Zegt het voort!  Haal uw vrienden over om Tor servers te draaien, verborgen

15) diensten aan te bieden en het op hun beurt door te vertellen aan hun
16) vrienden.</li>

17) 
18) <li>Wij zijn thans actief op zoek naar fondsen en sponsors.  Indien u Tor's
19) doelstellingen steunt, neemt u dan a.u.b. even de tijd voor een
20) <a href="<page donate>">donatie t.b.v. de verdere ontwikkeling van Tor</a>.
21) Indien u bedrijven, NGOs of andere organisaties weet die
22) verlegen zijn om veilige communicatie, vertel hen dan over ons.</li>
23) </ol>
24) 
25) <a id="Usability"></a>
26) <h2><a class="anchor" href="#Usability">Hulpprogramma's</a></h2>
27) <ol>
28) <li>We hebben goede methoden nodig voor het onderscheppen van DNS verzoeken,
29) zodat deze geen informatie lekken naar een plaatselijke waarnemer, waar
30) wij anoniem proberen te zijn (kan gebeuren doordat DNS verzoeken worden afgehandeld
31) v��r verzending naar de SOCKS proxy).</li>
32) <li>Tsocks/dsocks items:
33) <ul>
34) <li>We moeten <a

35) href="https://wiki.torproject.org/noreply/TheOnionRouter/TSocksPatches">al onze tsocks

36) patches toepassen</a> en een nieuwe vork onderhouden. Wij zullen uw oplossing
37) desgewenst hosten.</li>
38) <li>We zouden Dug Song's "dsocks" programma moeten opwaarderen voor het gebruik van 
39) <i>mapaddress</i> opdrachten door Tor's controle koppeling, opdat we niet langer
40) een retourtje binnen Tor verspillen aan het verwerken van DNS verzoeken voor het
41) leggen van verbindingen.</li>
42) <li>We moeten ons <i>torificatie</i> script laten bepalen welke type tsocks of
43) dsocks is ge�nstalleerd en deze dienovereenkomstig aanroepen. Dit komt waarschijnlijk
44) neer op het samenvoegen van hun koppelingen, waarbij de code wordt gedeeld of
45) ��n van de twee geheel wordt afgedankt.</li>
46) </ul>
47) </li>
48) <li>
49) Serverbeheerders wensen de optie tot het instellen van een zekere bandbreedte gedurende
50) een bepaald dagdeel en een andere bandbreedte gedurende een ander dagdeel. I.p.v.
51) programmeren in Tor, is een script gewenst dat via de
52) <a href="<page gui/index>">Tor Controller Interface</a> praat en een "setconf" uitvoert
53) om de bandbreedte aan te passen. Het script zou mogelijk onder (Unix) cron kunnen draaien
54) danwel slapen om op de juiste tijd de kneep te doen (dit laatste is waarschijnlijk beter
55) overdraagbaar). Zou iemand zo'n script voor ons kunnen schrijven?

56) Wij zullen het dan in de <a href="<gittree>contrib/">contrib/</a> plaatsen. Dit

57) zou een goede inzending zijn voor de <a href="<page gui/index>">Tor GUI wedstrijd</a>.
58)   <!-- We have a good script to adjust stuff now, right? -NM -->
59) </li>
60) 
61) <li>Berichtenverkeer kan <a

62) href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">het Tor

63) netwerk verlaten via een gekozen uitgangsserver</a>.  Echter het moet mogelijk zijn
64) alleen het land te selecteren en het programma vervolgens automatisch een uitgangsserver
65) te laten kiezen. De beste optie is om Blossom's directory ook op te halen, met een 
66) lokale Blossom client die dit veilig (via Tor, met echtverklaring van de
67) handtekening) doet, <tt>.country.blossom</tt> onderschept en de juiste actie neemt.</li>
68) 
69) <li>Over geografische lokaties gesproken: Iemand zou een wereldkaart moeten
70) tekenen, met elke Tor serverlokatie gemarkeerd door een speld.  Bonuspunten indien
71) de kaart zichzelf aanpast aan een groeiend, veranderend Tor netwerk. Eenvoudigst
72) zou zijn om alle gegevens naar Google te sturen en hen de kaart laten tekenen. In
73) hoeverre zou dit de privacy be�nvloeden en zijn er alternatieven?</li>
74) </ol>
75) 
76) <a id="Documentation"></a>
77) <h2><a class="anchor" href="#Documentation">Documentatie</a></h2>
78) <ol>
79) <li>We horen dat Tor gebruikers slachtoffer kunnen worden van anonimiteit-brekende
80) aanvallen via Javascript, Java, ActiveX, Flash, enz. indien zij
81) deze programma's niet uitschakelen. Bestaan er uitbeidingen, zoals
82) NoScript voor Firefox, welke dit risico eenvoudig te beheren maken?  Wat is
83) het risico precies?</li>
84) 
85) <li>Bestaat er een suite van uitbreidingen voor Firefox 1.5+ met volledige
86) Privoxy functionaliteit? We hebben vernomen dat Tor veel sneller werkt zonder
87) Privoxy in de lus.</li>
88) 
89) <li>Helpt u Matt Edman a.u.b. met het documenteren van zijn

90) <a href="<page vidalia/index>">Vidalia</a>  Tor controller.</li>

91) 
92) <li>Evalueer en documenteer

93) <a href="https://wiki.torproject.org/wiki/TheOnionRouter/TorifyHOWTO">onze

94) lijst van programma's</a> welke kunnen worden geconfigureerd voor gebruik met Tor.</li>
95) 
96) <li>We hebben betere documentatie nodig voor het dynamisch onderscheppen
97) en omleggen van verbindingen via Tor.  Tsocks (Linux), dsocks (BSD), freecap
98) (Windows) en een beter gebruik van onze nieuwe TransPort lijken goede kandidaten.</li>
99) 
100) <li>We hebben <a

101) href="https://wiki.torproject.org/noreply/TheOnionRouter/SupportPrograms">een lange lijst

102) potenti�el bruikbare programma's</a> die met Tor kunnen samenwerken. Welke zijn nuttig en in
103) welke situaties? Help ons a.u.b. met testen en vastleggen van de uitkomsten.</li>
104) 
105) <li>Help met het vertalen van de Tor webpagina's en documenten. Zie de
106) <a href="<page translation>">richtlijnen</a> indien u wilt meehelpen.
107) Ook hebben we mensen nodig om de bestaande Franse en Zweedse vertalingen
108) bij te houden, zie het betreffende <a href="<page translation-status>">status
109) overzicht</a>.</li>
110) 
111) <li>Kan iemand ons uitleggen en helpen besluiten of we de 
112) <a href="http://www.cacert.org/">cacert</a> weg met ons SSL
113) <a href="<page documentation>#Developers">SVN repository</a> moeten opgaan?</li>
114) </ol>
115) 
116) <a id="Coding"></a>
117) <h2><a class="anchor" href="#Coding">Programmeren en Ontwerp</a></h2>
118) <ol>
119) <li>Tor servers werken niet goed onder Windows XP.  Onder Windows doet Tor
120) een standaard <tt>select()</tt> systeem aanroep, welke niet-wegschrijfbaar 
121) geheugen gebruikt. Dit houdt in dat een gemiddelde Tor server deze
122) geheugenruimte in z'n geheel overschrijft, <a

123) href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems">resulterend

124) in systeemuitval</a>.
125) Vermoedelijk moeten we "overlapped IO" gebruiken. E�n oplossing is, om een
126) <a href="http://www.monkey.org/~provos/libevent/">libevent</a> te leren hoe
127) overlapped IO i.p.v. select() onder Windows te gebruiken, en vervolgens Tor op
128) de nieuwe libevent koppeling af te stemmen.</li>
129) 
130) <li>Omdat Tor servers elke cel die zij behandelen moeten opslaan en uitsturen,
131) gebruiken breedbandige Tor servers tientallen megabytes aan uitsluitend
132) buffergeheugen. We hebben een betere geheugenhi�rarchie nodig om te bepalen
133) wanneer buffers in te krimpen danwel uit te breiden. Moet dit misschien
134) analoog aan het Linux kernelontwerp worden ingericht, waar sprake is van
135) vele kleine buffers welke naar elkaar verwijzen, i.p.v. monolithische buffers?
136) </li>
137) 
138) <li>
139) We zijn verlegen om een offici�le centrale lokatie welke de vraag "Is dit
140) IP adres een Tor uitgangsserver?" beantwoordt. Dit zou moeten
141) leiden tot diverse koppelingen, inclusief een webkoppeling en een
142) DNSBL-stijl koppeling. Deze opzet is in staat de meest precieze
143) antwoorden te leveren, door een lokale kopie ("mirror") van de Tor
144) directory informatie aan te houden. Teer punt is, dat de
145) uitgangsserver-functie niet booleaans is. Daarom luidt de eigenlijke vraag
146) "Is dit IP adres een Tor uitgangsserver welke uit kan sturen naar
147) mijn IP adres:poort?".  DE DNSBL koppeling ontvangt waarschijnlijk
148)  honderen informatieverzoeken per minuut. Derhalve zijn er slimme
149) algoritmen nodig.  Bonuspunten voor algoritmen welke actief elke
150) uitgangsserver testen om te bepalen vanuit welk IP adres het Tor network
151) daadwerkelijk wordt verlaten.

152) <a href="<gitblob>doc/contrib/torbl-design.txt">Lees hier verder</a>.</li>

153) 
154) <li>
155) Af en toe vallen Tor servers uit, verliezen computers waarop zij draaien
156) hun netwerkverbinding of gebeuren er andere ongelukken. Een aantal Tor
157) beheerders heeft interesse getoond in een berichtendienst
158) welke periodiek nagaat of hun Tor server gezond is en een herinnering
159) stuurt indien dit niet het geval is. Is iemand bereid om een paar cgi
160) scripts en webpagina's te schrijven en een wget hack danwel iets
161) ingewikkelders, bijvoorbeeld <a
162) href="http://nagios.org/">Nagios</a> voor deze controle op te zetten?
163) De eerste versie zou alleen de directory poort kunnen uitlezen, bijvoorbeeld
164) door de cached netwerk statuspagina op het juiste IP adres en poort te
165) doorzoeken en dan de "/tor/server/authority" pagina op te vragen.</li>
166) 
167) <li>Het zou mooi zou om een live CD te hebben met alle inclusief de
168) meest recente versies van Tor, Polipo, Privoxy, Firefox, Gaim+OTR, enz.
169) Er zijn twee uitdagingen: De eerste is het documenteren van het system
170) en de keuzemogelijkheden, op een wijze welke veiligheidsmensen in staat
171) stelt een mening te vormen hoe veilig het zou moeten zijn.
172) De tweede is nadenken over hoe de inhoud kan worden bijgehouden, opdat
173) deze niet snel in onbruik raakt (in tegenstelling tot AnonymOS). Bonuspunten
174) indien het image bestand op moderne CDs met kleine vormfactor past.</li>
175) 
176) <li>
177) In analogie met een live CD image, zouden we moeten werken aan een intu�tief

178) veilig en goed beschreven USB image bestand voor Tor en de
179) hulpprogramma's.</li>

180) 
181) <li>Het door ons verkozen grafische bedieningspaneel voor Tor,

182) <a href="<page vidalia/index>">Vidalia</a> genaamd, heeft behoefte aan

183) velerlei ontwikkelingswerk.</li>
184) 
185) <li> We moeten daadwerkelijk beginnen met het bouwen van het
186) <a href="<page
187) documentation>#DesignDoc">blokkade-weerstand ontwerp</a> (tegen
188) firewalls enz). Dit omvat het verder uitwerken van het ontwerp,
189) wijzigen van diverse onderdelen van Tor, modificeren van

190) <a href="<page vidalia/index>">Vidalia</a>

191) ter ondersteuning van de nieuwe Tor functionaliteit, en planning
192) voor de uitgifte.</li>
193) 
194) <li>We hebben een flexibel simulatie-raamwerk nodig voor de studie
195) van "end-to-end traffic confirmation" aanvallen. Vele onderzoekers
196) hebben ad hoc simulators opgeklopt ter onderbouwing van hun
197) oordeel dat dergelijke aanvallen hetzij goed werken of goed kunnen
198) worden afgeweerd. Kunnen we een duidelijk omschreven simulator
199) bouwen die dusdanig open is, dat iedereen weet dat er redelijke
200) antwoorden uitkomen? Dit zal de prikkel geven tot veel nieuw
201) onderzoek. Zie <a href="#Research">onderstaande bijdrage</a> over
202) "confirmation" aanvallen voor de onderzoeksaspecten van deze taak
203) &mdash; wie weet, kunt u bij het gereedkomen ook meehelpen met het
204) schrijven van een stuk of drie artikelen.</li>
205) 
206) <li>We hebben prestatiemetingen nodig van <a
207) href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a>
208) tegen <a href="http://www.privoxy.org/">Privoxy</a>. Is Polipo
209) in feite aanmerkelijk sneller dan Privoxy, wanneer de vertraging door
210) Tor buiten beschouwing wordt gelaten?  Zijn de resultaten gelijk onder
211) Linux en Windows? Behandelt Polipo meer websites correct dan Privoxy
212) of omgekeerd? Zijn er problemen met de stabiliteit onder Windows
213) of andere wijdverbreide platforms?</li>
214) 
215) <li>In relatie tot het bovenstaande, zou u willen helpen met het
216) omprogammeren van <a
217) href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> voor
218) stabiel en effici�nt gebruik onder Windows?</li>
219) 
220) <li>We hebben een gedistribueerd test-raamwerk nodig. We beschikken
221) over eenheidstests. Mooier zou zijn een script dat een Tor netwerk opstart, korte
222) tijd gebruikt en bevestigt dat tenminste een deel ervan werkt.</li>
223) 
224) <li>Help Mark Perry a.u.b. met zijn <a

225) href="https://www.torproject.org/svn/torflow/">TorFlow</a>
226) bibliotheek (<a href="https://www.torproject.org/svn/torflow/TODO">TODO</a>). Dit  

227) betreft een python programmabibliotheek welke het <a

228) href="https://www.torproject.org/svn/torctl/doc/howto.txt">Tor controller

229) protocol</a> gebruikt om Tor op diverse manieren verbindingstrajecten
230) te laten uitzetten, en vervolgens de prestaties te meten en anomalie�n 
231) op te sporen.</li>
232) <!--
233) <li>Thans worden de verborgen service descriptors op slechts enkele directory
234) servers opgeslagen. Dit is slecht voor de privacy en de robuustheid. Voor
235) meer robuustheid, dienen we verborgen-service descriptiors minder priv� te
236) maken, omdat ze naar vele plaatsen moeten worden gespiegeld. Idealiter willen
237) we het opslag/opzoeksysteem van de Tor directory servers volledig scheiden.
238) Eerste probleem is het ontwerpen van een nieuw verborgen-service descriptorformaat
239) voor a) ascii i.p.v. binair voor gebruiksgemak; b) het versleuteld houden van de
240) lijst van introductiepunten, tenzij het <tt>.onion</tt> adres bekend is, zodat
241) de directory deze niet kan achterhalen en c) de directories toe te staan het
242) datum-tijdstempel en de handtekening van de verborgen service descriptor
243) echt te verklaren, zodat de descriptors niet kunnen worden verleid tot
244) het aannemen van een valse indentiteit. Ten tweede is elk betrouwbaar
245) gedistribueerd opslagsysteem goed, mits het echtverklaring van wijzingen
246) ondersteund. Dit is voor tot dusverre ge�mplementeerde DHT code niet het geval.</li>
247) -->
248) <li>Tor 0.1.1.x en latere versies ondersteunen hardware welke versleuteling
249) via OpenSSL versnelt. Niemand heeft dit echter ooit getest. Is er misschien
250) iemand die een testkaart wil hebben en ons wil laat weten of het werkt? </li>
251) 
252) <li>
253) Voer een veiligheidsanalyse van Tor uit met <a
254) href="http://en.wikipedia.org/wiki/Fuzz_testing">"fuzz"</a>. Bepaal of er
255) goede "fuzzing" bibliotheken bestaan voor wat we willen. Maak naam door
256) puntenwinst, wanneer wij speciaal vanwege u een nieuwe versie uitgeven!</li>
257) 
258) <li>Tor gebruikt TCP voor transport en TLS voor versleuteling van verbindingen.
259) Dit is mooi en eenvoudig, maar betekent wel dat alle cellen op een verbinding
260) worden vertraagd bij verlies van ��n enkel datapakket, en dat we alleen TCP
261) datastromen redelijk kunnen ondersteunen. We hebben een <a

262) href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">lijst

263) met redenen waarom we niet zijn overgegaan op UDP transport</a>. Echter het zou
264) prima zijn indien de lijst kan worden ingekort. Ook hebben we een <a

265) href="<gitblob>doc/spec/proposals/100-tor-spec-udp.txt">specificatie voor

266) voor Tor met UDP voorgesteld</a> &mdash; laat ons a.u.b. weten wat er
267) verkeerd aan is.</li>
268) 
269) <li>We zijn dichtbij IPv6 ondersteuning voor bestemmingsadressen
270) (vanaf uitgangsservers). Indien u veel waarde hecht aan IPv6, dan is dit de
271) eerste plaats om te beginnen.</li>
272) 
273) <li>Geen van alle naar uw zin? Kijk naar de <a

274) href="<svnprojects>design-paper/roadmap-2007.pdf">plan voor verdere

275) ontwikkeling van Tor</a> voor meer idee�n.</li>
276) <li>Uw idee hier niet gevonden? Tien tegen ��n dat we het toch nodig hebben! Neem
277) contact met ons op.</li>
278) </ol>
279) 
280) <a id="Research"></a>
281) <h2><a class="anchor" href="#Research">Onderzoek</a></h2>
282) <ol>
283) <li>De "website fingerprinting" aanval: Maak een lijst van een paar honderd
284) websites en een reeks "handtekeningen" voor elke site.  Observeer het
285) berichtenverkeer van een Tor client. Terwijl u hem data ziet ontvangen,
286) krijgt u snel inzicht in welke van deze sites hij aan het bezoeken is. Hoe
287) effecief is deze aanval op de geplaatste Tor codebasis? Begin vervolgens met
288) het verkennen van mogelijke verdedigingen: We zouden bijvoorbeeld Tor's cel
289) van 512 naar 1024 bytes kunnen vergroten, paddingtechnieken als <a
290) href="http://freehaven.net/anonbib/#timing-fc2004">defensive dropping</a>
291) kunnen toepassen of het berichtenverkeer kunnen vertragen.  Hoeveel effect
292) hebben deze maatregelen en wat is effect op de bruikbaarheid (gebruikmakend van een
293) toepasselijke metriek) van een succesvolle verdediging in elk
294) van deze gevallen?.</li>
295) 
296) <li>De "end-to-end traffic confirmation" aanval: Door bewaken van het
297) berichtenverkeer bij Alice en Bob kunnen we <a
298) href="http://freehaven.net/anonbib/#danezis:pet2004">handtekeningen vergelijken
299) en overtuigd raken dat we dezelfde datastroom zien</a>. Tot dusverre accepteert
300) Tor dit en neemt in alle gevallen aan dat het om een triviale aanval gaat.
301) Is dit eigenlijk wel waar? Hoeveel berichtenverkeer van welk soort distributie is
302) nodig om de vijand in zijn overwinning te doen geloven? Zijn er scenarios (bijv. weining
303) transmissie) welke de aanval vertragen? Werken sommige vormen van padding beter dan
304) dan andere?</li>
305) 
306) <li>The "routing zones" aanval: De meeste literatuur benadert het netwerktraject
307) tussen Alice en haar ingangsserver (en tussen Bob en zijn uitgangsserver) als
308) een enkelvoudige verbinding in een raster. In de praktijk kruist het traject
309) vele autonome systemen (ASes), en <a
310) href="http://freehaven.net/anonbib/#feamster:wpes2004">is het niet ongewoon dat
311) dezelfde ASes in zowel het ingangs- als het uitgangstraject voorkomen</a>.
312) Helaas, om nauwkeurig te voorspellen of een zeker (Alice, ingang, uitgang, Bob)-kwartet
313) gevaarlijk is, moeten we een complete Internet routing zone downloaden
314) en kostbare berekeningen uitvoeren. Zijn er praktische benaderingen, zoals het
315) vermijden van IP adressen in eenzelfde /8 netwerk?</li>
316) 
317) <li>
318) Andere onderzoeksvragen m.b.t. geografische diversiteit zetten de keuze van
319) een effici�nt traject af tegen de keuze van een willekeurig traject.  Zie Stephen
320) Rollyson's <a
321) href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">position
322) paper</a> hoe te trage keuzes af te danken zonder de anonimteit teveel 
323) geweld aan te doen. Deze veelbelovende redenering vraagt om nader onderzoek
324) en denkwerk.</li>
325) 
326) <li>Tor werkt niet erg goed op kabel of DSL servers met asymmetrische
327) bandbreedte. Gegeven dat Tor gescheiden TCP verbindigen voor elke transmissiestap
328) heeft: Indien alle bytes normaal binnenkomen terwijl er uitgaande bytes verloren
329) gaan, dan koppelt de TCP deze informatie niet terug. Moet Tor misschien detecteren
330) wanneer een aanmerkelijk deel van de uitgaande bytes verloren gaat en hierop de
331) snelheid van de inkomende informatiestroom afregelen? Ik kan me een regelschema
332) voorstellen waarbij we de transmissiesnelheid langzaam laten toenemen tot er
333) nog net geen uitgaande bytes verloren gaan en vervolgens via terugkoppeling de
334) snelheid van de inkomende datastroom hierop af te stemmen. We hebben iemand nodig
335) die goed is met netwerken om e.e.a. te kunnen simuleren en te helpen met het
336) ontwerpen van oplossingen, danwel de omvang van het prestatieverlies te begrijpen
337) en als argument voor heroverweging van UDP transport in te brengen.</li>
338) 
339) 
340) <li>Een aanverwant onderwerp is controle van verkeersopstoppingen.  Is ons
341) huidige ontwerp voldoende voor zwaar gebruik? Misschien moeten we variabele
342) i.p.v. vaste vensters uitproberen. Dit leek goed te gaan in een <a
343) href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">ssh
344) data-doorzet experiment</a>. We zullen moeten meten en knijpen, en
345) mogelijk grondig inspecteren als de resultaten goed zijn.</li>
346) 
347) <li>
348) Om dissidenten uit verre landen Tor ongehinderd ('s lands firewall omzeilend)
349) te laten gebruiken, hebben we een manier nodig om tienduizenden i.p.v.
350) honderden relais te verkrijgen. We kunnen ons een bedieningspaneel
351) voorstellen met een "Tor voor Vrijheid" knop die een poort opent en enkele
352) kB/s het netwerk in stuurt (dit zal nauwelijks ophef of kwesties t.a.v.
353) misbruik veroorzaken daar er geen uitgangsservers in het spel zijn).
354) Echter hoe kunnen we automatisch een lijst van deze vrijwillige clients
355) onder de goede dissidenten verdelen, zonder interceptie door de firewall?
356) Het is waarschijnlijk nodig op het niveau van menselijk vertrouwen te
357) werken. Zie ons <a
358) href="<page documentation>#DesignDoc">vroege blokkade-afweer
359) ontwerpdocument</a> plus ons <a

360) href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#BlockingResistance">FAQ

361) hoofdstuk</a> hierover. Lees daarna het onderdeel <a
362) href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship">censuur
363) afweer van anonbib</a>.</li>
364) 
365) <li>Tor trajecten worden stapsgewijs opgebouwd. Derhalve zijn we in theorie in
366) staat om enkele datastromen te doen uitgaan in de tweede stap, een paar andere
367) in de derde stap, enz. Dit lijkt mooi omdat de samenhange tussen uitgaande
368) datastromen welke een gegeven server kan zien wordt vergebroken. Maar als we
369) elke stroom willen beveiligen, dan omvat het kortste traject volgens onze
370) huidige logica minimaal 3 stappen (meer voor de rest).  Deze uitruil tussen
371) prestatie en beveiliging verdient nadere studie.</li>
372) 
373) <li>Het is niet moelijk Tor of dirservers met DoS aan te vallen. Zijn client
374) puzzels het juiste antwoord? Welke ander praktische benaderingen zijn er? Bonus
375) indien deze achterwaarts compatibel zijn met het huidige Tor protocol.</li>
376) </ol>
377) 
378) <a href="<page contact>">Laat ons weten</a> wanneer u vooruitgang heeft geboekt
379) op ��n van bovenstaande punten!
380) 
381)   </div><!-- #main -->
382)