All posts by edulix

Receta para el cálculo estadístico del voto fraudulento y de calidad del censo

Introducción

Este post va a explicar muy someramente una metodología para realizar un cálculo de probabilidad de voto fraudulento utilizando métodos estadísticos de inferencia bayesiana. Este es un documento informativo muy básico con un enfoque práctico, por lo que no entra a valorar cuales son los diferentes tipos de algoritmos aplicables (ni los parámetros de configuración de dichos algoritmos).

El cálculo estadístico que aquí se propone permite realizar una afirmación como:

La probabilidad de que más del 5% del censo sea fraudulento es menor o igual al 4%

Este procedimiento es aplicable a un censo, pero puede contextualizarse en una votación. Si por ejemplo tenemos una votación con una única candidatura ganadora, y la diferencia en votos entre la candidatura ganadora y la candidatura perdedora que más votos obtuvo es mayor al 5%, entonces podría realizarse la siguiente afirmación:

La probabilidad de que el voto fraudulento haya afectado al resultado es menor o igual al 4%

Nota: en una afirmación como la anterior se está asumiendo que cada votante sólo puede emitir 1 punto/voto y que el sistema de votación se comporta predeciblemente. Dicha afirmación habría que corregirla convenientemente en el caso de que se utilice un sistema de votación en el que dicha suposición no se de, como por ejemplo en el Borda tradicional (donde el votante tiene más de un punto para repartir) o en sistemas como por ejemplo VUT donde los resultados pueden variar con un sólo voto de forma bastante difícil de predicir a priori.

Contexto y ámbito de aplicación

El análisis estadístico como método de auditoría es utilizado en votaciones oficiales en todo el mundo, por ejemplo en Estados Unidos [6], país en el que se aplica en algunos estados ya de forma habitual. En USA se llegó a poner en cuestión la presidencia de Estados Unidos por fallos en el recuento de votos en un proceso electoral. Aprender de la experiencia de otros es muchas veces difícil, pero nunca está de más utilizarlo de forma ejemplarizante. La verificación de los resultados y en general aplicar técnicas de limitación de riesgos son prácticas altamente recomendables en procesos electorales donde se deciden materias importantes, ya sean en procesos de voto en papel o electrónico.

Este tipo de análisis en la terminología académica se suele conocer como “risk-limiting audit” o “auditoría de limitación de riesgo” y hay muchas publicaciones al respecto en la red. En este documento se explica un método para analizar un censo de votantes, sin embargo tradicionalmente el análisis en votaciones en papel se realiza sobretodo para verificar el recuento. Esto es debido a que a diferencia de lo que ocurre en el voto electrónico, los recuentos manuales son costosos en tiempo y recursos, y precisamente lo que un análisis estadístico permite es tener cierto grado de certeza sin llegar a hacer un costoso segundo recuento completo.

Limitaciones

La variable que más limita a la hora de poder tener certeza sobre la probabilidad de que el fraude haya afectado al resultado de una votación es el llamado margen de votos, es decir la diferencia entre cualesquiera dos candidaturas si al menos una de ellas es ganadora. Por tanto, en general cuantos más votos y menos candidaturas haya, más fácil es que la diferencia de votos entre candidaturas sea mayor, pero incluso en ese caso puede que haya sólo dos candidaturas y el margen de diferencia en votos sea ajustado.

El peor de los casos que sin embargo es típico en partidos políticos es la confección de listas electorales mediante primarias, porque hay muchas opciones, muchos puestos ganadores y por tanto una alta probabilidad no ya sólo de que la diferencia en votos de dos candidaturas con posibilidades de ganar sea bajo, sino incluso de que haya empates en votos.

Este tipo de análisis matemático estadístico presupone el peor de los casos, lo cual le permite ser a la par cautoloso y riguroso en los datos que arroja. En contrapartida, si un único voto (o un número de votos pequeño) puede alterar el resultado de una votación porque la diferencia en votos entre dos candidaturas es de muy pocos votos), si se quiere tener una probabilidad de que el voto fraudulento haya afectado al resultado baja, implica contactar con prácticamente todo el censo de votantes.

No obstante, incluso en el peor de los casos también hay que poner en valor otra cuestión, y es que incluso a pesar de que un único voto pueda afectar a uno de los puestos ganadores, un análisis estadístico permite limitar cuánto podrían bailar los resultados en el peor de los casos, y además también es de rigor apuntar que a priori es difícil adivinar cuales son las candidaturas que van a estar empatadas. Si por ejemplo de 200 candidaturas sólo hay un caso de dos candidaturas donde la diferencia de votos entre ellas es de un voto, habría que analizar cual es la probabilidad de que un atacante acierte a escoger una de esas 2 candidaturas para alterar el resultado. Ese análisis no se tiene en cuenta en el modelo simplificado que aquí se propone.

Por último, ha de remarcarse que este tipo de análisis estadístico es un método de seguridad enmarcado en el ámbito de la detección y obtención de información, pero no de la prevención ni de la actuación: permite averiguar información y poder sacar conclusiones acerca de la validez de un censo, pero no está pensado para mejorar la calidad del censo ni permite prevenir problemas en él.

Procedimiento

Es recomendable realizar el análisis del censo con la mayor antelación y previsión, una vez exista dicho censo. La razón es que toma tiempo, y que además el tiempo exacto que pueda tomar no se conoce completamente a priori, y concretamente depende de tres variables:

  1. el volumen de fraude que se vaya encontrando (desconocido a priori)
  2. el tamaño del censo (conocido a priori si es censo cerrado, e incluso si es censo abierto se puede tener una estimación)
  3. margen de error aceptable (desconocido a priori aunque se puede tener una estimación a priori)

Como hemos dicho anteriormente, con estas variables, y con la información que nos proporciona el análisis, al final el dato que se obtiene es una afirmación tan sencilla como la que sigue:

La probabilidad de que más del 5% del censo sea fraudulento es menor o igual al 4%

En el peor de los casos, se termina haciendo un análisis de todo el censo, por lo que la estimación de la cantidad de tiempo/recursos necesarios puede dimensionarse teniendo ese caso como límite superior.

Si existe un censo previo, se puede realizar un análisis de ese censo incluso antes de comenzar la votación. De hecho, puede que ese análisis se haya realizado previamente si lo hacemos a menudo. En el caso de que el censo esté abierto pero exista un censo previo, es recomendable comenzar con ese trabajo hecho, y luego seguir haciendo comprobaciones censales durante la votación sobre los nuevos elementos del censo.

El cálculo estadístico se puede ir realizando en cualquier momento y en tiempo real a medida que se van conociendo más datos. Por poner un ejemplo, si la votación no ha empezado aun, no se sabrá con certeza cual es el margen de error aceptable, porque ese dato depende de cuan ajustados sean los resultados, pero sí se puede tener una estimación. De igual manera, se puede ir actualizando el tamaño de la muestra estadística y el número de casos donde se ha detectado fraude.

El procedimiento es el siguiente:

1. Establecer un porcentaje de fraude aceptable

Por ejemplo un 5%. Si vamos a hacer unas primarias, si estimamos que vamos a tener alrededor de 2000 votos y creemos que es razonable pensar que los resultados no van a verse afectados si menos de 100 votos son fraudulentos, entonces el margen de error aceptable es de 100/2000 = 0.05 (es decir, un 5%). Por supuesto, si ya conocemos los resultados, ese dato ya no tendrá porqué ser una estimación, y podrá calcularse en base a los resultados reales.

2. Establecer el límite de la probabilidad que consideramos aceptable de que ese porcentaje anterior sea fraudulento

Por ejemplo, podemos establecer que “la probabilidad de que más del 5% del censo sea fraudulento no debe superar el 5%”.

3. Escoger una muestra del censo que se pretende analizar

Es muy importante hacerse de forma aleatoria, ya que el modelo estadístico asume un muestreo aleatorio. Se puede tener numerado el censo y generar números aleatorios con un generador de números aleatorios, como por ejemplo un dado o la web https://www.random.org/

NOTAS:

  • Cuanto menor sea el tamaño del censo más representativo será el muestreo para una muestra de igual tamaño. Por tanto usar como censo al conjunto de votantes, y no el censo de electores que siempre será mayor.
  • Los seres humanos somos MUY malas fuentes de aleatoriedad y en ningún caso se recomienda generar esos números “de cabeza”.
  • Si se está haciendo el análisis de forma iterativa a medida que va cambiando el censo, garantizar que la suma de los muestreos equivale a un muestreo aleatorio es más complicado de lo que parece y por ello en principio no vamos a analizar ese caso en este documento.

4. Verificar el fraude en la muestra elegida

Para verificar el fraude debe establecese previamente una forma muy concreta de actuación y valoración. En concreto, si por ejemplo se tiene el teléfono de la persona, se propone llamar a esta persona, informarle que se está verificando el censo y que nos diga sus datos censales y si ha participado en la votación. Es muy importante que sea la persona la que aporte los datos censales y no el verificador, porque de otra forma se adulteraría el resultado. Al final de la llamada, que deben ser cortas y al grano para ser eficientes y para eso lo recomendable es ir con un “script” de antemano, el verificador debe de clasificar a la persona como fraude o no-fraude, a efectos de luego realizar el cómputo de cuantos elementos fraudulentos hay. Si se quiere, podría afinarse más asignando una probabilidad de fraude con valores intermedios entre 0 y 1.

5. Calcular la probabilidad de fraude con los datos anteriormente obtenidos

Para eso se propone utilizar el formulario de [0]. Una vez introducidos los datos, la calculadora ofrece una frase de este estilo:

The probability that more than 3.00% of the votes/census are fraudulent is less or equal than 5.15%, according to a bayesian inference done using a sample size of 300 and having 4 invalid elements.

Si el censo ya está cerrado (porque era cerrado o porque la votación ha terminado y por tanto el censo de votantes está cerrado) y la probabilidad de fraude es menor al límite previamente marcado en el punto 2, entonces el análisis ha terminado exitosamente. Si esto ocurre cuando el censo no está cerrado, cuando varíe sustancialmente el censo (por ejemplo, si varía más de X votos o Y% porcentaje, o bien cada X días) se puede realizar de nuevo el procedimiento, a modo iterativo.

Si el porcentaje de fraude es superior al admisible según el punto 2, entonces debemos de aumentar el tamaño del muestreo con el objetivo de hacerlo más representativo y así reducir la probabilidad de que sea simplemente un error de muestreo. Debido a que el cálculo de la probabilidad de fraude se hace en tiempo real, se puede iterar todo este proceso de forma muy ágil, de manera que por ejemplo cada vez que se hace un muestreo de 50 personas elegidas aleatoriamente del censo se recalcula la probabilidad de fraude y se decide si seguir o no analizando.

Referencias

El formulario para calcular la probabilidad de fraude:

[0] http://jsfiddle.net/op1r411L/37/

Queda fuera del ámbito, eminentemente práctico de este documento, explicar la lógica matemática que sustenta la metodología aplicada. No obstante, sí que queremos referenciar material donde se explica en más detalle:

[1] https://blog.agoravoting.org/index.php/2014/06/04/voter-fraud-and-bayesian-inference/

[2] https://blog.agoravoting.org/index.php/2014/06/04/voter-fraud-and-bayesian-inference-part-2/

[3] http://www.cs.cmu.edu/~10701/lecture/technote2_betabinomial.pdf

[4] http://projecteuclid.org/download/pdf_1/euclid.ss/1009213286

Nuestra propuesta es utilizar el método bayesiano beta-binomial porque lo consideramos quizás el más adecuado, pero existen otros métodos estadísticos que en realidad al final dan resultados bastante parecidos. Algunos de ellos pueden verse aquí:

[5] http://epitools.ausvet.com.au/content.php?page=CIProportion

Existe una página hecha por expertos en la materia y bastante instructiva que contiene una numerosa cantidad de utilidades e información sobre cómo se debe realizar auditorías de limitación de riesgo, que como hemos explicado no es exactamente lo mismo que lo que estamos intentando hacer aquí pero la metodología es parecida:

[6] http://arstechnica.com/tech-policy/2012/07/saving-american-elections-with-10-sided-dice-one-stats-profs-quest/2/

[7] http://www.stat.berkeley.edu/~stark/Vote/auditTools.htm

EVOTE2014 – Agora Voting in the Austrian castle of electronic voting

Last week was a special one for us at Agora Voting. On Monday we were present at the press conference where the Podemos spanish political party presented the results of our most participated election yet (more than 112000 votes cast), and the same day we flew to Austria to attend the biannual evoting EVOTE2014 conference.

The conference took place during the whole week, and was held in the Schlosshofen castle in Austria. During this event, we got to meet many people involved in national electronic elections, election officials, and also cryptographers and in general academics that are improving the state of the art.

Group photo at EVOTE2014

We also had the opportunity to meet the people from Scytl who were very friendly with us. David Ruescas from Agora Voting discussed a few ideas with them regarding secure liquid democracy and listened to some of their interesting suggestions. We also had a few meetings with Rolf Haenni and his team from the University of Berne, who are doing important work in open source secure voting and kindly took the time to discuss some avenues of collaboration with us. Our plan is to help them develop their library and mixnet, and if things go well we may even be able to build a complete system together in the mid term. Rolf also mentioned the VOTEID conferece taking place next year, we may try to publish a paper there.

It was also nice to finally meet Douglas Wikstrom, the author of Verificatum, and the person who presented one of the most interesting papers in the conference. Towards the end of the week we got the chance to show our software in a demo session. Overall it’s been exciting and very important for us to be part of this event. This week, we’re back in Spain, working in the next Podemos internet election.

Nace la startup Agora Voting

Eduardo Robles y David Ruescas, principales impulsores de Agora Voting, hemos decidido que es el momento de dar un impulso empresarial a este proyecto de software libre. Contaremos con la participación del emprendedor Lucas Cervera como CEO y con la empresa Wadobo como socio tecnológico. Nuestro objetivo es convertir Agora Voting en la plataforma open source de referencia en el mundo, haciendo asequible y promoviendo el uso de sistemas telemáticos de votación seguros para organizaciones y la ciudadanía en general, complementándolo con nuestros servicios profesionales.

Agora Voting es un proyecto, entonces conocido como “Ágora Ciudadana”, que surge en el Partido de Internet en 2009. Tiempo después, los desarrolladores del proyecto decidimos separarlo e independizarlo de este partido político, con el objetivo de que funcionase de forma autónoma como sistema de votaciones de propósito general, con el objetivo de poder ser usado por otras organizaciones.

Este objetivo lo cumplimos con éxito: el año pasado el proyecto consiguió el hito de ser usado en el Congreso de los Diputados, y este 2014 ha sido utilizado en varios procesos electorales en los que han participado cientos de miles de personas. No fue hasta este mismo año que conseguimos financiar de alguna forma parte del desarrollo del proyecto. Estos trabajos los desarrollamos hasta ahora a través de la empresa social Wadobo, de uno del principales desarrolladores de Agora Voting. Hasta entonces, Agora Voting había sido posible exclusivamente gracias a la colaboración de decenas de personas que forman la comunidad, que trabajaron en él sin remuneración alguna a cambio.

Todas las semanas recibimos correos de gente que nos solicita realizar procesos de votaciones. Esto es una constatación de que nuestra sociedad de nuestro país quiere más democracia, y de que las votaciones digitales son ya una realidad. Sin embargo, la forma en que hemos colaborado en la realización de votaciones actualmente requiere de más recursos de los que disponemos actualmente, y lo que es más importante, las innovadoras medidas de seguridad que aplica Agora Voting en sus votaciones tienen un coste en recursos humanos que es mucho más bajo que el de la competencia, pero aun sigue siendo más alto del que muchas organizaciones pueden permitirse.

Es por todo esto y por que creemos que hay que dotar al proyecto de una estructura organizativa que le permita desarrollar todo su potencial, hoy anunciamos públicamente la startup Agora Voting (en proceso de creación), que es nuestra forma de dar respuesta a la demanda ciudadana que hemos generado. Como proyecto empresarial, nacemos comprometidos con la comunidad del proyecto, que seguiremos apoyando y saldrá fortalecida de este cambio. Nuestro compromiso con el proyecto de software libre es firme. Aun más, creemos que los principios de transparencia e independencia tecnológica que brindamos son fundamentales para un sistema de votación electrónico que vele por la legitimidad democrática de los procesos electorales donde participemos.

Anunciamos además una nueva colaboración con el partido político PODEMOS, que ha vuelto a confiar en Agora Voting para llevar a cabo sus votaciones en otoño. Esperamos poder llevar a cabo pronto proyectos similares con más partidos de España y el mundo. Por otro lado, pronto anunciaremos más detalladamente nuestros planes sobre los próximos desarrollos de Agora Voting. Respecto de este tema, nuestra intención de nuevo es bajar los costes asociados a las votaciones con altas medidas de seguridad, para así poder llegar aun a más gente.

La creación de la startup conllevará algunos cambios, que vamos a detallar como medida de transparencia, y que previamente hemos hablado con algunos de los miembros clave de la comunidad. Las cuentas de twitter y facebook con el nombre “AgoraVoting” que hacen referencia al proyecto de software libre han sido renombradas a “AgoraVotingOrg”. El proyecto de software libre usará el dominio agoravoting.org. Por otra parte, la empresa usará el dominio agoravoting.com y las nuevas cuentas “AgoraVoting” en twitter y facebook. Por otra parte, la instalación gratuita de Agora Voting que aparece en agoravoting.com seguirá estan disponible en ese dominio aunque próximamente la portada mostrará la web de la startup, con un acceso a dicha instalación gratuita, que seguirá funcionando como siempre.

Por qué el Voto Único Transferible (VUT) no es la panacea

Existe una corriente de gente que tenía una esperanza bastante alta en que el sistema de Voto Único Transferible (VUT) fuese el sistema por antonomasia a recomendar para cualquier votación entre un número alto de opciones (mayor que dos o tres). Un sistema que sirva desde para elegir un logo o lema hasta para realizar unas primarias.

Miniexplicación de cómo funciona VUT

VUT es un sistema de recuento de votos preferenciales. En el voto preferencial, el votante ante una lista de posibles opciones elige otra lista ordenada de las opciones que prefiere. Vale, pero luego ¿cómo hacemos el recuento, quienes son los ganadores? Pues hay muchos sistema para ello, y VUT es uno de ellos.

“Bajo el VUT, el voto de un elector se le asigna inicialmente a su candidato favorito, y si el candidato hubiera sido ya elegido o eliminado, todos los votos sobrantes se transfieren según las preferencias seleccionadas por cada votante.” (Wikipedia)

Funciona por rondas. En cada ronda, se establece una cuota, de manera que si alguna de las opciones candidatas obtiene ese número de votos automáticamente sale elegida. También es posible que en una ronda ninguna opción consiga llegar a la cuota; en ese caso, lo que se hace es eliminar la opción candidata con menos votos, y transferir sus votos.

Por último, he de decir que VUT no es un sistema concreto: es una clase de sistemas de recuento con estas características que he mencionado. Luego cambian los detalles: cómo se calculan las cuotas en cada ronda, cuantos votos se transfieren cuando una opción candidata gana o cuando se elimina una opción, etc.Como digo, esto es sólo una miniexplicación.

Listado de problemas

En Agoravoting soportamos VUT porque nos parece un sistema interesante y con aplicaciones, y sobretodo, porque nos lo solicitaron nuestros usuarios. No obstante, nuestra experiencia nos ha demostrado que no es la panacea. Diría aun más: no parecer existir un sistema de voto para muchas opciones que sea ideal y extensible a todas las situaciones, y en todo caso VUT desde luego no lo es.

Evidencia de ello fue la segunda ronda de las primarias para las elecciones al Parlamento Europeo de la Confederación Pirata. Los problemas que surgieron son los siguientes:

VUT sólo sirve para escoger ganadores

El VUT es un sistema pensado para que dado una lista de opciones y un conjunto de votos devuelva la lista de ganadores. Para escoger escaños en un parlamento, por ejemplo. Pero no ordena las opciones ganadoras.

Es cierto que normalmente es posible establecer un criterio sencillo para ordenar las opciones ganadoras, pero hemos de recalcar que eso ya es algo que no forma parte de VUT. El criterio más sencillo es que dado que en cada ronda normalmente sale sólo un ganador y las rondas sí que se hacen en un orden (ronda 1, ronda 2..), el orden de los ganadores se puede establecer según la ronda en que salieron.

Problemas de primera ronda

Como decía, VUT, El VUT funciona por rondas, y cualquier candidato que supere en una ronda cierta cuota es elegido. El primer problema con el criterio de ordenación sencillo que hemos explicado anteriormente es que en una ronda puede salir elegida más de una opción, simplemente porque varias opciones superen la cuota mínima en esa ronda.

No obstante, si habéis visto el recuento, seguramente diréis “¡no pasa nada! lo ordenamos según los votos que tenga cada ganador en esa ronda”.

Y es verdad, ese es un sistema casi infalible, porque como se transfieren votos entre opciones al pasar de ronda, cada opción candidata tiene un número decimal de votos y por tanto es muy complicado que haya ningún empate… menos en la primera ronda.

Y precisamente esa fue el primer gran problema que afrontamos en estas primarias piratas. Resulta que teníamos unos 60 candidatos y sólo 118 votos. El resultado que daba es que según la cuota de droop que es más o menos “(nº de votos / (nº candidatos + 1)) + 1” es que cualquier opción con dos votos en la primera ronda ganaba. Cataclismo: eso nos daba 21 ganadores en primera ronda, con un número de votos por opción candidata redondos porque aun no había habido aun transferencia de votos, y muchas opciones empatando.

Es por supuesto un caso poco usual. En una votación institucional con cientos de miles de votantes o millones de votantes no va a pasar esto. Pero son cosas que pueden pasar. Lo dicho: VUT no está pensado para ordenar ganadores y se nota.

Por supuesto, hay muchos posibles algoritmos aplicables para solucionar los empates. En el caso de las primarias piratas, optamos por aplicar una suerte de rondas de desempate entre los ganadores. La idea es sencilla: si hay empate en número de votos en primera opción, desempatar mirando el número de votos como segunda opción, o como tercera, etc. Lo hicimos así porque sigue el espíritu del VUT, pero por supuesto, podrían existir otras formas.

Problemas cocinando resultados

Incluso teniendo ya una lista de ganadores ordenada y superado los anteriores obstáculos, siguieron apareciendo problemas debido a la idiosincrasia de VUT. No fueron desde luego unas votaciones precisamente triviales, como podéis observar, aunque aprendimos mucho sobre VUT.

El siguiente problema fue la famosa “cocina”. La ley obliga a ordenar por paridad, de manera que en las listas electorales y mirando los candidatos según su orden, de cada grupo de cinco haya 3 de un sexo y 2 de otro.

Muy bien diréis, pues se re-ordena por cumplir con este imperativo legal y ya está. Pues no es tan sencillo, porque resulta que no existía tal paridad en la lista de ganadores, y por tanto para cumplir con la ley, hacía falta sacar mujeres de entre de los candidatos que no habían ganado.

¿el problema? que VUT no te da más que una lista de opciones ganadoras. Repito: que no, que no sirve para ordenar y menos para cocinar resultados. No te dice siquiera cual sería la opción que más cerca se ha quedado ¿la que tiene más votos en la última ronda o en la primera o en la tercera?

Algún avispado dirá: pues vuelve a ejecutar VUT con un ganador más. Eso puede no funcionar, porque no sólo puede ocurrirte que no sea mujer (y entonces qué, probar con otro ganador más y así hasta que salga el número de mujeres que necesites? pff) sino que además VUT no es estable. Si aumentas el número de opciones ganadoras, puede y es es de hecho bastante probable, que alguna de las opciones que antes se dieron por ganadoras ya no aparezca como tal. Paradojas de la vida.

Por supuesto, para casos como este puedes aplicar el criterio que consideres más oportuno, como mirar los votos como primera opción/en primera ronda (es lo mismo) y escoger al ganador de ahí. Si mal no recuerdo, eso hicimos en las primarias piratas.

.. y aun tiene más problemas

Me diréis: la mayoría de esos problemas afectan sólo a las primarias, y es cierto. Pero en realidad, VUT tiene muchas más irregularidades. Con esto no estoy diciendo que otros sistemas como Approval voting o los de clase Condorcet sean la panacea porque tampoco lo son.

En VUT puede haber candidatos que son opción más preferida que el último ganador y sin embargo no salir elegidos. Cuando sólo hay una opción ganadora es fácil de verlo.

También se critica y con razón la complejidad que requiere entender VUT, por no hablar de replicar el recuento. Que conste que lo que he explicado arriba de VUT es lo básico: existen muchos más detalles según qué algoritmo específico de VUT se utilice. También es difícil interpretar los resultados y hacer el recuento en otros algoritmos como los de método Condorcet, pero por ejemplo en Approval voting es todo mucho más sencillo.

Además si quieres usar VUT en colegios electorales, que sepas que no puedes hacer un recuento por mesa: debido a que el algoritmo no es estable como hemos comentado antes, no puedes simplemente sumar resultados. Tienes que contar todas las papeletas de forma centralizada en un solo sitio juntas. Un caos vamos.

Y como todo sistema de voto, existe el voto táctico, es decir no votar por preferencias sino según crees que pueda maximizar un resultado favorable a tus preferencias. De nuevo, al no ser VUT estable, es posible que al seleccionar una opción en tu papeleta estés quitándole posibilidades de salir ganadora. Todos estos problemas de los que estoy hablando están explicados (en inglés) en un caso práctico en este pequeño artículo.

Conclusiones

Por todo esto, creo que Podemos hicieron muy bien en optar por usar approval voting pese a que les ofrecimos también VUT como opción (chicos listos ;-), y desde luego para la Confederación Pirata recomendaré no volver a usar VUT para primarias, visto lo visto.

A bitcoin based, completely distributed voting system

The Agora Voting project has already implemented a voting system that has been used in spanish congress [0] and uses secure cryptographic methods based on ElGamal mixnets: encryption keys are distributed on a set of authorities where if at least one of them remains honest, the secrecy of the vote is preserved, and even if all authorities are compromised, the tally cannot be forged because it’s universally verifiable via mathematical proofs. This is a standard method and has been used in Norwegian general elections, for example.

We believe that the quest for secure electronic voting must continue. Even if vote secrecy is maintained by a set of authorities and the tally proofs are mathematically verifiable, vote casting is still done by one web server and this is a single point of failure, prone to DDoS attacks. We now announce our commitment to develop a working Bitcoin-based voting system that provides both secrecy of the vote and verifiability of the tally.

The basic idea is very simple: to use the bitcoin network as an online, distributed notary and timestamping service to register votes. Notary services based on bitcoin already exist, for example proof-of-existence, bitnotar or chronobit. This proves that the system can work: we need to adapt and make it practical: we must allow many votes in a short period of time, provide ways to check the validity of the registered votes and detect which transfers reflect the hash of a vote. We also have to document all this and develop a working solution.

Please note that this is only the beginning, we have many more plans towards distributing trust in online voting. In the future, we plan to use namecoin so that you don’t have to trust the SSL certificate authorities cartel, just the network and the hashtag of an election, which is public. Another ambitious and promising idea is to use the blockchain to anonymize the votes altogether using zerocoin so we can remove the need for a trusted set of authorities altogether. Just trust the name and the network. Make the whole process secure but deeply distributed.

To develop all this we need time and resources and we ask the bitcoin community and enthusiasts for your help: please join the discussion at our mailing list [1], but also please donate to 1EwqtN6GwHmkfYEfxGhuVcjrNBdQwvXMd3. If we reach 100BTC, we will release and develop the complete plan to use the bitcoin blockchain to distribute trust onto the network. The initial draft of the plan is already written, we have hashed it so that its existence can be verified a posteriori, the sha256 hash is:

9251615dfc780e353b5d2c2946ca999d225d91c4e565e7e0330a7bd1800dc43c.

Let’s make remove unneeded third parties from electronic voting processes; just trust the vote.


[0] http://www.theguardian.com/world/2013/sep/11/joan-baldovi-spain-transparency-bill?CMP=twt_gu
[1] https://groups.google.com/forum/#!forum/agora-ciudadana-devel

Hackathon democrático

Ciudadanos. Diseñadores. Programadores. Hackers. Abogados. Periodistas. TÚ. El 18-19 de Octubre en Deskmadrid (Legazpi).

Mejoremos Agoravoting para que vuelva a ser utilizado para tomar decisiones reales en el Congreso de los Diputados. Lo vamos a dar todo por mejorar la democracia.

¿Qué es y qué haremos?

Es una una maratón hacker, una reunión de todo tipo de ciudadanos interesados en avanzar el desarrollo de Agoravoting lo máximo posible en un corto periodo de tiempo, haciendo piña y comunidad.

El pasado 12 de septiembre hicimos historia en el Congreso con el diputado Joan Baldoví cuando cedió su voto en la Ley de Transparencia a la ciudadanía mediante la plataforma AgoraVoting. Fue un primer paso, y un éxito que pronto volveremos a repetir, mejorar y replicar.

En este hackathon democrático nuestro objetivo  es mejorar la interfaz de Ágora aplicando lo aprendido con el feedback recibido con #CongresoTransparente:

  • Crear un proceso de registro + emisión de voto mucho más rápido y natural
  • Hacer más dinámica la votación de portada
  • Optimizar la interfaz de revisión de DNIs, donde los operadores puedan revisar los DNIs escaneados con mayor facilidad y rapidez
  • Dar el acabo final al soporte voto cifrado y seguro
  • Separar los procesos de parar votación, hacer recuento y publicarlo
  • Soportar votaciones multi-idioma

Estos son solo algunos de los puntos que nos planteamos resolver en el hackathon, pero para todo ello necesitamos vuestra ayuda:

¿A quien va dirigido?

Todo el mundo

Si estás interesado en la democracia online, crees que es el futuro y estás dispuesto a echarnos una mano para construirlo, entonces definitivamente ¡ven y participa! Sean cuales sean tus habilidades o intereses, tu aportación puede ser muy valiosa para nosotros. No hay que registrarse, pero si vas a venir puedes mandarnos un twit a @AgoraCiudadana y darle visibilidad al evento.

Desarrolladores

Necesitamos hackers como tú que se echen al ruedo para tocar el código multidisciplinar de ágora. Python, Javascript, Backbone, Django, HTML5/CSS3, Seguridad y Cifrado, SSL, Varnish, Nginx, Linux, Java, Administración de Servidores, Arduino, despliegue en la nube.. Si te interesa alguno de estos temas/tecnologías o quieres toquetearlas, te estamos buscando a tí, ésta es tu oportunidad.

Diseñadores

Necesitamos gente como tú para que Ágora entre por los ojos, sea intuitivo y la experiencia de usuario sea estupenda. Un diseñador vale más que mil palabras.

Ciudadanos, Activistas

Si no fuese por tí, todo esto no estaría pasando. Eres a quien más necesitamos. Necesitamos ideas, hacer pruebas de usuario, traducir a diferentes idiomas, amigos que nos animen y apoyen.

Traductores

A medida que avanza el software, hay que mantener las traducciones que ya tenemos al Español, al Vasco, al Gallego. También necesitamos traducciones al Valencià, Catalán.. ¿quieres colaborar con una traducción a tu idioma preferido? no dudes en aportar si sabes idiomas.

Abogados

Un software de votación necesita tener unas condiciones de usuario, una política de privacidad, una política de cookies, cumplir con la LOPD. El código legal no es fácil de cumplir y lo sabes mejor que nosotros, por eso te necesitamos.

Periodistas

Lo que hacemos no sabemos explicarlo en palabras, pero tú sí. Si no nos conocen, no existimos. Vente y comunícanos con el mundo real.

¿Dónde es?

El evento se celebrará en Madrid, , junto al espacio Matadero y el acceso a Madrid Río, C./Maestro Arbós, 9 28045. Está a 3 minutos andando de la parada de metro Legazpi (líneas 6 y 3).

Ver mapa más grande

¿Cuándo es?

El evento se va a organizar en  dos días, el viernes 18 de octubre comienza a las 19:30 comenzaremos con una pequeña introducción de 30 minutos y luego estaremos hackeando a base de pizzas y bebidas hasta que el cuerpo aguante de madrugada. Al día siguiente el sábado 19 comenzaremos a las 12:00 y estaremos todo el día de maratón, de nuevo hasta que el cuerpo aguante. Lo damos todo por mejorar la democracia.

¿Qué necesito llevarme?

Traed vuestros portátiles y cacharros, pero sobretodo, ¡vuestra energía y cerebros! El Internet, la electricidad, el techo, mesas y sillas lo ponemos nosotros. Las pizzas y bebidas de un local cercano a buen precio. Y no te preocupes si no puedes traerte tu portátil, porque seguro que de alguna manera podrás colaborar. ¡Te esperamos allí!

Agora Ciudadana 2.1.0 release

Two months and around 250 commits after our second stable release, Agora Ciudadana team is proud to announce version 2.1 of the project. It contains lots of bug fixes, improvements and new features. The release is live in agoravoting.com and you can download the installable package with install instructions here: agora-ciudadana-2.1.0.zip.

New features

The list of new features is quite large, and among the changes are:

  • Support for multiple questions in a single election
  • Support for two election types: plurality and Single Transferable Vote (STV)
  • New voting booth
  • More compact top menu
  • New delegation graph for a delegate in an agora over time
  • New (beta) election graph, which allows to visualize liquid democracy in practice
  • Lots of small improvements

With 2.1.0 version released, the development team is already busy working on the 3.0 release, which will focus on adding support for encrypted elections. In the meanwhile, have fun voting!

Versión 2.0 de Agora Ciudadana disponible

Cinco meses y más de 260 contribuciones después de nuestra última versión estable 1.1, el equipo de Agora Ciudadana está orgulloso de anunciar la versión 2.0 del proyecto. Puedes probar esta versión online en agoravoting.com y también descargar el paquete instalable con las instrucciones de instalación aquí: agora-ciudadana-2.0.zip.

Con 2.0 introducimos la API REST v1, que proporciona un interfaz programático exhaustivo, documentado y testado unitariamente a Agora. No se han añadido nuevas características de usuario para la página web en esta release: la API REST conforma un gran cambio en la infraestructura del proyecto.

La API REST hace que agora sea más flexible al proporcionar un punto de extensión estable y estandarizado. Las extensiones que pueden ser desarrolladas con la API REST pueden proporcionar un amplio abanico de características: desde un interfaz móvil completamente dierente que conecta con este servicio web, a la creación de un ágora donde las votaciones son creadas automáticamente para cada votación en el congreso. También parece existir mucho interés en la automatización de la membresía de los usuarios en un ágora, integrando la membresía con la base de datos externa de una organización que opera un ágora.

Más allá de proveer un punto de extensión flexible y potente, este cambio de arquitectura proporciona una separación entre la lógica de la aplicación y la interaz. Una parte importante del esfuerzo en esta release se ha llevado a cabo en el desarrollo de una batería de tests concienzuda de la API REST. Esto mejora la confianza en la validez del código, ayuda a la detección de bugs y regresiones, y permitirá desarrollar código con más confianza y agilidad. También se ha adoptado sistema de integración contínua (Travis-CI).

El código de la página web ha comenzado la migración hacia el uso de la API REST para todo su funcionamiento. La migración continuará en las siguientes releases, con el objetivo de conseguir una aplicación web totalmente basada en servicios web.

Esta release no podría haber ocurrido sin los colaboradores de Agora. Es necesaria una mención especial por la colaboración de Kaleidos, quien ubicó en su sede el evento semanal Piweek en donde empleados deKaleidos, Wadobo, y Secuoyas realmente impulsaron el desarrollo de esta release.

Hackers working on Agora Ciudadana 2.0 during the piweek development sprint
Hackers working on Agora Ciudadana 2.0 during the piweek development sprint

La lista completa de colaboradores (ordenada por número de contribuciones) para esta release es:

  • Eduardo Robles Elvira
  • Daniel Garcia Moreno
  • Andrey Antukh
  • Andrés Moya
  • Javier Aguirre
  • Félix Robles Elvira
  • David Ruescas
  • Alejandro Blanco

Agora Ciudadana 2.0 release

Five months and more than 260 commits after our last stable release version 1.1, the Agora Ciudadana team is proud to announce version 2.0 of the project. The release is live in agoravoting.com and you can download the installable package with install instructions here: agora-ciudadana-2.0.zip.

With 2.0 we introduce the REST API v1, which provides a comprehensive, documented and unittested programatic interface to agora. No new user features have been developed for the web site in this release: the REST API provides a big change in the architecture of the project.

The REST API makes Agora more flexible providing a stable and standardized extension point. The extensions that can be developed with the REST API can provide a wide range of features: from a completely different mobile interface that connects with this web service, to the creation of an agora where elections are created automatically for each election in congress. There also seems to be a lot of interest in the automation of users membership changes in an agora, integrating user membership with the external members database of an organization operating an agora.

Besides providing a flexible and powerful extension point, this architecture change provides a separation between the logic of the application and the interface. An important part of the effort in this release was put in the development in a thorough battery of unit tests of the REST API. This improves the confidence on the correctness of the code, eases the detection of bugs and regressions, and will allow to develop code with more confidence and agility. A continuous integration system (Travis-CI) has also been adopted.

The code of the web site has started the migration to the usage of the REST API for all its operation. This migration will continue in further releases, aiming for a fully web-services based full-fledged one page web application.

This release could have not happened without the contributors of Agora. A special mention is needed for the collaboration of Kaleidos, which hold in their headquarters the week-long Piweek event in which employees of Kaleidos, Wadobo, and Secuoyas really pushed the development of this release.

Hackers working on Agora Ciudadana 2.0 during the piweek development sprint
Hackers working on Agora Ciudadana 2.0 during the piweek development sprint

The full list of contributors (ordered by number of commits) for this release is:

  • Eduardo Robles Elvira
  • Daniel Garcia Moreno
  • Andrey Antukh
  • Andrés Moya
  • Javier Aguirre
  • Félix Robles Elvira
  • David Ruescas
  • Alejandro Blanco

Sprint de programación de Ágora Ciudadana el Jueves 29 de Noviembre

El próximo Jueves 29 se va a celebrar un coding hackaton de Ágora Ciudadana, estamos intentando que sea en el Patio Maravillas de Madrid (aun por confirmar el lugar). También participarán hackers de Wadobo de forma online, y animamos a todo el que quiera unirse a participar de una u otra forma. El evento comenzará a las 10:00 de la mañana y estaremos todo el día y noche hasta que el cuerpo aguante.  Ágora es una red social de votaciones escrita en django, con bootstrap y el objetivo en este hackaton es hacer (o al menos comenzar) una refactorización:

  • separar el modelo de la vista, modularizando el código para hacerlo más flexible (permitir de forma más escalable diferentes tipos de votaciones, separar en diferentes ficheros cuando tenga sentido, etc)
  • crear un API REST de todo Ágora
  • mantener una batería de tests unitarios sobre dicha API. crucial para un sistema de votaciones
  • convertir Ágora en una aplicación web basada en backbonejs que se conecte con el servidor únicamente mediante la anterior API REST

Se partirá de una API propuesta y documentada, que se explicará al comienzo, modificaremos si es necesario y acordaremos entre todos. Luego implementaremos una versión usable de “paja” de la API, y nos dividiremos el trabajo en varios grupos que trabajarán en paralelo sobre las siguientes tareas:

  • implementar la API
  • implementar tests de la API
  • implementar la aplicación web en backbone usando la API