[hm] {difu:} proyecto red social bcnencomu

psy epsylon en riseup.net
Sab Ago 13 22:10:55 CEST 2016


Blablabla... Pragmatismo / "pragmato-cracia" / AI <-> Democracy /
"demos-crazy".

-----------

Quiz�s sea interesante que la siguiente propuesta de bcnencomu (o de
quien sea) detalle algunos par�metros m�s concretos, para que la gente
se sit�e mejor.

Por ejemplo, una l�nea de tiempo (o roadmap), si se tiene una decisi�n
tomada sobre una aplicaci�n a utilizar o incluso un lenguaje o un texto
con una vertiente m�s de investigaci�n, si se buscan ideas y gente que
las haga funcionar.

Un nivel de prioridad (normal<cr�tica), sin dar demasiados detalles a
otros competid..(partidos), pero si dejando ver su relevancia y necesidad.

Recursos que puedan ser �tiles y no haga falta buscar (soporte humano),
etc.

Tambi�n, no es lo mismo implementar algo experimental, con el riesgo que
conlleva, que buscar una soluci�n ya experimentada que cumpla una
funci�n delimitada, en producci�n.

Es �D, I+D o I+D+i?. Parecen etiquetas chorras, pero si va de
"conquistar el planeta", tambi�n es bueno saberlo. ;-)

Tampoco estar�a mal saber el nivel de compromiso, en por ejemplo,
mantener la infraestructura, si existir� un proceso de delegaci�n,
cursos de ense�anza o relevo de mantenedores, etc.

Ojo, lo comento sin haber hecho antes ninguna propuesta contextual
similar. Quiz�s la misma, al ser de la Administraci�n, lleve un
protocolo que pase por �ste tipo de comunicados y m�s adelante se
detalla cada punto de otras maneras (reuniones, etc..), ni idea esa parte.

Lo que si te puedo decir es que he visto que se habla de Discourse.
Bueno, es una soluci�n centralizada que utilizamos en otros �mbitos.
Quiz�s haya que resaltar las deficiencias en la gesti�n, de por ejemplo,
los grupos. O algunos detalles sin implementar de la federaci�n.

Tal vez, si se trata �nicamente de comunicarse mediante hilos y crear
"grupos" o "temas", con algo como BitMessage (
https://es.wikipedia.org/wiki/Bitmessage ), es m�s que suficiente:

""""""""""""""""""""""
A partir de la versi�n 0.3.5, Bitmessage introdujo una caracter�stica
llamada chan, una lista de correo descentralizada an�nima. A diferencia
de las Listas de correo electr�nico tradicionales:

    - un chan no puede cerrarse tirando abajo todos los servidores o un
grupo de servidores debido a la naturaleza descentralizada de los chans.
    - un chan no puede ser censurado ya que cualquier usuario de
Bitmessage que sabe la contrase�a puede leer el chan o publicar
cualquier mensaje en el chan.
    - en un chan, los mensajes de los usuarios son an�nimos hasta tal
punto de que los mensajes no contienen ni la direcci�n del emisor ni el
receptor del Bitmessage.

Existen una serie de chans p�blicamente conocidos dedicados a temas que
van desde la privacidad_en_Internet a la pol�tica o a los juegos de ajedrez.
""""""""""""""""""""""""

Esa parte es la m�s extrema en anonimato. Pero se pueden generar
etiquetas para las direcciones que permiten identificar a la personas, a
los grupos y a los temas.

Lo digo adem�s, porque sean las ciudadanas las que "mantienen" el
contenido de la red, a trav�s de la arquitectura p2p y la Administraci�n
�nicamente trabaje como facilitadora/herramienta/pegamento. M�s justo
para la ciudadania, altamente improbable. Porque no se trata �nicamente
de la licencia, sino de la forma en que se despliega/mantiene el
recurso. Poco hay m�s "democr�tico" que el p2p, a la hora de comunicar
datos.

Otro detalle tambi�n interesante sobre Discourse es que no tiene un
sistema de permisos sobre el contenido, como por ejemplo tiene Elgg, lo
cual, en seg�n que contextos, delimita m�s de un modo u otro su uso.

Como foro, con hilos, moderaci�n, "me interesa", etc.. est� genial.
Tiene buena est�tica y se ha trabajado bastante lo as�ncrono.

El editor de textos para publicar es algo l�mitado. Las p�blicaciones
tienes una est�tica forma algo monol�tica. Pero al estar modularizado,
seguro ya hay "plugins" por ah� o se puedan implementar soluciones de
manera no muy complicada, a la carta.

Sobre su seguridad, ahora mismo no sabr�a decir, pero supongo todo sea
cuesti�n de sincronizarse con la comunidad.

Hace tiempo alguna vulnerabilidad ya hemos reportado, como por ejemplo,
que utilice un par�metro redirect en el login, mediante POST. Al estar
sin filtrar (en la mayor�a de los casos), permite crear ataques de
impersonaci�n m�s sofisticados a trav�s de links maliciosos...

REQUEST:

POST /login HTTP/1.0
Accept: /Content-Type: application/x-www-form-urlencoded
User-Agent: [snipped]
Host: forum.[discourse.org]
Content-Length: 60
Cookie: [snipped]
Connection: Close
Pragma: no-cache

username=foo&password=bar&redirect=http://www.whitehouse.gov/

RESPONSE:

HTTP/1.1 302 Moved Temporarily
Sever: [snipped]
Date: [snipped]
Content-Type: text/html; charset=utf-8
Connection: close
[snipped]
Location: http://www.whitehouse.gov/

[snipped]

Si el servidor (o la petici�n del atacante), conlleva seguir el
"Location", es posible llevarse a la gente a otros lugares sin que se
enteren tras loguearse y encadenar otro tipo de ataques (CSRF, etc..)

Pero vamos, en l�nea con las plataformas similares...

------------ pr�xima parte ------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: </pipermail/hackmeeting/attachments/20160813/214efe9e/attachment.pgp>


M�s informaci�n sobre la lista de distribuci�n HackMeeting