Ex Director de Tecnología (2017-2019)
Comunicador Social de la Universidad de Lima. Antes colaborador en GNOME, Debian, WebKit.
En las próximas elecciones municipales de octubre, ONPE implementará el Voto Electrónico Presencial, reemplazando la tradicional cédula de papel con tablets. En esta segunda entrega de nuestra serie sobre el VEP, hablaremos de los problemas técnicos que hemos detectado.
Ex Director de Tecnología (2017-2019)
Comunicador Social de la Universidad de Lima. Antes colaborador en GNOME, Debian, WebKit.
Hace unas semanas estuvimos presentes en el evento de «Hackathon» de ONPE sobre la seguridad del Voto Electrónico Presencial (VEP). Aunque se explicaron algunos conceptos del software y hardware que se usará en las elecciones de Octubre, salimos con algunas preguntas que nos parece son importantes para todos, como ciudadanos antes que especialistas.
Durante la capacitación para la hackathon, el personal técnico de ONPE explicó a grandes razgos la arquitectura y el diseño del sistema del VEP. De manera resumida, el VEP consiste en que los electores seleccionen su preferencia electoral, por ejemplo alcalde para su distrito, en una pantalla en lugar de en una cédula de papel, como toda la vida.
El «pitch» de venta de ONPE es que esta solución va a hacer más rápido y simple el voto, va a hacer más rápidos los resultados, y es «cien por ciento segura».
De cara al votante, el sistema del VEP está dividido en dos componentes: la estación de identificación y la estación de votación. Ambas estaciones consisten en un tablet Samsung Galaxy que usa un sistema Android personalizado («ONPEDroid»), y una aplicación visual que cumple las funciones específicas de cada estación.
El proceso está pensado para que el votante llegue a la mesa de sufragio, se identifique en la primera estación, que es manejada por los miembros de mesa, reciba una tarjeta que le permite votar en la estación de votación, y luego devuelve la tarjeta a los miembros de mesa, cerrando el proceso.
La comunicación entre estas dos estaciones es mediante tarjetas con chip, smartcards, tales como las de débito o crédito que usamos diariamente. Ninguno de los tablets está conectado a internet.
##FOTO
Aunque ya escapa a la intención de este artículo, también hay otros dos sistemas que son de particular interés desde el punto de vista de la seguridad: el sistema de transmisión de resultados, y el sistema de despliegue del software a los tablets.
El sistema de transmisión de datos es un punto obvio de ataque, lo único que sabemos de este aspecto es que se usan certificados digitales para la comunicación, y que la información entregada por cada estación es recibida cifrada, pero no sabemos si es transmitida a la central de ONPE cifrada o no.
Por otro lado el despliegue del software a los tablets, es decir la instalación del software de ONPE en cada tablet antes de ser distribuidos, también es un punto crítico de potencial ataque por parte de un actor malicioso o infiltrado en ONPE. De esto tampoco logramos recoger detalles.
Nuestra primera preocupación es que justamente estos procesos, altamente técnicos, son difíciles de dimensionar por parte de personal o ciudadanos que no son especialistas. Para un observador casual, transmitir los resultados por internet podría sonar infalible, pero como cualquier entusiasta del software sabe, eso es mas bien una gran superficie de ataque si no es manejada con mucho cuidado por los detalles.
El sistema base de los tablets para el VEP es Android, específicamente «ONPEDroid», una versión personalizada por ONPE. Según lo que explicaron, ONPEDroid está basado en Android KitKat 4.4 (cuyo soporte terminó en 2014), con los sistemas de red, wifi, bluetooth, navegación y notificación desactivados.
Además, ONPEDroid tiene un servicio de «cripto sistema» desarrollado internamente por ONPE (!!), un sistema GNU/Linux virtualizado para poder imprimir desde los tablets (!!!), y las aplicaciones de votación o identificación. El sistema además viene configurado con llaves de cifrado, que se corresponden entre la estación de votación y la estación de identificación, no está claro cómo se usan estas llaves o dónde se almacenan.
A pesar de las repetidas menciones de nombres y tipos de algoritmos y seguridad basada en llaves, no se explicó exactamente para qué o cómo son parte del sistema, especialmente en el contexto del «cripto sistema». Tampoco se dio ningún detalle sobre cómo se generan estas claves, dónde se administran, o cómo se comprueba luego si los tablets estaban tal como salieron del centro de despliegue de software.
La primera pregunta en todo este enredo es justamente qué código ha desarrollado ONPE y cómo exactamente funciona. Es de especial interés entender cómo están garantizando la integridad de los datos y su cifrado. El personal de ONPE mencionó que hay hashes de comprobación a lo largo del sistema pero sin ver el código es imposible saber qué tan fiable es el proceso de creación de los hashes, y de validación de los mismos.
Un posible problema, por ejemplo, sería que los hashes se corresponda al número de serie de la máquina, o al nombre de archivo («votos.xml», por ejemplo). O quizá el código que comprueba si el hash es válido da por asumido que el archivo ya fue verificado en otra forma previamente, o solo verifica el hash del archivo, pero no la coherencia interna del contenido.
Igualmente nos gustaría haber tenido oportunidad de conocer cómo es el formato XML en el que se almacenan los votos en la estación de votación, qué se incluye en las tarjetas SD de backup en las estaciones de votación, cómo se transmiten los datos a la central de acopio, si es que hay opciones de desarrollo que por error podrían quedarse activadas, si es que las claves de cifrado dependen de algún factor externo, exactamente cómo funciona el sistema de despliegue del software a los tablets en la central de ONPE, etc.
La complejidad y cantidad de partes involucradas en el sistema no es pequeña, y en todas esas interacciones es donde existe el potencial para errores, o problemas de seguridad. No es necesario imaginar un escenario de catástrofe en el que un actor malicioso logra vulnerar la seguridad del VEP, bastaría con que los tablets fallen o comiencen a emitir errores a mitad de jornada, cosa que una cédula de papel no hace.
Dentro de lo que pudimos conocer del sistema tomamos nota de algunos factores particulares que pueden presentar los problemas más graves. Sin conocer el código, no podemos más que especular, pero nos parece razonable que estos sean puntos de análisis.
Según explicó el personal de ONPE, las estaciones de votación vienen precargadas con un archivo XML que contiene una cantidad total y fija de líneas donde se almacenan los votos emitidos. Estas líneas, conocidas como nodos o registros, vienen ya cargadas y se usan de forma aleatoria para evitar que posteriormente se pueda identificar a un elector según el momento en que votó.
Es decir, en vez de registrar un voto tras otro, de forma secuencial (por ejemplo, del voto #000 al #230), el archivo XML ya viene cargado con el total de registros necesarios (en este ejemplo 230), y cuando se registra un voto se selecciona de manera aleatoria dónde almacenarlo. De esta manera el primer votante podría ser almacenado en el registro #129, el siguiente votante podría ser registrado como el #012, y así sucesivamente.
La estación de votación además tiene tarjetas de memoria SD que sirven como backup en caso de que el tablet fallase. El backup busca proteger los votos emitidos, para que siempre se pueda contabilizar lo votado, así haya algún error durante el proceso.
Nuestras dudas respecto a esa tarjeta SD es exactamente qué contienen y cómo se valida la confiabilidad e integridad de las mismas. Si bien a lo largo del sistema de ONPE se repite e insiste en el concepto de cifrado y hasheado de todos los elementos, ese tipo de medidas depende siempre de qué tan bien escrito y considerado está el código que valida las medidas.
Un ejemplo sería que para vender licor nos pidiesen nuestro DNI, pero el encargado de verificar nuestro DNI hubiese perdido sus lentes. Sí, hay una comprobación de la medida de seguridad (el DNI), pero dicha comprobación no es óptima.
Por último nos queda una fuerte duda sobre cómo y qué es lo que ONPE ha desarrollado o añadido a Android. Durante las presentaciones se mencionó el famoso «cripto sistema», y una serie de cambios para deshabilitar opciones de comunicación en los tablets. Todo esto suena muy bien, pero el nivel de complejidad de modificar e implementar un sistema operativo entero es muy alto. Solamente en la configuración del núcleo del sistema, el software que comunica el hardware con las aplicaciones, ya hay miles de opciones que requieren de entendimiento especializado para modificarse.
Además de los potenciales problemas técnicos, creemos que existen variables sociales que pueden ser fácilmente explotadas por atacantes o actores maliciosos.
Un primer problema en la promesa del VEP es que llegada la hora de cierre, bastará con unos minutos de interactuar con los tablets y le mesa de votación tendrá impreso el acta de cierre, lista para ser firmada. Sin embargo, creemos que se instala un incentivo perverso para que miembros de mesa y personeros simplemente firmen la mesa y se vayan tan pronto como puedan a sus casas.
Imaginemos un escenario en el que un personero con experiencia técnica detecta algo extraño en el cierre de la mesa. Quizá un tablet se tuvo que reiniciar, o alguna de las tarjetas con chip se perdió, o se dio por inoperativa. Si este personero exige un conteo manual, las otras cuatro o cinco personas de la mesa van a querer matarlo. A diferencia de una elección con papel, en el escenario del VEP, el conteo manual es «un último recurso». Se da por asumido que la máquina no puede equivocarse, y no puede ser engañada. Por supuesto, todos sabemos que no es el caso.
Otro problema social consiste en que en el sistema del VEP, la identificación es mediante el número de DNI (leído con un lector de código de barras, o ingresado manualmente). El presidente o un miembro de mesa recibe el DNI del votante, lo busca en el sistema, y si a su criterio la foto coincide con la persona, la persona es autorizada para votar por ese número de DNI.
A primera vista, parece el proceso de siempre, pero ahora existe una diferencia crucial: no es necesario firmar ni dejar la huella digital. Aunque esto parezca conveniente para evitar tener que quitarse la tinta de los dedos, resulta en realidad en un problema de confiabilidad.
Si anteriormente era necesario falsificar firmas y huellas para generar un voto fraudulento, en el sistema del VEP bastaría con la complicidad de los miembros de la mesa, o algún fallo de software que permita registrar los votos antes o después de la votación oficial. Recordemos que la única comprobación de identidad es la coincidencia visual de foto y persona, y eso es totalmente según criterio del miembro de mesa que opera el tablet de identificación.
Finalmente, otro grave problema social es que el conocimiento requerido para entender, identificar, y auditar problemas en el proceso del VEP es altamente especializado. No cualquier persona puede notar una manipulación técnica de los tablets o el software en ellos. Menos aún, desde fuera, la ciudadanía puede auditar las etapas del proceso.
Imaginemos un caso en el que una mesa de sufragio está compuesta por personas que tienen fobia a la tecnología. Todos conocemos gente de todas las edades que tienen profundo miedo a las computadoras para cualquier cosa más complicada que mandar correos o entrar a redes sociales. Pensemos en qué tan complicado sería engañarlas o confundirlas para manipular las estaciones del VEP frente a ellos.
Esta crítica no es exclusiva de nuestra experiencia, en 2009 la Corte Constitucional Federal de Alemania determinó que el voto electrónico era inconstitucional puesto que el público no era capaz de escrutar de manera significativa el proceso, justamente porque al volverse electrónico muchas etapas se convertían en opacas, o absolutamente incomprensibles para el público no especialista.
La pregunta sobre seguridad empieza en 5:23.
En una entrevista reciente con Canal N, Frank Guzmán, gerente de informática de ONPE, fue cuestionado sobre cómo es que el sistema del VEP estaba siendo garantizado y analizado por potenciales problemas de seguridad, dado que muchos especialistas habían manifestado sus dudas. La respuesta de Guzmán fue que la seguridad estaría justamente dada por el evento de la Hackathon.
Como dijimos recientemente, un evento de tipo Hackathon, y con claros cortes publicitarios, no es suficiente para garantizar la seguridad de un sistema tan complejo como este, menos aún un sistema que tendrá a cargo algo tan importante como la elección de autoridades populares.
Creemos que es responsabilidad de ONPE respaldar sus afirmaciones de seguridad, simpleza y confiabilidad. No es responsabilidad de estudiantes o entusiastas absorber el costo de consultorías y auditorías de seguridad que ONPE debería haber encargado de manera pública y transparente.
Es muy importante para nosotros dejar claro que nuestra exposición de estas dudas y preocupaciones no es un ataque al equipo de ONPE, ni tampoco una denuncia de malos manejos o malas intenciones. Creemos que el equipo de ONPE tiene las mejores intenciones en el desarrollo de su sistema, pero como especialistas también sabemos que desarrollar soluciones de software de esta complejidad, sin opiniones externas, es muy difícil, y es aún peor si el tema que se está atendiendo es tan crítico como la elección de nuestras autoridades. Nos parece que con el afán de mantener en secreto el sistema, se están perdiendo valiosas oportunidades de mejora.
Esperamos que ONPE flexibilice su actitud hacia su solución y tome medidas para hacerla realmente confiable, sin tener que confiar en su palabra, o en el entusiasmo de un grupo de estudiantes desvelados durante un fin de semana.
Ex Director de Tecnología (2017-2019)
Comunicador Social de la Universidad de Lima. Antes colaborador en GNOME, Debian, WebKit.
La semana pasada la ONPE anunció públicamente una hackathon sobre el voto electrónico, pero en el formulario de inscripción acabó exponiendo el nombre, fecha de nacimiento y número de todos los DNIs del Perú.
El 7 de junio, la ONPE anunció la organización de su hackathon 2018 con el título «DESAFIANDO LA SOLUCIÓN DEL VOTO ELECTRÓNICO PRESENCIAL». Según las bases del concurso, el objetivo es «…aportar en el mejoramiento de la gestión pública a través del desarrollo de soluciones tecnológicas electorales.», pero según la nota de prensa el objetivo es «fomentar soluciones tecnológicas en la gestión pública, el intercambio académico y cultural bajo un enfoque de ideas innovadoras en beneficio de los ciudadanos y la difusión de mecanismos de seguridad del Voto Electrónico Presencial, como una solución tecnológica electoral confiable.»
Sin embargo, el video de difusión parece describir un evento exclusivamente de seguridad, para poner a prueba la implementación del voto electrónico presencial:
Confundidos por estos mensajes contradictorios, decidimos investigar los requisitos de inscripción para aprovechar lo que parecía ser una oportunidad de interactuar con los equipos técnicos de ONPE y del voto electrónico.
Para inscribirse en el evento es necesario escoger un nombre de equipo y luego registrar a tres integrantes para ese equipo. Lo interesante es que el formulario no pide nombres, edades, de hecho no pide ningún ingreso de información personal. Lo único que pide es el número de DNI de los participantes.
Luego de ingresar el DNI de un integrante, el sistema indica que presionemos «VALIDAR» para cargar los datos de la persona, en este ejemplo hemos usado el DNI del Presidente Vizcarra. Curiosamente, alguien ya ha registrado el DNI del ex presidente PPK.
Al presionar «VALIDAR», el sistema carga el nombre, sexo, y si la persona es mayor de edad.
Si han leído nuestro blog recientemente ya deben estar sospechando cómo acaba esto. Especialmente si han leído nuestro reporte sobre cómo RENIEC expuso la fotografía de todos los DNIs del Perú.
Este formulario de inscripción carga (o cargaba) la información desde una dirección de la siguiente forma:
http://hackathon.pe/hackathon_ve/person/04412417
En esa dirección, el sistema respondía con la información de dicho DNI en el formato de datos JSON:
Esta dirección puede (o podía) ser consultada sin necesidad de identificarse con algún tipo de usuario, ni romper algún tipo de seguridad, ni nada por el estilo. Es una dirección públicamente accesible, sin ningún control de acceso, repeticiones, ni nada por el estilo.
Tal como la última vez que reportamos este tipo de problemas, decidimos revisar si era posible abusar de este error de manera automatizada y de esa forma descargar la información de cientos de personas sin mayor esfuerzo, y potencialmente la de millones de personas.
Confirmamos rápidamente que no había ningún tipo de limitación o seguridad asociada a esta dirección web, así que decidimos crear una prueba de concepto, es decir, un programa sencillo que demuestre la vulnerabilidad de forma sencilla.
Luego de una mañana de trabajo y pruebas, desarrollamos una aplicación que demostraba cómo era posible descargar automáticamente estos datos y convertirlos en un archivo de Microsoft Excel, o sea, una hoja de cálculo, una base de datos con nombres, fechas de nacimiento y números de DNI.
En el siguiente video pueden ver cómo en menos de treinta segundos logramos descargar la información de cincuenta personas, y archivarla en formato Excel, todo esto sin intervención humana, es decir, de manera completamente automática.
VIDEO JSON
HISTORIA DE COMO LO REPORTAMOS
Nuestra preocupación sobre cómo se usan nuestros datos en el Estado vuelve a confirmarse. Este tipo de aplicaciones, hechas sobre la marcha y sin mayor cuidado, parecen muy simples pero acaban generando vulnerabilidades y agujeros de seguridad que exponen información de todos los peruanos.
Nos preocupa que con el objetivo de aparentar modernidad, este tipo de problemas sigan apareciendo. En el caso concreto de esta inscripción, quizá un formulario de Google Forms hubiese sido suficiente, pero sin duda menos «impresionante».
Seguiremos vigilando este tipo de iniciativas y sus inevitables errores.
Ex Director de Tecnología (2017-2019)
Comunicador Social de la Universidad de Lima. Antes colaborador en GNOME, Debian, WebKit.
Ex Director de Tecnología (2017-2019)
Comunicador Social de la Universidad de Lima. Antes colaborador en GNOME, Debian, WebKit.
Como parte de nuestro trabajo de facilitar derechos y libertades mediante tecnología, hoy compartimos una pequeña aplicación que desarrollamos recientemente para monitorear sitios web en búsqueda de cambios. La llamamos «guachidog» y está disponible desde hace unos días en GitHub de Hiperderecho.
El problema
En nuestro trabajo diario de monitoreo legislativo, una de las cosas más comunes que tenemos que hacer es constantemente visitar sitios web en búsqueda de cambios y novedades. La mayoría de sitios web que revisamos son sitios del estado, que no tienen funcionalidades más prácticas como feeds RSS, o suscripción a notificaciones. Así que no queda de otra más que presionar «refresh» (o recargar) una y otra vez, hasta que nos olvidemos, o encontremos lo que buscamos.
La solución
Con ese problema en mente nos preguntamos cómo podríamos automatizar el proceso, y nuestra idea fue crear una aplicación que revisara automáticamente los sitios web que le indicásemos. Para no duplicar trabajo revisamos todas las alterantivas ya existentes, y a pesar que nos gustaron algunas (y especialmente perma.cc), los requisitos y recursos que instalarlas y mantenerlas requerían eran demasiado. Nuestro objetivo era crear algo extremadamente simple de mantener, y que cualquier otra organización similar a la nuestra, quizá sin director de tecnología, pudiese echar a andar en poco tiempo y con pocos recursos.
[insertar youtube]
Así fue como decidimos basarnos en newsdiffs, una aplicación web desarrollada en un Mozilla Hackfest por X, Y y Z. Decidimos desarrollar el código más sencillo posible para facilitar que otros usuarios pudiesen fácilmente modificarlo. Sacrificamos algo de elegancia por simpleza y facilidad para quienes echen a andar el sistema, que asumimos no son programadores ni técnicos muy experimentados.
Guachidog
Hemos creado un sitio web con algunos detalles más sobre guachidog, así como una guía de instalación [link github], y un video demostrativo [link yt]. Para cualquier duda sobre el sistema pueden contactar a nuestro director de tecnología, diego@hiperderecho.org. Esperamos que esta base sea útil e incentive a implementaciones y modificaciones que sean útiles en el trabajo de monitorear la web.
Ex Director de Tecnología (2017-2019)
Comunicador Social de la Universidad de Lima. Antes colaborador en GNOME, Debian, WebKit.
En setiembre de 2017, colaboramos con SUNEDU para solucionar un filtrado de datos personales que comprometía a todos los estudiantes del Perú. Gracias al oportuno reporte de Hiperderecho, la información personal de todos los portadores de un carné universitario válido hoy se encuentra más segura.
La historia comienza con La Liga Juvenil de Defensa de Internet, un proyecto de Hiperderecho para reunir y potenciar ideas de estudiantes universitarios que quieran hacer incidencia en la sociedad usando tecnología. En nuestras interacciones con los miembros de la Liga acabamos descubriendo que el nuevo carné universitario tiene impreso un código QR en la parte de atrás. Siguiendo nuestra curiosidad, nos pusimos a revisar qué era lo que el código contenía. Para nuestra sorpresa el código era simplemente una dirección web del siguiente formato:
https://www.carneuniversitario.com.pe/Search.aspx?CodAlumno=0180020140000
Al entrar a esta dirección, se podía ver una representación web del carné universitario original, y con algunos cambios se podían ver los datos de otros alumnos:
Sin embargo, lo que hacía potencialmente peligrosa esta representación online es que los datos como nombre, carrera, universidad, estaban todos mostrados como texto simple. Es decir, resultaban fácilmente recolectables al igual que la foto del alumno, y estaban disponible como datos para ser consumidos y guardados por cualquiera.
Peor aún, como los códigos de alumno están conformados exclusivamente por números, con algo de astucia se podía automatizar el ingresar a todos los carnés emitidos por SUNEDU, desde el “0000000000000” hasta el “9999999999999”. El sistema no impedía este tipo de consultas automatizadas, y según nuestro cálculo preliminar, en un día se podría haber descargado una copia completa de la base de datos de alumnos universitarios del Perú, incluyendo nombre completo, DNI, universidad, carrera. Todo sin vulnerar ninguna medida de seguridad ni adivinar contraseñas.
Al confirmar la gravedad del problema, preguntamos a algunos estudiantes amigos de Hiperderecho qué les parecía que su información estuviese expuesta de esta manera en internet. La mayoría se sorprendió de ver sus datos disponibles de forma tan pública, y otro buen grupo encontró innecesario que con el simple cambio de un dígito se pudiese acceder a la información de cualquier otro alumno, y no solo la personal.
Reunidas estas impresiones y el análisis y evidencia del problema, decidimos contactar a las autoridades responsables. Empezamos contactando a PeCERT, la institución del estado encargada de coordinar la respuesta ante problemas de seguridad en las plataformas digitales del estado. Nos comunicamos con PeCERT a finales de setiembre pero nunca obtuvimos respuesta. De hecho, hasta ahora no sabemos nada de ellos.
En paralelo, pudimos entablar comunicación con el área de Comunicación de SUNEDU, la entidad precisamente encargada de emitir los carnés. Gracias a la intervención del área de Comunicación, logramos canalizar nuestro descubrimiento hacia el área técnica de SUNEDU y entendieron la magnitud del problema. Al poco tiempo, logramos reunirnos con ellos para conversar más a detalle de lo ocurrido. En la reunión nos presentaron las acciones que ya habían tomado luego de nuestro reporte y que planeaban tomar: una auditoría independiente al proveedor que se encargaba de manejar el sitio carneuniversitario.com.pe (el cual resulta es el proveedor también responsable de imprimir los carnés físicos), según SUNEDU la auditoría no había encontrado signos de abuso del sistema. No tuvimos acceso a ese reporte, pero creemos que es poco probable que se haya explotado la vulnerabilidad.
Adicionalmente, el equipo de SUNEDU nos aseguró que dos medidas se implementarían tan pronto como fuese posible: (1) exigir un segundo dato único antes de mostrar los datos del carné (los últimos dígitos del DNI); y, (2) añadir una salvaguarda a usos automatizados del sitio (en este caso el aditamento reCAPTCHA de Google).
Para finales de octubre pudimos confirmar que los cambios ya se habían aplicado y el sitio ya no era susceptible al error de seguridad que habíamos detectado.
Al final de la experiencia, quedamos muy satisfecho de haber encontrado en SUNEDU a una institución tan receptiva de nuestros comentarios y preocupaciones además de muy felices de haber contribuido a mejorar la seguridad de un servicio del estado.
Sin embargo, hay una lección más grande en esta historia. Seguimos igual preocupados por la manera en que instituciones del estado continúan usando nuestros datos de manera poco reflexiva, sin informarnos, y potencialmente exponiéndonos a empresas o grupos que nada tienen que ver con la relación de confianza entre ciudadanos y estado.
En este caso, tenemos que cuestionar cuál es la real utilidad de tener un código QR en el carné universitario cuando dicho código es solo un link a un sitio web que replica la información del carné. Si lo que se busca es evitar falsificaciones, ¿es realmente lo más efectivo? ¿Tiene sentido esperar que en una boletería, o en un bus, el encargado de cobrar el medio pasaje: escanee un código QR e ingrese a un sitio web en su celular solo para verificar si el carné es válido? Nuestra impresión es que la idea no tiene aplicación pragmática, más aún con los cambios ahora introducidos para asegurar el sistema contra el filtrado tremendo de datos que estaba presente en el diseño original. Consideramos que otras soluciones de verificación podrían aplicarse. Pensemos en que el DNI no tiene un sitio web donde verificarse, y no por eso la gente ha perdido confianza en ese documento.
Por otro lado, la base de datos, o cuando menos el sitio web, está alojado en un dominio privado, un .com.pe que cualquiera de nosotros pudo haber comprado, o podría comprar, y cuyos contenidos son administrados por el proveedor de la impresión de carnés universitarios para SUNEDU. No creemos que exista ningún tipo de mala fe, pero sí es necesario cuestionar si poner en manos de un tercero el distribuir esta información a través de la web es un buen cuidado de nuestro datos.
Para terminar solo nos queda desear que futuras interacciones con otras instituciones del estado en temas de seguridad digital sean tan positivas como la que tuvimos en esta ocasión con SUNEDU. Hiperderecho se debe a los ciudadanos y no a instituciones o patrocinadores, y los usuarios que merecen que su información y derechos (privacidad incluida) sean respetados por el estado.
Ex Director de Tecnología (2017-2019)
Comunicador Social de la Universidad de Lima. Antes colaborador en GNOME, Debian, WebKit.
Desde hace unos meses el equipo de Hiperderecho viene colaborando con jóvenes de diferentes universidades de Perú en un proyecto para difundir y defender nuestros derechos dentro y fuera de internet.
El proyecto, la “Liga Juvenil de Defensa de Internet”, nace de nuestro interés en involucrar voces y perspectivas diferentes a las que usualmente tendríamos acceso. Siguiendo este interés vimos una gran oportunidad en llegar a jóvenes estudiantes universitarios para desarrollar en conjunto proyectos relacionados a tecnología, aprovechando los recursos que Hiperderecho tiene disponibles, desde técnicos hasta sociales.
Ex Director de Tecnología (2017-2019)
Comunicador Social de la Universidad de Lima. Antes colaborador en GNOME, Debian, WebKit.
