Lunes 27 de marzo de 2017

Usemos Linux: Jugar Ping Pong desde la consola con pong-command

Crear una imagen Docker a partir de debootstrap para Debian Jessie

Antes de empezar a tocar el tema sobre crear una imagen Docker a partir de debootstrap de Debian, les dejo el enlace de los artículos sobre docker del blog.

Lo primero que se tiene que hacer es instalar debootstrap:

#apt-get install debootstrap

A continuación se crea un directorio para construir la jaula debootstrap:

mkdir debian-jaula

Ahora se ejecuta debootstrap pasando la distribución a bajar, el directorio donde se crea la jaula y el repositorio a usar:

debootstrap jessie debian-jaula/ http://ftp.debian.org/debian
I: Retrieving Release 
I: Retrieving Release.gpg 
I: Checking Release signature
I: Valid Release signature (key id 75DDC3C4A499F1A18CB5F3C8CBF8D6FD518E17E1)
I: Validating Packages 
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Found additional required dependencies: acl adduser dmsetup insserv libaudit-common libaudit1 libbz2-1.0 libcap2 libcap2-bin libcryptsetup4 libdb5.3 libdebconfclient0 libdevmapper1.02.1 libgcrypt20 libgpg-error0 libkmod2 libncursesw5 libprocps3 libsemanage-common libsemanage1 libslang2 libsystemd0 libudev1 libustr-1.0-1 procps systemd systemd-sysv udev 
I: Found additional base dependencies: libdns-export100 libffi6 libgmp10 libgnutls-deb0-28 libgnutls-openssl27 libhogweed2 libicu52 libidn11 libirs-export91 libisc-export95 libisccfg-export90 libmnl0 libnetfilter-acct1 libnettle4 libnfnetlink0 libp11-kit0 libpsl0 libtasn1-6 
I: Checking component main on http://ftp.debian.org/debian...
I: Validating acl 2.2.52-2
I: Retrieving libacl1 2.2.52-2
I: Validating libacl1 2.2.52-2
........................
..............
I: Configuring isc-dhcp-client...
I: Configuring tasksel...
I: Configuring tasksel-data...
I: Configuring libc-bin...
I: Configuring systemd...
I: Base system installed successfully.


Ahora se muestra el contenido del directorio:

ls debian-jaula/
bin/  boot/  dev/  etc/  home/  lib/  lib64/  media/  mnt/  opt/  proc/  root/  run/  sbin/  srv/  sys/  tmp/  usr/  var/

Ahora se crea la imagen por medio de tar y de docker import:

tar -C debian-jaula/ -c . | docker import - ecrespo/debian
sha256:49ad34e39c5f9ede2c1c57994895065236a5965496631e8fcab00b00778d85fa
Como se puede ver, se genera la imagen y el ID de la misma en sha256, se coloca en subrayado la parte que identifica la imagen al listas las imagenes.


Al hacer docker images se tiene lo siguiente:
REPOSITORY                                        TAG                 IMAGE ID            CREATED             SIZE
ecrespo/debian                                    latest              49ad34e39c5f        2 minutes ago       272.7 MB


Al tener la jaula lista se puede hacer personalizaciones y adaptaciones a fin de crear la imagen docker.

Este artículo se basa en a documentación del wiki de Debian sobre debootstrap y en un artículo sobre imagen base de docker

Linux Adictos: openSUSE Tumbleweed ya cuenta con Gnome 3.24
Javier Smaldone

Javier Smaldone
Blog de Javier Smaldone

Exposiciones sobre el voto electrónico en la Cámara de Diputados

Intervenciones de distintos especialistas en el Plenario de Comisiones de Asuntos Institucionales; Justicia; Presupuesto y Hacienda en la Honorable Cámara de Diputados de la Nación, incluidas en el libro Voto electrónico, una solución en busca de problemas.

Exposiciones en Diputados

“En el proyecto de ley sobre voto electrónico, hay aspectos contradictorios”

Daniel Penazzi

Mi nombre es Daniel Penazzi, soy Doctor en Matemática con el título en la Universidad de Minnesota y Licenciado en Matemática y en este momento soy profesor en la Universidad Nacional de Córdoba en la Facultad de Matemática, Astronomía, Física y Computación. Si bien mi título es de matemática, justamente como hay computación desde hace 17 años enseño esta materia. Me he dedicado a la criptografía y tengo dos papers publicados en voto electrónico. Como el tiempo es poco le voy a dar una pequeñísima clase de cómo son los sistemas de voto electrónico en general.

Hay sistemas de voto electrónico que usualmente se llaman sistemas dre, que significa en inglés direct recording electronic machines, en donde los actos de generar el voto y de contarlo están en el misma máquina. Esos sistemas pueden o no tener un registro en papel y son muy peligrosos. Quince años o más de ataques demostraron que estos sistemas no deben usarse.

Otro sistema alternativo llamado sistema ire por indirect recording electronic voting machines intenta imitar lo que uno hace cuando vota a mano. Es decir, el votante genera un voto, ese voto se deposita de alguna forma, se plasma en algún objeto físico y ese objeto físico se deposita en una urna en donde se anonimiza y, luego, se cuenta aparte. Esos sistemas son muchos más seguros que los sistemas de dre con o sin papel.

Acá el problema no es que haya un registro en papel –porque, por ejemplo, en Venezuela tienen un registro en papel–, tener un registro en papel solo ataca el problema de integridad y de verificabilidad. Los dre son peligrosos por otro problema: vulneran el secreto del voto. ¿Por qué vulneran el secreto del voto? Porque dado que la misma máquina que genera cuenta, el votante por su parte no puede saber si su voto no va a ser revelado de alguna forma. Entonces los sistemas ire son mejores pero eso no significa que no se puedan hacer mal.

Lo que yo quería aclarar es que en este proyecto de ley hay aspectos contradictorios. En el articulo 15, por ejemplo, en donde se define lo que es sistema de emisión de sufragio con boleta electrónica, lo que se está definiendo es un sistema dre con papel. Sin embargo, en los artículos 31, 33, 37 y 38 lo que se está definiendo es un sistema ire. O sea en la misma ley se contradice. Obviamente los que hicieron este proyecto están pensando en un sistema parecido al de MSA (Magic Software Argentina), o sea un sistema ire. La diferencia entre esos dos sistemas no consiste en que haya un registro en papel sino que en el sistema ire no debe quedar ningún registro en la máquina que genera el voto de lo que el votante voto.

En este sentido, por más que digamos “bueno, vamos a corregir el artículo 15 porque está medio mal escrito, para tratar de reflejar lo que dicen el 31, 33, 37 y 38” no es suficiente, sigue faltando precisión. Debe estar explícito que el sistema que genera el voto no guarda ningún registro, porque si no ocurren situaciones como en Brasil. Hace poco, Brasil fue “hackeado” por un investigador llamado Diego Aranha, quien reveló que, por una mala implementación de algoritmos criptográficos, se puede conocer quién voto a qué candidato, es decir, conocer todo el orden de las votaciones de los votantes, cliqueando en qué momento voto y saber qué voto.

Entonces es importante que estos aspectos cambien en esta ley. Por supuesto que mejor sería no proponer un sistema de voto electrónico. Como mucha gente ha dicho, el sistema de boleta única en papel contada a mano es mucho mejor desde el punto de vista de seguridad que este sistema. Y si lo que quieren es rapidez, están los sistemas electrónicos que pueden utilizarse en el conteo solamente. Es decir, uno genera el voto a mano, con lo cual resuelve todos los problemas de seguridad que hay en los sistemas de generación de votos electrónicos y luego sí, se cuenta electrónicamente y por supuesto hay que tener una auditoría post-elección como está señalado en el artículo 111 bis. Pero ahí lo que uno hace es aislar los dos problemas.

El mayor problema de seguridad está en la generación del voto porque la máquina está en contacto con la persona que está votando y existe un derecho fundamental, un derecho del votante. Este derecho no es solo que el voto sea secreto, sino que el ciudadano sepa por su cuenta que el voto no está siendo revelado. En el sistema propuesto por MSA y en la ley no queda claro que se le ofrezca esa garantía al votante. Hay métodos propuestos por bibliografía específica, aunque no todos el 100% seguros, para intentar que el votante tenga alguna seguridad por su cuenta, sin tener que depender del personal de la compañía ni de los que van a auditar el voto. En cambio, en la ley, la redacción de los artículos 31, 33, 37 y 38 no parecería dejar lugar a ese tipo de sistemas.

Igual, si bien hay sugerencias en la bibliografía específica sobre el voto electrónico es bastante costoso –en términos de dinero– y posiblemente tiene otros problemas, así que en general quizá de acá a un par de años se puedan hacer. Yo no las recomendaría. Por ejemplo, muchos de esos sistemas usan criptografía como la encriptación homomórfica, zero knowledge proof, y un montón de otras cosas que sería difícil explicárselas al común de la gente.

Es decir, por más que uno pueda diseñar un sistema que, en abstracto, sea bueno, explicárselo a millones de personas no va a ser fácil. En este sentido, la International Association for Criptological Research (iacr) tiene un sistema de voto no solo electrónico sino a distancia y lo usan. Pero ellos mismos dicen: “esto sirve para nosotros que somos criptógrafos y sabemos los que estamos haciendo, este no es un sistema que se pueda adaptar masivamente”. Entonces, aun cuando se pudiera de forma técnica resolver estos problemas que menciono, siempre quedaría el problema de cómo explicárselo a millones de personas. Por eso, en general, lo que la gente recomienda por ahora es o todo manual o por lo menos que la generación del voto sea manual y si después se quiere hacer un conteo electrónico se hace.

Para terminar, me gustaría hacer una pequeña analogía: hay gente que se opone a las centrales nucleares y gente que está a favor de las centrales nucleares. Y en general uno hace un análisis de costo, riesgo y beneficios y estará de un lado o de otro. Pero aun la gente que está a favor de las centrales nucleares no tiene la locura de diseñar una central nuclear como si fuera una central termoeléctrica común. Muchos de los que estamos acá hacemos la relación costo, riesgo y beneficios del voto electrónico y concluimos: mejor no, mejor quedarnos con el papel. Algunos de ustedes por ahí dicen que les parece que la ecuación da por el lado de los beneficios, bien. Ustedes son los legisladores y si ustedes quieren adoptar el voto electrónico, bien, pero por lo menos diséñenlo bien. No dejen todos estos huecos que hay acá porque va a ser un desastre.

Muchos me dijeron “bueno, pero hay que demostrar…”; no, no hay que demostrar nada. Nosotros no tenemos que demostrar nada. La persona o compañía que introduzca el sistema, que proponga el sistema, ellos tienen que dar una serie de afirmaciones de seguridad y demostrar que esas afirmaciones se cumplen. No estoy diciendo que prueben que el sistema es 100% seguro. Si dicen que la máquina que genera el voto no tiene ningún registro, que lo digan explícitamente; y si, luego, se verifica que sí tiene un registro que lo guarda, tiene que haber penalidades, así como hay penalidades para el que se mete y vulnera el sistema. Tiene que haber sanciones penales y no solo económicas para el que dice que está prestando un sistema que no tiene ciertas características y después resulta que tiene vulnerabilidades.

El votante, como dije antes, tiene su derecho fundamental de saber que su secreto no será revelado y para que les quede otra analogía: el sistema debe ser tal que el votante piense “esta máquina con la que voy a interactuar para producir el voto, es mi enemiga, no mi amiga”. Y sin embargo el protocolo que me están dando para que yo vote me permite burlarla y ganarla. Si no tiene eso, como no lo tiene esta ley y como no lo tiene el sistema de MSA, es un problema grave. Finalmente otra analogía: uno no construye un puente y dice: “Mire, el puente es seguro, ya pasó una semana y no se cayó ningún auto”. La gente que construye puentes hace cálculos y demuestra que el puente está bien construido. Nada más. Gracias.

“Hay que verificar, garantizar y demostrar matemáticamente que el sistema cumple con esas propiedades”

Iván Arce

Gracias por la invitación a todas las autoridades, a los diputados, a la comisión. Voy a tratar de ser lo más rápido posible, es difícil ser rápido, hablar en diez minutos de seguridad, tic y voto electrónico. Yo me dedico a la seguridad tic, lo he hecho los últimos veinte años en el sector público, en el sector privado, con la comunidad académica, con la comunidad de practicantes, en el ámbito nacional y en el internacional. Trabajé dieciséis años en el sector privado en una empresa de seguridad informática, trabajo actualmente en la Fundación Sadosky coordinando un programa de seguridad en tic. Además, fui editor doce años de la revista IEEE Seguridad y privacidad. IEEE es una asociación profesional de ingenieros, electrónicos y electricistas, es una de las dos más importantes del mundo en la materia. Finalmente, soy fundador del Centro para el Diseño del Software Seguro de IEEE. Dicho todo esto aclaro que mis comentarios y observaciones son a título personal, ninguna de todas las instituciones que mencioné fueron consultadas o participaron en el proyecto. Hablo en calidad de experto a título personal.

Voy a tratar de hacer referencia o tomar algunos puntos de algunos oradores anteriores que hablaron de cosas de las que yo tenía previsto hablar, empezando por lo que dijo la Dra. Tula cuando hablaba de los tres principios rectores que uno debería esperar del voto electrónico que están de hecho enunciados en el artículo 1 del proyecto de ley. Ella hablaba de integridad, auditabilidad y secreto como principios rectores, eso cuando se habla en un sistema informático se tiene que traducir a propiedades del sistema. Una cosa es hablar de estas cosas como principios o cosas que son deseables y otra cosa distinta es que un sistema tenga esas propiedades y se pueda garantizar que esas propiedades se cumplen y el sistema las brinda. Para garantizar esto a lo que se recurre generalmente en la ciencia de la computación es a la matemática. Hay que verificar, garantizar y demostrar matemáticamente que el sistema cumple con esas propiedades.

Enrique Chaparro suele hacer mención de un teorema del 2009 que precisamente te muestra matemáticamente que no se puede construir un sistema que satisfaga simultáneamente esas tres propiedades. Eso no es el fin del mundo y ahora les voy a explicar por qué pero la conclusión es que hay una demostración matemática que señala que no se puede construir un sistema que simultáneamente satisfaga las tres características –integridad, auditabilidad y secreto– al mismo tiempo. Ahora bien, es una demostración matemática, por lo que dista de la implementación práctica.

La seguridad en las tecnologías de información y comunicaciones trata de manejar el riesgo de sistemas tecnológicos imperfectos –no perfectos y demostrados matemáticamente que lo son, sino sistemas tecnológicos imperfectos en presencia de ataques o de adversarios. Eso es a lo que yo me dedico y ahí hay que hacer una nueva salvedad que es el tema de la presencia de los adversarios. La seguridad en tic estudia los sistemas informáticos y tecnológicos desde el punto de vista no de los fenómenos naturales sino de la presencia de actores, adversarios, con capacidades, es decir, agentes inteligentes que tienen recursos, tienen conocimientos y tienen incentivos o desincentivos y capacidad de acción variada. Hay que caracterizar correctamente cuál es el adversario.

En el contexto de un sistema electoral el adversario va desde un entusiasta de la informática que tiene intenciones de causar problemas o curiosidad, hasta una o varias agencias de inteligencia estatales nacionales o extranjeras. En el medio hay una gran variedad de potenciales adversarios. Las organizaciones delictivas nacionales e internacionales, el proveedor del sistema y toda su cadena de abastecimiento deben ser considerados como un potencial adversario; un grupo de activistas, un tipo como yo que sabe de informática y de seguridad o un conjunto de personas como yo que quieren hacer algo dañino también. Es por lo tanto necesario caracterizar a los adversarios adecuadamente y diseñar los sistemas para prevenir amenazas identificadas de cualquiera de estos. Hay que determinar cuál es el nivel de riesgo que uno quiere asumir en el uso de un sistema que, como dije, es imperfecto. Y hacerlo explícitamente. El proyecto de ley que estamos tratando habla de la seguridad en el artículo 1, enunciando principios, pero no habla de cuestiones precisas en todo el resto del proyecto. Por lo tanto deja un margen muy amplio, muy abierto a que puedan suceder cualquier tipo de cosas ya sean malas o buenas. En principio eso es preocupante porque lo que sucede generalmente en la práctica no es bueno, no es la situación ideal sino todo lo contrario.

Se ha mencionado en este debate el tema de la auditoría y de los plazos, particularmente si no me equivoco esto figura en el artículo 15 del proyecto y frente a eso tengo que hacer algunos comentarios. El primero y principal es que los plazos previstos en el artículo 15 hablan de la auditoría, de los 120 días anteriores a la elección, pero lo que hay que considerar desde el punto de vista de la seguridad informática o seguridad tic, es todo el proceso de un sistema de desarrollo electoral. Desde su concepción, diseño, implementación, prueba en laboratorio, prueba de campo, puesta en funcionamiento, mantenimiento en la elección y lo que sucede después. En el mundo de la seguridad informática, la seguridad de software, no es suficiente hacer la auditoría de artefactos, de códigos de programas sino que hay que tener una idea de las prácticas empleadas y las actividades. Hay un conjunto de prácticas conocidas tendientes a minimizar el riesgo durante todo el ciclo de vida de desarrollo de los sistemas tecnológicos y todos esos rasgos deben ser tenidos en cuenta a fin de minimizar el riesgo de seguridad en un sistema de esta naturaleza.

Independientemente de esto que les cuento, una auditoría de veinte días es insuficiente para lo que se está tratando y me podrían preguntar cuántos días son suficientes. La respuesta a eso sería: no les puedo decir porque no se cuál es el sistema, qué grado de complejidad tiene, cuáles son los componentes que usa, cuáles son los proveedores del proveedor y cuál es la práctica o la madurez en términos de seguridad que tiene cada uno de ellos. Solo es posible determinar cuáles son las necesidades de auditoría cuando se tiene alguna especificación o alguna indicación concreta sobre qué es lo que se quiere auditar. Así que creo que eso es algo que se debería considerar. Se debería considerar también quien determinaría esto. Porque evidentemente no se puede determinar en una ley de antemano y posiblemente no se puede determinar en una reglamentación tampoco, hay que considerarlo de una manera un poco más precisa.

El Dr. Tullio hablaba de las diferencias entre, si no me equivoco, auditoría y homologación. Sugiero retirar la palabra homologación. Se podría reemplazar por certificación. Tanto una certificación como una homologación se hacen respecto a algún criterio preestablecido de antemano. Y es muy difícil definir criterios de antemano. La autoridad de asistencia electoral en los Estados Unidos se tomó cinco años para definir los criterios de homologación de sistemas electorales tecnológicos, con dos periodos de 120 días abiertos a comentarios y sugerencias del público en general.

Para terminar, aunque tengo muchos más comentarios para hacer, me voy a enfocar en uno que me parece fundamental y que es un tanto preocupante en el proyecto de ley. Me refiero a los artículos 59 y 60. En el 60 se crea el delito informático electoral; el 59 habla de otros delitos. En ellos se mencionan cosas o prácticas que son frecuentes en la investigación y desarrollo en seguridad informática o seguridad tic, para hacerlo más informal. Eso es preocupante porque el efecto de desincentivo o de temor que puede generar en la comunidad de investigación tanto de practicantes como académica por explorar e identificar problemas de seguridad en los sistemas de seguridad propuestos, va directamente en detrimento de la seguridad del sistema. En seguridad informática, el ataque y la defensa de un sistema se complementan y son ambos necesarios. Desde el año 800 esto se aplica en los sistemas criptográficos; desde 1950 en adelante (seguramente 1970), en la práctica de sistemas de seguridad modernos. Tanto el ataque como la defensa son necesarios y hay que incentivar a ambos. Solo se pueden solucionar los problemas de seguridad si hay gente activa sistemáticamente buscándolos para resolverlos y aquello que vaya en detrimento, con buena o mala intención, no importa, pero que vaya en detrimento de esa práctica en realidad presenta un potencial problema que puede redundar en mayor inseguridad y no mayor seguridad de los sistemas previstos. Les agradezco a todos su tiempo y su atención.

“La auditoría de este sistema de voto es imposible”

Alfredo Ortega

Me presento: soy Alfredo Ortega, tengo un Doctorado en Matemática en el Instituto Tecnológico de Buenos Aires (itba) y, aparte de la experiencia académica, me especialicé en auditoría y seguridad de software por casi quince años. En estos años, estudié y trabajé en la creación de ataques de software y hardware en todo tipo de dispositivos: computadoras, dispositivos móviles como celulares e impresoras –porque también son computadoras–, y específicamente en el sistema de voto como el de boleta única electrónica, usado en 2015.

En primer lugar, todo sistema tiene ventajas y desventajas. Las ventajas están sobrerrepresentadas en el proyecto de voto y acá vinimos a hablar lamentablemente de las desventajas. Si uno tiene más desventajas que ventajas, hay que pensar si conviene o no implementar un sistema de este tipo. Como ya muchas personas dijeron, las tres características fundamentales que tiene que tener un sistema de voto que son auditabilidad, resistencia al fraude y secreto. Estas no se garantizan en este sistema y, por ende, se presenta muy vulnerable a la coacción del votante.

Específicamente escuché que muchos hablaban de las posibilidades de auditar el sistema. Trabajé mucho tiempo en auditorías y es imposible auditar este sistema en el tiempo propuesto. Es bastante lógico si uno piensa que son decenas de personas desarrollando un sistema por diez años pero si uno lo quiere auditar en 180 días, es imposible hacerlo. Además uno puede auditar una máquina pero hay casi 90.000 maquinas que no necesariamente son las mismas. Entonces, la auditoría de este sistema de voto es imposible. No es extrapolable a nivel nacional, se lo puede hacer con una universidad con un equipo de fútbol pero no con un país.

Por esta razón, justamente, no se puede mantener el secreto del voto porque no se puede confiar en lo que hay adentro de una computadora. Nadie sabe a ciencia cierta todos los componentes, miles de componentes, que tiene una computadora adentro. El votante no puede confiar en algo que tenga componentes electrónicos, lamentablemente. Hay un dato interesante, la misma boleta electrónica tiene una computadora dentro. Lo escuché nombrar como memoria pero es una computadora. Insisto: la boleta misma tiene computadora dentro cuyo código nadie sabe quién lo escribió ni quién lo fabricó.

Además, me gustaría hablar sobre ataques específicos a los sistemas de voto. En cuanto a los ataques de los adversarios, uno se va a enfrentar con gente que está muy preparada, hay ataques que no se pueden detectar con auditorías. El sistema de boleta única electrónica pasó por muchas auditorías; muchas universidades –todas las que conozco– auditaron este sistema. Cada universidad encontró una falla distinta. Porque es una falacia que uno puede limpiar un sistema de vulnerabilidades. Uno jamás va a terminar de encontrar las en un sistema. Después de que todas las universidades hicieron su auditoría, lo vi yo personalmente y encontré otra vulnerabilidad, que permitía poner muchos votos de una misma persona en la boleta. Es algo básico en el conteo de los votos pero se les pasó. Y no porque hayan sido malas personas sino porque es algo natural del software. No porque las máquinas no estén preparadas sino porque en una auditoría es imposible sacar todas las fallas de un sistema. Y lamentablemente el sistema de voto no tolera fallas, no es como un sistema de tarjetas de crédito, de cajero, que pueden ser tolerantes a fallas. Este sistema no tolera fallas. Porque una falla permite que haya un error en la elección, se elija a otra persona y no se pueda volver atrás. Con una tarjeta de crédito se puede volver atrás perfectamente en cualquier transacción.

También, me gustaría hablar de un dato muy interesante: los ataques prácticos –no teóricos– que sufrió el sistema de voto. El sistema de voto de boleta única electrónica sufrió ataques no a los meses sino a los días de ser implementado, es decir, antes de la votación ya sufrió cuatro ataques informáticos de los cuales hay registros por la policía. Uno de los “atacantes”, a quien la policía allanó, justamente no se trataba de un ataque sino de una persona que avisó de los ataques.1 Quiero centrarme en los demás, de los que nadie habla, de los dos ataques que la policía no pudo encontrar. No sé si saben de dónde salieron esos ataques. Uno salió de Texas y otro salió de New Jersey. Esto que parece tan tranquilo significa que la policía tiene evidencia del primer ataque internacional al voto electrónico; y no se puede hacer absolutamente nada porque se trata de otro país, de otra jurisdicción. Fue un ataque internacional, fue antes de que ocurriera siquiera la primera votación. Esto es importante explicarlo: en el ambiente de la informática y la electrónica, todos los países están atacando. Existe la ciberseguridad, un área moderna. Todos los países están tratando de atacarse constantemente. Son expertos en hacerlo. No por nada este ataque fue a días de estar el sistema online. La policía que es una policía realmente eficiente –no podemos decir que es una policía sin recursos porque a las dos personas que fueron de Argentina las individualizaron, al instante, en corto tiempo– no puede hacer absolutamente nada contra los ataques internacionales.

Ahora bien, la empresa dice que estos sistemas de votos no son vulnerables porque no están conectados a Internet. Eso es totalmente falso. Hay ataques famosos como el de Stuxnet que se han realizado sin que las máquinas estén conectadas a Internet. No se puede pelear contra un adversario que tiene diez o veinte años de experiencia en ataques de sistemas informáticos. Yo tengo esa cantidad de años en el área: uno puede creer que los ataques son cosas que les pasan a otras personas, que no van a suceder en este sistema electrónico y que se van a poder frenar y detectar. Los ataques efectivos son los que no se pueden detectar.

Por casualidad, me mandaron un mail para venir a este lugar como invitación, ese mail tenía un link al sitio de la Cámara de Diputados. A través de ese link, que tenía una falla, uno puede entrar a la base de datos y bajarse los datos de todos los empleados, los diputados, los pedidos de declaración jurada. Los tengo acá, los traje. Esta es exactamente la misma falla de los Panamá papers, no exactamente pero el mismo tipo de falla que permitió los Panama papers y que permitió los leaks de Wikileaks. Es algo muy común y muy sencillo de hacer. Yo lo reporté, por supuesto, al sistema de seguridad informática que fue muy expeditivo en arreglar este problema; ya no existe, para que se queden tranquilos. Pero este tipo de fallas prevalece en la mayoría de los sistemas.

Por eso, como conclusión, quiero decir que es muy difícil hacer un sistema totalmente seguro y simple. El mundo se está moviendo para alejarse del sistema de voto electrónico. No quiere decir que en algún momento futuro se pueda llegar, pero hoy en día no se puede hacer. Y como prevención los países están alejándose del voto electrónico. Veo que Argentina justamente está yendo en contra de los países y no podemos ir en contra otra vez del conocimiento mundial, por algo lo están haciendo, aprendamos de la gente con experiencia y tratemos de hacer el voto de alguna manera que no involucre ningún sistema informático. Gracias.

Notas

1 Se refiere a Joaquín Sorianello. Más información puede leerse en http://www.lanacion.com.ar/1807647-segun-un-programador-que-detecto-fallas-en-el-sistema-de-voto-electronico-allanaron-su-casa

“La compra de votos no se elimina con este sistema”

Delia Ferreira Rubio

Lo primero que quiero señalar es que esta discusión no es “máquina sí, máquina no”, esta discusión es “rápido y moderno” (título de película) contra “seguro, íntegro y transparente”. Eso es lo que estamos discutiendo y como eso es lo que estamos discutiendo, estamos discutiendo sobre calidad de la democracia; sobre derechos y libertades de los ciudadanos y los electores; sobre los valores que dan sustento al sistema electoral; y sobre la legitimidad de ustedes, que son los electos. Ese es el resultado de un proceso electoral íntegro. La boleta única papel, que usa la mayoría de los países del mundo, es más barata, ofrece muchos más proveedores, evita los monopolios y soluciona el robo de boletas igual que la boleta única electrónica.

Respecto de la boleta única electrónica –y acá estoy llegando a la confusión total–, mal que les pese al señor ministro y a los funcionarios nacionales, es un sistema de voto electrónico. Hemos tenido acá el reconocimiento del Dr. Lozano que, luego de señalar en una sentencia como miembro del Tribunal Superior de la Ciudad que no era voto electrónico, ahora ha dicho que en la ciudad se aplicó el voto electrónico. Así que me parece muy interesante este reconocimiento. Pero además, ¿para qué vamos a decir una cosa por otra en el Congreso de la Nación, donde no tenemos las restricciones que en la Ciudad Autónoma de Buenos Aires, donde justificaron que las autoridades dijeran una cosa por otra? Porque si reconocían que era voto electrónico tenían que volver a la Legislatura. Para saltarse la Legislatura inventaron la historia de que la boleta única electrónica no es voto electrónico. Acá no necesitamos esa cuestión así que sinceremos ya que estamos sincerando tanto en el país.

¿Qué hay detrás de la decisión de adoptar este sistema de voto electrónico? Veamos los argumentos, veamos si son ciertos. Un argumento es “este sistema es rápido y moderno”. Cuidado con lo moderno porque estamos haciendo una ley que se supone que va a durar más de seis meses así que el año que viene, sobre todo en materia de tecnología, podríamos llegar a decir que esto es una antigualla. Pero me puse a mirar en los estándares internacionales en materia de sistemas electorales y en los tratados de derechos humanos que hablan de las elecciones libres y no encontré ningún tratado ni ningún estándar que diga que el principio electoral madre en una democracia es rápido y moderno. El problema con moderno es que si es tan moderno no me explico cómo puede ser que países mucho más desarrollados y modernos que Argentina no utilicen el sistema. A nivel internacional, solo tres países usan el sistema: la India, Brasil y Venezuela. La verdad es que creo que algo deben de estar haciendo bien con la boleta papel los países que son modernos y desarrollados y tienen mucha más tecnología que nosotros como Inglaterra, Alemania, Holanda y los países escandinavos, además de muchos lugares de países latinoamericanos. Entonces lo moderno hay que ponerlo en tela de juicio. También usan la boleta papel Corea y Corea del Sur y lo menciono porque ya voy a volver sobre el tema de si acá tenemos un problema de privatización del sistema electoral o tenemos un problema de extranjerización del sistema electoral. Lo dejo planteado. Corea del Sur es el país elegido por el Ministerio de Modernización para realizar convenios en la materia.

Además, la otra gran ventaja de este sistema de voto electrónico serían los resultados rápidos. Vamos a ver los resultados rápidos, suponiendo que “rápido y furioso” fuera un valor democrático. El 5 de julio de 2015 se realizaron elecciones en la Ciudad de Buenos Aires, con boleta única electrónica, y en mi provincia, en toda la provincia de Córdoba, con boleta papel (con un modelo distinto del de Santa Fe pero modelo papel). Veamos que ahora supimos las cosas. Sobre la rapidez inicial: a las 19:27 –tengo todos los documentos bajados del escrutinio–, CABA informaba un porcentaje escrutado de 4,7% de las mesas; en Córdoba, a las 19:17, un porcentaje de 1,4% de las mesas. Efectivamente en la Capital iban más rápido. Las 23:55, hora en el que en el día de la elección presidencial todavía no sabíamos nada, en Córdoba teníamos escrutados con boleta única papel el 65% de las mesas y la tendencia no varió hasta después. Alrededor de las 02:00 am del día 6 de julio el escrutinio de Capital y de Córdoba iban cabeza a cabeza, 93,4 y 93,5%. Así iban funcionando. Eso es lo rápido y furioso.

Por otro lado, a mí me parece que rápido y con errores no es un buen negocio. En el caso del voto electrónico de la Capital Federal, ni la empresa, ni las autoridades, ni las auditorías detectaron algo que mencionó la diputada Stolbizer hace un momento. Un error en la carga de los resultados estaba dando más votos que votantes en algunas comunas. Por ejemplo en la comuna 14, 21:57 de la noche, cantidad de electores 147.100, cantidad de votos 147.363. O sea que habían votado más que el total de los electores de la comuna. A las 00:29, información oficial del sistema que la autoridad electoral dice que funcionó tan bien, seguía diciendo que esa comuna tenía a 170.000 electores y que habían votado 147.363. Recién se corrigió esto a las 02:00 am del día siguiente y se corrigió no porque la empresa lo detectó, no porque los autores lo detectaron, no porque las autoridades lo detectaron, se corrió porque los que estábamos observando la elección desde nuestras respectivas casas –y hay muchos que estábamos esa madrugada siguiendo la elección–, empezamos a ver que había una discordancia total entre la cantidad de electores de las comunas y la cantidad de votos que habían recibido. Gracias a nuestro trabajo conjunto, descubrimos que todo el padrón electoral del distrito Ciudad de Buenos Aires estaba mal cargado en la base que se estaba utilizando para dar los resultados. Y gracias a que lo hicimos público en las redes sociales se corrigió a las 02:00 am del día siguiente. Lo mismo pasaba con la comuna 1, por ejemplo, que es un caso muy lindo. Esa comuna tenía 166.483 electores empadronados a las 21:00; pero a las 02:00 am, 181.207 empadronados. Así que se ve que había habido un proceso de empadronamiento, solo El Cronista Comercial mencionó esta irregularidad al día siguiente sobre la base de lo que habíamos dicho los que estábamos observando. Pero rápido y moderno evidentemente no es para mí lo que vale acá sino los valores fundamentales. Y me voy a referir solo a algunos.

Sobre el secreto del voto y la integridad de las elecciones, les voy a leer lo que dice la patente del sistema MSA, la lectura de la totalidad de los códigos puede hacerse dentro de la urna sin necesidad de tener que abrirla, evitando todo contacto manual con los votos. Se pueden leer todos los votos que están en la urna, también se pueden leer con un simple aplicativo que se demostró que funcionaba voto por voto para poder hacer el sistema de compra de votos. De manera tal que el sistema de votos se puede vulnerar con el sistema de boleta única electrónica, como se vulneró en Holanda que determinó la eliminación del sistema, como se vulneró en Brasil. Y también habría que recordar el discurso de Maduro cuando en Venezuela dijo al día siguiente de una elección, “tengo lista de todos los empleados públicos que votaron en contra del partido”, previo a una purga. La compra de votos no se elimina con este sistema, lo que se hace es utilizar otro sistema para comprar los votos. Es graciosa la norma del proyecto que dice que no se podrá sacar fotos a la boleta, porque están pensando en la boleta papel y no en cómo se puede probar en cómo ha votado una persona para el voto. El clientelismo que el gobierno dice que se elimina con esto tampoco se elimina evidentemente porque sino no habría clientelismo en Venezuela, Salta, en la Ciudad de Buenos Aires o en muchos otros países.

Un último punto, porque todo lo demás ya lo he escrito y publicado y lo pueden buscar en las redes, es que yo confio en que el que va a determinar el sistema electoral de la nación sea el Congreso de la Nación. Entonces, me pregunto si ya han pedido informes sobre el convenio celebrado por el Ministerio de Modernización con una empresa o con el estado coreano para el desarrollo del software y la provisión de las máquinas. Y me pregunto si les mostraron, de hecho es que no les mostraron porque estuve desde esta mañana acá, si les han mostrado el prototipo que ha llegado desde Corea y que el Ministerio de Modernización y el Ministerio del Interior le muestran a determinadas personas. Podrían pedirlo. Y me pregunto finalmente, lo último que me enteré ayer de un funcionario del gobierno que no sabía con quién estaba hablando, si es cierto que el gobierno de Corea ha ofrecido el regalo del software que se va a utilizar. Entonces la pregunta es: ¿privatización, tercerización o extranjerización del sistema electoral? Muchas gracias.

“¿Qué seguridad tiene un votante de estar seguro del secreto?”

Javier Smaldone

Mi nombre es Javier Smaldone, soy programador y administrador de redes de sistemas. No soy especialista en seguridad informática pero sé lo suficiente sobre el tema para sobrevivir en lo que hago. No pertenezco a ninguna entidad, a ningún organismo, ni club de fútbol, ni partido político, así que vengo a hablar acá como un ciudadano común. Por el poco tiempo que tenemos y lo cansados que estamos todos esta altura de la noche, me gustaría poner el foco en una cosa que se ha mencionado, sobre todo en los últimos discursos, pero en gran parte del día se ha pasado por arriba, y es el tema del secreto.

El énfasis siempre ha estado puesto mayormente en lo que es auditabilidad y verificabilidad. Saber que los resultados son correctos, saber que los conteos están bien hechos, tener forma de verificar si ese conteo electrónico coincide con un conteo manual, pero nos olvidamos de una cosa. Está probado que no se puede tener un sistema ni electrónico, ni manual, ni de ningún tipo que permita a la vez garantizar el secreto, la auditabilidad y la verificabilidad. Aquí, en Argentina, tomamos una decisión hace mucho tiempo y pusimos el secreto por delante de todo, fue en el año 1912. Todas las complicaciones que tenemos de cómo diseñamos las boletas, de cómo hacemos el procedimiento para emitir el voto, de cómo escrutamos las mesas y los controles cruzados de escrutinio provisorio y definitivo, vienen de la necesidad de preservar el secreto del voto. Sino no habría este problema, habría otros.

¿Cómo garantizamos el secreto del voto hoy con boletas de papel? Sea con la boleta partidaria en un cuarto oscuro o con la boleta única como usamos en Córdoba y en Santa Fe. ¿Cómo hace el votante para estar seguro de que nadie sabe lo que está votando? Mirando. En el cuarto oscuro mirando que no haya nadie, llevando si quiere la boleta desde su casa guardada en un bolsillo. Él puede asegurarse de que nadie va a saber a quién voto. Hay algunos problemas con eso que ya los voy a detallar. Y con la boleta única de papel también, mirando. ¿Cómo hace el votante para asegurarse de que no se viola el secreto del voto cuando tiene que emitir su voto a través de una computadora? Creyendo lo que dicen en la auditoría. Creyendo, confiando: todo empieza con un acto de fe.

De las auditorías ya han hablado suficiente. Las auditorías nunca son suficientes, en particular en este sistema, en este proyecto de ley que es el sistema del MSA. Se ha probado que pasó por un montón de auditorías que detectaron la posibilidad de meter varios votos en una boleta, que se comieron que en esa carcasa de plástico no había una computadora sino que había dos y la segunda con su software no fueron ni siquiera mencionadas en las auditorías. Incluso la segunda violaba el decreto reglamentario de la ley electoral porque tenía capacidad de almacenamiento permanente. Memoria permanente, suficiente para almacenar todos los votos emitidos en una mesa y ni se nombró. Entonces, las auditorías.

¿Qué seguridad tiene un votante de estar seguro del secreto? Creer o no. Qué piensan ustedes, qué camino tomará aquella persona para la que su trabajo, su plan social, su bolsón, sus $400 dependan de a quién vote. Creer en la auditoría o agachar la cabeza, apretar el botoncito que le dijeron que tiene que apretar y votar cómo lo mandaron a votar. Ya el solo hecho de que el elemento de votación requiera de auditorías lo invalida. No estamos hablando de que el procedimiento de votación permita hacer controles sino que el mismo elemento de votación requiera de una auditoría de una élite que le dice al votante “nadie va a saber cómo votaste”, cuando a lo mejor hay un puntero que le dice “ojo, cómo votás porque vamos a saber”. ¿Será cierto o no? Y después hay otra cosita más que es la violación voluntaria del secreto, la posibilidad de demostrar a quién se voto. Algo que debería estar imposibilitado por el sistema.

Con la boleta única de papel sí hay un problema, lo sufrimos en Córdoba y en Santa Fe y cada elección se tiene que controlar: el tema de las fotos. Es más, en Córdoba en particular, en mi ciudad, Rio Cuarto, se dieron cuenta en la mitad de una elección cuando alguien notó que andaban celulares dando vueltas por todos lados. Ya se había aprobado la reforma, ya se habían diseñado las boletas, ya se había hecho todo y en el medio de una elección los vivos de siempre ya sabían cómo hacerlo. En la auditoría, no nos dimos cuenta de que sacan fotos, le muestran al puntero la foto y les pagan. De ahí en más no se puede sacar foto. Pero cómo evito yo que alguien saque una foto cuando está poniendo cruz en una boleta a través de un tabique así. Mirando con mucho cuidado.

Ahora les voy a mostrar una cosa, espero que se vea la pantalla. Este es un celular, un Samsung S4, medio viejito, no es el último. Tengo una aplicación que funciona así: tengo dos boletas con votos. Supongamos que soy puntero del partido azul. Voy y voto con la boleta única electrónica, elijo las opciones, confirmo y la máquina me entrega esto. Este celular lo tengo en el bolsillo, esto no usa la cámara del celular, esto usa el lector de chips. Y lo que hago es esto, paso el chip cerca del celular, ven cómo cambio, está en amarillo, leyó el voto maestro, leyó este voto. El celular se lo doy a un votante y le digo “ponetelo en el bolsillo y andá a votar. Cuando termines de votar saca la boleta y hacete el que estás leyendo y pasatelo al lado del bolsillo. Si el celular se pone en rojo, no cobrás, pero si el celular me lo traés en verde, cobrás”. Y todo esto sin sacar el celular del bolsillo. ¿Cómo lo evitan? ¿Cacheando votantes? La aplicación no, pero esta metodología la hicimos pública antes del 5 de julio en Capital Federal. Nadie dio bolilla. Después la publicamos para que se vea que es una pavada hacerla, funciona con celulares de $2000. Nada más, muchas gracias.

“La posibilidad de que se deslice un error es muy alta”

Enrique A. Chaparro

Estoy aquí no solo como miembro de la Fundación Vía Libre sino con algunos múltiples sombreros, como casi todos tenemos. Durante los últimos treinta años, mi actividad principal ha sido la seguridad de los sistemas de información. He pasado por algunas universidades y de algunas me he graduado y de otras me han echado. El último sombrero es el de mi condición de ciudadano de a pie. Trataré de combinarlos en los próximos diez minutos señalando algo que dos académicos irlandeses McGaley y Gibson señalaban en el momento en que Irlanda analizaba el paso a un sistema del voto electrónico. McGaley y Gibson decían que ningún sistema electoral es mejor que la confianza que los votantes tienen en él. Esta es una cuestión central porque independientemente de que discutamos meses sobre cuáles son las fallas reales o percibidas de nuestro sistema electoral, lo cierto es que hay una sensación en la ciudadanía de que hay fallas estructurales en el sistema electoral actual.

Ahora bien, una de las soluciones que propone el Poder Ejecutivo para resolver esta cuestión es una serie de cambios en el método de votación. Nosotros nos oponemos ontológicamente al voto electrónico, ¿qué quiere decir? Esencialmente que no conocemos forma en que un sistema de voto electrónico pueda garantizar las condiciones fundamentales que nos impone por ejemplo el artículo 25 del Pacto Internacional de Derechos Civiles y Políticos. Es decir, elecciones genuinas con voto universal e igual protegidas por secreto. Esto se debe no a capricho, no a opinión, sino a cosas que sabemos en el plano de la teoría. Es imposible construir un sistema de voto que al mismo tiempo garantice verificabilidad, secreto e integridad. Eso es un teorema que se llama teorema de Hosp y Vora, resuelto en el año 2009. También sabemos que cualquier proclama de seguridad que hagamos es, en términos de conocimientos científicos, no falsable. Esto que quiere decir, que puedo demostrar que una condición de seguridad es necesaria pero jamás puedo demostrar que es suficiente. Por lo tanto además hay un error conceptual en uno de los ítems del artículo 14 bis propuesto que dice que la máxima seguridad solo existe en el infinito. Nuestra posición ontológica debería ser explicada largamente pero tenemos limitaciones de horario y estamos todos muy cansados.

Entonces, además, desearíamos apuntar algunas cuestiones que están ligadas al proyecto en particular. La justificación del proyecto propone que este sistema sugerido resolvería la cuestión que plantea el Tribunal Supremo Constitucional alemán en su fallo del 2009 302 y 402 del segundo senado del Bundesverfassungsgericht. Esto no es así y permítanme intentar el test por dos vías. En primer lugar, porque si imprimir el voto fuese la solución a la inconstitucionalidad que plantea el Tribunal Supremo Constitucional alemán, supongo que los alemanes no son tan estúpidos como para no haber agregado un pedacito de papel a su sistema. Y en segundo lugar, porque si uno hace un repaso a la doctrina alemana y a todos los comentaristas jurídicos alemanes a partir de ese fallo, van a encontrar mayoritariamente que la doctrina opina que el camino que deja abierto es muy estrecho. Nada autoriza a suponer que una copia impresa garantice que estamos efectivamente en ese camino estrecho. Porque de las copias impresas sabemos a partir de experiencias de otros países, que el porcentaje de lectura es muy bajo, mucho más aún en un sistema cuyo modelo favorito del Ejecutivo es la provincia de Salta y la Ciudad de Buenos Aires, un sistema que no fuerza a leer la copia para obtener el voto, a diferencia de otros que implican apretar un botón por o por no después de haber visto la versión impresa. Y por otro lado por diferencias cognitivas que son típicas de nosotros, los humanos, nos cuesta mucho distinguir aquello que está en pantalla respecto de lo que tenemos en la mano. Yo acabo de escoger la foto en colores de una persona y me presentan en un papel impreso una lista de nombres. La posibilidad de que se deslice un error es muy alta. Los mejores estándares que tenemos de esto dicen que, por lo menos, la mitad de los votantes pasan por alto errores serios de diferencia entre lo que sucedió en pantalla y lo que ha sido mostrado impreso.

Ciertamente los problemas de índole técnica son muchas y hay algunos problemas graves de índole técnica en el proyecto. Por ejemplo, cuando se plantea la auditoría ex post del sistema. Con todo respeto lo digo, me parece que el Ministerio del Interior podría haber invertido una pequeña cantidad de dinero en preguntarle a algún estadístico en cómo se hace una muestra correcta. La muestra del 5% no tiene ninguna relación con lo que se pretenda muestrear. El tamaño de la muestra depende del tamaño de la diferencia. Entonces, con la norma tal como la prevé la ley, en este momento el presidente de la República podría ser otro y el jefe de gobierno podría ser otro y se ajustaría perfectamente a los términos de la ley. Pero además tenemos un problema, nosotros usamos para la asignación de los cargos de los cuerpos colegiados del sistema proporcional D’Hont y entonces cuando repartimos el último cargo la diferencia es muy pequeña. En términos comparativos, la banca 15 para el actual oficialismo o la octava para el principal partido de oposición en la Ciudad de Buenos Aires se definen por 531 votos. Persiste ampliamente en el conteo el error del 5% que plantea la ley y podemos tener casos más extremos.

Otro riesgo que enfrentamos –y que han señalado aquí algunos de los oradores que me precedieron– es el problema de la privatización del sistema electoral. Holanda lo experimentó. Les recomiendo y no quiero ser particularmente aburrido sobre la cuestión, una publicación de Anne Marie Oostveen, quien analizó los efectos de la privatización del sistema holandés. Cuando los holandeses recuperaron la autonomía para manejar las elecciones, no sabían cómo hacerlas porque habían estado en el sector privado durante más de una década. Eso es la sabiduría fundamental de la maquinaria de la democracia. Si no sabemos cómo hacer elecciones, vamos a perderlas todas.

¿Cuánto vale el poder político de un país? No pregunto cuánto cuesta, me pregunto cuánto vale. ¿Cuántas voluntades están dispuestas a sacrificar cualquier cosa por el poder político de un país? Un columnista se preguntaba el otro día en el Washington Post cuánto vale la presidencia de los Estados Unidos. Bien, eso, lo que podamos imaginar que vale el poder político de un país es el presupuesto con el que cuenta el adversario y a grandes presupuestos, grandes ataques. Que no solo debemos pensar en términos del potencial fraude que un sistema electrónico multiplica maravillosamente, porque hay cambio de dos o tres líneas de códigos en un programa se replica en 95.000 mesas electorales del país a una escala que no podemos lograr con los procedimientos manuales. El problema es la pérdida del secreto o la amenaza de la pérdida del secreto y en tercer lugar, el problema del sabotaje.

Siempre estamos pensando que estamos compitiendo entre partidos que quieren llegar al poder por vía legitima y están dispuestos a ceder un poco éticamente para robarse unos votos. Pero ¿qué pasa si lo que yo quiero hacer es sabotear el sistema electoral? ¿Qué pasa si en el medio de la elección tenemos un evento catastrófico tal como un caballo de Troya que pare todas las maquinas de votación a las 00:35? Estamos sin red. El proyecto que plantea el Poder Ejecutivo no tiene ninguna alternativa. Si tenemos un evento catastrófico, tenemos un incendio en términos del sistema político. Suspender una elección. Y esto se logra con tres o cuatro líneas de código que eventualmente insertó un obrero en una factoría china dentro de un chip que está entre los miles de chips de una máquina.

No quisiera ser ave de mal agüero pero mi función desde el punto de vista de la sociedad civil es ser opositor independientemente de quién sea el oficialismo. Finalmente, quiero tomarme este último minuto para dedicarlo a las disonancias que existen en términos de régimen penal que se impone en el proyecto del Ejecutivo. Quiero señalar varias cosas, en primer lugar el que aparezcan tipos penales nuevos significa que el Poder Ejecutivo está evaluando que existen amenazas nuevas respecto de aquello que ya teníamos, porque a uno no se le ocurriría por ejemplo crear una figura penal por derribar aviones con el pensamiento, nadie va a crear un tipo penal relacionado con la tentativa supersticiosa. Entonces, ciertamente, lo que se está persiguiendo es que hay nuevas amenazas que necesitan un nuevo régimen penal y que las que existían siguen existiendo porque si no hubiéramos sustituido el régimen penal existente. Pero, además, quiero señalar que por ejemplo el proyecto se lleva puesto el criterio de proporcionalidad de la ley penal. Les voy a dar dos ejemplos simples. Por el artículo 134, si yo interrumpo a un empleado de correos que lleva un telegrama con los resultados, estoy condenado a una pena de prisión de entre seis meses y dos años. Ahora, si yo lo que hago es interrumpir el cable que comunica el lugar de captación de votos con el lugar de acopio la pena varía entre dos y seis años. Mismo delito, distinta figura dependiendo del medio comisivo. Quisiera señalar que algunos delitos electorales, que son delitos de intención, están planteados en términos más duros que el abuso sexual de personas menores de trece años. Muchas gracias.

Linux Adictos: Los globs te ayudan: cómo borrar todos los ficheros excepto uno
Javier Smaldone

Javier Smaldone
Blog de Javier Smaldone

El elemento de votación y el secreto del voto

Artículo de mi autoría incluido en el libro Voto electrónico, una solución en busca de problemas.

Javier Smaldone

Por estos días en la Argentina se está discutiendo la reforma del sistema electoral. En particular, la del sistema de votación. Casualmente, acaban de cumplirse cien años de la primera elección realizada bajo la llamada Ley Sáenz Peña. Sin embargo, en persecución de una supuesta modernidad, muchos parecen olvidarse del aporte fundamental de esta ley al sistema democrático argentino: la garantía del secreto del voto.

Así se oponía el estanciero, ex ministro del autonomismo y profesor de Derecho Constitucional de la UBA, Carlos Rodríguez Larreta al punto más importante del proyecto de Sáenz Peña:

Si mi peón hubiera tenido la misma acción que yo para resolver los problemas económicos internacionales, o políticos del país, habríamos estado viviendo bajo un régimen absurdo. No ha sido así, gracias a Dios, porque yo he dirigido a mi peón. Pero el voto secreto lo independiza, al privarlo de una influencia saludable y legítima… Y lo malo es que a menudo no tenemos un solo peón sino varios, y que algunos tienen muchos.1

Y, dados los intereses que defendía, razón no le faltaba.

Por otro lado, de esta forma relató las consecuencias de la primera votación en un cuarto oscuro, con voto secreto, el historiador Félix Luna:

Así llega el 7 de abril. Se vota con tranquilidad en todo el país. En la Capital Federal la Unión Nacional compra votos descaradamente. No pocas incidencias ocurren con este motivo. Los comités de la Unión Nacional están atestados de ciudadanos. En uno de ellos don Tomás de Anchorena pregunta uno por uno a los votantes:

–¿Votaste bien, m’hijito…?

–Sí, doctor –era la respuesta obligada.

–Bueno, tomá diez pesos…

En esas condiciones resultó inexplicable para muchos el resultado de la Capital: triunfo radical, minoría socialista… La oligarquía, los círculos oficiales no comprendían que el pueblo porteño, con su escondida picardía, se había dado el gusto de “burlar a los eternos burladores y al mismo tiempo, votar a la novia del corazón: Hipólito Yrigoyen…”, como dice agudamente un escritor antiyrigoyenista.2

Tiempo después, en el Congreso, el presidente Roque Sáenz Peña resumiría magistralmente en una frase los efectos que causó la instauración del secreto del voto:

Si hubo votos pagados, no hubo votos vendidos.3

Estancieros modernos

Desde las elecciones provinciales y nacionales de 2015, se han difundido numerosos informes periodísticos sobre el accionar de la versión moderna de don Tomás de Anchorena y sus esbirros: flotas de automóviles de alquiler –incluso motocicletas– usados como transporte de votantes, quienes reciben bolsones de alimentos, dinero en efectivo y hasta viviendas a cambio de “votar bien”. El llamado “clientelismo político” sigue estando, un siglo después, a la orden del día.

Pero, ¿por qué funciona? Porque cuando el sistema de votación era novedoso desconcertó a quienes querían cometer fraude, pero con el paso del tiempo estos fueron “tomándole la mano”. Lo mismo ocurre con cualquier sistema: cuando es puesto en funcionamiento, salvo fallas evidentes, todo marcha bien. Pero luego van apareciendo formas de explotar sus vulnerabilidades o de trampearlo. Y al sistema actual de votación se le han encontrado varias.

“Tomá esta boleta. Es la que tenés que poner en el sobre. Tiene una marquita aquí, ¿la ves?”. “Nuestro fiscal va a firmar tu sobre de forma en que podamos saber a quién votaste. Más te vale que cumplas con el trato”. Frases como estas son pronunciadas por los “punteros políticos” –delegados de la versión moderna de aquel estanciero– a los votantes al entregar el dinero en efectivo, el bolsón, o el plan social.

¿Podrá el fiscal identificar la boleta con la supuesta marca entre más de 200 que habrá en la urna? ¿Será cierto que tiene una forma de “firma codificada” para saber a qué votante pertenece cada sobre? Posiblemente no, pero… ¿estará dispuesto quien recibió un pago por su voto a correr el riesgo de traicionar al puntero? ¿O el voto comprado se transformará, ante la duda y el temor, en voto vendido? Dados los ingentes recursos que se destinan a estas maniobras, todo parece indicar que esto último es lo que en efecto sucede. La coerción resulta efectiva.

La garantía del secreto

Para que el secreto del voto ocasione el efecto deseado –nada menos que la libertad de elegir– es el votante quien debe estar seguro de su garantía. Y el sistema debe permitírselo. Si quien es presionado no puede asegurarse por sus propios medios de que nadie puede saber cómo votó, la presión surtirá efecto. En esto, el sistema electoral es como la esposa de Julio César: “Además de ser honesta, debe parecerlo”.

La reforma electoral impulsada desde el gobierno actual –y que cuenta con el apoyo mayoritario de fuerzas políticas y el público en general– introduce un nuevo elemento entre el votante y la expresión de su voluntad: un sistema informático. El procedimiento de emisión del voto parece bastante robusto desde el punto de vista de asegurar que el escrutinio reflejará la selección realizada por el ciudadano frente a la computadora. La máquina permite seleccionar los candidatos en la pantalla, y luego imprime voto en una boleta de papel, y lo almacena en un chip de identificación por radiofrecuencia (RFID) contenido en la misma. El votante tiene la posibilidad de leer lo impreso, y hasta de ver lo que está grabado –en realidad, lo que la máquina le dice que está grabado– en el circuito electrónico embutido en el papel. Luego, en el escrutinio, los votos deberán contarse para poder verificar que lo impreso coincida con lo almacenado digitalmente. Ante la discrepancia o la duda deberá prevalecer lo escrito en el papel (en una instancia posterior, ya que el resultado de la mesa se basará no en lo que sus integrantes puedan leer, sino en lo que la computadora pueda contar).

Más allá de las particularidades técnicas de este sistema propuesto llamado “boleta única electrónica” –del cual existe solo una implementación en el mundo, perteneciente a una empresa privada–, ¿cómo puede el votante estar seguro de que su voto es secreto, cuando debe emitirlo mediante una computadora? La respuesta corta es: no puede.

Y aquí de nada sirven las auditorías (menuda tarea, si acaso posible, para un sistema de tal complejidad). El solo hecho de que el medio de votación requiera de auditorías especializadas demuestra que el mismo no puede ser controlado por el votante, y esto debería disparar todas las alarmas. No se trata de si un grupo de personas con los conocimientos técnicos y los recursos apropiados puede –dado un tiempo razonable– asegurarse de que el sistema garantiza el secreto. Se trata de que el votante, parado frente a una computadora, pueda estar seguro de que la amenaza del puntero –“votá bien, porque tenemos las computadoras tocadas y vamos a saber a quién votaste”– no tiene asidero. Lamentablemente, esa seguridad del votante no es posible.

¿Cómo puede violarse el secreto mediante una computadora de votación? Las formas son variadas y sorprendentes. Desde la decodificación de emisiones electromagnéticas4 (técnica conocida como interferencia de Van Eck),5 hasta la utilización de componentes no previstos ni auditados6 que permitan almacenar el orden y la composición de cada voto. Y en el caso de usar chips como el de la “boleta única electrónica”, existe incluso la posibilidad de leer el contenido de la boleta desde cierta distancia.7 Ni qué decir de las nuevas formas en que se puede obligar a un votante a demostrar si “votó bien”, algunas tan simples como la utilización de un celular oculto.8

Puede argüirse –en un ejercicio de ingenuidad– que estas prácticas son demasiado complejas o rebuscadas. Ante cada posibilidad de vulnerar el secreto puede ofrecerse una solución a modo de paliativo. Pero el hecho es que el ciudadano común (y aun el experto en informática) no podrá, parado frente a una computadora en el momento de elegir a sus representantes, saber a ciencia cierta que nadie lo está espiando a través de ese sistema.

Fácil y rápido, como antes de 1912

Antes de la Ley Sáenz Peña, votar era muy simple. No había discusiones sobre boletas, sobres, ni máquinas de ningún tipo. Los ciudadanos desfilaban ante la mesa, expresaban su voluntad de viva voz y las autoridades de la misma tomaban nota (en 1873, se cambió el voto oral por el escrito, pero seguía siendo público). Los resultados estaban disponibles ni bien finalizaba el comicio, sin demoras. Y nadie podía sospechar que se había cambiado su voto, ya que todo estaba a la vista. Pero llegó el secreto, y cambió de raíz el sistema de votación.

Estamos a más de cien años de ese cambio, y celebramos que gracias a él pudimos finalmente tener elecciones libres y justas, aun tolerando ciertas demoras en conocer los resultados. Y también, sabemos que es posible que algunos votos sean adulterados, pero también podemos buscar la forma de mejorar el sistema (y la fiscalización) para minimizar esos casos.

Hoy se nos propone votar usando computadoras. Con la promesa de tener resultados provisorios más rápidamente, con la esperanza de que sea más difícil adulterar el resultado de la votación (esperanza que muchas veces radica en una forma de pensamiento mágico).9 A cambio, la posibilidad del votante de cerciorarse de que su voto es secreto se ve severamente comprometida. ¿Puede alguien que esté bajo presión correr el riesgo de creer en la palabra autorizada de un grupo de auditores que le asegura que todo se hace correctamente? ¿Debe un ciudadano confiar en una élite al realizar el acto vital y primigenio de una democracia republicana? Claramente, no.

Sobre cómo mejorar el sistema

El sistema actual tiene problemas, eso es evidente. Pero en la búsqueda de la solución, no debe debilitarse el pilar del secreto del voto. ¿Hay robo de boletas o boletas falsas en el cuarto oscuro? Usemos boletas únicas –como la mayoría de los países del mundo–, papeles con grillas donde aparezcan todas las opciones, que sean retiradas de la mesa de votación por el votante (lo que también elimina el “voto cadena”). ¿Alguien duda sobre la posibilidad de boletas marcadas? Que la boleta única sea retirada por el ciudadano de una pila colocada al lado del presidente de mesa, eligiendo la que más le plazca. ¿Se adulteran boletas en el escrutinio? Pensemos en medidas de seguridad para evitarlo (no, ninguna funcionará sin fiscalización, por más que usemos los sistemas electrónicos más rebuscados). ¿Las actas confeccionadas manualmente tienen errores o resultan ilegibles? Usemos sistemas de impresión dispuestos en los centros de votación. ¿El escrutinio provisorio parece una “caja negra” en donde pueden alterarse los resultados? Usemos los medios que proveen la informática y las telecomunicaciones para abrirlo a la ciudadanía, de modo que todos podamos controlar, desalentando por lo tanto las manipulaciones.

En la mejora del sistema de votación, debemos buscar más transparencia. Debemos dar más control al votante sobre su voto, y no menos. Interponer entre el votante y su voluntad un elemento tan opaco (u oscuro) como una computadora va exactamente en el sentido opuesto: no ofrece transparencia, necesita auditorías; no brinda confianza, la requiere.

La experiencia mundial así lo evidencia: el uso de computadoras para emitir el voto, luego de más de cuatro décadas de investigación, desarrollo y pruebas, está en franco retroceso en la inmensa mayoría de los países. Actualmente, solo en Brasil, Venezuela, India y la mitad de Bélgica se vota usando computadoras. En los EE. UU., pionero mundial del uso de máquinas –inicialmente mecánicas, luego electrónicas– para votar, cada vez son más los estados que se vuelcan al uso de boletas de papel. En 2010, Israel descartó el uso de un sistema muy similar al de la “boleta única electrónica”. Finalmente, en el caso extremo de países como Alemania, los Países Bajos, Irlanda y el Reino Unido, después de probar en mayor o menor grado alternativas de este tipo, erradicaron completamente las máquinas.

Es particularmente esclarecedor el fallo de 2009 de la Corte Constitucional de Alemania, que declaró inconstitucional el uso de computadoras para votar (el énfasis es agregado):

1. El principio de la publicidad de la elección del artículo 38 en relación con el art. 20 párrafo 1 y párrafo 2 ordena que todos los pasos esenciales de la elección están sujetos al control público, en la medida en que otros intereses constitucionales no justifiquen una excepción.

2. En la utilización de aparatos electorales electrónicos, el ciudadano debe poder controlar los pasos esenciales del acto electoral y la determinación del resultado de manera fiable y sin conocimientos técnicos especiales.10

La garantía del secreto del voto es esencial. Es vital fortalecerla, para seguir preservando la máxima de Sáenz Peña, y que un voto comprado no pueda transformarse en un voto vendido, si el votante así lo dispone.

Notas

1 Sampay, Arturo, “Constitución y pueblo”, Buenos Aires, Cuenca ediciones, 1974.

2 Luna, Félix, “Yrigoyen”, Buenos Aires, Sudamericana, 1999.

3 Ibíd.

4 Este video ilustra cómo funciona dicha decodificación: https://www.youtube.com/watch?v=hwz1BLRgTg0

5 Más información sobre esta técnica en https://es.wikipedia.org/wiki/Interferencia_de_Van_Eck

6 “El sistema oculto en las máquinas Vot.ar”, 15/07/2015, https://blog.smaldone.com.ar/2015/07/15/el-sistema-oculto-en-las-maquinas-de-vot-ar/

7 “Sobre el chip RFID de la ‘boleta única electrónica’”, 08/01/2016, https://blog.smaldone.com.ar/2016/01/08/sobre-el-chip-rfid-de-la-boleta-unica-electronica/

8 “Comprando votos con la boleta única electrónica”, 03/09/2015, https://blog.smaldone.com.ar/2015/09/03/comprando-votos-con-la-boleta-unica-electronica/

9 “Magia electrónica”, 01/08/2015, https://blog.smaldone.com.ar/2015/08/01/magia-electronica/

10 Sentencia 2 BVC 3/07 – 2 BVC 4/07, Corte Constitucional Alemana (traducción de Manfredo Koessl).

Domingo 26 de marzo de 2017

Linux Adictos: Cómo proteger el borrado accidental de archivos en Linux
Javier Smaldone

Javier Smaldone
Blog de Javier Smaldone

¿Qué es el voto electrónico?

Artículo de Beatriz Busaniche y Federico Heinz incluido en el libro Voto electrónico, una solución en busca de problemas.

Beatriz Busaniche y Federico Heinz

Existen varias definiciones para lo que se denomina comúnmente como “voto electrónico”. En un sentido amplio, se considera voto electrónico a la incorporación de recursos informáticos en cualquier parte del proceso electoral, ya sea en el registro de ciudadanos, la confección de mapas de distrito, la logística electoral, el ejercicio del voto en sí mismo, el escrutinio y la transmisión de resultados. Sin embargo, en esta introducción, vamos a considerar estrictamente dos de las áreas del sufragio: la emisión del voto en sí misma y el recuento de votos.

En un sentido estricto denominaremos voto electrónico a los mecanismos diseñados para emitir y contar los sufragios en un único acto, a través de algún sistema informático instalado y en funcionamiento en el lugar mismo donde el elector concurre a expresar su voluntad política. Entonces, entendemos por voto electrónico a todo sistema informatizado para el acto de emitir y contar los votos en la mesa de votación, donde los ciudadanos y las ciudadanas entran en contacto directo con los dispositivos electrónicos. Consideramos el uso de computadoras, urnas electrónicas o dispositivos similares para la emisión y recuento automatizado del sufragio. Los mecanismos en los que la computadora no está directamente involucrada en el acto de emisión del voto, así como aquellos que utilizan la informática exclusivamente para la automatización del recuento y la consolidación de resultados quedan así expresamente fuera de nuestra atención.

No existe una única forma de implementar voto electrónico, más bien podríamos decir que existen tres grandes tipos de sistemas a utilizar, que difieren no solo en su implementación, sino y fundamentalmente en sus riesgos y beneficios. Los mecanismos más frecuentemente identificados se pueden agrupar en tres grandes conjuntos:

a) los sistemas de recuento automático de votos mediante reconocimiento óptico de las marcas hechas en la boleta por parte de los ciudadanos (sistemas que hacen hincapié en el escrutinio electrónico);

b) los sistemas de registro electrónico directo (red, o dre por su sigla en inglés) ejemplificados comúnmente con los denominados kioscos de votación o urnas electrónicas;

c) los sistemas de votación a distancia a través de Internet.1

Sistemas usados

a. Sistemas de recuento automático

Los primeros sistemas de esta clase datan del siglo xix, cuando se comenzaron a implementar en la ciudad de Nueva York mediante tarjetas perforadas. Actualmente, la mayoría de los sistemas de este tipo se basan en el reconocimiento óptico de marcas hechas por el votante sobre la boleta, ya sea de forma directa o a través de una máquina de marcar boletas. Entre los años 1994 y 2003, por ejemplo, Venezuela utilizó sistemas de este tipo, basados en boletas impresas en papel con un espacio rellenado por el elector y posteriormente contabilizados mediante un sistema de reconocimiento óptico de caracteres.

En principio, los sistemas de recuento automático resuelven el problema más álgido de la incorporación de tecnología al sufragio: al mantener el principio de que la voluntad del elector se expresa en un trozo de papel anónimo, desacopla el acto de emisión de voto (que debe ser inauditable) del acto de escrutinio (que debe ser auditable en todos sus detalles). De esta manera es posible construir un sistema en el cual todos los resultados en los que la informática está involucrada pueden ser auditados independientemente de los dispositivos usados y el software en sí, mediante el simple recurso de realizar un recuento manual.

Aun así, la aplicabilidad de estos mecanismos no puede tomarse en forma aislada, sino en el contexto del sistema completo del cual forman parte. Es posible realizar muchas decisiones respecto del sistema como un todo que pueden anular total o parcialmente las ventajas del mecanismo.

Un elemento que no puede faltar en la aplicación de sistemas de recuento automático es la auditoría manual de los resultados arrojados por una porción estadísticamente significativa de las máquinas usadas, seleccionadas al azar luego del acto eleccionario. De lo contrario, una programación maliciosa del software de tabulación de votos podría alterar los resultados sin ser detectada.

Estos sistemas pierden una porción importante de sus ventajas cuando la boleta no es marcada a mano por el elector. Las máquinas de marcar boletas vuelven a introducir en el sistema muchos de los problemas asociados con las máquinas de registro directo. Si bien permiten que el votante verifique que las marcas en la boleta se correspondan con sus elecciones, suponen un doble trabajo para el votante (elegir por un lado, controlar por otro), lo que aumenta la probabilidad de que el elector no realice concienzudamente el control. Esto hace factible el mismo ataque que se puede hacer en las máquinas de red: introducir código que intente adulterar la intención del votante, pero abandonar el intento si el votante rechaza la boleta. De esta manera se pueden secuestrar los votos de todos aquellos ciudadanos que no sean lo suficientemente cuidadosos. También se pone en riesgo el anonimato del voto, toda vez que la máquina de marcar boletas podría agregar, además de las manchas legítimas, algunas que pasen por “suciedad” pero que, en realidad, codifiquen información que permita reconstruir la secuencia de emisión de los votos.

Otro mecanismo que reduce la utilidad de estos dispositivos es el de pasar la boleta por el escáner antes de introducirla en la urna, en vez de hacerlo al abrir esta. Esto no solo aumenta los costos –requiere un escáner por mesa, mientras que de otro modo puede utilizarse el mismo escáner para varias de ellas–, sino que potencialmente permite registrar la secuencia en la que se emitieron los votos, y así reconstruir la relación de cada votante con su voto.

Una crítica común a este tipo de mecanismo señala la dificultad que presentan en el caso de elecciones complejas, en particular cuando se realiza una elección para múltiples cargos en múltiples niveles de distrito. En una elección en la cual, por ejemplo, se deba elegir concejales de la ciudad, intendente, legisladores provinciales, legisladores nacionales, gobernadores y presidente, la magnitud de la boleta dificulta al votante el marcado de todas las opciones, así como su posterior lectura detallada. Sin embargo, esto es más una crítica de las elecciones complejas que del sistema de recuento automático en sí: mientras más compleja es una elección, más difícil es votar en ella y contar los votos. La “solución” a este problema ofrecida por los sistemas red consiste, básicamente, en barrerlo bajo la alfombra: como en ellos es imposible contar a mano los votos, disfrazan el vicio de virtud declarando que es una tarea “innecesaria”.

Otra crítica común a estos mecanismos, e igualmente inmerecida, es la que objeta la facilidad con la que se puede alterar o anular un voto mediante el agregado de marcas por parte de quienes realizan el escrutinio. Si bien la factibilidad del ataque es real, es exactamente la misma que con cualquier sistema basado en papel, que a su vez es mejor que la de cualquier sistema completamente electrónico: mientras que las boletas pueden ser alteradas, esto debe ser hecho individualmente con cada boleta, y el impacto de una persona corrupta se circunscribe a las boletas bajo su custodia. En el sistema electrónico, en cambio, una única persona corrupta tiene el potencial de infectar un gran número de máquinas, comprometiendo de esa manera incluso la integridad de votos en masa, incluyendo los de mesas cuyos fiscales actúen de buena fe.

b. Sistemas de registro electrónico directo (red)

Los sistemas red o dre son aquellos que más se corresponden con el imaginario popular de las “urnas electrónicas”. Representan, además, el modelo preferido de la mayoría de las empresas que participan de este mercado. Las urnas electrónicas usadas en Brasil, así como en varios estados de EE. UU. o en las últimas elecciones de Venezuela pertenecen a esta clase.

Los sistemas red se caracterizan por realizar simultáneamente el registro y la tabulación del voto mediante un dispositivo informático, operado directamente por el votante mediante un teclado, una botonera especial, o una pantalla táctil. Además, algunos sistemas de red ofrecen ayuda para personas con algún tipo de discapacidad, por ejemplo mediante una interfaz de audio para superar las dificultades visuales. A diferencia de los sistemas de recuento automático, en los que el soporte fundamental del voto es la boleta marcada por el ciudadano, en las máquinas red el registro se realiza directamente en la memoria del dispositivo.

Muchos proveedores de equipamiento señalan como una ventaja del sistema el hecho de que permite “independizar del papel” a la elección. Por lo general, recomiendan no usar la opción ofrecida por algunos modelos de máquinas red de usar impresoras similares a las que funcionan dentro de las cajas registradoras para generar una cinta de auditoría, argumentando que “desnaturaliza el voto electrónico”. En todo caso, las máquinas red no usan el papel emitido para sus resultados, sino que se basan enteramente en los registros presentes en su memoria.

Los sistemas red pueden configurarse de tal modo que permitan al usuario corregir sus opciones y hasta votar en blanco, pero no permiten invalidar el voto ni cometer errores clásicos que resultan en la anulación del voto.

Por otro lado, estos sistemas suelen ser también los preferidos por aquellos que trabajan en las elecciones, porque son los que más trabajo ahorran: no hay boletas que custodiar, el recuento de votos es inmediato, y no hay riesgo de que un nuevo recuento de votos arroje una diferencia con el anterior. La máquina obtendrá siempre el mismo resultado independientemente de si este refleja la voluntad de aquellos que la usaron para votar o no.

En esta preferencia, se hace evidente un punto de tensión entre los intereses de los ciudadanos (que necesitan que el resultado refleje sus elecciones) y los de quienes están encargados de conducirlo (que desean terminar la tarea con la mayor rapidez y el menor esfuerzo posible, descargando tanta responsabilidad como se pueda por eventuales errores o actos de corrupción).

c. Sistemas de votación a través de Internet

También conocidos como sistemas de votación a distancia, se trata de mecanismos para emitir el sufragio desde una computadora común conectada a la red de redes, permitiendo que los sufragantes emitan su voluntad desde sus propios domicilios, desde puntos públicos de acceso, e incluso desde el extranjero. Existen variantes de estos sistemas que permiten emitir el voto no solo desde una computadora personal, sino eventualmente también desde un teléfono celular o un sistema de televisión digital.

Uno de los desafíos más graves que enfrenta este tipo de sistemas es la identificación del votante, imprescindible para asegurar varias propiedades importantes del mecanismo, tales como evitar que alguien vote más de una vez o en nombre de otra persona, o que voten personas que no están habilitadas para hacerlo. Este problema suele resolverse mediante una clave unívoca y personal, que puede incluir elementos físicos de autenticación tales como la posesión de una tarjeta de identificación criptográfica o un generador de claves pseudoaleatorias.

Aun con los métodos de autenticación más sofisticados, no queda claro que sea posible reconciliarlos con los requerimientos de identificación exigidos por la ley, que por lo general requieren la verificación de documentos de identidad por parte de autoridades electorales. Un problema adicional asociado al de la identificación es que estos sistemas obligan a que la máquina que recibe el voto tenga conocimiento de quién lo está emitiendo. Esto ofrece un punto único de ataque para quien quiera violar el secreto del voto: basta con obtener la información almacenada en el servidor del sistema de votos para averiguar cómo votó cada persona que lo usó.

Los defensores de estos sistemas señalan que se prestan a ser usados en lugares en los que la participación en las elec- ciones no es obligatoria y está permitido votar por correo. El argumento es sólido, en el sentido de que es un sistema que puede ser usado en contextos en los que la experiencia muestra que el riesgo de fraude es bajo.

Es interesante señalar que hay experiencias exitosas de uso de votación a distancia en ciertos ámbitos específicos, en particular en aquellos en los que los participantes tienen un grado alto de familiaridad y acceso a recursos informáticos y está ausente la exigencia de anonimato. El proyecto Debian, por ejemplo, un proyecto comunitario de desarrollo de software integrado por personas de todo el mundo que no tienen oportunidad de encontrarse físicamente para votar, utiliza voto a distancia como una herramienta cotidiana, con excelentes resultados. El sistema es robusto, justo y difícil de engañar, pero solo funciona gracias al hecho de que el voto no es secreto.

Principales problemas detectados en los sistemas de voto electrónico

Estos sistemas suelen venir de la mano de contundentes afirmaciones acerca de sus virtudes, tales como una mayor transparencia del acto electoral, la eliminación del clientelismo político, la rapidez e infalibilidad del conteo, el menor costo de cada elección, y la mayor participación ciudadana.

Lamentablemente, estas afirmaciones categóricas no vienen acompañadas de datos sólidos que las sustenten, y algunas empresas proveedoras invierten un esfuerzo nada despreciable en evitar que sean verificadas por terceras partes independientes, como fue el caso de Sequoia Systems en 2008, que intentó impedir una auditoría independiente de seguridad encomendada por el estado de Nueva Jersey argumentando que llevarla a cabo violaría los términos de uso del software que controla las urnas.

De hecho, ninguna de esas afirmaciones soporta un análisis profundo y, si bien algunas de ellas pueden ser ciertas para algunos casos particulares, la experiencia internacional demuestra que en la realidad están muy lejos de reflejar el verdadero desempeño de las urnas electrónicas. Detengámonos, entonces, en estas afirmaciones categóricas alrededor del voto electrónico.

1. La transparencia

La afirmación de que las urnas electrónicas aportan a la transparencia del comicio es, probablemente, la más aventurada. Es difícil comprender cómo un proceso opaco se haría más transparente mediante el recurso de agregar una “caja negra”. Lejos de aportar a la transparencia, la urna electrónica obstaculiza la capacidad de la mayoría de los ciudadanos de fiscalizar la elección.

Cualquier persona sabe cómo verificar, con solo mirar, que una urna está vacía o que un precinto de seguridad está intacto, y el sistema educativo apunta a garantizar que todas las personas sepan leer, escribir y contar. Pero estas habilidades son inútiles a la hora de ver qué pasa “dentro” de una urna electrónica: la inspección ocular no sirve para ver si está vacía sino que es necesario usar un programa diseñado a tal fin, que imprima un ticket que diga “sí, estoy vacía”. La pregunta es: ¿Podemos creerle?

Cuando la urna imprime los resultados, los obtiene de operar sobre sus registros internos, almacenados en medios magnéticos que los fiscales no pueden leer por sus propios medios. La única “comprobación” posible de que la urna está efectivamente vacía, o de que los totales son correctos, es repetir la operación, la que previsiblemente dará siempre el mismo resultado. Aun si confiáramos en que el programa de la urna es correcto, el fiscal promedio carece de los conocimientos y las herramientas necesarios para comprobar si el programa que está instalado en la urna ha sido adulterado o no.

Incluso un fiscal con grandes conocimientos de programación y electrónica digital, provisto de herramientas especializadas, probablemente demoraría días en verificar con algún grado de confianza que la urna está efectivamente “en cero”, mientras que hacerlo con el mismo grado de confianza con el que puede hacerse inspeccionando el interior de una urna de cartón es efectivamente impracticable. Se trata de un problema de la misma complejidad que la construcción de programas de computadora libres de errores, algo que el estado del arte aún no nos permite. Para peor, las acciones que debería realizar este hipotético auditor especializado son mucho más invasivas que las necesarias para adulterar el funcionamiento de la urna, de modo que, suponiendo que nos diga que la urna está “limpia”, no solo no va a poder demostrárselo a alguien que no esté similarmente especializado, sino que no tenemos manera de saber si lo que hizo, en realidad, fue verificarla o subvertirla.

Este es un problema fundamental de las urnas electrónicas: mientras la verificación de su confiabilidad dependa exclusivamente de comprobar que “funciona bien”, la tarea de su fiscalización queda necesariamente en manos de una élite tecnológica, a la que el resto de la población no tiene más remedio que creerle. Para corromper la fiscalización de una elección basada en papel, es necesario contar con fiscales corruptos en un número importante de mesas, pero en el caso de las urnas electrónicas basta con sobornar o extorsionar a un grupo pequeño de personas fácilmente identificables.

Estas dificultades a menudo son desestimadas, argumentando que se pueden realizar elecciones de prueba controladas para ver cómo se comporta la urna, y señalando que estas urnas se han usado en muchos lugares sin problemas. Lamentablemente, este argumento ignora el hecho de que es muy sencillo programar la máquina de modo que no se comporte de la misma manera durante las pruebas que durante la elección, y que la experiencia demuestra que en la mayoría de las elecciones, la necesidad de actualizar el software (ya sea el mismo software de la urna o su sistema operativo) lleva a que el programa que corre durante la elección pueda no ser el mismo que se usó durante las pruebas.

Por lo demás, la afirmación de que estas urnas han sido usadas sin problemas es harto aventurada: no sabemos si hubo problemas o no, precisamente porque la opacidad del mecanismo no nos permite comprobarlo adecuadamente. Es perfectamente posible que en esas elecciones haya habido problemas masivos, sin que nadie haya podido probarlo y ese es precisamente el escenario que las urnas electrónicas facilitan. De hecho, hay elecciones como las de EE. UU. en 2004, en las que las diferencias entre las encuestas en boca de urna y los resultados finales sugieren fuertemente que las urnas dieron resultados incorrectos.

2. El fin del clientelismo

El clientelismo político es un problema social, económico y educativo que no se soluciona con tecnología. Para que la “compra de votos” funcione, es necesario contar con un mecanismo que permita al comprador un grado importante de confianza en que el votante efectivamente votará por el candidato al que prometió votar. En las elecciones en papel, esto puede hacerse a través del denominado “voto en cadena”, mecanismo que algunos sistemas de voto electrónico hacen efectivamente imposible.

Sin embargo, pensar que el voto en cadena y el clientelismo son lo mismo es un error: el voto en cadena es solo un mecanismo para romper el secreto del voto. No es el único, y las urnas electrónicas ofrecen mecanismos alternativos potencialmente mucho más eficaces. Esto se debe a la naturaleza fundamentalmente distinta de las urnas electrónicas. Por ejemplo, mientras que las urnas normales son contenedores pasivos de información, los circuitos de la urna electrónica emiten radiación electromagnética. Experimentos realizados en Holanda demostraron que estas emisiones hacían posible detectar por quién votaba una persona desde una distancia de 25 metros, usando solo dispositivos disponibles comercialmente.

Por ejemplo, en el estado de Ohio se descubrió, dos años después de usarlas, una grave falencia en las urnas electrónicas que permite violar el secreto del voto luego de los comicios: los reportes emitidos por la urna al final del recuento permiten reconstruir el vínculo entre voto y votante. Este caso es particularmente grave, porque ilustra un aspecto a menudo ignorado del cálculo de riesgo a la hora de usar una urna electrónica: el hecho de que no conozcamos vulnerabilidades en la urna no quiere decir que no existan, ni que nadie las conozca. Alguien que estuviera en conocimiento de esta vulnerabilidad hubiera podido organizar una compra o extorsión masiva de votos que hubiera sido indetectable y requerido un esfuerzo logístico mucho menor que el voto en cadena.

3. La rapidez en el conteo

Una de las escasas ventajas promocionadas que podría ser verificable es la rapidez en el conteo. De hecho, cuando todo sale bien, los resultados pueden ser inmediatos. El problema surge cuando evaluamos el impacto potencial de las distintas cosas que pueden salir mal. Mientras que en la urna de papel, la influencia de un inconveniente es por lo general proporcional a la magnitud de este, en las urnas electrónicas un problema muy pequeño puede tener consecuencias muy graves. Esto lleva a que si los resultados de la urna electrónica no son inmediatos, por lo general no se los puede obtener nunca. Por lo general, no hay un punto medio.

El 16 de diciembre de 2007, por ejemplo, se utilizaron cuatro urnas electrónicas de la firma Altec Sociedad del Estado (Río Negro) en la localidad de Las Grutas, en Argentina. Transcurrida la jornada electoral, una de esas urnas arrojó un resultado sorprendente: 0 votos. Fue afortunado que, en este caso, las urnas hayan llevado registro en papel, porque el registro digital se había perdido completamente, pero aun así el escrutinio demoró horas, porque los votos impresos sobre una tira de papel eran mucho más difíciles de identificar que las boletas originales. La única explicación de la empresa proveedora de la urna fue que “alguien debe haber sacudido la urna”.

De la misma manera, existen casos en los que una falla técnica en una urna electrónica produjo que la urna contara miles de votos en mesas en las que votaban solo cientos de personas, o el caso de Nueva Jersey, en el que los resultados fueron inmediatos, pero el total de votos emitidos no coincidía con la suma de los votos emitidos por partido. ¿Puede decirse que ese resultado es inmediato, cuando en realidad es evidentemente incorrecto?

La rapidez, sin confianza ni seguridad, no sirve para mucho en un proceso electoral. Esta es un área en la que la eficacia (hacerlo bien) debe primar por sobre la eficiencia (hacerlo rápido).

4. La economía

La idea de que usar urnas electrónicas permite economizar dinero en los comicios ha sido refutada por auditores independientes que la pusieron a prueba. En el estado de Maryland, por ejemplo, entre 2002 y 2003 se compraron 19 mil máquinas de pantalla táctil a la firma Diebold. Para poder concretar la compra, el Estado tomó un crédito de 67 millones de dólares, 44 de los cuales fueron a las arcas de la empresa en concepto de compra y mantenimiento de las urnas. Antes de incorporar estos dispositivos, Maryland usaba un sistema de escaneo óptico.

Según el informe de la organización Save Our Votes, publicado en febrero de 2008,2 el cambio de tecnologías implicó un aumento promedio de 179% en el costo total por votante. En uno de los condados, el aumento fue de 866%. Por cierto, las máquinas de Diebold aún no se terminaron de pagar y ya deben ser renovadas. El estado de Maryland está considerando volver al sistema de escaneo óptico.

5. La participación ciudadana

Un tema crítico a la hora de evaluar la implementación de voto electrónico es la participación ciudadana. Nuestras democracias modernas están golpeadas por el descrédito de las clases dirigentes y la falta de confianza en los sistemas políticos. El halo de modernidad que otorga el voto electrónico parece ser la panacea para entusiasmar a los votantes y alentar la participación en los comicios.

Sin embargo, es importante destacar que la incorporación de urnas electrónicas tiene efectos claramente contrarios al objetivo de mejorar la participación ciudadana. Sin ir más lejos, las personas poco afines con los sistemas computacionales serán los primeros excluidos: adultos mayores o personas de escasos recursos, personas con dificultades visuales o con bajísimo nivel educativo que hoy día no requieren mayor preparación para elegir una boleta, ponerla en una urna y emitir su voluntad política, se verán enfrentados a un sistema mucho más complejo para votar.

Pero este no es el único inconveniente. Quizás el mayor problema es que aquellos que hoy auditan las elecciones en nuestro nombre (maestras de escuela, empleados públicos, fiscales de partidos políticos) se verán incapaces de auditar eficazmente un sistema de esta naturaleza. Solo personas altamente calificadas en ingeniería de software, electrónica y hardware podrán comprender el funcionamiento de estos sistemas. Incluso personal calificado en seguridad de sistemas de información se manifiesta incapaz de evaluar, validar y corroborar el funcionamiento correcto de urnas electrónicas. Estos mismos expertos difícilmente se atrevan a firmar a conciencia una certificación de seguridad de las urnas pues no existe método formal de validación que los avale.

Así, la participación real y tangible de la ciudadanía se verá reducida a la confianza ciega en un pequeño número de fiscales informáticos que, aun teniendo amplios conocimientos de la materia, no podrán certificar la validez de un resultado en el que todos los demás tendremos que confiar. Aquellos que tenemos la voluntad política de ejercer nuestro derecho a auditar nos veremos limitados por carecer de conocimientos técnicos, y tendremos que dejar la participación real a una pequeña élite de técnicos autorizados.

Si bien no existen sistemas perfectos, la diferencia de impacto es sustancial. Una mesa de votación tradicional puede registrar inconvenientes y ser anulada. El impacto sobre los resultados globales será mínimo. Sin embargo, un error mínimo en un sistema de votación electrónica puede alterar el resultado de una elección simultáneamente en un
gran número de mesas.

6. Otros problemas generales

A todo esto vale agregar que, en la gran mayoría de los casos, los proveedores de urnas electrónicas son empresas privadas cuya composición accionaria deberíamos conocer en detalle antes de confiarles un proceso público y ciudadano como es la emisión del voto. ¿Cuáles serán los mecanismos para auditar a las empresas proveedoras? ¿Cómo sabremos cuáles son sus vinculaciones políticas y sus intereses en cada elección? ¿Estamos dispuestos a privatizar un proceso ciudadano como el acto de votar?

Estas preguntas surgen a la luz de escándalos ocurridos en los EE. UU. donde, por ejemplo, uno de los principales accionistas de una de las empresas proveedoras de urnas (ES&S) resultó ser un senador republicano con obvios y
marcados intereses en el resultado electoral.3

No son pocos los inconvenientes que aparecen a la hora de evaluar la automatización de la emisión del voto. Sin embargo, es muy poco lo que se discute y ciertamente escaso el conocimiento sobre los mismos. El acto de votar es lo suficientemente importante como para que nos ocupemos de este tema, y nos preocupemos frente a incorporaciones acríticas de tecnología que, lejos de mejorar nuestras democracias, son amenazas al derecho esencial de la ciudadanía a votar en condiciones de secreto, transparencia y seguridad.

Notas

1 Tula, María Inés (coord.). “Voto Electrónico. Entre votos y máquinas. Las nuevas tecnologías en los procesos electorales”, Buenos Aires, Ariel Ciencia Política ‐ Centro de Implementación de Políticas Públicas para la Equidad y el Crecimiento (cippec), 2005.

2 “Cost Analysis of Maryland’s Electronic Voting System”, febrero de 2008. Disponible en http://www.saveourvotes.org/reports/2008/08-costs-mdvotingsys-tem.pdf

3 Harris, Bev. “Senator Hagel Admits Owning Voting Machine Company”, Scoop, 31/01/2003. Disponible en: http://www.scoop.co.nz/stories/HL0301/S00166.htm

Sobre los autores

Beatriz Busaniche es Licenciada en Comunicación Social por la Universidad Nacional de Rosario (UNR), Magíster en Propiedad Intelectual de flacso y Candidata al Doctorado en Ciencias Sociales en FLACSO. Además, es docente en grado y posgrado en la Universidad de Buenos Aires (UBA) y en FLACSO y presidente de la Fundación Vía Libre, organización civil sin fines de lucro dedicada a la defensa de derechos fundamentales en entornos mediados por tecnologías de información y comunicación. Ha escrito múltiples artículos sobre el voto electrónico y sus problemas. Es autora del libro Propiedad intelectual y derechos humanos (Tren en movimiento, 2016).

Federico Heinz es programador y especialista en software libre. Fue cofundador de Fundación Vía Libre, en la que actualmente participa como colaborador.

Viernes 24 de marzo de 2017

Usemos Linux: Selene Media Encoder: Un sencillo convertidor de audio y vídeo para Linux
Usemos Linux: DesdeLinux nominado a los Open Awards 2017 como Mejor Blog

Viernes 17 de marzo de 2017

Estructura de datos en python (Grafos)

Continuando con la serie de artículos sobre estructuras de datos en python. En este caso se tocará el tema de grafos con dos ejemplos, uno con listas y otro con matrices.

Los artículos anteriores son:

Este artículo se basa en los códigos en github Grafos con listas adyacentes y Grafos con matriz adyacente y del vídeo en youtube Grafos en Python.

De ejemplo de grafo se usará un modelo de procesos de colas, a continuación la imagen:


A continuación el código manejando el grafo como una lista:


#!/usr/bin/env python



class Vertice(object):

def __init__(self, n):

#Se define el nombre del vertice y la lista de vecinos

self.nombre = n

self.vecinos = list()



def agregarVecino(self, v):

if v not in self.vecinos:

self.vecinos.append(v)

self.vecinos.sort()







class Grafo(object):

#Se crea un diccionario de vertices.

vertices = {}



def agregarVertice(self, vertice):

#Se pregunta si vertice es una instancia de Vertice y si el nombre no esta en la lista de vertices.

#Si se cumple se agrega el vertice al diccionario de vertices.

if isinstance(vertice, Vertice) and vertice.nombre not in self.vertices:

self.vertices[vertice.nombre] = vertice

return True

else:

return False



def agregarBorde(self, u, v):

#Si u y v estan en vertices. se agregan como vecinos.

if u in self.vertices and v in self.vertices:

self.vertices[u].agregarVecino(v)

self.vertices[v].agregarVecino(u)

return True

else:

return False



def printGrafo(self):

#Se muestra el grafo.

for key in sorted(list(self.vertices.keys())):

print(key + str(self.vertices[key].vecinos))



if __name__ == '__main__':

g = Grafo()

cinco = Vertice('5')

tres = Vertice('3')

cuatro = Vertice('4')

uno = Vertice('1')

dos = Vertice('2')

for i in range(ord('1'), ord('6')):

g.agregarVertice(Vertice(chr(i)))



bordes = ['53','54','31','35','41','42','45','12','13','14','21','24']

for borde in bordes:

g.agregarBorde(borde[:1],borde[1:])



g.printGrafo()







Al ejecutar el script se tiene:
python grafo-listas.py
1['2', '3', '4']
2['1', '4']
3['1', '5']
4['1', '2', '5']
5['3', '4']


Como se ve, los vertices relacionados, el 1 se conecta con 2,3 y 4, el 2 con 1 y 4, el 3 con 1 y 5, el 4 con 1,2 y 5; y el 5 con 3 y 4.

El siguiente código muestra otra manera de crear el grafo, en este caso se puede manejar el peso de los bordes (aunque no se usa en el ejemplo).  A continuación el código:


#!/usr/bin/env python3



#Se importa nuevas caracteristicas de print

from __future__ import print_function





#Se crea la clace vertice que solo tiene como argumento su nombre.

class Vertice(object):

def __init__(self, n):

self.nombre = n





#Se crea la clase grafo con vertices e indices de bordes como diccionarios

#y bordes como una lista.

class Grafo(object):

vertices = {}

bordes = []

indices_bordes = {}





def agregarVertice(self,vertice):

#Si vertice es una instancia de su clase y su nombre no esta en el 

#diccionario de vertices se agrega.

if isinstance(vertice, Vertice) and vertice.nombre not in self.vertices:

self.vertices[vertice.nombre] = vertice

#Se recorre los bordes y se agregan.

for fila in self.bordes:

fila.append(0)

self.bordes.append([0] * (len(self.bordes)+1))

self.indices_bordes[vertice.nombre] = len(self.indices_bordes)

return True

else:

return False



def agregarBorde(self,u,v, peso=1):

#Se agrega el borde.

if u in self.vertices and v in self.vertices:

self.bordes[self.indices_bordes[u]][self.indices_bordes[v]] = peso

self.bordes[self.indices_bordes[v]][self.indices_bordes[u]] = peso

return True

else:

return False





def printGrafo(self):

#Se muestra el grafo

for v, i in sorted(self.indices_bordes.items()):

print(v + ' ', end='')

for j in range(len(self.bordes)):

print(self.bordes[i][j], end='')

print(' ')    





if __name__ == '__main__':

g = Grafo()

cinco = Vertice('5')

tres = Vertice('3')

cuatro = Vertice('4')

uno = Vertice('1')

dos = Vertice('2')

for i in range(ord('1'), ord('6')):

g.agregarVertice(Vertice(chr(i)))



bordes = ['53','54','31','35','41','42','45','12','13','14','21','24']

for borde in bordes:

g.agregarBorde(borde[:1],borde[1:])



g.p

rintGrafo()





Al ejecutar el script se tiene lo siguiente:
python grafo-matrix-adyacente.py 
1 01110 
2 10010 
3 10001 
4 11001 
5 00110 

Como en el caso anterior, el vertice 1 se conecta con 2,3 y 4, el vertice 2 se conecta con 1 y 4, el vertice 3 conecta a 1 y 5, el vertice 4 conecta a 1,2 y 5; y el vertice 5 conecta con 3 y 4.



Se tienen dos formas de representar un grafo, puede usar el que prefiera, dependiendo de la complejida, si se necesita manejar pesos, la opción es el de la matriz.


Domingo 12 de marzo de 2017

Ubuntips: ¿Ver porno mete virus en el ordenador?
Ubuntips: Nueva cita de la tecnología con el MWC 2017

Estructura de datos en Python (Lista Enlazada)

Continuando con la serie de estructuras de datos, en el artículo anterior se trato de la estructura de datos Nodo, en este artículo se usará el Nodo por medio de composición en la lista enlazada.

Este artículo se basa del tutorial en youtube llamado Python:Linked Lists donde pasan el enlace al código en github.

La lista enlazada se basa en el Nodo, como recordarán el Nodo tiene el dato y lo que apunta al próximo nodo.  En el caso de la lista enlazada contendrá lo siguiente:

  • Argumentos:
    • Nodo: Al crear la lista enlazada se crea un Nodo sin datos y que apunte a None.
    • primero: variable privada que apunta al primer nodo.
    • ultimo: variable privada que apunta al último nodo.
    • tamagno: variable privada que lleva la cantidad de nodos que maneja la lista.
  • Métodos:
    • obtenerTamagno: Devuelve el tamaño de la lista.
    • add: Agrega un nodo a la lista enlazada.
    • remove: Remueve un nodo de la lista enlazada.
    • find:Busca un dato en la lista, devuelve el dato o False.


El código de la lista enlazada se muestra a continuación:


#!/usr/bin/env python3

#Se importa Nodo de nodos.

from nodos import Nodo









class ListaEnlazada(object):

    def __init__(self,primero = Nodo(None,None)):

        """Se asigna como Nodo inicial a primero y ultimo por que apuntan al mismo nodo

        y se define el tamagno de la lista en cero"""

        self.__primero = primero 

        self.__ultimo = self.__primero

        self.__tamagno = 0





    def obtenerTamagno(self):

        """Devuelve el tamagno de la lista"""

        return self.__tamagno



    def add(self,d):

        """Agrega un nodo a la lista enlazada"""

        #Se crea una instancia de nodo donde se le pasa el dato d y se coloca

        #como proximo nodo el primer nodo.

        nodoNuevo = Nodo(d,self.__primero)

        #El primer nodo apunta al nodo nuevo y se incrementa el tamagno.

        self.__primero = nodoNuevo

        self.__tamagno += 1





    def remove(self,d):

        """Se elimina el nodo que tenga el dato d"""

        #Al nodo actual se le asigna el primer nodo

        nodoActual = self.__primero

        #Y al nodo anterior se le asigna None.

        nodoAnterior = None



        #Mientras exista el nodo actual-

        while nodoActual:

            #Si el dato de nodo actual es igual al dato que se esta buscando.

            if nodoActual.dato == d:

                #Si existe nodo anterior

                if nodoAnterior:

                    #Se asigna  al apuntador proximo del nodo anterior el proximo de nodo actual

                    nodoAnterior.proximo = nodoActual.proximo

                else: 

                    #A primero se le asigna el apuntador al proximo nodo del nodo actual

                    self.__primero = nodoActual.proximo

                #En cualquiera de los dos casos se decrementa el tamagno de la lista.

                self.__tamagno -= 1

                #Devuelve True por que se elimino.

                return True

            else:

                #Se asigna al nodo anterior el nodo actual

                nodoAnterior = nodoActual

                #Se asigna al nodo actual, el nodo proximo del nodo actual

                nodoActual = nodoActual.proximo





    def find(self,d):

        """Se busca d en la lista enlazada, si existe devuelve d, si no devuelve None"""

        #a nodo actual se le asigna el primer nodo.

        nodoActual = self.__primero

        #Mientras exista el nodo actual.

        while nodoActual:

            #Si el dato de nodo actual es igual a d, devuelve d

            if nodoActual.dato == d:

                return d

            else:

                #Si no, el nodo actual apunta al proximo nodo.

                nodoActual = nodoActual.proximo

        #Si no se encuentra devuelve None.

        return None 







if __name__ == '__main__':

    miLista = ListaEnlazada()

    miLista.add(1)

    miLista.add(8)

    miLista.add(12)

    print("size: {0}".format(miLista.obtenerTamagno()))

    print (miLista.find(8))

    miLista.remove(8)

    print("size: {0}".format(miLista.obtenerTamagno()))

    print(miLista.remove(12))

    print("size:{0} ".format(miLista.obtenerTamagno()))

    print(miLista.find(5))





Al ejecutar el script se tiene lo siguiente:

python listas.py 
size: 3
8
size: 2
True
size: 1
None


Como se puede ver se agregan 3 elementos a la lista, luego se muestra el tamaño de la lista, se va eliminando cada elemento de la lista, donde se muestra el tamagno de la lista mientras se va eliminando elementos, y por último se busca el valor de 5 en la lista donde devuelve None. 



Martes 31 de enero de 2017

Ubuntips: ¿Qué es mejor, Linux o Windows?

Lunes 30 de enero de 2017

Eduardo Federico

Eduardo Federico
Paraiso Linux

Como agregar un certificado SSL gratuito desde Vesta Panel

Si están al tanto de las noticias sobre internet, webs, SEO y tecnologia en general, seguramente habrán leído los nuevos cambios que involucran a la seguridad de las webs y las transcacciones realizadas en distintas webs.

Lo voy a resumir muy facilmente:

  • Muchas webs estan implementando certificados SSL en sus webs. Esto les permite tener una url que empiece con https://
  • Esto es debido a que no tenerlo puede afectar al SEO de un sitio. Ver esta nota en el blog de webmasters de google.
  • Ademas Chrome y Mozilla muestran como inseguros los sitios que no cuenten con dicho certificado. Ver nota en ayudawp.

La cuestión es que hace unos años tener un certificado SSL significaba desenbolsar $50 dolares anuales por cada sitio. Pero gracias a los certificados de Let’s Encrypt podemos tener certificados 100% gratuitos y muy fáciles de instalar.

Y como se hicieron tan comunes, la ultima version del panel Vesta agrega una opcion para que agregar este tipo de certificados a tu web sea todavia mas facil. Vamos a ver como hacerlo.

En la seccion WEB de su panel Vesta, hagan click en EDIT del dominio en cuestion.

Veran que hay un check que dice SSL Support. Deben marcarlo y tambien marcar el que aparece debajo que dice Lets Encrypt Support.

Guardan los cambios.

Ahora en su navegador prueban escribir la url completa con https:// y el navegador deberia marcarles esa web como segura.

Redirigir http a https

Ahora lo que deben hacer es solución un pequeño problema muy grande, y es no tener 2 versiones del mismo sitio. Para ello vamos a editar el archivo .htaccess y agregamos esto:

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://paraisolinux.com/$1 [R,L]

Obviamente poniendo tu url en lugar de la mia.

Para probar escriben en la navegador escriben la url sin el https y si se redirige esta bien.

Solucionar Error 403 forbidden

En la mayoría de los sitios con hacer lo anterior ya estaría todo solucionado. Pero si por ejemplo siguieron el tutorial de Laravel + Vesta veran que no funciona, lo que deberán hacer es:

sudo nano /home/admin/conf/web/sapache2.conf

Y editar las mismas lineas mencionadas en el tutorial mencionado.

 

La entrada Como agregar un certificado SSL gratuito desde Vesta Panel pertenece a Paraiso Linux.

Domingo 29 de enero de 2017

Eduardo Federico

Eduardo Federico
Paraiso Linux

Como añadir un subdominio en Vesta Panel

Ya hemos visto lo sencillo que es agregar un dominio a Vesta. Pero tambien vimos que es necesario tocar los RECORDS.

Para agregar un subdominio también tendremos que hacerlo. Pero sigue siendo una tarea super sencilla.

Primero nos dirigimos a la seccion WEB de Vesta. Alli vamos a agregar el subdominio haciendo click en 'ADD WEB DOMAIN'.

Al igual que cuando añadimos el dominio deberemos elegir correctamente la IP y crear un usuario FTP.

A continuación nos dirigimos a nuestra cuenta de Digital Ocean y en la seccion 'Networking' buscamos la opcion 'Manage Domain' del dominio que nos interesa.

En esta nueva pagina debemos agregar un nuevo Record del tipo A. Escribiendo en el primer campo el nombre del subdominio y en el segundo campo eligiendo el droplet a donde apuntara ese dominio.

Ahora si ingresan en ese subdominio deberían ver la pagina por defecto de Vesta.

Una cosa mas. Si por X casualidades de la vida, en ese subdominio desean tener un proyecto realizado con Laravel o Lumen, lo mejor seria seguir el tutorial para instalar Laravel en Vesta.

 

La entrada Como añadir un subdominio en Vesta Panel pertenece a Paraiso Linux.

Eduardo Federico

Eduardo Federico
Paraiso Linux

Como instalar un proyecto de Laravel en Vesta Panel

Voy a suponer que saben como instalar un proyecto básico de Laravel. Este tutorial no es para cubrir esa parte. Sino una situacion que seguramente le pasa a muchos desarrolladores. Y es esta:

-Tenemos un proyecto realizado en laravel, seguramente en github o bitbucket

-Deseamos hacer publico ese proyecto usando nuestro panel Vesta

-Ya hemos realizado al instalacion de Vesta, creado el nuevo dominio y brindado acceso via SSH.

-Pero obviamente no podemos simplemente hacer un git pull del proyecto dentro de la carpeta public_html porque no queremos que todo el proyecto sea accesible sino simplemente la carpeta public.

Si se te presento esa situación, esto es lo que debes hacer:

Paso 1- Acceder via SSH

ssh admin@[la ip]

Paso 2- Acceder a la carpeta del dominio

cd web/[tu dominio]/public_html

Paso 3- Eliminar los archivos existentes que no nos interesen. Ej:

rm index.html robots.txt

Paso 4- Clonar el repositorio de interes

git clone git@bitbucket.org:sefsinalas/project-d-site.git .

Notar el punto del final. Eso es para que todo se clone en el directorio actual.

Paso 5- Volver a la carpeta home escribiendo

cd

Y abrir el siguiente archivo

sudo nano conf/web/apache2.conf

En ese archivo nos encontraremos con la configuracion del virtualhost de apache.

Buscamos la linea que dice

DocumentRoot /home/admin/web/[tu dominio]/public_html

Y la cambiamos por

DocumentRoot /home/admin/web/[tu dominio]/public_html/public

Tambien donde dice

<Directory /home/admin/web/[tu dominio]/public_html>

por

<Directory /home/admin/web/[tu dominio]/public_html/public>

Paso 6- Opcional

Revisar la version de node escribiendo

nodejs --version

Si es una version menor a la 6 entonces lo mejor sera desinstalarla e instalar una version nueva. Algo asi:

sudo apt-get purge nodejs npm
curl -sL https://deb.nodesource.com/setup_7.x | sudo -E bash -
sudo apt-get install -y nodejs

Paso 7- Por supuesto necesitan volver al directorio public_html y hacer las cosas que ya saben sobre laravel. Dar permisos a la carpeta storage, hacer npm install, copiar el archivo .env y cualquier otra cosa que requiera su proyecto.

Paso 8- Reiniciar el servidor. Pueden hacerlo desde la consola o desde el panel Vesta en la sección Server.

Eso seria todo. Por supuesto esto es solo una forma de hacerlo, existen varias otras, mas fáciles o difíciles, mas seguras o inseguras. Una de ellas seria olvidar GIT y usar FTP, y aqui tienen otra forma de parte de Bobby Allen.

Consejo: para probar que el tutorial salio bien recomiendo cambiar momentáneamente los nombres de los archivos public/.htaccess y public/index.php y crear un archivo index.html que diga algo como 'En mantemiento'.

La entrada Como instalar un proyecto de Laravel en Vesta Panel pertenece a Paraiso Linux.

Lunes 09 de enero de 2017

Mariano Mendez

Mariano Mendez
[A]NTRAX - [L]ABS

BING: El buscador olvidado


Posicionamiento WEB

Hoy día, quien tiene una un sitio Web de cualquier naturaleza, sea para ofrecer un servicio, producto, o incluso para compartir materiales o documentación digital, si quiere marcar presencia en la red de redes, necesariamente tendrá que considerar el posicionamiento WEB o SEO (Search Engine Optimization). 

Sabemos que el SEO comprende una serie de estrategias, técnicas, o incluso habilidades para lograr las primeras posiciones en los resultados de los buscadores clásicos: Google, Bing, Yahoo, etc.
Va de suyo que podemos pagar marketing publicitario para tales fines; sin embargo las destrezas del SEO nos permiten lograr estupendos posicionamientos en las búsquedas gratuitamente,  aunque impliquen laboriosidad.

En mi opinión, se leen muchísimos tips para el SEO de Google, pero me queda la sensación que tanto Bing como Yahoo, no siempre son tenidos en cuenta en este trabajo de posicionar nuestro sitio digital. 

Aclaro que no es mi idea en esta entrada enumerar estrategias o sugerencias para mejorar el SEO, sino apuntar a que se consideren otros buscadores diferentes de Google a la hora de posicionar un espacio cibernético.  Sino llamar a la reflexión para tener presente al  segundo motor de búsqueda más importante: BING.


Números en BING

La cuota de mercado de BING, según señalan  los expertos va en ascenso:

“...Bing actualmente cuenta con el 21,9% de la cuota de mercado en escritorio en Estados Unidos. Una información que ha llamado nuestra atención y que demuestra que el buscador de Microsoft no ha dejado de crecer. Un punto en el que podrían tener que ver las últimas novedades incorporadas por el gigante tecnológico. Pero vayamos con los datos.



 “En concreto, la cifra supone un incremento de un 0,1 porcentual respecto del mes de junio, cuando contaba con el 21,8%. Los datos ofrecidos por la citada compañía, asimismo, muestran una caída del 0,4 por parte de Google...”

Los números de la gráfica hablan por sí mismos.


Otros comentarios sobre Bing

Más allá de las cifras expuestas, es oportuno recordar que Facebook y Skype emplean a Bing como buscador por defecto y las redes sociales o la mensajería instantánea son puntos claves en el SEO, tanto  por su extendido uso como por su  notoriedad.

Si a esto le agregamos los aspectos técnicos que a Bing le preocupan como, por ejemplo: velocidad, link rotos del sitio, evitar contenidos flash, entre otros; se torna una sumatoria de elementos que no deberían estar olvidados para el SEO de nuestra Web.

Posicionar un espacio digital no es tarea sencilla, pero es la base para el éxito del mismo.
Como comenté antes, no dejaré un tutorial de sugerencias, pero quiero destacar en lo referente al SEO en bing una interesante guía para que al momento de poner manos a la obra la consideren.

Mariano Mendez

Mariano Mendez
[A]NTRAX - [L]ABS

Cómo comprar BITCOINS


En esta entrada hablaremos de las criptomonedas, en particular de los Bitcoin. Seguramente todos han oído hablar de este tipo de moneda digital, pero no está de más recordar qué es y para qué sirven los Bitcoins, sin perjuicio de algunas reflexiones personales sobre las ventajas de su uso.

Referencias previas del término Bitcoin

Si consultamos en Wikipedia el término Bitcoins:


“Bitcoin (signo: BitcoinSign.svg; abr.: BTC, XBT) es una criptodivisa concebida en 2009. El término se aplica también al protocolo y a la red P2P que lo sustenta y de forma común se denomina como una moneda digital. Generalmente se usa «Bitcoin» para referirse a la red o al protocolo y «bitcoin» (plural: «bitcoines») para referirse a las unidades monetarias.”


De la transcripción precedente puede inferirse que bajo la expresión “Bitcoin” se comprenden tres aspectos diferentes:

Como moneda digital o unidades  de pago en intercambios comerciales vía online.


Como protocolo estandarizado que da soporte a las transacciones electrónicas, sin la mediación de terceros.

Como red para donde se negocian las operaciones comerciales.
Desglosadas estas referencias, hay que destacar que la criptomoneda se sustenta en un sistema totalmente peer-to-peer(persona a persona) donde los intermediarios quedan excluidos. La no intervención de terceros y la ausencia de una Autoridad Central bancaria de país alguno,  es una de las ventajas de los Bitcoins, en la medida que inhibe la especulación y la participación en ganancias como lo hacen las entidades financieras. 

Apoyando estas líneas de pensamiento, en bitcoins.org se reseña: 


“De la misma manera que nadie controla la tecnología detrás del correo electrónico, Bitcoin tampoco tiene propietarios. Bitcoin lo controlan todos los usuarios de Bitcoin del mundo. Aunque los programadores mejoran el software, no pueden forzar un cambio en el protocolo de Bitcoin porque todos los demás usuarios son libres de elegir el software y la versión que quieran. Para que sigan siendo compatibles entre sí, todos los usuarios necesitan utilizar software que cumpla con las mismas reglas. Bitcoin sólo puede funcionar correctamente si hay consenso entre todos los usuarios. Por lo tanto, todos los usuarios y programadores tienen un gran aliciente en proteger dicho consenso.”


Se señala como creador del sistema a  Satoshi Nakamoto y el 12/01/2009 se anota como la primera transacción con esta moneda; y desde esa fecha no solo se ha disparado el uso de Bitcoins, sino el valor que los respalda. Razones evidentes por las que se hace recomendable su uso.  

¿Cómo comprar Bitcoins?

Adscribirse al sistema no es difícil y en lo particular recomiendo las orientaciones del siguiente enlace como comprar bitcoins en Argentina, donde se explica detalladamente los pasos a seguir para la adquisición y operaciones con la moneda criptográfica de la que hablamos. Además de contener un estupendo FAQ de preguntas frecuentes que solventan toda duda. 

A modo de cierre de la entrada y en forma sintética  se pueden destacar cuatro puntos a saber:

Seguridad del sistema: basado en un sistema criptográfico altamente seguro.


    Anonimicidad en las transacciones: la privacidad es un elemento fundamental al momento de adquirir, vender, enviar o recibir pagos. 

      Operaciones en tiempo real al instante:se puede enviar y recibir pagos a cualquier lugar del mundo en forma instantánea.
Expansión de la criptomoneda:actualmente casi todos los negocios online aceptan el Bitcoin como medio de pago. Se habla del Bitcoin como la moneda futurística.


Domingo 08 de enero de 2017

David Moreno

David Moreno
dm's blog

Thanks Debian

I sent this email to debian-private a few days ago, on the 10th anniversary of my Debian account creation:

Date: Fri, 14 Aug 2015 19:37:20 +0200
From: David Moreno 
To: debian-private@lists.debian.org
Subject: Retiring from Debian
User-Agent: Mutt/1.5.23 (2014-03-12)

[-- PGP output follows (current time: Sun 23 Aug 2015 06:18:36 PM CEST) --]
gpg: Signature made Fri 14 Aug 2015 07:37:20 PM CEST using RSA key ID 4DADEC2F
gpg: Good signature from "David Moreno "
gpg:                 aka "David Moreno "
gpg:                 aka "David Moreno (1984-08-08) "
[-- End of PGP output --]

[-- The following data is signed --]

Hi,

Ten years ago today (2005-08-14) my account was created:

https://nm.debian.org/public/person/damog

Today, I don't feel like Debian represents me and neither do I represent the
project anymore.

I had tried over the last couple of years to retake my involvement but lack of
motivation and time always got on the way, so the right thing to do for me is
to officially retire and gtfo.

I certainly learned a bunch from dozens of Debian people over these many years,
and I'm nothing but grateful with all of them; I will for sure carry the project
close to my heart — as I carry it with the Debian swirl I still have tattooed
on my back ;)

http://damog.net/blog/2005/06/29/debian-tattoo/

I have three packages left that have not been updated in forever and you can
consider orphaned now: gcolor2, libperl6-say-perl and libxml-treepp-perl.

With all best wishes,
David Moreno.
http://damog.net/


[-- End of signed data --]

I received a couple of questions about my decision here. I basically don’t feel like Debian represents my interests and neither do I represent the project – this doesn’t mean I don’t believe in free software, to the contrary. I think some of the best software advancements we’ve made as society are thanks to it. I don’t necessarily believe on how the project has evolved itself, whether that has been the right way, to regain relevancy and dominance, and if it’s remained primarily a way to feed dogmatism versus pragmatism. This is the perfect example of a tragic consequence. I was very happy to learn that the current Debian Conference being held in Germany got the highest attendance ever, hopefully that can be utilized in a significant and useful way.

Regardless, my contributions to Debian were never noteworthy so it’s also not that big of a deal. I just need to close cycles myself and move forward, and the ten year anniversary looked like a significant mark for that.

Poke me in case you wanna discuss some more. I’ll always be happy to. Specially over beer :)

Peace.

Jueves 15 de diciembre de 2016

Mariano Mendez

Mariano Mendez
[A]NTRAX - [L]ABS

XSS por POST


Hace unos días reportaron un XSS por POST en el formulario de contacto de Underc0de. Por suerte no era nada riesgoso, pero era una vulnerabilidad que debíamos arreglar.
En esta ocasión usaremos el código de ese formulario de contacto para reproducir la falla y para ver como probar si nuestras aplicaciones son vulnerables a los XSS por POST.

El código del formulario de contacto está acá: www.hospedando.com.mx/descargas/formulario.zip por si alguno desea realizar la prueba.

Además, necesitaremos alguna herramienta que modifique los parámetros que enviemos por POST. Yo usare Tamper Data que es un complemento de Firefox:

https://addons.mozilla.org/es/firefox/addon/tamper-data/

Una vez montado el formulario de contacto se vera algo así:



El primer paso será completar todos sus campos y abrie Tamper Data. Una vez hecho esto, damos en "Comenzar Modificación" (En el tamper data) y enviamos el formulario de contacto.
Seguido a esto, nos aparecerá una alerta en Tamper Data para modificar los datos que estamos enviados.


Damos en modificar, y revisamos los valores que está enviando del lado derecho, que son los que hemos cargado desde el formulario.


Ahora es momento de jugar con estos campos. Este formulario de contacto no filtra sus variables, asique colocaremos algún vector de XSS en sus parámetros.
En este caso, coloqué un simple alert en el campo correo.

<script>alert('XSS')</script>

Pero podemos buscar o usar cualquier otro. Al dar en Aceptar, el sitio seguirá cargando con la nueva información suministrada...


Y como podrán apreciar, apareció el Alert con nuestro mensaje.

Espero que les sirva!

Lunes 29 de agosto de 2016

David Moreno

David Moreno
dm's blog

Webhook Setup with Facebook::Messenger::Bot

The documentation for the Facebook Messenger API points out how to setup your initial bot webhook. I just committed a quick patch that would make it very easy to setup a quick script to get it done using the unreleased and still in progress Perl’s Facebook::Messenger::Bot:

use Facebook::Messenger::Bot;

use constant VERIFY_TOKEN => 'imsosecret';

my $bot = Facebook::Messenger::Bot->new(); # no config specified!
$bot->expect_verify_token( VERIFY_TOKEN );
$bot->spin();

This should get you sorted. What endpoint would that be, though? Well that depends on how you’re giving Facebook access to your Plack’s .psgi application.

Domingo 21 de agosto de 2016

David Moreno

David Moreno
dm's blog

WIP: Perl bindings for Facebook Messenger

A couple of weeks ago I started looking into wrapping the Facebook Messenger API into Perl. Since all the calls are extremely simple using a REST API, I thought it could be easier and simpler even, to provide a small framework to hook bots using PSGI/Plack.

So I started putting some things together and with a very simple interface you could do a lot:

use strict;
use warnings;
use Facebook::Messenger::Bot;

my $bot = Facebook::Messenger::Bot->new({
    access_token   => '...',
    app_secret     => '...',
    verify_token   => '...'
});

$bot->register_hook_for('message', sub {
    my $bot = shift;
    my $message = shift;

    my $res = $bot->deliver({
        recipient => $message->sender,
        message => { text => "You said: " . $message->text() }
    });
    ...
});

$bot->spin();

You can hook a script like that as a .psgi file and plug it in to whatever you want.

Once you have some more decent user flow and whatnot, you can build something like:



…using a simple script like this one.

The work is not finished and not yet CPAN-ready but I’m posting this in case someone wants to join me in this mini-project or have suggestions, the work in progress is here.

Thanks!

Miércoles 29 de junio de 2016

PCTux: El hashtag que pide a Messi que no se vaya

Lunes 13 de junio de 2016

Javier Ledesma

Javier Ledesma
Ubuntronics

Richard Stallman nos explica: ¿Por que no usar celulares?

Richard Matthew Stallman (nacido en Manhattan, Nueva York, 16 de marzo de 1953), con frecuencia abreviado como «rms» es un programador estadounidense.


Es principalmente conocido por el establecimiento de un marco de referencia moral, político y legal para el movimiento del software libre, como una alternativa al desarrollo y distribución del software no libre o privativo.

Continuar leyendo »

Domingo 12 de junio de 2016

Javier Ledesma

Javier Ledesma
Ubuntronics

¿Cómo crear una lista de los paquetes instalados con Pacman y Yaourt?

Hacer una lista de todos los paquetes instalados en nuestro sistema ─en mi caso Arch Linux─ por medio de los gestores: Pacman y Yaourt, ¡es muy fácil!


Con ejecutar un solo comando en un Terminal es posible conocer los paquetes que hemos instalados, a excepción de los paquetes "base" y "base-devel".

Continuar leyendo »

Lunes 06 de junio de 2016

Javier Ledesma

Javier Ledesma
Ubuntronics

Jugar a Game Boy Advance en Linux con mGBA

Game Boy Advance (abreviada como GBA) es una popular consola de videojuegos de la compañía Nintendo. Hubo juegos de todos los géneros para esta consola que también, es compatible con todos los juegos de Game Boy y todos los de Game Boy Color.


mGBA en un emulador de Game Boy Advance con el que podrás disfrutar de todos los juegos de la fantástica consola de Nintendo en tu ordenador.

Continuar leyendo »

Viernes 05 de febrero de 2016

PCTux: Cupones de descuento en Argentina

Domingo 08 de noviembre de 2015

Sergio A. Alonso

Sergio A. Alonso
Bunker Blog

Taller de Linux y Ruby on Rails

Hace tiempo que no posteo en el Blog
Sepan disculpar: no solo no me he retirado, sino que gracias a mis dos últimos empleos, Belatrix y Supercanal (donde sigo trabajando) he aprendido mucho y apenas me ha alcanzado el tiempo para transmitir conocimientos nuevos
Como para no dejar completamente de lado la docencia, lanzo la cuarta edición de este Taller, con muchas novedades.
Si bien el Taller es presencial, incluye un aula virtual propia con todo lo necesario para crear los primeros algoritmos en Ruby, diseñar aplicaciones web, hacer scripting, y armar ambientes reales de producción.
El taller es muy intenso: incluye varios meta conocimientos alrededor de esta tecnología adquiridas a lo largo de 20 años de experiencia: intercambio de llaves, GIT, seteo de Apache, balanceadores de carga, debug sobre el terreno, despliegue de nodos, deploy en clouds, y una larga lista de habilidades tanto del desarrollador web como de esa nueva profesión que se viene gestando llamada DevOp.


Ejemplo del aula, la cual gracias a Screen y al fantástico Codebox IDE me permite asistir rápidamente a los alumnos:

Para los impacientes, aquí les dejo un enlace a la descripción del Taller, clase por clase: https://goo.gl/ngQ2BE

Enlace hacia la nota completa: http://goo.gl/BLyqdy

Se agradece su difusión.

Martes 13 de octubre de 2015

¿Que es QRDA? #QRDA @QRDAve

QRDA nace bajo la idea de proveer soluciones tecnológicas a distintas organizaciones sin fines de lucro, a través del apoyo de twitter.com/delbosquetech y con el respaldo de la Comunidad del Software Libre en Venezuela.

Esta idea la propone Luis Ortiz, gran amigo y compañero de trabajo. Se desarrolla en una reunión social (agua, cerveza, jugos, refresco, pizza) por lo que es considerado un evento entre panas que buscamos un mismo fin: dar apoyo con nuestro conocimiento tecnológico para desarrollar proyectos determinados.

Luis en la Charla de Inicio de QRDA

Luego de establecer las bases que sustentarían este proyecto, se fueron creando diferentes tickets en github que permitieran establecer un orden a las actividades que se van desarrollando, para luego crear las diferentes listas de correo y comenzar a trabajar.

Al final de la actividad pudimos compartir con personas que se acercaron de diferentes parte de Venezuela y que integran la Comunidad del Software Libre, gente con la cual me identifico y que se ha ganado mi respeto.

La lista de agradecimiento es extensa, son muchos los involucrados en este maravilloso proyecto que, aún y cuando está comenzando, podría asegurar que ayudará a muchas personas y tendrá un crecimiento positivo. Muchas gracias a todos.

Les dejo las redes sociales de QRDA para que también puedan seguir este proyecto y, si lo desean, puedan unirse a nosotros:

https://twitter.com/QRDAve/
https://instagram.com/qrda.ve
https://www.facebook.com/QRDA.com.ve
http://qrda.com.ve

Nuevamente Gracias por venir.

Lunes 14 de septiembre de 2015

La accesibilidad web para personas con discapacidad visual

“La Accesibilidad” hoy en día es una de las palabras más utilizadas cuando nos referimos a las persona con alguna discapacidad, más específicamente la discapacidad visual. Ésta no solamente abarca los aspectos de software y hardware, sino que además se centra en la vida misma de estas personas, cómo puede hacerse más fácil la tarea de convivir con personas que no tienen este tipo de desventaja; debido a esto, las instituciones del Estado se han interesado y comprometido a realizar medios más accesibles para ellos, así por ejemplo tenemos los pasos peatonales, incluso hoy en día hablamos de la creación de páginas web o sistemas de información accesibles. Es importante resaltar que se debe hacer un buen uso de la tecnología para poder romper las barreras que se presentan.
La construcción de estos sistemas o páginas web son de gran ayuda para las personas que viven con esta discapacidad debido a que han sido de alguna forma discriminados, sin dejar a un lado que este grupo está ya formado por más de 30 mil personas en nuestro país, esto de acuerdo a las cifras arrojadas en el censo realizado por CONAPDIS (Consejo Nacional para las Personas con Discapacidad). Es por ello que en estos momentos se debe luchar por incluir a todas estas personas en las actividades cotidianas del hombre, más específicamente en el mundo de las tecnologías, permitiéndoles conocer, por medio de páginas web por ejemplo, todo el contenido que puede ser de su interés y así pueda salir adelante de una mejor manera. El objetivo principal es que estos sistemas estén disponibles para todas estas personas y que sean incluidas en el aparato productivo de nuestro país, además de que la misión es producir, transformar e implantar bienes y servicios lo suficientemente accesibles para ellos.
La tiflotecnología ha logrado grandes avances; a nivel mundial existen organizaciones dentro de las cuales podemos mencionar a La Once (Organización Nacional de Ciegos Españoles), la cual ha sido pionera en el uso de herramientas o dispositivos que ayudan a las personas con esta discapacidad, a ser independientes. También existen escuelas destinadas a la enseñanza completa de estas personas, como son la Lighthouse International en Estados Unidos, encargada de enseñar de manera completa con la finalidad de lograr el desenvolmiento de estos; les proporcionan ayuda en cuanto a la orientación, el uso del computador, el uso del bastón, además de otras actividades, todo con la finalidad de que cada uno de ellos no pase a ser una carga para sus familias, sino que sean personas independientes y capaces de desenvolverse tanto tecnológicamente como en las relaciones de su vida diaria.
La metodología aplicada en esta investigación es documental, ya que trata de ver lo que existe hoy en día, cómo se puede mejorar y cómo se pueden crear herramientas que verdaderamente sean útiles para el trabajo diario, ya que no tendría ningún sentido desarrollar aplicaciones sin tomar en cuenta a los usuarios interesados acerca de cómo se les puede ayudar.
Palabras Claves: Hardware, Software, Software Libre, Tiflotecnología, Discapacidad, Discapacidad Visual.

Este es uno de los tantos articulo arbitrado realizado en el proceso de postgrado, luego explicare las fases y las herramientas a usar.

Sábado 12 de septiembre de 2015

Instalar Samba en Debian

Primero que nada hacemos la instalación del paquete
root@orthanc:/home/julioh# aptitude install samba

En nuestro home creamos el nombre de una carpeta que vamos a usar para compartir
mkdir share
chmod 777 share

Luego modificamos el archivo de configuración de samba

root@orthanc:/home/julioh# nano /etc/samba/smb.conf


# Samba config file created using SWAT
# from UNKNOWN (192.168.42.219)
# Date: 2014/05/15 14:19:36
[global]
server string = %h server
map to guest = Bad User
obey pam restrictions = Yes
pam password change = Yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
unix password sync = Yes
syslog = 0
log file = /var/log/samba/log.%m
max log size = 1000
dns proxy = No
usershare allow guests = Yes
panic action = /usr/share/samba/panic-action %d
idmap config * : backend = tdb
hosts allow = 127.0.0.1, 192.168.41.0/24, 192.168.40.0/24
#hosts deny = 0.0.0.0/0
#Comentamos el HostDeny para que me acepte los rangos de ip #de nuestra red interna
#[homes]
# comment = Home Directories
# valid users = %S
# create mask = 0700
# directory mask = 0700
# browseable = No

#[printers]
# comment = All Printers
# path = /var/spool/samba
# create mask = 0777
# printable = Yes
# print ok = Yes
# browseable = No
[print$]
comment = Printer Drivers
path = /var/lib/samba/printers
[SALA]
comment = Archivos Compartidos
path = /home/julioh/share
#admin users = root, SalaP, sala01, sala02
#username = root
#hosts allow = 192.168.41.0
#read list = @users
#public = yes
#only guest = yes
#Le descomentamos para que puedan escribir
writable = yes
read only = yes
valid users = SalaP, root, sala01, sala02
write list = SalaP, root, sala01, sala02
# Lineas agregadas
# crear archivos con permisos rxw
create mask = 0700
# crear directorios con permisos rxw
directory mask = 0700

Luego Detenemos el demonio y lo volvemos a levantar
root@orthanc:/home/julioh# /etc/init.d/samba restart
[ ok ] Stopping NetBIOS name server: nmbd.
[ ok ] Starting NetBIOS name server: nmbd.
[ ok ] Stopping SMB/CIFS daemon: smbd.
[ ok ] Starting SMB/CIFS daemon: smbd.
[ ok ] Stopping Samba AD DC daemon: samba

Luego de esos podremos compartir archivos en un directorio seguro para una red interna.

Lunes 07 de septiembre de 2015

Sergio A. Alonso

Sergio A. Alonso
Bunker Blog

Shot of work's laptop




A typical work session with Arch, Mate Window Manager, Numix Theme + my own colors.

Vim Janus with Molokai theme, Oh-my-zsh with Agnoster theme, Terminator, Tig, and Fuck correct typos. 

Wallpaper is one of my favorites related to Owl's Moving Castle, downloadable from here: http://www.allmacwallpaper.com/get/iMac-21-inch-wallpapers/-Howl's-Moving-Castle-1920x1080/5226-9.jpg

Jueves 02 de julio de 2015

Che … ¿y los datos?

Hace mas de un año, en abril de 2014, hice una presentación sobre Gobierno Abierto / Datos Abiertos para Libres del Sur / FAP.

En dicha presentación me enteré que dentro de la Secretaría de Desarrollo Tecnológico se había iniciado un proceso de apertura de datos de la administración municipal.

Como con todo aquello que hace el Intendente Pulti, me pareció bien la iniciativa pero me reservé las opiniones para mas adelante, ya que su costumbre siempre es patear para adelante y esperar que los reclamantes se cansen.

Ah, y también hacer mucha parafernalia y ruido con poquitas nueces.

Así fue como apareció el “Portal de Datos Abiertos” de la MGP. Y se hizo un Hackaton. Y un Concurso de Aplicaciones.

Me voy a referir al primer punto, el portal de datos abiertos.

Se suponía que allí uno iba a poder encontrar la información que necesitara sobre la Municipalidad y la ciudad, en formatos libres y abiertos, y actualizada.

Lo que realmente se encuentra (con la excepción de los datos de llamadas al 147, que parecen ser extraídas directamente del sistema que usa el call center), es todo lo que publicaron hace un año y olvidaron ahí.

Asi se ve la parte sobre datos sobre seguridad:

datos_seguridad_20150701

Así los referidos a medio ambiente:

datos_medioambiente_20150701

datos_medioambiente_osse_20150701

Los de movilidad:

datos_movilidad_20150701

Los de economía y presupuesto:

datos_economía_20150701

datos_presupuesto_20150701

Adicionalmente, en la página de Información Presupuestaria, los archivos que hasta el 2014 se publicaban en formato de planilla de cálculo, ahora han pasado a estar publicados en pdf, dificultando así cualquier análisis que uno quiera hacer, u obligando a convertirlos, con los problemas que implica cuando se tratan de datos en esquemas de tablas.

Todo sigue igual. O peor. Pero manteniendo el relato.

Domingo 17 de mayo de 2015

25 años de Internet en Argentina

patchcord_keyboardHoy es el día en que se conmemora el “día de Internet”. En realidad, el Día Mundial de las Telecomunicaciones y de la Sociedad de la Información, pero a veces es bueno simplificar un poco 😉 .

Este festejo surge de una propuesta de la Cumbre Mundial sobre la Sociedad de la Información, que pidió a la Asamblea General de las Naciones Unidas instituir el 17 de mayo como Día Mundial de la Sociedad de la Información, lo cual resultó decidido en forma afirmativa. Luego, la ITU (International Telecommunication Union) decide unificarlo con su Día de las Telecomunicaciones, dado que en esta fecha, y de eso también hoy se festejan los 150 años, se fundaba dicha unión.

Pero, lo que es la casualidad, resultó que un día 17 de mayo de 1990, en la ciudad de Buenos Aires y de la mano de Jorge Amodio, Argentina ponía en marcha su primer enlace a Internet.

Como fue que esto sucedió pueden leerlo en el blog del propio Amodio, haciendo click aquí.

También destaco este documento histórico: el e-mail en el cual se informa al administrador en USA que el enlace estaba funcionando.

>From pete Thu May 17 19:55:20 1990
>Subject: Line up ….
>To: atina!umd5.umd.edu!rcoltun (Rob Coltun)
>Date: Thu, 17 May 90 19:55:20 GMT-3:00
>
> Hi Rob,
>
> glad to contact you again, and very glad now because I’m
>looking the Cisco console showing “line up” over our link.
>
> I sent to Glenn the formal Internet Number and Autonomus
>System registration.
>
> Can you help me with the configuration of the Cisco router,
>I believe that we are able to do real networking tests ( your words
>sometime ago ) …
>
> I’ll wait your response,
>
> Best regards,
> Jorge.

Por esto es que quiero enviar mi saludo y las felicitaciones a quienes fueron los pioneros de Internet en Argentina, los que tras 25 años nos han dejado un legado de posibilidades extrarordinarias.

Gracias colegas!!!

Domingo 05 de abril de 2015

A 10 años del ICANN Meeting en Mar del Plata

Hace 10 años, un día 4 de abril de 2005, se iniciaba en Mar del Plata el ICANN Meeting XXII, el primero en ser realizado en nuestro país.

No fue casualidad que se haya organizado en la ciudad donde vivo. Un año antes, un grupito de marplatenses propusimos que se hiciera en nuestra ciudad y tuvimos la suerte de que los costos de alojamiento y comida estuvieran, en ese momento, bastante mas bajos que en la Ciudad de Buenos Aires, lo que nos dio ventaja en la decisión final de donde se hacía.

Y así empezó esta aventura que hoy es uno de los mas gratos recuerdos de mi vida profesional.

El evento se llevó a cabo en el Hotel Sheraton de Mar del Plata, quien tuvo que acelerar la instalación de su red inalámbrica para poder brindar la conectividad a los que terminaron siendo 604 participantes de 80 países distintos, con 60 APs

La conectividad a Internet se contrató a Comsat, quien tuvo que poner dos parabólicas de 2.5 metros de diámetro para poder brindar los 10 mbps simétricos que nos solicitaron con un rango /23 para contar con 512 Ips.

6 servidores DHCP, DNS y SMTP, con una estación de monitoreo de red, 20 PCs de uso público, transmisión en vivo de las reuniones y hasta hacer de service de los equipos que se le iban rompiendo a los miembros de ICANN.

Todo el grupo estuvo compuesto por gente de primera.

En la organización, Oscar García, del Polo Informático Mar del Plata, Antonio Harris, de Cabase, OTI Internacional en los servicios turísticos y Congress Rental en servicios de audio, video en pantalla gigante, registración, traducción, etc.

En la técnica, Steve Conte, Alexander Kulik, Tim Cole y Mike Evans, de ICANN, Guillermo Pereira Irujo, Claudio Roulliet, Alexis Bertola, Martín Salinas y yo, de Comtron, Marcelo Valencia y Hector Blanche, de Comsat, Juan Gimeno Rossi y German Paak, del Hotel Sheraton.

Y, a continuación, la “medalla” que nos quedó de recuerdo, con la firma, nada mas y nada menos, que de Vinton Cerf.

Para el final, el agradecimiento a Ignacio Marcos, que pasó una tarde para conocernos personalmente y que terminó a un costado, tomando un mate y mirándonos ir de un lado para otro, ya que gracias a el y a esa visita este blog existe como tal.

Jueves 06 de noviembre de 2014

Martín Albisetti

Martín Albisetti
Martin Albisetti's blog

Click packages and how they’ll empower upstreams

As the pieces start to come together and we get closer to converging mobile and desktop in Ubuntu, Click packages running on the desktop start to feel like they will be a reality soon (Unity 8 brings us Click packages). I think it's actually very exciting, and I thought I'd talk a bit about why that is.

First off: security. The Ubuntu Security team have done some pretty mind-blowing work to ensure Click packages are confined in a safe, reliable but still flexible manner. Jamie has explained how and why in a very eloquent manner. This will only push further an OS that is already well known and respected for being a safe place to do computing for all levels of computer skills.
My second favorite thing: simplification for app developers. When we started sketching out how Clicks would work, there was a very sharp focus on enabling app developers to have more freedom to build and maintain their apps, while still making it very easy to build a package. Clicks, by design, can't express any external dependencies other than a base system (called a "framework"). That means that if your app depends on a fancy library that isn't shipped by default, you just bundle it into the Click package and you're set. You get to update it whenever it suits you as a developer, and have predictability over how it will run on a user's computer (or device!). That opens up the possibility of shipping newer versions of a library, or just sticking with one that works for you. We exchange that freedom for some minor theoretical memory usage increases and extra disk space (if 2 apps end up including the same library), but with today's computing power and disk space cost, it seems like a small price to pay to empower application developers.
Building on top of my first 2 favorite things comes the third: updating apps outside of the Ubuntu release cycle and gaining control as an app developer. Because Click packages are safer than traditional packaging systems, and dependencies are more self-contained, app developers can ship their apps directly to Ubuntu users via the software store without the need for specialized reviewers to review them first. It's also simpler to carry support for previous base systems (frameworks) in newer versions of Ubuntu, allowing app developers to ship the same version of their app to both Ubuntu users on the cutting edge of an Ubuntu development release, as well as the previous LTS from a year ago. There have been many cases over the years where this was an obvious problem, OwnCloud being the latest example of the tension that arises from the current approach where app developers don't have control over what gets shipped.
I have many more favorite things about Clicks, some more are:
- You can create "fat" packages where the same binary supports multiple architectures
- Updated between versions is transactional so you never end up with a botched app update. No more holding your breath while an update installs, hoping your power doesn't drop mid-way
- Multi-user environments can have different versions of the same app without any problems
- Because Clicks are so easy to introspect and verify their proper confinement, the process for verifying them has been easy to automate enabling the store to process new applications within minutes (if not seconds!) and make them available to users immediately

The future of Ubuntu is exciting and it has a scent of a new revolution.

Martes 30 de septiembre de 2014

Sergio A. Alonso

Sergio A. Alonso
Bunker Blog

El Mundo Según JuanCPovE: Día de la Tierra, ese pequeño punto azul pálido en...

El Mundo Según JuanCPovE: Día de la Tierra, ese pequeño punto azul pálido en...: Siempre en este día cito a Carl Sagan y su obra "Pale Blue Dot". Una buena razón para reflexionar y cambiar de una buena vez nue...

Lunes 01 de septiembre de 2014

PCTux: Mejorar la velocidad de carga de aplicaciones con Prelink

Jueves 31 de julio de 2014

Martín Albisetti

Martín Albisetti
Martin Albisetti's blog

Engineering management

I'm a few days away from hitting 6 years at Canonical and I've ended up doing a lot more management than anything else in that time. Before that I did a solid 8 years at my own company, doing anything from developing, project managing, product managing, engineering managing, sales and accounting.
This time of the year is performance review time at Canonical, so it's gotten me thinking a lot about my role and how my view on engineering management has evolved over the years.

A key insights I've had from a former boss, Elliot Murphy, was viewing it as a support role for others to do their job rather than a follow-the-leader approach. I had heard the phrase "As a manager, I work for you" a few times over the years, but it rarely seemed true and felt mostly like a good concept to make people happy but not really applied in practice in any meaningful way.

Of all the approaches I've taken or seen, a role where you're there to unblock developers more than anything else, I believe is the best one. And unless you're a bit power-hungry on some level, it's probably the most enjoyable way of being a manager.

It's not to be applied blindly, though, I think a few conditions have to be met:
1) The team has to be fairly experienced/senior/smart, I think if it isn't it breaks down to often
2) You need to understand very clearly what needs doing and why, and need to invest heavily and frequently in communicated it to the team, both the global context as well as how it applies to them individually
3) You need to build a relationship of trust with each person and need to trust them, because trust is always a 2-way street
4) You need to be enough of an engineer to understand problems in depth when explained, know when to defer to other's judgments (which should be the common case when the team generally smart and experienced) and be capable of tie-breaking in a technical-savvy way
5) Have anyone who's ego doesn't fit in a small, 100ml container, leave it at home

There are many more things to do, but I think if you don't have those five, everything else is hard to hold together. In general, if the team is smart and experienced, understands what needs doing and why, and like their job, almost everything else self-organizes.
If it isn't self-organizing well enough, walk over those 5 points, one or several must be mis-aligned. More often than not, it's 2). Communication is hard, expensive and more of an art than a science. Most of the times things have seemed to stumble a bit, it's been a failure of how I understood what we should be doing as a team, or a failure on how I communicated it to everyone else as it evolved over time.
Second most frequent I think is 1), but that may vary more depending on your team, company and project.

Oh, and actually caring about people and what you do helps a lot, but that helps a lot in life in general, so do that anyway regardless of you role  🙂

Jueves 15 de mayo de 2014

Martín Albisetti

Martín Albisetti
Martin Albisetti's blog

A story on finding an elusive security bug and managing it responsibly

Now that all the responsible disclosure processes have been followed through, I’d like to tell everyone a story of my very bad week last week. Don’t worry, it has a happy ending.

 

Part 1: Exposition

On May 5th we got a support request from a user who observed confusing behaviour in one of our systems. Our support staff immediately escalated it to me and my team sprung into action for what ended up being a 48-hour rollercoaster ride that ended with us reporting upstream to Django a security bug.

The bug, in a nutshell, is that when the following conditions lines up, a system could end up serving a request to one user that was meant for another:

- You are authenticating requests with cookies, OAuth or other authentication mechanisms
- The user is using any version of Internet Explorer or Chromeframe (to be more precise, anything with “MSIE” in the request user agent)
- You (or an ISP in the middle) are caching requests between Django and the internet (except Varnish’s default configuration, for reasons we’ll get to)
- You are serving the same URL with different content to different users

We rarely saw this combination of conditions because users of services provided by Canonical generally have a bias towards not using Internet Explorer, as you’d expect from a company who develops the world’s most used Linux distribution.

 

Part 2: Rising Action

Now, one may think that the bug is obvious, and wonder how it went unnoticed since 2008, but this really was one was one of those elusive “ninja-bugs” you hear about on the Internet and it took us quite a bit of effort to track it down.

In debugging situations such as this, the first step is generally to figure out how to reproduce the bug. In fact, figuring out how to reproduce it is often the lion’s share of the effort of fixing it.  However, no matter how much we tried we could not reproduce it. No matter what we changed, we always got back the right request. This was good, because it ruled out a widespread problem in our systems, but did not get us closer to figuring out the problem.

Putting aside reproducing it for a while, we then moved on to combing very carefully through our code, trying to find any hints of what could be causing this. Several of us looked at it with fresh eyes so we wouldn’t be tainted by having developed or reviewed the code, but we all still came up empty each and every time. Our code seemed perfectly correct.

We then went on to a close examination of all related requests to get new clues to where the problem was hiding. But we had a big challenge with this. As developers we don’t get access to any production information that could identify people. This is good for user privacy, of course, but made it hard to produce useful logs. We invested some effort to work around this while maintaining user privacy by creating a way to anonymise the logs in a way that would still let us find patterns in them. This effort turned up the first real clue.

We use Squid to cache data for each user, so that when they re-request the same data, it’s queued up right in memory and can be quickly served to them without having to recreate the data from the databases and other services. In those anonymized  Squid logs, we saw cookie-authenticated requests that didn’t contain an HTTP Vary header at all, where we expected it to have at the very least “Vary: Cookie” to ensure Squid would only serve the correct content all the time. So we then knew what was happening, but not why. We immediately pulled Squid out of the middle to stop this from happening.

Why was Squid not logging Vary headers? There were many possible culprits for this, so we got a *lot* of people were involved searching for the problem. We combed through everything in our frontend stack (Apache, Haproxy and Squid) that could sometimes remove Vary headers.

This was made all the harder because we had not yet fully Juju charmed every service, so could not easily access all configurations and test theories locally. Sometimes technical debt really gets expensive!

After this exhaustive search, we determined that nothing our code removed headers. So we started following the code up to Django middlewares, and went as far as logging the exact headers Django was sending out at the last middleware layer. Still nothing.

 

Part 3: The Climax

Until we got a break. Logs were still being generated, and eventually a pattern emerged. All the initial requests that had no Vary headers seemed for the most part to be from Internet Explorer. It didn’t make sense that a browser could remove headers that were returned from a server, but knowing this took us to the right place in the Django code, and because Django is open source, there was no friction in inspecting it deeply.  That’s when we saw it.

In a function called fix_IE_for_vary, we saw the offending line of code.

del response['Vary']

We finally found the cause.

It turns out IE 6 and 7 didn’t have the HTTP Vary header implemented fully, so there’s a workaround in Django to remove it for any content that isn’t html or plain text. In hindsight, if Django would of implemented this instead as a middleware, even if default, it would have been more likely that this would have been revised earlier. Hindsight is always 20/20 though, and it easy to sit back and theorise on how things should have been done.

So if you’ve been serving any data that wasn’t html or plain text with a caching layer in the middle that implements Vary header management to-spec (Varnish doesn’t trust it by default, and checks the cookie in the request anyway), you may have improperly returned a request.

Newer versions if Internet Explorer have since fixed this, but who knew in 2008 IE 9 would come 3 years later?

 

Part 4: Falling Action

We immediately applied a temporary fix to all our running Django instances in Canonical and involved our security team to follow standard responsible disclosure processes. The Canonical security team was now in the driving seat and worked to assign a CVE number and email the Django security contact with details on the bug, how to reproduce it and links to the specific code in the Django tree.

The Django team immediately and professionally acknowledged the bug and began researching possible solutions as well as any other parts of the code where this scenario could occur. There was continuous communication among our teams for the next few days while we agreed on lead times for distributions to receive and prepare the security fix,

 

Part 5: Resolution

I can’t highlight enough how important it is to follow these well-established processes to make sure we keep the Internet at large a generally safe place.
To summarise, if you’re running Django, please update to the latest security release as quickly as possible, and disable any internal caching until then to minimise the chances of hitting this bug.

If you're running squid and want to check if you could be affected, here's a small python script to run against your logs we put together you can use as a base, you may need to tweak it based on your log format. Be sure to run it only against cookie-authenticated URLs, otherwise you will hit a lot of false positives.

Jueves 04 de octubre de 2012

LugSaJu: La tecla que te salva del DESASTRE

Jueves 09 de agosto de 2012

Dear Martínez

Dear Martínez
La vida Linux

Software de mensajería instantánea Jitsi 1.0

La competencia entre los programas de mensajería instantánea a través de VoIP, video conferencia y más, es grande y todas satisfacen nuestras necesidades. Competidores somo Skype, Ekiga, lideran el poderío de uso, pero existen otras alternativas menos utilizadas por no ser famosas, pero de mejor dicción y predisposición de servicio al usuario, tal como Jitsi, antes conocido como SIP Communicator y que desde hace tan solo días, ha lanzado su nueva versión estable.

Jitsi 1.0 Software de mensajería instantánea Jitsi 1.0

El renovado Jitsi 1.0 reúne todas las funciones que se pueden encontrar en diversos programas con las herramientas VoIP, video conferencia, mensajería instantánea tanto para Windows como para Mac y GNU/Linux. Esta interfaz es sumamente cómoda y amigable, siendo intuitiva y fácil de utilizar. Es compatible con los protocolos más populares de mensajería instantánea y telefonía, pero también se le puede dar uso con las cuentas habituales de correo tales como Hotmail, Gmail o Yahoo, o bien otros como AIM, XMPP, Jabber, SIP y la posibilidad de emparejar la cuenta de la red social Facebook.

Entre sus características más destacadas se encuentra la de transferencia de llamadas atendidas o ciegas, el cambio de estado automático cuando el usuario no se encuentre utilizando el ordenador, la autoconexión, además de permitir grabar las llamadas para seguridad del usuario y el cifrado de protocolos SRTP Y ZRTP. No obstante, también permite establecimiento de conexión de medios directa mediante protocolo ICE, streaming de escritorio, almacenamiento de contraseñas cifradas, transferencia de archivos, soporte IPv6 para SIP y XMPP, etc.

 

Jueves 02 de agosto de 2012

Dear Martínez

Dear Martínez
La vida Linux

Aprende a tocar la guitarra con TuxGuitar

Un nuevo software para los amantes de la guitarra y la música, además de para aquellos aficionados que siempre quisieron aprender, existe una herramienta llamada TuxGuitar, siendo un editor visual de tablaturas y partituras de código abierto. Esta aplicación ha de ser ideal para llevarla consigo a cualquier parte. Desarrollada hace tiempo, es una idea que surgió para crear una herramienta que le haga competencia al popular Guitar Pro, pero que esta pueda ser utilizada por todo el mundo de forma gratuita.

Tux Guitar Aprende a tocar la guitarra con TuxGuitar

La herramienta de Tux Guitar es muy útil para el aprendizaje de la música y el arte de utilizar cualquier guitarra, aunque también cuenta con bajo, teclado y batería con el cual el usuario podrá aprender lo que no, o poner en práctica lo conocido en la materia. Desarrollado por la compañía Java, se puede abrir y exportar ficheros GP3, GP4 y GP5, además de ser compatible con los archivos del Guitar Pro, permitiendo que se pueda utilizar las partituras creadas para ese programa.

No solamente el Tux Guitar es un simple editor visual de partituras con el que se puede componer la música, sino también ofrece una gran variedad de efectos de sonido, soporte multipista, tempo, posibilidad de tercetos, scroll automático en la reproducción y muchas otras herramientas que lo ayudarán a formar su música tal como la disponga.

Lunes 16 de julio de 2012

Dear Martínez

Dear Martínez
La vida Linux

Nueva versión de MythTV 0.25 con soporte para Windows

El conocido reproductor de TV se ha escondido en la sombra de las noticias tecnológicas respecto a Linux durante un año y medio, sin tener novedades de ellas y varios retrasos en el desarrollo de la última versión del reproductor, por lo que MythTV anunció que ha sido liberado y trae 5200 cambios como si fuera poco. Muchos saben en qué consiste este software reproductor de TV y multimedia, por lo que les interesará saber sobre las novedades de cambios.

MythTV Nueva versión de MythTV 0.25 con soporte para Windows

En la versión 0.25 de MythTV se incluyen nuevas características que destacan el interés en los usuarios, como nuevas capacidades de aceleración de video, tales como VAAPI y video de DirectX2, mejoras de audio, incluyendo soporte para E-AC3, TrueHD y DTS-HD, mejoras de los metadatos que integra gestión de grabaciones y videos, una API para aplicaciones de terceros, para aprovechar la interacción con el frontend y backend, control del televisor y otros componentes AV a través del consumer electronics control, o la inclusión de un HTTP Live Streaming, para compartir el contenido de video en tiempo eral a través de la API integrada.

También se destaca en el nuevo reproductor MythTV, el MythMusic que ha sido completamente reescrito y MythVideo que ahora se ha integrado completamente, en lugar de ser distribuido como un plug-in por separado. Además, a través de MythThemes, todos los temas, incluyendo los de terceros, se pueden descargar directamente desde el selector de temas de la interfaz.

 

Jueves 05 de abril de 2012

Soft-Libre: GNOME 3.4 disponible con interesantes novedades
Soft-Libre: Wallpapers para Ubuntu 12.04 LTS
Soft-Libre: LibreOffice adquiere capacidad colaborativa en la nube + LibreOffice 3.5.2

Domingo 26 de febrero de 2012

Luciano Bello

Luciano Bello
Luciano's webpage

Lessons Learned: Fettisdagen y Semla

Fettisdagen, (martes de carnaval). Fet es grasa, mientras tisdag es martes. El sufijo en es el artículo determinado. Por lo tanto, el martes graso

Semla, Comida. Etimológicamente, viene de semilla. También llamado fastlagsbulle, es una berlinesa (bola de fraile, que le dicen) con crema y pasta de almendras en su interior.

SemlaFlickr
En el post sobre Lucía ya hemos hablado sobre lo sorprendentemente apegado que son los suecos a ciertas fiestas de origen religioso, incluso cuando solo el 23% de ellos dice cree en algo llamado dios (ya no decir "ser cristiano"). Este parece ser un nuevo caso de lo mismo.

En Argentina, así como en muchos (por no decir todos) países de América existe el carnaval. En otras palabras, festejar y comer antes de los 40 día de ayuno y penitencia por la Cuaresma que comienza el día siguiente, es decir, el Miércoles de Ceniza.

Acá, y en otros países nórdicos, no parece haber carnaval. Lo que sí hay es Fettisdagen. Éste podría ser un martes de lo más común, si no fuese porque se consumen enormes cantidades de semla.

Casualmente, ese martes me tocó ser el anfitrión del PhD fika (cuando los estudiantes de doctorado nos juntamos a tomar café y conversar), por lo me subí a la tradición y los invité con semla de distintos sabores. El sabor está dado por la crema, que puede ser común, de vainilla, con canela y otras variantes.

Los semlor (plural de semla) es algo tan popular en la cultura sueca que un detective de cuentos para chicos llamado Ture Sventon es adicto a estos (y también vuela en una alfombra mágica, pero no viene al caso).

Y este podría no ser único caso sueco de adición a semla. En el siglo XVII, rey Adolfo Federico habría muerto (literalmente) de un atracón después de clavarse 14 porciones de semla (tradicionalmente servidos con un tazón de leche caliente) como postre.

La receta, aquí.

Domingo 15 de enero de 2012

Luciano Bello

Luciano Bello
Luciano's webpage

Corriendo Debian en un server fanless

Debido a una reciente mudanza, he bajado unos servers que tenía corriendo en casa de mis padres. Sin embargo, en mi nuevo hogar estoy en proceso de generar una nueva DMZ, esta vez, sin ventiladores.

El primer paso de este proceso ocurrió en forma de weekend project y consiste en hacerme de un "servidor". Las comillas hacen referencia a que no se trata de un gran server sino un procesador ARM de 200Mhz y 32MB de RAM, lo que es suficiente para que corra Debian y algunos otros servicios que pueden ser interesantes.

Los ingredientes

  • Un all-in-one LAN server que es la forma en que DealExtreme llama a unos dispositivos con chips de la familia str8132. Dado que vamos a instalar snake-os en ellos (en este caso se trata de la versión 1.3.2-20111019), es importante chequear la lista de compatibilidad. En particular me hice de un NS-K330 por 40 dólares.
  • Storage USB, puede ser en la forma de stick o como disco portable.
  • Un RS232 to TTL level converter, también conocido como cable para Nokia N1200/1208/1650/2630/2670. Es para conectarse por serie a la consola. No lo necesitamos ahora mismo, pero está bueno tenerlo a mano en caso de brickearlo, aunque es un procedimiento que no explicaré esta vez.

Instalación de Snake-OS

Es realmente sencillo. Lo primero es bajar snake-os, desde la sección de downloads de la web. Es importante que el archivo sea de la forma snakeos-<versión>-from-original.zip Instalar el que dice from-snake lleva definitivamente al brickearlo y recuperarlo puede ser complejo.
Desde la página de administración del dispositivo hay que subir el archivo snakeos-<versión>-from-original.bin contenido en el zip bajado. Confirmar el md5sum no está de más.

Acceso inicial

Los datos para acceder a la nueva interfaz con el browser:

http://192.168.0.240 (si es que no hay un DHCP en la red)
usuario: admin
contraseña: snake

Por SSH la contraseña de root la misma y, al cambiarla por la página de administración, se cambia en todos los accesos.

Post instalación

Incluso cuando Max opine que el uso de memoria virtual está rumbo a la extinción (lo cierto es que tal vez no es la mejor idea cuando el storage es de estado sólido como en los pendrives), activé el uso de SWAP desde el menú Service-Swapfile.

Si se quieren las mismas prestaciones que se tenían con el firmware original, hay que instalar unos paquetes adicionales. El sistema de paquetes que utiliza snake-os es opkg y tiene que ser primero activado desde Service-Opkg. Los paquetes pueden bajarse desde la página de download de snake-os y se instalan desde System-Packages. En particular, pueden ser interesantes (siempre pensando en los features originales):
Transmission: Es un cliente de BitTorrent, para dejar tus descargas corriendo. Es bastante mejor que el original.
miniDLNA: Es el server de streaming compatible con DLNA/UPnP-AV. Está un poco verde, pero se está trabajando en su mejora.

Corriendo Debian dentro

Las instrucciones están acá. Aunque esto es lo más obvio y necesario:

wget http://snake-os.googlecode.com/files/debian_chroot.tgz
tar -xvf debian_chroot.tgz
mount -o bind /proc /usb/sda1/debian/proc
mount -o bind /dev /usb/sda1/debian/dev
chroot /usb/sda1/debian/

Esta instalación base requiere unos 200MB. Tiene todo el potencial de un Debian (¡porque lo es!).
Claro que falta ajustar varios detalles, pero será la piedra inicial para el resto.

Lunes 12 de diciembre de 2011

Luciano Bello

Luciano Bello
Luciano's webpage

Lessons Learned: Lucia

Lucia, fiesta (13 de diciembre). Tradicional fiesta sueca asociada a Santa Lucía de Siracusa, el solsticio y las velas.

Según el santoral católico, el 13 de Diciembre (o sea, en un par de horas) es el día dedicado a Santa Lucía. Dato que seguramente pasa totalmente desapercibido para la gran mayoría de la personas del mundo. A menos claro, que se sea habitante de Suecia (o de Sicilia, pero no viene al caso).

El día de Santa Lucía, o simplemente Lucia como prefieren llamarlo acá, es de la fiestas más importantes de la cultura sueca. Y, como extranjero, me es sumamente difícil de entender como en un país tan poco religioso algo así tiene cabida. Así que analicemos los hechos.

La santa en cuestión: Durante el siglo III y principios del IV vivió en Siracusa (una ciudad de Sicilia, Italia) una joven católica de familia potentada llamada Lucía, quien tenía intensiones de consagrarse a Dios. Pero un despechado pretendiente la denunció a la autoridades (eran tiempos de persecución a los católicos) y fue enjuiciada y sentenciada a muerte. La tradición cuenta que se ordenó torturarla arrancándole los ojos y que aún así siguió viendo por milagro divino (sí, lo que tiene en la bandeja de la estampita son un par de ojos). Más datos sobre su vida en la Wikipedia y referencias.
Es, obviamente, patrona de los ciegos. También, aunque bastante menos evidentemente, de los electricistas, choferes, afiladores y cristaleros. Tal vez en este último caso exista alguna relación con el tradicional arte de soplar vidrio que existe en Suecia.

Su asociación con la luz: El nombre Lucía, hace clara referencia al latín, Lux. La leyenda de los ojos también parecen referir a la luz (o a la falta de ésta). Aunque no pude encontrar referencias, algunas personas me comentan que Santa Lucía fue condenada a la hoguera y que el fuego no la consumía. Y que por esto hay velas durante la celebración. Aún más simpático es que parece ser que, por errores acumulados durante la Edad Media en el calendario Juliano, la festividad de Lucía coincidía con el día más corto del año, el solsticio de invierno.

Conociendo lo odioso que puede ser la oscuridad en estos lares y lo fanático de las velitas y de los artefactos lumínicos que son lo locales, no parece ser tan loco que quieran festejar que los días empiezan a alargarse (aunque esto no ocurrirá hasta dentro de poco más de una semana).

Las velas también pueden hacer referencia a una leyenda pre-cristina en que la noche más larga del año lo animales nocturnos adquirían poderes sobrenaturales (incluso podían hablar) y había que mantenerlos alejados con fuego.

Luciatåg: Significa procesión de Lucia. Es el acto por excelencia y se celebra totalmente independiente de la fiesta religiosa. Se realiza en escuelas (especialmente en las guarderías) y en ámbitos públicos en donde una mujer representa a Lucia llevado "la luz" con una corona de velas (electrónicas en muchos casos, matando cierta divertida tensión macabra). La vestimenta es una túnica blanca ceñida por una faja roja, representando el martirio. Las tärnor (literalmente, golondrinas, aunque también puede ser las damas de honor o doncellas) acompañan a Lucia llevando velas en las manos y cantando canciones tradicionales. Hay más personajes, pero quedarán para otro post.

Entre las muchas tradiciones gastronómicas asociadas a esta época del año, hay una que hace referencia directa a Lucia: los lussekatter. Son como unas facturas dulces de azafrán y que representan ojos. La palabra lussekatt se traduce como gatos de Lucia y se suele acompañar con Glögg, una especie de glühwein local.

Para terminar, durante esta fecha se elige en Estocolmo la Sveriges Lucia. Es una especie de concurso por representar a Lucia a nivel nacional en donde cada ciudad propone su candidata. Las participantes representan a una entidad de beneficencia y tengo entendido que se valoran las cualidades para canto y la personalidad con entrevistas que son televisadas. Se puede votar por tu Lucia favorita a través de SMS, aunque creo que la votación para este año ya está cerrada. ¿Que qué se lleva la ganadora? No tengo idea...

Pero acá les dejo las candidatas finalistas de este año:

Lunes 07 de noviembre de 2011

Punto Libre: サイトマップ

Viernes 01 de abril de 2011

Tecnoscopio: Clon de Counter-Strike Gratis en tu navegador

Miércoles 30 de marzo de 2011

Tecnoscopio: Gestor de Descargas para Megaupload Depositefiles y otros

Lunes 28 de marzo de 2011

Tecnoscopio: Generación de electricidad con peatones y tránsito de autos

Miércoles 09 de marzo de 2011

Punto Libre: デートを成功させる

Martes 09 de noviembre de 2010

Fabián Flores Vadell

Fabián Flores Vadell
Speed Books Argentina

Proyectos

Inicia una nueva etapa que implica materializar la idea, que originalmente tomó forma con este pequeño proyecto, de producir documentación en español sobre tecnologías libres que pudieran tener un nicho de interés en la comunidad y que particularmente interesen a los participantes de este proyecto. Los primeros proyectos que verán la luz estarán relacionados con: La programación con Smalltalk.
Fabián Flores Vadell

Fabián Flores Vadell
Speed Books Argentina

¿Libertad o propiedad? Antorchas en la Biblioteca

A continuación el video y la transcripción de la conferencia de Carlos Sánchez Almeida En este ocaso somos aún antorchas, luz que sobresale en el horizonte. Y, mientras esta muralla resista, seremos custodios de la Palabra divina. - Así sea –dijo Guillermo con tono devoto–. Pero, ¿qué tiene que ver eso con la prohibición de visitar la biblioteca? - Mirad, fray Guillermo –dijo el Abad–,

Domingo 31 de octubre de 2010

Fabián Flores Vadell

Fabián Flores Vadell
Speed Books Argentina

PHP 5 Power Programming

In this book, PHP 5's co-creator and two leading PHP developers show you how to make the most of PHP 5's industrial-strength enhancements in any project—no matter how large or complex. Their unique insights and realistic examples illuminate PHP 5's new object model, powerful design patterns, improved XML Web services support, and much more. Whether you're creating web applications, extensions,