Sistema Open Source para Identificar potenciales fraudes electorales, minimizar su ocurrencia e impacto.
Sistema Open Source para Identificar potenciales fraudes electorales, minimizar su ocurrencia e impacto.
Este es un proyecto Open Source (codigo libre) cuyo objetivo es minimizar y detectar la posibilidad de fraude electoral en las proximas elecciones presidenciales de Argentina donde se define finalmente quien sera presidente.
La intencion de crear este sistema es mantener y preservar la democracia y la transparencia al pueblo argentino.
Los objetivos de este sistema son:
Este repositorio tiene la finalidad de:
Estos repositorios son las partes complementarias del proyecto:
¿Qué tipos de fraude se esperan detectar? En una elección como esta, hay muchas formas de hacer fraudes si alguien controla el sistema de cómputos oficial.
Esta es la lista de Tipos de Fraudes que se quieren atacar. Esa es la columna vertebral de este proyecto, de ahí deriva toda la funcionalidad que se va a construir. Si querés, podés programar algo de lo que se necesita para alguno de los tipos de fraudes identificados, si se te ocurre algún otro tipo de fraude y cómo minimizarlo, lo podés agregar a la lista y especificar qué habría que hacer para eso. Y si tienes tiempo y energía, podrías empezar programando lo que haga falta en lo que llegan otros y te ayudan.
En este caso, el Sistema Oficial de cómputos tiene cargado correctamente todos los datos, pero aún así, el agrupamiento por Provincia / Nación es incorrecto.
En este caso, el Sistema Oficial de cómputos tiene cargado correctamente todos los datos, pero además de las mesas reales, hay mesas que solo existen en el sistema y que se usan para cambiar los resultados globales.
El tercer tipo de fraude sería que las mesas cargadas en el Sistema Oficial tienen datos diferentes a las actas de los fiscales. Esto actualmente se puede detectar a mano si el fiscal revisa el Sistema Oficial. El problema es que el sistema oficial podría mostrarle los datos correctos por un tiempo y luego cambiarlos más adelante cuando el fiscal ya los consultó y los vio correctos. Seguramente un fiscal solo verificaría una vez los datos y si están bien, daría por hecho de que eso luego no cambia más.
Estos serían gente que se inscribieron como fiscales solo para quedarse con una mesa o grupo de mesas y luego no ir o abandonar a último momento cuando es muy difícil conseguir reemplazo y reasignar sus mesas.
El sistema debe tener pre-cargados los datos de los Fiscales de Mesa y su trabajo en las elecciones PASO y GENERALES para que si en ellas se ausentaron sin causa, o de manera sospechosa, no se los vuelva a convocar para el BALLOTAGE.
Este tipo de fraude se basa en reclutar e inscribir Fiscales de Mesa que en vez de fiscalizar y defender los votos de LLA, en realidad hacen lo opuesto. Las mesas con Fiscales Judas podrían permitir que se carguen en el Sistema Oficial datos falsos porque la contabilización ya fue corrupta.
El sistema debe permitir a los usuarios del tipo Auditores Externos ver los datos de los Fiscales de Mesa para poder investigarlos y así poder inferir si son del tipo Judas o no. Los Fiscales de Mesa serán invitados a proveer información de manera opcional de sus identidades en redes sociales, y a los que lo hagan, sumarán puntos en su reputación como Fiscal. Del otro lado, un ejército de auditores externos puede investigar con su DNI y esas identidades sociales cuál es el background real de esas personas y en base a los resultados de estas investigaciones, asignarle a cada fiscal un score que puede usarse en un caso extremo para descalificarlo o al menos para observarlo con precaución.
El sistema debe cubrir el caso de fiscales que simplemente son incompetentes y por ignorancia cargan mal los datos en el sistema. Esto significa que deberían existir mecanismos para excluir datos de este tipo de fiscales o que algún tipo de usuario los pueda sobreescribir basándose, por ejemplo, en las fotografías de las actas.
El sistema debe ayudar a administrar los Fiscales de Mesa y los Fiscales Generales, para que por lo menos haya un Fiscal General en cada escuela como mínimo. Los casos donde no hay ni siquiera un Fiscal General por escuela son una pérdida gigante de votos. También debe gestionar la asignación de Fiscales de Mesa, para que ante la escasez, estos sean enviados a los lugares donde más se necesitan. Por ejemplo, a las escuelas donde haya una mayor cantidad de electores combinado con una menor cantidad de Fiscales de Mesa.
Esta APP tendría estos tipos de usuarios:
Fiscal de Mesa: El principal usuario de esta APP serían los Fiscales de Mesa de LLA. Serían quienes cargan los datos.
Fiscal General: Supervisa a los Fiscales de Mesa en una determinada escuela. El fiscal general DEBE tomar fotos de todas las actas de todas las mesas de la escuela a la cual fue asignado. En teoría siempre hay aunque sea un fiscal general, aunque pudiera no haber ningún Fiscal de Mesa. Si lo hace y las sube al sistema, podemos tener detrás un ejército de voluntarios por internet que transcriba los valores de las fotos en registros numéricos y así tener la primera versión de datos en el sistema bien temprano después del cierre de la votación. Debería ser una responsabilidad del Fiscal General tomar las fotos de todas las mesas de una escuela, porque de esa manera podríamos evitar el tipo de fraude Mesas Inexistentes en el que en el sistema oficial aparece luego alguna mesa que en la realidad no existió. Si cada uno de nuestros fiscales toma foto de TODAS las mesas físicamente presentes en cada escuela, podríamos detectar esas mesas fantasmas.
Delegado del Partido: Son personas de confianza de LLA que durante la votación pueden ir de una escuela a otra para apoyar y auditar a los Fiscales Generales y a los Fiscales de Mesa.
Auditor Interno: Serían gente de LLA que analizaría los datos cargados por los Fiscales de Mesa y los compararían con los datos oficiales. La APP trataría de automatizar esa comparación con el objetivo de detectar diferencias y potenciales fraudes.
Auditor Externo: Sería cualquier persona que complete el proceso de sign up como auditor externo. Este perfil tendría acceso a la funcionalidad necesaria para consultar datos y documentos digitalizados y reportar anomalías que luego serían levantadas por los Auditores Internos. Es importante notar que el fraude se tiene que detectar lo antes posible porque una vez que se declara a alguien ganador, difícilmente eso se vuelva atrás sin importar la cantidad de denuncias de fraude que haya después. Eso elimina la posibilidad de solo cargar una foto y luego que alguien en algún momento digite los datos de esa foto. En general, la detección de los distintos tipos de fraude debería ser instantánea y es más, si es posible, cualquier persona de la población en general debería poder ver el recuento de votos de acuerdo a los fiscales de LLA incluso antes que salgan los datos oficiales, cosa de que antes de que se nombre un ganador ya haya una reacción del público general ante un potencial fraude de gran escala.
Público: Cualquier persona que quiera ver los resultados en línea, de acuerdo a los datos cargados por los Fiscales de Mesa de LLA. También podrán navegar por toda la información disponible en el sistema.
Carga de Datos: La APP permitiría a los Fiscales de Mesa cargar los datos de las mesas que supervisan. El sistema acumularía todos los datos en una base de datos.
Reportes para Auditores: El sistema generaría diferentes tipos de reportes orientados a detectar fraude, basándose en los datos cargados por los Fiscales de Mesa y los datos Oficiales.
Consultas para el Público: El sistema permitiría ejecutar diferentes tipos de consultas para el público en general.
Mapa / Reporte de Fiscales Trabajando: El sistema debería permitir saber en línea dónde hay y dónde no hay fiscales, así a través de las redes se puede movilizar a la gente para que vaya a fiscalizar, especialmente en los casos más extremos donde, por ejemplo, no hay nadie. Un reporte en línea ordenado por gravedad de dónde hacen falta fiscales con urgencia sería óptimo. Sería más grave en las escuelas con mayor cantidad de electores donde hay la menor cantidad de fiscales. De ahí podrían tomar los datos que estarían actualizados a toda hora durante la votación de dónde es más crítico llamar por las redes para que se refuercen esas escuelas.
Mapa / Información de Bunkers-Sucursales: El sistema debe permitir visualizar un mapa o varios mapas en los cuales se debería poder ver dónde ir a buscar boletas personales y así que la gente pueda ver dónde ir a buscarlas.
Cloudflare: Se utiliza para la gestión de DNS, CDN y seguridad en la capa 7.
React SPA: Alojada en S3.
API Express: Hospedada como un monolito en una función Lambda. Esto permite flexibilidad para los desarrolladores y evita la complejidad de tener que adaptarse al desarrollo de microservicios.
API Gateway: Aquí ocurre la magia de hacer un monolito serverless, ya que todos los endpoints se proxean a la Lambda que ejecuta el servidor Express.
DynamoDB: Otro servicio serverless que nos evita tener que lidiar con configuraciones de escalado y posibles picos inesperados de tráfico. Esto asegura que la aplicación pueda soportar altos niveles de carga sin fallar.
S3 Bucket: Aquí se subirán assets en forma de videos o imágenes como pruebas de fraudes.
Hay muchas formas de abordar la arquitectura de un sistema como este. Enumeremos primero los criterios más importantes que queremos seguir y, a partir de ellos, derivaremos la arquitectura que emerja.
El sistema completo debe desarrollarse y probarse en tiempo récord. Ese es el principal contraint.
Necesitamos poner a trabajar a muc
No open issues yet, or sync has not completed.