Hablar sobre la plataforma Mac se ha convertido (desgraciadamente) en uno de esos temas en los que tienes que tener cuidado. Es como la política, religión o el fútbol. Gente autodeclarada experta se pone a hablar sobre el tema, y el FUD llega a niveles insospechados. Esto exactamente sucede actualmente con el tema del trojano Flashback en OS X, un caldo de cultivo especial para que amantes de la manzana y enemigos de cupertino se enfrenten en alegatos interminables. En estos casos es importante ser objetivos y hablar con los hechos.

Veamos, ¿que es Flashback? Flashback es un método de entrega que depende de una vulnerabilidad en la versión de Java para OS X. Dicho de otra forma, se ha aprovechado una vulnerabilidad de Java en OS X para descargar, instalar y ejecutar un programa sin que el usuario lo sepa. El usuario primero es dirigido a un sitio Web que contiene código JavaScript, que a su vez carga un applet de Java y aprovechándose de la vulnerabilidad expuesta, este descarga un binario sin intervención del usuario. Después, el binario es ejecutado (de nuevo sin intervención) y este descarga y ejecuta el código malicioso convirtiendo a la Mac en turno en miembro de la botnet.

La vulnerabilidad es bien conocida, de hecho son dos y pueden consultarlas aquí y aquí. Las dos tienen que ver con Java Web Start (una funcionalidad para ejecutar código Java desde un servidor remoto) y la ejecución segura de applets Java. Cuando estas dos vulnerabilidades fueron cerradas en Febrero, los autores de Flashback comenzaron a utilizar otra vulnerabilidad (CVE-2012-0507) ya arreglada por Oracle (autores de Java) en Febrero, pero aún sin distribuir el parche por Apple. Recordemos que Apple ya no es el responsable de Java en su sistema operativo, dejando esta tarea a Oracle.

¿Entonces de quien es la culpa? De Oracle. Ellos son los responsables de la seguridad en Java. Flashback no ataca una vulnerabilidad en OS X, sino varias vulnerabilidades en Java que permiten la descarga y ejecución de código malicioso fuera de las restricciones impuestas (el famoso sandbox).

Apple arregló el error muy rápido. ¡Bien por ellos!. De hecho no. Apple se tardó 1 mes aproximadamente en liberar el parche creado por Oracle, y solo lo hizo una vez que la vulnerabilidad había sido aprovechada y usuarios infectados. Las razones técnicas para hacerlo (si las hay) no las se, pero lo que si se es que eso más que hacer quedar mal a OS X, hace quedar mal a Java en OS X a costa de sus usuarios. Bien sabido por todos es la negligencia de Apple por plataformas que permitan el desarrollo de aplicaciones que puedan ser ejecutadas en múltiples plataformas. La manzana prefiere el lock-in (al igual que Microsoft). Aún así, el error está en código de Oracle, y no de Apple.

Esto no quiere decir que OS X “no le entran virus” por favor no caigan en la desinformación. OS X al igual que todos los sistemas operativos del mundo son vulnerables. Las mismas precauciones deben ser tomadas por usuarios de OS X, que usuarios de Windows o de GNU/Linux.

Megacable
El caso es que por varias razones, mi proveedor de Internet era Megacable y por un tiempo no tuve quejas. Estaba dispuesto a tolerar sus caídas frecuentes siempre y cuando estuvieran en el rango de una vez al mes, y por períodos cortos de tiempo. Cualquier cosa por arriba de 1 hora ya se convierte en un problema. Lo que me agradaba de Megacable es que siempre estaban por encima de la competencia con respecto a ancho de banda / precio. Por ejemplo, cuando contraté lo hice con el paquete de 2 Mbps, al tiempo lo subieron a 5 Mbps y después a 10 Mbps manteniendo un costo muy similar. Pero con el incremento vinieron otros problemas:

• Interrupciones en el servicio más frecuentes (varias veces al mes, a veces en la misma semana)
• Ancho de banda extremadamente variado dependiendo de la hora del día
• Dificultad para usar ciertos servicios (bloqueo de puertos, o fallos en su Web proxy)
• Servicio al cliente muy deficiente. En repetidas ocasiones me dicen que mandarán a un técnico a ver el problema, y el técnico nunca llega

Telmex
Soy creyente de darle a una compañía en donde más le duele: su billetera. Decidí quejarme con mi dinero y llevar mi negocio a otra parte. La pregunta era ¿a donde?. La única opción viable en mi cabeza en ese momento era Telmex con su servicio infinitum; con el plus de recibir una línea de teléfono y llamadas ilimitadas a cualquier parte de México y USA, contraté el servicio de 10 Mbps con llamadas y no se que tanta cosa más. Lo que sucedió después de ahí es largo y complicado, así que lo voy a explicar con una lista en orden cronológico:

1. Fuimos a contratar el servicio a las oficinas de Telmex. En ese momento me entregaron el modem ASDL, y me dijeron que los técnicos tardaban hasta 8 días hábiles para hacer la instalación en la casa (mi casa no contaba con instalación telefónica).
2. A los cinco días hábiles, nos llama un técnico a preguntar si el domicilio es correcto. El domicilio estaba completamente mal, se les dio el domicilio correcto y nos dijeron que más tarde hablarían para confirmar la dirección.
3. La llamada nunca llegó, por lo que fuimos al centro de atención donde se hizo la contratación. Nos indicaron que “hubo un error en el sistema” y capturaron mal la dirección. Por este error, se tenía que hacer una cancelación del contrato y hacer un contrato nuevo y esperar solamente tres días más, ya que me pondrían en prioridad uno.
4. En ese momento les dije que no me interesaba su servicio. Precisamente la falta de buen servicio fue una de las razones que me hizo cambiarme de proveedor de Internet, y Telmex, desde el inicio, me estaba demostrando su incapacidad de proporcionar un buen servicio. Así que quedé de llevarles el modem de regreso y hacer como si nada hubiera pasado.
5. Ese mismo día por la tarde (un Sábado) llegaron los técnicos de Telmex a hacer la instalación. Mágicamente no tuve que esperar tres días más, sino que ese mismo día podía quedar la instalación aunque la señal de Internet no llegaría sino hasta el Lunes. Decidí (malamente) darles una segunda oportunidad y deje que hicieran la instalación. Lo que yo quería era un servicio estable y que cumpla lo que me ofrecen y por lo que estoy pagando, no estarme peleando con ISPs. Por lo visto no puedes tener una sin la otra.
6. Llega el Lunes y si, llega la señal de Internet. Hasta ahora todo bien. Comienzo a utilizarlo y se siente extremadamente lento. No lento, lentísimo. Inmediatamente hice una prueba de ancho de banda, y para mi sorpresa solo alcanza los 320 Kbps un servicio que supuestamente es de 10 Mbps. Confirmé este dato en la propia configuración del modem, en la información del enlace claramente dice 320 Kbps de bajada máximo.
7. Inmediatamente fuimos a las oficinas a ver que estaba pasando, y nos informan que la colonia en donde vivo no ofrece el servicio de 10 Mbps y por esta razón tengo el servicio que tengo. Si, esto no me lo habían dicho antes. Ahora mi pregunta es: ¿Y la gente que no sabe como checar el ancho de banda? ¿Que no sabe que son 10 Mbps? Me prometieron que verían que hacer en este caso para darme los 10 Mbps, pero si es verdad que en esta colonia no se puede ofrecer el servicio de 10 Mbps es porque no existe la infraestructura para hacerlo. Jalar un cable de una colonia vecina (que fue lo que me dijeron que harían) no va a solucionar el problema, a menos que sea lo suficientemente cerca para no degradar la señal.
8. Me dijeron que llamarían en la semana para confirmar la solución a mi problema, pero nunca llamaron. Eso si, llamaron para hacer una encuesta de calidad en el servicio (irónicamente) y después me llamaron para ver que había pasado con mi situación, y me aconsejaron muy amablemente que le diera seguimiento, que hablara a las oficinas (!) en vez de ser ellos los que le den seguimiento.

Lo que me sorprende es cómo después de todo, me llaman para decirme que “me aconsejaban que le diera seguimiento, que hablara, que insistiera”. Eso no debe ser necesario, aqui yo soy el cliente, y ellos deben ofrecerme un servicio de calidad y si no, me voy con otra empresa que si lo haga. A mi no me interesa darle seguimiento a una situación que ni es mi culpa, ni tiene por qué haber pasado. Entiendo el error en la dirección, eso nos puede pasar a todos, pero no decirme que el servicio (mas caro) que estoy contratando no existe en mi domicilio, darme un servicio más barato automáticamente sin avisarme, y después aconsejarme que le de seguimiento es completamente ridículo. Es una situación que no estoy dispuesto a tolerar.

Iusacell
Así que viendo mis opciones fui a Axtel, pero solo ofrecen 2 Mbps como máximo. Mi última opción fue Iusacell. Después de hablar con el representante de ventas, que me juraba y perjuraba que su paquete de 3 Mbps me era suficiente ya que lo hacían por fibra óptica, y explicarle que yo necesito el de 10 Mbps sin importarme si es por fibra, cable, aire, palomas mensajeras o señales de humo, me indicó que por $700.00 (más barato que Telmex) me ofrecen un paquete de 10 Mbps con fibra óptica a la casa, solo que tenía que esperar 3 días más para que entraran las nuevas tarifas y velocidades. La espera en realidad no era necesaria pero lo hicimos así ya que, de otra manera, me hubieran ofrecido un paquete de 7 Mbps por un precio un poco mayor así que esperamos. Me indicaron que fuera el tercer día temprano para que la instalación quedara ese mismo día y, para mi sorpresa, el mismo día quedó la instalación. Hasta ahora son los únicos que cumplen lo que prometen.

Después de hacer la instalación, los técnicos se retiraron y me indicaron que mandarían a alguien con el modem. Por qué no traían ellos el modem no lo se, pero les doy el beneficio de la duda ya que, hasta ahora, han cumplido con todo al pie de la letra. Si traen el modem hoy como lo prometieron, el ancho de banda ofrecido es el disponible, y su sevicio a cliente es tan bueno como el servicio de venta, seré un usuario de Iusacell feliz y contento.

Update: Iusacell cumplió. Tengo fibra óptica instalada en mi casa, a 10 Mbps instalados el mismo día que dijeron que se haría la instalación. Así si hago negocio con ellos con gusto.

Recientemente The Pirate Bay, uno de los sitios con más cojones que existe en el planeta, anunció que relegaría el uso de archivos .torrent y se enfocaría principalmente en los llamados magnet links. Sus argumentos son muy válidos, e inmediatamente se dejaron venir olas de desinformación. Que si The Pirate Bay habían doblado las manitas y cedieron ante la presión de alguna organización. Que si SOPA. Que si PIPA. Que si es el fin del mundo como lo conocemos, o por lo menos del P2P facilitado por el protocolo Bittorrent.

Nada de eso puede estar más alejado de la verdad. Como todo, el uso de la Distributed Hash Table (DTH) y Magnet Links sobre los ya tradicionales archivos .torrent tiene sus ventajas y desventajas que es lo que precisamente vamos a explorar aquí.

Durante mis estudios de maestría, hice investigación en el tema de las redes inalámbricas de sensores (WSN por sus siglas en Inglés) y cómo múltiples dispositivos de bajo poder de procesamiento, podían colaborar para cubrir una área extensa. Esto tiene retos interesantes muy bien documentados en la literatura, pero una de las cosas que más llamó mi atención es la diseminación de datos entre los pares que forman la red. Estamos hablando de una red creada impromptu, sin infraestructura previa, que necesita compartir datos de manera continua. Tal vez definirla como una red P2P tenga sentido, pero quiero dejar al lado las connotaciones negativas que arrastra este término, similar a lo que sucede con “Pirata” o “Nazi”.

En aquella época pensaba en una WWW descentralizada. La arquitectura actual de Internet ha pasado la prueba de escalabilidad: millones de nodos conectados, compartiendo millones y millones de paquetes. Además, cualquiera puede entrarle al juego, conectarse y compartir. Sin embargo uno de los servicios clave de Internet, o por lo menos de los más populares, es completamente centralizado. Estoy hablando de la Web y protocolos relacionados. La “simplicidad” en la arquitectura de la Web es tanto su mayor bendición, como su talón de Aquiles ya que la hace altamente vulnerable a distintos ataques. Los ataques de negación de servicio (DoS, infames ahora gracias en parte al colectivo Anonymous) son un ejemplo claro, aunque en este caso la solución no está al nivel de la implementación de la Web, sino dos capas más abajo (o 3 si consideran HTTP como capa de aplicación o de presentación) en la capa de transporte.

Otro ataque menos complejo (y menos efectivo) es el que enmarca la referida como ley “SOPA”. Esto no es más que eliminar el registro DNS de un sitio determinado. Una vez que esta eliminación sea diseminada en la mayoría de los servidores DNS que forman la World Wide Web, prácticamente nadie podría acceder al sitio atacado via URL. El sitio seguiría existiendo y sería accesible via IP, solo el nombre que hace referencia al sitio dejaría de funcionar. Una Web descentralizada resolvería estos problemas; una Web que no dependiera de un solo servidor central para operar. Donde fuera posible hacer privadas secciones de la Web, o conectarlas a la nube para formar parte de la Web pública. Donde todo, desde la resolución de nombres hasta las peticiones HTTP se basen en un protocolo P2P y no en un servidor central. Una Web imposible de censurar, controlada por todos y por nadie. Una Web apoyada en redes centradas al contenido como fue propuesto por Ted Nelson e investigado por Van Jacobson.

Lo que tenemos actualmente
Internet no fue concebido para una Web de tal naturaleza. En sus orígenes, Internet fue concebido para habilitar la transferencia de datos no solo entre computadoras incompatibles, sino también entre distintas redes de computadoras. Esta red de redes proporciona un medio adecuado para la comunicación de datos entre dos computadoras que se encuentran, posiblemente, distribuídas alrededor del mundo. Sin embargo, con el uso masivo que se le da a Internet actualmente, el problema básico que se trató de solucionar con la arquitectura de Internet ha cambiado. El nuevo modelo de uso de Internet impone otro tipo de retos a la arquitectura unicast y multicast sobre la que está basado, caracterizándose por:

• Contar con un gran número de clientes autónomos comunicándose entre sí (hasta el punto de agotar las direcciones IPv4).
• Variar el número de clientes en cualquier momento (Móviles, Tablets, Consolas y Refrigeradores, todos conectándose a la red).
• Contar con una distribución geográfica amplia.
• Contar con patrones de interacción entre los clientes dinámicos e impredecibles (como Twitter cuando hay un desastre natural o un evento inesperado).
• Generar tráfico en grandes cantidades.

Ejemplos de aplicaciones que utilizan a Internet con este nuevo modelo incluyen aplicaciones Web populares, redes de intercambio de información, agregadores de noticias, redes inalámbricas de sensores, descubrimiento de servicios y juegos masivos multijugador, entre otras. ¿Qué tienen en común estas aplicaciones? que el flujo de comunicación se determina por los intereses específicos de quien recibe información, contrario a lo que sucede actualmente en Internet, donde se utiliza una dirección específica asignada por quien envía los datos.

Van Jacobson propone una red en donde cualquier dispositivo que pueda mover datos, y tenga datos válidos, tenga la oportunidad de atender la petición. En dicha red se eliminan dos cosas:

1. La rigidez de la pila TCP/IP. Si un punto final de la comunicación entre A y B es eliminado, todos los puntos intermedios se reconfiguran automáticamente para seguir moviendo datos.
2. El flujo de datos se determina por intereses y no por direcciones IP. Esto ayuda a eliminar la congestión por peticiones muy populares. Una petición muy popular puede ser el disco mas reciente de la banda en el último grito de la moda, o dos millones de script kiddies atacando a la víctima de la semana de Anonymous.

Actualmente existen aplicaciones que implementan algunas de las ideas expuestas en la teoría de redes centradas al contenido. Estas aplicaciones crean una capa sobre la red existente (denominada overlay) y proporcionan servicios orientados al contenido, utilizando como transporte a la pila TCP/IP. Uno de estos overlays es precisamente Bittorrent.

Bittorrent como overlay centrado al contenido
Bittorrent es un protocolo de aplicación, es decir forma parte de la capa 6 en el modelo OSI. Bittorrent sirve para la distribución de archivos de gran tamaño sin la necesidad de un repositorio central. ¿Suena conocido? Los clientes inician una transferencia conectándose a un servidor central, que les comparte información de otros clientes que se encuentran compartiendo el mismo archivo. Una vez obtenida esta información, los clientes se conectan entre si para iniciar la transferencia.

Analicemos un poco más de cerca cómo se inicia una transferencia:

1. El cliente descarga un archivo (el .torrent) que contiene metadatos sobre los archivos a transferir, y la localización de uno o más servidores a los cuales el cliente se debe conectar para obtener información sobre otros clientes descargando el mismo archivo.
2. El cliente lee el .torrent y se conecta a los servidores ahí listados (el tracker).
3. Al conectarse a un tracker, este envía información sobre otros clientes interesados en el mismo archivo.
4. El cliente recibe la información enviada por el tracker, y se conecta a los otros clientes interesados en el mismo archivo.
5. Los clientes comienzan a compartir el archivo sin intervención del tracker.

El overlay creado por los nodos participantes en una transferencia Bittorrent forman una arquitectura híbrida descentralizada, en donde el tracker facilita la comunicación entre los distintos clientes. Una vez que varios clientes se conectan entre si, se elimina la necesidad del tracker siempre y cuando los clientes mantengan su conexión. Si eliminas el tracker, ningún otro cliente puede unirse a la red formada por los clientes conectados (llamada swarm o enjambre).

Ya podemos determinar dos puntos críticos de Bittorrent:

1. La dependencia del tracker. Sin este servidor central, otros clientes no pueden unirse al enjambre y no pueden iniciarse otras transferencias.
2. La dependencia del .torrent para obtener información del tracker. Este es un punto crítico ya que los archivos deben ser encontrados y descargados por los clientes para iniciar así una transferencia. Ya se ha probado (por medio de demandas a The Pirate Bay y otros) que el simple hecho de indexar y facilitar archivos .torrent es peligroso (legalmente hablando) aún cuando en tu servidor no se encuentre ningún archivo con copyright. Tener metadatos (pero no los datos mismos) de localizaciones de servidores con clientes que se encuentran descargando archivos con copyright, es suficiente para hacerte acreedor a una demanda. No se diga ya hostear un tracker…

Mejorando Bittorrent. Magnet Links y Distributed Hash Table.
Eliminando los dos puntos críticos expuestos anteriormente, Bittorrent se convierte en un overlay completamente descentralizado. ¿Pero cómo pueden encontrarse los clientes entre ellos, sin la existencia de un servidor central que los coordine? Tanto los Magnet Links como la Distributed Hash Table (DHT) juegan un papel determinante en la descentralización de Bittorrent.

El concepto de una DHT no es nuevo, su investigación y desarrollo fue motivado en parte por las redes P2P como GNUtella y Napster. Dos aproximaciones muy distintas al mismo problema:

• Los clientes de Napster, al conectarse enviaban al servidor una lista con los archivos compartidos. Las búsquedas se realizaban en el servidor único y dirigían al autor de la búsqueda hacia el nodo que contenía el recurso compartido.
• Los clientes de GNUtella, en vez de enviar la búsqueda a un único servidor central, utilizaban un mecanismo de flooding o “inundación” que enviaba la búsqueda a todos los nodos de la red. Esto evita el servidor central, pero es mucho menos eficiente.

Bittorrent adoptó una DHT para sustituir o complementar el tracker. De hecho, algunos clientes Bittorrent permiten al usuario evitar el uso del tracker, y solo recibir clientes que vengan directamente de la DHT. La implementación de la DHT de Bittorrent es basada en Kademlia. Los nodos que forman el overlay se comunican utilizando UDP y son asignados un ID, y es este mismo ID el que es utilizado por la red para localizar el valor buscado (usualmente un hash de un archivo). Las búsquedas son restringidas a O(log(n)) nodos, por aquello de la eficiencia.

Todo bien, pero aún es necesario que un cliente se conecte al enjambre formado por la DHT. A esto se le conoce como proceso de inicialización o bootstrap. En esta fase, el cliente necesita conocer la dirección IP de alguno de los nodos participantes, quien se encargará de diseminar el ID del nuevo nodo al resto de la red.

Aún eliminando la necesidad del tracker con la DHT, queda el inconveniente del proceso de inicialización, para lo cual el .torrent sigue siendo necesario. Para solucionar este inconveniente se desarrollaron los Magnet Links. Un Magnet Link en realidad es un esquema URI nuevo. ¿Un que? Un esquema URI se refiere a la estructura para nombrar recursos de manera uniforme. Seguramente se habrán topado con direcciones como file:, news:, http:, ftp:, mailto:, entre otros. Bueno pues esto forma parte de un esquema de nombramiento regulado por la IANA, y tiene una estructura fija.

Entonces, el esquema URI Magnet forma lo que llamamos Magnet Links, que son utilizados principalmente para referirnos a recursos disponibles para ser descargados de redes P2P. Un Magnet Link, contrario a un link regular, apunta a un archivo basado en su contenido o metadatos y no en donde se encuentra el archivo. Si encontramos similitudes con el contenido de un archivo .torrent, no es ninguna casualidad. Al igual que la investigación y el desarrollo de las DHT, el esquema Magnet fue desarrollado como parte de otros esquemas URIs utilizados en los proyectos eDonkey2000 (esquema ed2k:) y Freenet (esquema freenet:).

Un Magnet Link contiene uno o mas parámetros, que le indican al cliente de donde iniciar la descarga. Por ejemplo, un link puede contener el nombre del archivo, su tamaño en bytes, el hash del archivo, un link Web tradicional que se considere aceptable para descargar el archivo, palabras clave para realizar búsquedas del archivo, la dirección de un tracker Bittorrent, entre otras cosas. Ventajas del uso de magnet links sobre archivos .torrent es que pueden ser compartidos simplemente copiando y pegando el text en correos o mensajería instantánea, en comparación de los archivos .torrent en donde se tiene que enviar el archivo para iniciar la transferencia.

The Pirate Bay elimina el uso de .torrent
Lo que nos lleva finalmente a la decisión de The Pirate Bay de dejar de ofrecer archivos .torrent como fuente de información principal (los .torrent siguen estando disponibles, pero no son la opción por defecto) para conectarse a un enjambre, favoreciendo a los Magnet Links.

La decisión anterior les ahorra mucho ancho de banda ya que no se tienen que descargar archivos .torrent. Además los Magnet Links son mas difíciles de bloquear, y aún no se ha probado en la corte que tener Magnet Links en una página sea algo ilegal (aunque seguramente no tardarán en probarlo).

Pero mucho más importante que esto es el paso que se da hacia un overlay completamente descentralizado, en donde no sea necesario el tracker ni el uso de archivos .torrent por los usuarios (en realidad el protocolo Bittorrent depende de los archivos .torrent, pero usando Magnet Links los usuarios no tienen que descargar el archivo manualmente). Si, sigue existiendo la necesidad de un directorio en donde se puedan buscar Magnet Links, y el bootstrap es mas lento, pero el ahorro de ancho de banda, además de descentralizar la localización del .torrent justifica su uso.

Conclusión
Como vemos, es posible actualmente usar Bittorrent para compartir archivos de gran tamaño de manera descentralizada. Esto tiene la gran ventaja de ser menos propenso a ataques de censura (como SOPA y PIPA) y permite distribuir la carga de distribución entre los mismos clientes, en vez de en un solo servidor central.

En mi opinión, el futuro de la red es hacia una red completamente descentralizada, centrada al contenido. Ya sea implementada a nivel físico, o como un overlay sobre la existente. Las redes centradas al contenido se presentan como una evolución a la estructura tradicional de las redes actuales. No es que la solución actual (el protocolo TCP/IP) no sirva, sino que el problema original ha cambiado. La necesidad actual es una forma de diseminar datos y no de simplemente tener conversaciones entre dos puntos finales. La diferencia entre diseminación y conversación es que una diseminación puede ser uno a uno, uno a muchos o muchos a muchos. Claramante se observa que una conversación es solamente un caso especial (uno a uno) de una diseminación.

Una red centrada al contenido como la que propone Jacobson soluciona, por diseño, muchos de los problemas con los que se enfrenta Internet actualmente (siendo la censura uno de ellos). El hecho de que los datos mismos puedan ser validados y no se dependa de la seguridad del canal por el cual fueron transmitidos permite una diseminación oportunista, es decir, una red en donde cualquier dispositivo capaz de mover datos puede y será utilizado. La diseminación oportunista haría prácticamente imposible situaciones como la negación de servicio por parte de proveedores de Internet, o la eliminación de la neutralidad de Internet. Los usuarios se vuelven administradores de sus propios canales de comunicación, ya que pueden solicitar solo aquel contenido que le interesa, y la prioridad de éste (deseo obtener el correo electrónico de mi lugar de trabajo, y el noveno juego de la serie mundial de béisbol). La habilidad de definir solamente el contenido de interés elimina ataques del tipo negación del servicio ya que los altos volúmenes de tráfico no solicitado nunca llegarían a los canales de comunicación de la víctima si éste no lo solicita explícitamente.

A lo largo de la historia, hemos visto como la guerra impulsa a la ciencia. Por un Internet libre, abierto, neutro y sin censura.