[Grey-Walter] (pr:topact) resumen 1
Pablo
pablo at lechuza.rec.usal.es
Fri Dec 5 18:17:56 CET 2003
Hola, llevaba un tiempo desconectado de la lista y ahora que la he
retomado he decidido hacer un resumen para aclararnos (yo por lo
menos) como está todo.
Descripción del Proyecto Topact
-------------------------------------
El proyecto topact surge como una iniciativa para desarrollar la
topología (análisis estructural y característico) de una red, en
concreto la red activista estatal y, simultáneamente, la generación
de material propio sobre las diferentes líneas de investigación que
se lleven a cabo para la finalización del proyecto.
Para llevar acabo estos objetivos se dividirá el proyecto en una
serie de módulos (actividades) que se pondrán en marcha para cada una
de las fases del proyecto.
Módulos
----------
..::Debates::..
Hasta el momento de los tres temas básicos (qué mapear, qué
consecuencias traen los mapeos y qué obtenemos con los mapeos) que se
consideraban debatir se han tratado dos:
o Qué mapear? De momento sólo se tratarán las páginas webs de los
grupos albergados en sinDominio, excluyendo las listas de correo y
las sindicaciones.
o Consecuencias, ¿se deben hacer públicos los resultados?: A pesar
de que un trabajo de este tipo podría ofrecer abundante información
sobre la red estudiada (vulnerabilidades, fallos, puntos débiles,
etc.) y esta información podría utilizarse contra la propia red
estudiada, esta información también presenta la posibilidad de
arreglar esos puntos débiles que posee la red, además de que la
transparencia es una de las piezas clave para poder llevar a cabo
alguna acción y añade una capacidad de invulnerabilidad.
Resta saber qué información nos aportaría un estudio como éste y
hasta que punto se ciñe a la realidad. En mi opinión nos aporta la
posibilidad de ver cómo se organizan estas redes, cuáles son sus
centros neurálgicos, así como sus puntos fuertes/débiles, ver cómo
evolucionan, si se forman nuevas redes en su interior, redes
parelelas y similares, si absorbe o se fusiona con otras redes (por
ejemplo hace unos años el activismo político de izquierdas no estaba
muy relacionado con el software libre, sin embargo hoy en día cada
vez van más unidos nop?).
Para que este estudio se ajuste a la realidad hay que hacerlo de
forma continua, no dejar nunca de sondear la red estudiada para ver
cómo evoluciona.
..::Reto::..
El reto consiste en un problema que se resolverá entre toda la lista
El diseño del algoritmo sería un reto?
.:Lecturas:.
Son lecturas que se harán y comentarán en la lista de forma que se
aprendan nuevos campos y se generen materiales para estudios
posteriores o para la publicación
..::Cursos, Material::..
Como forma de publicación del conocimiento generado con las lecturas,
los trabajos, estudios particulares, partes del proyecto, etc.
..::Programación::..
Aplicación práctica de todo lo estudiado y debatido en los módulos
anteriores.
Fases y desarrollo
---------------------
.:Exploración:.
Ahora mismo ya hemos fijado los límites del mapeo (red activista
establecida en sinDominio y limitada a las páginas web), hemos
encontrado el estudio sobre la Blogosfera (que convendría estudiar
con un poco de profundidad) y un par de textos que pueden estar
interesantes para pasar al módulo de lecturas.
El algoritmo de mapeo que se me ha ocurrido lo expongo al final de
esta parte.
.:Aprendizaje:.
Incluye la lectura de los textos encontrados y las primeras de
pruebas de uso o programación de los programas requeridos.
Posteriormente iríamos pasando a las demás fases: aproximación,
topométrica-topográfica, topológica y publicación.
-- Adicionalmente queda pendiente a) fijar un calendario, b)
coordinación de módulos y c)diseño definitivo.
Algoritmo de mapeo:
Según hemos visto nuestro proyecto plantea crear un sistema que
mediante el análisis de diversas fuentes (páginas webs, logs, listas
de correo, sindicaciones, etc.) construya una base de datos que
posteriormente sea analizada y representada para extraer unas
conclusiones.
He pensado en dividir tal sistema en 3 partes (o interfaces o capas o
como queráis llamarlo), que se corresponderían con la topometría, la
topografía y la topología/cartografía:
1. Interfaz de recogida y absorción del web. Se encargaría de ir
filtrando y analizando el medio oportuno (logs, web, listas de
correo, etc.) e ir generando información estándar, similar
independientemente de que el medio sea una web, un log... y
procesable por la interfaz 3. Esta información se almacenaría
mediante la interfaz 2.
Esto sería un crawler que recorriese la web de sinDominio, detecte
a) qué tipos de datos recibe (txt, html o similares, png, pdf...) y
si los puede analizar o no,
b) el idioma en que están tales datos y en función de éste si se
desechan o se archivarán indicando que están en el idioma que sea.
Tratándose de sinDominio me temo que estará casi todo en castellano,
pero por escalabilidad será más adecuado dar soporte a distintos
idiomas, aunque sea en versiones posteriores.
c) de qué va la página recibida, esto es, sacar las keywords de la
página. Sólo si se van a analizar los artículos, por ejemplo para
determinar si se repiten o no en otras páginas.
y tras la detección se dedique a la extracción de los links de la
página (lo que incluye "completarlos" y verificarlos) para almacenar
en la interfaz 2 la dirección de la página y la dirección de las
páginas enlazadas, así como otra info. (idioma, tamaño, keywords,
última acutalización del registro, primera actualización, etc.)
Este crawler se ejecutaría en ordenadores "normales" (los que tenemos
en casa en el trabajo, los "nuestros")
2. Interfaz de almacenamiento. Recibiría datos de la interfaz 1 y los
almacenaría para que en un momento dado la interfaz 3 pueda
analizarlos.
Bueno, esto trataría de una base de datos, por nombrar una MySQL que
es más o menos gpl y muy potente.
Se ejecutaría en un servidor, p.ej. de sinDominio, y recibiría la
información de los diferentes crawlers instalados en nuestros
ordenadores que han ido explorando el web.
Hay que garantizar que los datos que recibe de los crawlers son
verdaderos, para esto podemos:
a) fiarnos sin más (si suponemos que nadie tiene la intención de
alterar los datos),
b) hacer que la conexión se haga encriptada (un túnel SSH p.ej.) para
garantizar que nadie altera los datos por el camino (sin embargo nos
estamos fiando de que el cliente sea de confianza ) o
c) repartir claves públicas (una distinta para cada usuario, que
tendrían que registrarse antes de poder trabajar), además usar un
túnel SSH y además guardar en la base de datos (BBDD) quién introduce
qué registro y cuándo (para poder eliminar los registros trucados de
un posible saboteador del análisis). Esta opción es la más segura
pero la que más dificulta la participación de la gente (es cerrada) y
la más compleja de programar (esto es más tiempo, más fallos, más
quebraderos de cabeza, más limitaciones, etc.)
Habría que definir qué formato tendría cada entrada en la BD y cómo
se organizaría ésta, ¿alguien sabe de bases de datos?
3. Interfaz de análisis. Analiza los datos que saca de la interfaz 2
y que han sido estandarizados por la interfaz 1 antes de incluirlos
en la 2. Muestra los resultados, las conclusiones, el zumo que sale
tras analizar todo lo que ha recogido la interfaz 1 y se ha
introducido en la 2.
Una retaíla de programas (que no tienen porque ejecutarse en el
servidor) que vaya leyendo los registros de la base de datos (se
conecta al servidor y lee) y sacando gaficos, dibujitos,
distribuciones estadísticas, conclusiones, etc.
Sabéis algo de data mining? el datawarehouse tiene algo que ver en
esto?
aquí quizá se puedan aplicar redes neuronales que saquen
conclusiones, sistemas expertos?...
Lo básico sería un programa que muestre los datos de la BD para
comprobar si todo va bien, luego ya se mejorarían
Consideraciones Finales:
Propongo que:
- discutamos este planteamiento en la lista. Si os parece damos de
plazo hasta el lunes 17 para que el algoritmo ya esté perfectamente
planteado y definido (dentro de lo posible). Tb. se definirán el
formato de las entradas de la base de datos, la forma de conexiones y
demás cuestiones comunes a las 3 interfaces. Podemos ve el
plantemiento del estudio de la blogosfera
- si os parece bien vamos haciendo grupos de desarrollo dentro del
módulo de Programación de forma que ya se vayan programando las
diferentes interfaces en cuanto los puntos comunes estén bien
definidos. Desde luego hay que tratar de reutilizar código al máximo
(estoy presuponiendo qeu vamos a programar casi todo en vez de
utilizar programas ya existentes) para ahorrar tiempo. La interfaz 2
conociendo MySQL ya está prácticamente hecha ya que mysql es muy
potente (aunque hay que vigilar la seguridad), si conocéis otra BD
comentad.
- vamos desarrollando unas lecturas,unos retos, debates, etc.
- fijemos un calendario para todas las actividades
de programar, en qué lenguaje? para qué sistemas? ojo! yo he escrito
esto con C+linux en la cabeza.
Para la programación hay que utilizar CVS o un sistema similar, no sé
si sindominio tiene un servidor CVS, hispalinux sí. Es necesario para
programar adecuadamente entre varias personas (y tb. que esas
personas tengan su reloj en hora, para lo cuál no está de más un
servidor ntp o parecido)
Para tratar todos los temas que tenemos que tratar hay que utilizar
por fuerza el algoritmo de formato de sujeto del mensaje y hay que
procurar que los mensajes sean muy concretos (no un mensaje que
pinche en todos lados como éste sino muchos mensajes que cada uno
toque en su parte)
creo que ya está todo, si habéis llegado hasta aquí premio!: botella
de lejía para el caballero (hay alguna tía en la lista o estamos como
siempre??)
More information about the Grey-Walter
mailing list