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

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

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

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

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

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

90) 
91) <li>Evalueer en documenteer

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

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

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

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

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

123) in systeemuitval</a>.
124) Vermoedelijk moeten we "overlapped IO" gebruiken. E�n oplossing is, om een
125) <a href="http://www.monkey.org/~provos/libevent/">libevent</a> te leren hoe
126) overlapped IO i.p.v. select() onder Windows te gebruiken, en vervolgens Tor op
127) de nieuwe libevent koppeling af te stemmen.</li>
128) 
129) <li>Omdat Tor servers elke cel die zij behandelen moeten opslaan en uitsturen,
130) gebruiken breedbandige Tor servers tientallen megabytes aan uitsluitend
131) buffergeheugen. We hebben een betere geheugenhi�rarchie nodig om te bepalen
132) wanneer buffers in te krimpen danwel uit te breiden. Moet dit misschien
133) analoog aan het Linux kernelontwerp worden ingericht, waar sprake is van
134) vele kleine buffers welke naar elkaar verwijzen, i.p.v. monolithische buffers?
135) </li>
136) 
137) <li>
138) We zijn verlegen om een offici�le centrale lokatie welke de vraag "Is dit
139) IP adres een Tor uitgangsserver?" beantwoordt. Dit zou moeten
140) leiden tot diverse koppelingen, inclusief een webkoppeling en een
141) DNSBL-stijl koppeling. Deze opzet is in staat de meest precieze
142) antwoorden te leveren, door een lokale kopie ("mirror") van de Tor
143) directory informatie aan te houden. Teer punt is, dat de
144) uitgangsserver-functie niet booleaans is. Daarom luidt de eigenlijke vraag
145) "Is dit IP adres een Tor uitgangsserver welke uit kan sturen naar
146) mijn IP adres:poort?".  DE DNSBL koppeling ontvangt waarschijnlijk
147)  honderen informatieverzoeken per minuut. Derhalve zijn er slimme
148) algoritmen nodig.  Bonuspunten voor algoritmen welke actief elke
149) uitgangsserver testen om te bepalen vanuit welk IP adres het Tor network
150) daadwerkelijk wordt verlaten.
151) <a href="<svnsandbox>doc/contrib/torbl-design.txt">Lees hier verder</a>.</li>
152) 
153) <li>
154) Af en toe vallen Tor servers uit, verliezen computers waarop zij draaien
155) hun netwerkverbinding of gebeuren er andere ongelukken. Een aantal Tor
156) beheerders heeft interesse getoond in een berichtendienst
157) welke periodiek nagaat of hun Tor server gezond is en een herinnering
158) stuurt indien dit niet het geval is. Is iemand bereid om een paar cgi
159) scripts en webpagina's te schrijven en een wget hack danwel iets
160) ingewikkelders, bijvoorbeeld <a
161) href="http://nagios.org/">Nagios</a> voor deze controle op te zetten?
162) De eerste versie zou alleen de directory poort kunnen uitlezen, bijvoorbeeld
163) door de cached netwerk statuspagina op het juiste IP adres en poort te
164) doorzoeken en dan de "/tor/server/authority" pagina op te vragen.</li>
165) 
166) <li>Het zou mooi zou om een live CD te hebben met alle inclusief de
167) meest recente versies van Tor, Polipo, Privoxy, Firefox, Gaim+OTR, enz.
168) Er zijn twee uitdagingen: De eerste is het documenteren van het system
169) en de keuzemogelijkheden, op een wijze welke veiligheidsmensen in staat
170) stelt een mening te vormen hoe veilig het zou moeten zijn.
171) De tweede is nadenken over hoe de inhoud kan worden bijgehouden, opdat
172) deze niet snel in onbruik raakt (in tegenstelling tot AnonymOS). Bonuspunten
173) indien het image bestand op moderne CDs met kleine vormfactor past.</li>
174) 
175) <li>
176) In analogie met een live CD image, zouden we moeten werken aan een intu�tief
177) veilig en goed beschreven USB image bestand voor Tor en de hulpprogramma's.
178) 
179) <li>Het door ons verkozen grafische bedieningspaneel voor Tor,

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

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

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

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

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

225) betreft een python programmabibliotheek welke het <a

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

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

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

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

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

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