[or-cvs] r11345: Finished translating this file. It's quite long in compariso (website/trunk/es)

[ruben at seul.org]

Author: ruben
Date: 2007-09-01 13:45:07 -0400 (Sat, 01 Sep 2007)
New Revision: 11345

Added:
   website/trunk/es/volunteer.wml
Log:
Finished translating this file.
It's quite long in comparison to the others I translated.



Added: website/trunk/es/volunteer.wml
===================================================================
--- website/trunk/es/volunteer.wml	                        (rev 0)
+++ website/trunk/es/volunteer.wml	2007-09-01 17:45:07 UTC (rev 11345)
@@ -0,0 +1,345 @@
+## translation metadata
+# Based-On-Revision: 10181
+# Last-Translator: ruben at ugr es
+
+#include "head.wmi" TITLE="Volunteer" CHARSET="UTF-8"
+
+<div class="main-column">
+
+<!-- PUT CONTENT AFTER THIS TAG -->
+<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>
+<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>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>.
+  <!-- We have a good script to adjust stuff now, right? -NM -->
+</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.
+También necesitamos gente que ayude a mantener las traducciónes francesa y sueca 
+existentes - vea <a href="<page translation-status>">el resumen de estado de 
+traducción</a>.</li>
+<li>¿Puede alguen hacernos un recorrido que explique si queremos usar
+<a href="http://www.cacert.org/">cacert</a> para nuestro 
+<a href="<page documentation>#Developers">repositorio SVN</a> SSL?</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>Right now the hidden service descriptors are being stored on just a
+few directory servers. This is bad for privacy and bad for robustness. To
+get more robustness, we're going to need to make hidden service
+descriptors even less private because we're going to have to mirror them
+onto many places. Ideally we'd like to separate the storage/lookup system
+from the Tor directory servers entirely. The first problem is that we need
+to design a new hidden service descriptor format to a) be ascii rather
+than binary for convenience; b) keep the list of introduction points
+encrypted unless you know the <tt>.onion</tt> address, so the directory
+can't learn them; and c) allow the directories to verify the timestamp
+and signature on a hidden service descriptor so they can't be tricked
+into giving out fake ones. Second, any reliable distributed storage
+system will do, as long as it allows authenticated updates, but as far
+as we know no implemented DHT code supports authenticated updates.</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><!-- #main -->
+
+#include <foot.wmi>
+


Property changes on: website/trunk/es/volunteer.wml
___________________________________________________________________
Name: svn:executable
   + *