Dust RSS: Una breve introducción
La idea de utilizar un sistema de distribución como DUST vino precedida por la controvertida persecución que hemos visto estos últimos tiempos entre los partidarios y los detractores de Wikileaks. En el caso de Wikileaks, el revuelo mediático producido fue tan grande, que consiguió aunar las fuerzas entre atacantes y defensores. Sin embargo, ¿qué podría hacer una persona única que publica su blog contra un ataque de estas características? Poco.
Con este planteamiento pensamos en hacer un sistema que, con los menores cambios posibles, cualquiera pudiera publicar sus noticias, sus posts, y garantizar la perdurabilidad de su canal de noticias y de sus usuarios.
Actualmente la mayoría, si no todos, de los blogs tienen publicado un feed RSS. Lo normal es que este feed RSS se encuentre en algún formato estándar basado en XML entendible por los clientes RSS que tienen los lectores. Todo esto funciona de maravilla, y no queremos tocarlo, queremos que se siga utilizando esta infraestructura de feeds, pero queremos cambiar el canal, para no depender de HTTP.
El Feed al P2P
Con este fin, pensamos en algo bastante evidente, utilizar canales P2P, lo que es bastante evidente. En un entorno “extremo”, es decir, en caso de emergencia, alguien podría publicar, cuando estuviera bajo un ataque, el fichero XML en la red P2P y punto. Sin embargo, su audiencia tendría que saber de ese cambio y, sobre todo, estar preparado técnicamente para este cambio.
Un cliente RSS que haga polling al P2P
Es por ello, que nuestro objetivo es tener con Dust RSS un cliente que haga polling al P2P, al igual que los clientes RSS tradicionales hacen polling por HTTP. Es decir, que los clientes se puedan suscribir al feed RSS vía P2P de igual forma que a día de hoy lo hacen al feed RSS vía http. Este cliente, lo que va a entregar, a cualquiera de las aplicaciones que lo quieran utilizar, es un feed XML del blog, que luego la aplicación de turno procesará tal y como procesa los feeds RSS que descarga vía http.
La distribución de los contenidos externos al XML
Hay que tener en cuenta que muchos componentes que se visualizan en la lectura de un feed XML son externos, es decir, que en el documento XML solo vienen referenciados por su ruta http, es necesario hacer una publicación de los mismos vía P2P, así, cuando se “dusterice” el Feed RSS hay que añadir un modificador a las etiquetas que vinculan contenido externo http para indicar que esos documentos están disponibles en la red P2P, y bastará con añadir su hash de publicación en la red.
La publicación del Feed RSS
Por supuesto, una vez creado el fichero XML, este deberá ser compartido por P2P junto con todos los archivos vinculados. Con este procedimiento, el fichero XML estará en la red P2P y en él estarán los hashes de descarga P2P de todo el contenido externo, que también estará en la red P2P. El cliente DustRSS deberá hacer polling por el nombre del feed, descargarlo, leer los vínculos p2p externos, y descargarse el contenido externo de la red P2P para poder darle al lector RSS un feed completo.
Evitar suplantación de publicaciones con PGP
Por supuesto, en este entorno de trabajo, hay como problema, que cualquiera pueda publicar un feed e intentar suplantar al publicador, así que decidimos que todos los feeds fueran firmados con PGP, es decir, el hash del fichero en la red P2P más el nombre del blog firmados con la clave privada PGP.
Por su parte, el cliente dust RSS se encargará de hacer polling y comprobar que el fichero está firmado correctamente, lo que implica que durante el proceso de subscripción al feed RSS de Dust deberá obtener la clave pública del publicador, para así descargar solo los archivos XML correctos.
Cuando tengamos más avanzado el proyecto os pasaremos los detalles técnicos en detalle, ya que, tanto el dusterizador como el cliente se publicarán junto con su código fuente.
Esperamos que todos podáis ver la charla durante la próxima RootedCON, que la daremos el viernes 4 a las 13:00 horas y que, antes. os podáis suscribir vía Dust RSS a algunos blogs, y darnos todas vuestras ideas.
Saludos Malignos!
10 comentarios:
s/pooling/polling/g
@anónimo, done.
Interesante el descentralizar como medida de emergencia ante ataques (me recuerda a las redes ad-hoc :D)
Si os he entendido bien, el feed se publica en la red p2p y el cliente lo busca por su nombre.
Eso implica usar un servidor p2p que contenga una BD con los feeds, ¿no? ¿O la idea es usar los servidores ya existentes de las redes p2p (que ahora que lo releo, me parece más lógico)?
@kabracity
No es indispensable el uso de servidores centrales (que estaríamos creando un punto de fallo), también se puede utilizar alternativas como una tabla de hashes distribuidos (DHT) para evitar la centralización de la información.
Ten en cuenta que si se delegase la distribución de dichos ficheros a servidores de la red p2p volveríamos a una situación muy parecida a la actual con los proveedores de hosting y la facilidad de cerrar servicios.
Saludos
El hecho de que se haga uso de PGP me plantea alguna incógnita dado que este sistema presenta su "fuerte" en casos extremos de persecución de contenidos.
Digamos que fulanito publica algún documento comprometedor, llamemoslo no se, "Cable" :-)
A través de la infraestructura PKI (que entiendo tendrá que tener algún sistema de certificados para validar quien es quien) no podría el ente afectado por dicha publicación perseguir al autor?
O se da por hecho que la autoría de lo publicado es en todo momento publica y conocida?
¡Que buena idea!
Realmente parece un proyecto muy muy interesante, estaré a la espera de más detalles.
@Alejandro
Sí, eso es lo que estaba viendo, que sin ningún mecanismo alternativo estaríamos cayendo en el mismo problema, todo lo que sea centralizado es susceptible de ser tirado.
Lo del DHT (al ver de qué va me ha venido a la cabeza la red Kad de emule) es bastante práctico, aunque quizás que no fuera el único ¿no? Que convivan los dos métodos, de forma que aunque te tiren servidores puedas intentarlo por DHT.
@Jon yo entiendo que el que publica es alguien "conocido", para que se pueda reconocer si algo proviene de él o no. Pero (tal y como lo entiendo) no tiene por qué ser alguien físico, puede ser un grupo, o cualquier alias con su pareja clave publica-privada.
@kabracity estoy de acuerdo contigo en que no tiene porqué ser alguien fisico, pero en mi opinion tampoco sería cuestión de que me haga pasar por Chema por ejemplo y empieze a meter basura no?
Quiero decir, aunque no sea un CA, alguién o algo tendrá que establecer el entorno de confianza no?
Ideas... Je, je, je... Si se me ocurre algo, os lo haré saber... xD
@kabracity
De momento se va a incorporar soporte para una red descentralizada, luego ya será cuestión de ver la acogida e implementar más redes si es buena.
@kabracity y @jon
Si confiásemos en un tercero que actúe como autoridad certificadora volveríamos a la misma situación, un punto central que intentar tumbar, por lo que la mejor solución pasará por crear el par de claves y dar a conocer la pública.
saludos
Publicar un comentario