es/volunteer.wml (9b157749a) - tor-webwml.git

volunteer.wml

## translation metadata
# Based-On-Revision: 11649
# Last-Translator: ruben at ugr es

#include "head.wmi" TITLE="Volunteer" CHARSET="UTF-8"

<h2>Tres cosas que todo el mundo puede hacer ahora:</h2>
<ol>
<li>Por favor considere <a href="<page docs/tor-doc-server>">ejecutar
un servidor</a> para ayudar a crecer a la red Tor.</li>
<li>¡Dígaselo a sus amigos! Consiga que ejecuten servidores. Consiga que ejecuten 
servicios ocultos. Consiga que se lo digan a sus amigos.</li>
<li>Estamos buscando financiación y esponsors. Si le gustan los fines de Tor,
por favor <a href="<page donate>">tomese un momento para donar para apoyar 
el nuevo desarrollo de Tor</a>. Además, si conoce compañías, NGOs, agencias,
u otras organizaciones que quieran seguridad en las comunicaciones, hágales
saber de nosotros.</li>
</ol>

<a id="Usability"></a>
<h2><a class="anchor" href="#Usability">Soporte de Aplicaciones</a></h2>
<ol>
<li>Necesitamos buenas maneras de interceptar peticiones DNS para que 
no se filtre su petición a un observador local mientras intentamos ser
anónimos. (Esto pasa porque la aplicación hace la resolución DNS antes
de ir al proxy SOCKS.)</li>
<li>Asuntos de Tsocks/dsocks:
<ul>
<li>Necesitamos <a
href="http://wiki.noreply.org/noreply/TheOnionRouter/TSocksPatches">aplicar
todos nuestros parches de tsocks</a> y mantener un nuevo fork. Nosotros lo hospedaremos
si quiere.</li>
<li>Deberíamos parchear el programa "dsocks" de Dug Song para que use las 
órdenes <i>mapaddress</i> de Tor desde el interfaz de control, para que
no desperdiciemos un viaje de ida y vuelta dentro de Tor haciendo la
resolución antes de conectar.</li>
<li>Necesitamos hacer que nuestro script <i>torify</i> detecte cuál de tsocks o
dsocks está instalado, y llamarlos apropiadamente. Esto probablemente significa
unificar sus interfaces, y podria suponer compartir código entre ellos o 
descartar uno enteramente.</li>
</ul>
</li>
<li>La gente que ejecuta servidores nos dice que quieren tener un BandwidthRate
durante una parte del día, y un BandwidthRate diferente en otras partes 
del día. Mejor que codificar esto dentro de Tor, deberíamos tener un pequeño
script que hable via el <a href="<page gui/index>">Interfaz de Control de Tor</a>,
y que use setconf para cambiar el ancho de banda usado. Quizás se ejecutaria
desde cron, o quizás dormir hasta el momento adecuado y hacer los cambios
(eso es probablemente más portable). ¿Puede alguien escribir uno para nosotros
para que lo pongamos en <a href="<svnsandbox>contrib/">contrib/</a>?
Esta es una buena entrada para la <a href="<page gui/index>">Competición
de GUI de Tor</a>.
  
</li>
<li>Tor puede <a
href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">salir
de la red Tor desde un nodo de salida particular</a>, pero deberiamos poder
especificar simplemente un país y que se elija uno automáticamente. Lo
mejor es obtener el directorio de Blossom también, y ejecutar un cliente
Blossom local que obtenga este directorio de forma segura (via Tor y comprobando
la firma), que intercepte hostnames <tt>.country.blossom</tt>, y que haga
lo correcto.</li>
<li>A propósito de datos de geolocalización, alguien debería dibujar un
mapa de la tierra con una marca para cada servidor Tor. Bonus si se 
actualiza conforme la red crece y cambia. Desafortunadamente, las formas
fáciles de hacer esto es enviar todos los datos a Google y hacer que te
dibuje el mapa. ¿Cuánto impacto tiene esto en la privacidad, y tenemos 
alguna otra opción buena?</li>
</ol>

<a id="Documentation"></a>
<h2><a class="anchor" href="#Documentation">Documentación</a></h2>
<ol>
<li>Hemos oído que los usuarios de Tor pueden ser víctimas de ataques
que rompen el anonimato desde javascript, java, activex, flash, etc, 
si no los desactivan. ¿Existen plugins (como NoScript para Firefox) que
hagan más fácil a los usuarios controlar este riesgo? ¿Cuál es el riesgo
exactamente?</li>
<li>¿Hay un conjunto completo de plugins que reemplacen toda la funcionalidad
de Privoxy para Firefox 1.5+? Hemos oído que Tor es mucho más rápido cuando
sacas a Privoxy del conjunto.</li>
<li>Por favor ayude a Matt Edman con la documentación y howtos de su 
controlador Tor,
<a href="http://vidalia-project.net/">Vidalia</a>.</li>
<li>Evalúe y documente
<a href="http://wiki.noreply.org/wiki/TheOnionRouter/TorifyHOWTO">nuestra
lista de programas</a> que pueden ser configurados para usar Tor.</li>
<li>Necesitamos mejor documentación para interceptar dinámicamente conexiones
y enviarlas a través de Tor. tsocks (Linux), dsocks (BSD),
y freecap (Windows) parecen buenos candidatos, y también lo sería usar mejor
nuestra nueva característica de TransPort.</li>
<li>Tenemos una lista enorme de <a href="http://wiki.noreply.org/noreply/TheOnionRouter/SupportPrograms">programas potentialmente útiles que son interfaz con Tor</a>. 
¿Cuáles son útiles en cada situación? Por favor ayudenos a probarlos y 
documentar sus resultados.</li>
<li>Ayudenos a traducir la página web y la documentación a otros idiomas.
Vea las <a href="<page translation>">guías de traducción</a> si quiere ayudar.
Necesitamos especialmente traducciones al árabe o al farsi, para los muchos usuarios de Tor en áreas con censura.
</li>
</ol>

<a id="Coding"></a>
<h2><a class="anchor" href="#Coding">Codificación y Diseño</a></h2>
<ol>
<li>Los servidores Tor no funcionan bien en Windows XP. En
Windows, Tor usa la llamada al sistema estandar <tt>select()</tt>,
que usa espacio en la zona no paginada. Esto significa que un servidor
Tor de tamaño medio vaciará la zona no paginada, <a
href="http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems">causando
el caos y colgando el sistema</a>. Probablemente deberíamos estar usando E/S
solapada en su lugar. Una solución sería enseñarle a <a
href="http://www.monkey.org/~provos/libevent/">libevent</a> a usar
E/S solapada en lugar de select() en Windows, y luego adaptar Tor a
la nueva interfaz de libevent.</li>
<li>Como los servidores Tor tienen que almacenar-y-reenviar cada célula
que manejan, los servidores Tor de gran ancho de banda terminan usando 
docenas de megabytes de memoria sólo para buffers. Necesitamos mejores 
heurísticas para cuándo encojer/expandir los buffers. ¿Quizás esto debería
de modelarse siguiendo el diseño de buffers del kernel de Linux, en donde
tenemos muchos buffers pequeños enlazados entre sí, en lugar de buffers 
monolíticos?</li>
<li>Necesitamos un sitio central oficial que responda preguntas del tipo 
"¿Es esta dirección IP un servidor Tor de salida?". Debería dar varias
interfaces, incluyendo una interfaz web y una interfaz de estilo DNSBL.
Puede dar las respuestas más actualizadas guardando un mirror local de la
información del directorio Tor. Lo más lioso es que ser un servidor de salida
no es un valor lógico: así que la pregunta es en realidad "¿Es esta 
dirección IP un servidor Tor de salida que puede salir a mi dirección:puerto IP?"
El interfaz DNSBL recibirá probablemente cientos de peticiones por minuto,
así que se necesitan algoritmos inteligentes. Puntos de bonus si hace testing
activo a cada nodo de salida para averigura de qué direcciones IP está 
realmente saliendo.
<a href="<svnsandbox>doc/contrib/torbl-design.txt">Lea más aquí</a>.</li>
<li>Algunas veces los servidores Tor se cuelgan, o a los ordenadores en los
que están se les cae la red, u otros accidentes pasan. Algunos operadores Tor
han expresado un interes en inscribirse en un servidio "de notificación"
que compruebe periódicamente si sus servidores Tor están saludables y 
les envíe un correo de recuerdo si no lo están. ¿Alguien quiere escribir
unos cuantos scripts cgi, unas cuantas páginas web, y configurar algún tipo
de hack con wget y/o algo más complejo como <a 
href="http://nagios.org/">Nagios</a> para hacer la monitorización? 
La primera versión podría comprobar sólo el puerto de directorio, e.g.
mirar la página de stado de la red cacheada para la dirección IP y el
puerto correctos y luego pedir la página "/tor/server/authority".</li>
<li>Sería estupendo tener un LiveCD que incluya las últimas versiones
de Tor, Polipo o Privoxy, Firefox, Gaim+OTR, etc. Hay dos retos aquí:
primero documentar el sistema y las elecciones lo suficientemente bien
para que la gente de seguridad pueda formarse una opinión sobre si debería
ser seguro, y la segunda es averiguar cómo hacerlo fácilmente mantenible,
para que no se quede obsoleto rápidamente como AnonymOS. Puntos de Bonus
si la imagen de CD cabe en uno de esos CDs de tamaño pequeño.</li>
<li>Relacionado con la imagen de LiveCD, deberíamos trabajar en una 
imagen USB que sea intuitivamente segura y bien documentada para Tor
y las aplicaciones de soporte. Bastante de la parte difícil es decidir 
qué configuraciones son seguras, documentar esas decisiones, y hacer
algo que sea fácil de mantener en el futuro.</li>
<li>Nuestro interfaz gráfico preferido para Tor, llamado
<a href="http://vidalia-project.net/">Vidalia</a>, necesita todo tipo
de trabajo de desarrollo.</li>
<li>Necesitamos constuir realmente nuestro <a href="<page
documentation>#DesignDoc">diseño de resistencia al bloqueo</a>. Esto incluye
rellenar el diseño, modificar muchas partes distintas de Tor, adaptar
<a href="http://vidalia-project.net/">Vidalia</a> para que soporte las
nuevas características, y planificar la implantación.</li>
<li>Necesitamos un entorno de simulación flexible para estudiar los
ataques de confirmación de tráfico de punta a punta. Muchos investigadores
han creado rápidamente simuladores ad-hoc para dar soporte a sus intuiciones
o bien de que los ataques funcionan muy bien o de que alguna defensa funciona 
bien. ¿Podemos construir un simulador que esté documentado claramente y 
lo suficientemente abierto para que todo el mundo sepa que está dando
una respuesta razonable? Esto generará mucha investigación nueva.
Vea la entrada <a href="#Research">debajo</a> sobre ataques de confirmación
para detalles sobre el aspecto de investigación de esta tarea &mdash; 
quién sabe, cuando esté hecho quizás usted pueda escribir un artículo o
varios también.</li>
<li>Necesitamos un estudio que mida <a
href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a>
contra <a href="http://www.privoxy.org/">Privoxy</a>. ¿Es Polipo en
realidad significativamente más rápido, una vez que se tiene en cuenta
la ralentización debida a Tor? ¿Son los resultados los mismos tanto en Linux
como en Windows? Relacionado, ¿maneja Polipo más sitios web correctamente que
Privoxy, o vice versa? ¿Hay problemas de estabilidad en alguna plataforma 
común, e.g. Windows?</li>
<li>Relacionado con lo dicho arriba, ¿querría ayudar a portar <a
href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> para que
se ejecute de forma estable y eficiente en Windows?</li>
<li>Necesitamos un entorno de test distribuido. Tenemos test de unidad,
pero sería excelente tener un script que arranque una red Tor, la use
durante un rato, y verifique que al menos parted de ella funcionan.
</li>
<li>Ayude a Mike Perry en su biblioteca <a
href="http://tor.eff.org/svn/torflow/">TorFlow</a>
(<a href="http://tor.eff.org/svn/torflow/TODO">TODO</a>):
Es una biblioteca python que usa el <a
href="http://tor.eff.org/svn/torctl/doc/howto.txt">protocolo de control de 
Tor</a> para indicar a Tor que construya circuitos de formas variadas,
y luego mide el rendimiento e intenta detectar anomalías.</li>

<li>Tor 0.1.1.x y posteriores incluyen soporte para aceleradores criptográficos 
hardware via OpenSSL. Sin embargo, nunca nadie los ha probado. ¿Alguien quiere
conseguir una tarjeta y decirnos cómo va?</li>
<li>Perform a security analysis of Tor with <a
href="http://en.wikipedia.org/wiki/Fuzz_testing">"fuzz"</a>. Determine
if there are good fuzzing libraries out there for what we want. Win fame by
getting credit when we put out a new release because of you!</li>
<li>Tor usa TCP para el transporte y TLS para encriptación del enlace.
Esto es bonito y simple, pero significa que todas las celdas de un enlace se
retrasan cuando se pierde un solo paquete, y significa que sólo podemos
permitir flujos TCP. Tenemos una <a
href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">lista
de razones por las que no hemos cambiado a transporte UDP</a>, pero sería excelente
ver que esa lista se hace maś corta. También tenemos una propuesta de <a
href="<svnsandbox>doc/spec/proposals/100-tor-spec-udp.txt">especificación
para Tor y UDP</a> &mdash; por favor díganos qué problemas tiene.</li>
<li>No estamos tan lejos de tener soporte IPv6 para las direcciones
de destino (en los nodos de salida). Si le importa mucho IPv6, ése es
probablemente el primer sitio para empezar.</li>
<li>¿No le gusta ninguna de éstas? Mire el <a
href="<svnsandbox>doc/design-paper/roadmap-2007.pdf">plan de desarrollo Tor</a> 
para más ideas.</li>
<li>¿No ve su idea aquí? ¡Probablemente la necesitemos de todas formas! 
Contáctenos y averígüelo.</li>
</ol>

<a id="Research"></a>
<h2><a class="anchor" href="#Research">Investigación</a></h2>
<ol>
<li>El "ataque de fingerprint de sitios web": hacer una lista de unos
cuantos cientos de sitios web populares, descargar sus páginas, y hacer
una serie de "firmas" para cada sitio. Entonces observar el tráfico de
un cliente Tor. Conforme lo observa recibiendo datos, rápidamente se 
puede adivinar cuál de esos sitios está visitando (si los visita). 
Primero, cómo de efectivo es este ataque en el código Tor? Después 
empezar a explorar defensas: por ejemplo, podríamos cambiar el tamaño
de celda de Tor desde 512 bytes a 1024, podríamos usar técnicas de
relleno como <a
href="http://freehaven.net/anonbib/#timing-fc2004">descarte defensivo</a>,
o podríamos añadir retrasos al tráfico. ¿Cuánto impacto tienen éstos,
y cuánto impacto en la usabilidad (usando alguna métrica adecuada) 
tiene una defensa exitosa en cada caso?</li>
<li>El "ataque de confirmación de tráfico de punta a punta":
mirando el tráfico de Alicia y de Bob, podemos<a
href="http://freehaven.net/anonbib/#danezis:pet2004">comparar
las firmas de tráfico y convencernos de que estamos mirando el mismo 
flujo</a>. Por ahora Tor acepta esto como un hecho consumado y asume que
este ataque es trivial en todos los casos. Lo primero de todo, ¿es eso
realmente cierto? ¿Cuánto tráfico de qué tipo de distribución se necesita
para que el adversario tenga confianza en que ha ganado? ¿Hay escenarios
(e.g. no transmitir mucho) que enlentecen el ataque? ¿Algunos esquemas
de relleno de tráfico o control de tráfico funcionan mejor que otros?
</li>
<li>El "ataque de las zonas de enrutado": la mayoría de la literatura
piensa en el camino en la red entre Alice y su nodo de entrada (y entre
el nodo de salida y Bob) como un enlace simple en algun grafo. En la 
práctica, sin embargo, el camino atraviesa muchos sistemas autónomos 
(ASes), y <a
href="http://freehaven.net/anonbib/#feamster:wpes2004">es común
que el mismo AS aparezca tanto en el camino de entrada como en el de salida</a>.
Desafortunadamente, para predecir con precisión si un cuádruple Alice, entrada,
salida, Bob será peligrosos, necesitamos descargar una zona de enrutado de Internet
entera y hacer operaciones caras en ella. ¿Hay aproximaciones prácticas, como
evitar direcciones IP en la misma red /8?</li>
<li>Otras preguntas de investigación sobre la diversidad geográfica consideran
la compensación entre elegir un circuito eficiente y elegir un circuito aleatorio.
Mire el <a
href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">
artículo de posición</a> de Stephen Rollyson sobre cómo descartar elecciones
particularmente lentas sin dañar el anonimato "demasiado". Esta línea de
razonamiento necesita más trabajo y más ideas, pero parece muy prometedora.
</li>
<li>Tor no funciona muy bien cuando los servidores tienen ancho de banda
asimétrico (e.g. cable o DSL). Como Tor tiene conexiones TCP separadas 
para cada salto, si los bytes de entrada llegan bien y los bits de salida
se están descartando todos, los mecanismos de ralentización de TCP no 
transmiten realmente esta información de vuelta a los flujos de entrada.
¿Quizás Tor debería detectar cuándo está descartando muchos paquetes de 
salida, y limitar la velocidad de los flujos de entrada para regular esto
él mismo? Puedo imaginar un esquema de subida y bajada de la velocidad
en el que elegimos un límite conservativo, lo incrementamos despacio hasta
que se pierdan paquetes, lo bajamos y repetimos. Necesitamos alguien que
sea bueno con las redes para simular esto y ayudar a diseñar soluciones;
y/o necesitamos entender la extensión de la degradación del rendimiento,
y usar esto como motivación para reconsiderar el transporte UDP.</li>
<li>Un tema relacionado es el control de congestión. ¿Es nuestro
diseño actual suficiente una vez que tengamos un gran uso? Quizá
deberíamos experimentar con ventanas de tamaño variable en lugar
de ventanas de tamaño fijo? Eso pareció ir bien en un <a
href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">experimento
de rendimiento de ssh</a>. Necesitaremos medir y hacer cambios, y quizás
reestructurar si los resultados son buenos.</li>
<li>Para permitir a disidentes de paises remotos usar Tor sin ser
bloqueados en el cortafuegos del país, necesitamos una forma de conseguir
cientos de miles de relays, no sólo unos cuantos cientos. Podemos imaginar
un GUI del cliente Tor que tenga un botón de "Tor para la Libertad" arriba
que abra un puerto y reenvie unos cuantos KB/s de tráfico a la red Tor. 
(Unos cuantos KB/s no deberían ser mucha molestia, y hay pocos casos de abuso
ya que no son nodos de salida.) ¿Pero cómo distribuimos una lista de estos 
clientes voluntarios a los disidentes buenos de un modo automático que no deje
a los cortafuegos a nivel de país interceptarlos y enumerarlos? Probablemente
necesite funcionar en el nivel de confianza entre humanos. Vea nuestro
<a href="<page documentation>#DesignDoc">documento de diseño inicial de 
resistencia al bloqueo</a> y nuestra
<a
href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#BlockingResistance">entrada
de la FAQ</a> sobre esto, y luego lea la <a
href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship">sección
de restencia a la censura de anonbib</a>.</li>
<li>Los circuitos Tor se construyen un salto cada vez, así que en teoría tenemos
la habilidad de hacer que algunos flujos salgan del segundo salto, algunos del
tercero, y así sucesivamente. Esto parece bueno porque rompe el conjunto de
flujos de salida que un servidor dado puede ver. Pero si queremos que cada flujo
esté seguro, el camino "más corto" debería ser al menos de 3 saltos de acuerdo con
nuestra lógica actual, así que el resto serán aún más largos. Necesitamos examinar
este intercambio forzado entre rendimiento y seguridad.</li>
<li>No es tan difícil hacer DoS a servidores Tor o servidores de directorio.
¿Son los puzzles a los clientes la respuesta correcta? ¿Qué otros enfoques prácticos
hay? Bonus si son compatibles hacia atrás con el protocolo Tor actual.</li>
</ol>

¡<a href="<page contact>">Haganoslo saber</a> si ha hecho progreso en algo 
de esto!

</div>

#include <foot.wmi>

tor-webwml.git

Fixed missing / in tags