Lecciones Aprendidas

Respecto a la metodología de SEAGLASS

Por cada etapa del proyecto:

1. Formalización de alianzas y pruebas de configuración inicial

1. Si bien la convocatoria a participar como Organización Coordinadora Local fue bastante exitosa, solicitamos el compromiso dentro de las mismas en mantener el proyecto fuera del alcance de los medios de comunicación de cada país mientras se llevara a cabo el desarrollo del proyecto FADe.
2. Durante el desarrollo del proyecto, la compra de los teléfonos convencionales se convirtió en una actividad bastante complicada, dado el stock limitado en el mercado del modelo específico que considera la metodología. Esto podría ser una limitación para otros grupos que potencialmente quieran desarrollar la metodología SEAGLASS.
3. La compra de los cables de comunicación T191 se convirtió en una tarea bastante complicada, ya que el envío y la recepción podían tardar un par de meses. Por eso nuestro equipo decidió comprar cada pieza por separado y fabricarlas nosotros mismos. Esto requería cierto nivel de habilidad y conocimientos de electrónica. Click aquí
4. Después de experimentar un poco, aprendimos que es esencial tener cuidado con la forma en que se ensamblan los cables Serial – USB. En algunas pruebas, el uso físico exhaustivo afectó su correcto funcionamiento. Estas fallas se corrigieron al final. Además, no es fácil conseguir el convertidor de USB a serie en la mayoría de los mercados latinoamericanos. Sugerimos visitar proveedores minoristas e internacionales para obtener el stock necesario del proyecto.

2. Instalación e inicio de pruebas de campo.

1. Aunque la guía escrita para reproducir el montaje y la plantilla de actividades a desarrollar durante la capacitación es la misma para cada una de las Organizaciones Coordinadoras Locales. Fue necesario adecuar los contenidos en función de la naturaleza de cada caso particular en cuanto a geografía local, léxico y nivel técnico.
2. Inicialmente, fueron probadas tres versiones diferentes de la aplicación SEAGLASS (0.7.1 a 0.7.3) debido a errores con la recopilación de datos móviles, lo que dificultó la preparación de los materiales de capacitación de manera eficiente. La distribución de aplicaciones a través de Google Play Store puede afectar la disponibilidad de la aplicación.
3. Aunque la última versión de la aplicación SeaGlass tenía una interfaz con una experiencia de usuario cómoda, aún tomó tiempo administrar y comprender todas sus funciones.
4. La experiencia de usuario de la aplicación SEAGLASS resultó confusa para algunos operadores locales con respecto a la redacción y la terminología. Recomendamos hacer una evaluación de USX para detectar posibles mejoras en la aplicación.
5. Cada Organización Coordinadora Local debe desarrollar su modelo de amenazas. Se recomienda encarecidamente que cada organización sea tratada de forma individual.
6. Resultó necesario asignar una cantidad de sensores fijos y sensores de respaldo durante el desarrollo del proyecto, dependiendo de las dimensiones de cada ciudad y las características locales.
7. Dado el contexto de las ciudades seleccionadas, variables como cortes de energía, dificultades en el tránsito de automóviles, organizaciones que cierran sus oficinas, entre otras, debieron ser consideradas para construir un plan de respaldo.
8. A medida que cambia la realidad de una ciudad, o el colectivo activista, necesitábamos adaptar el plan de medición de forma dinámica con la Organización Coordinadora Local.
9. Para implementar la aplicación SEAGLASS en los teléfonos con sensor, decidimos que cada teléfono debe tener su propia cuenta de Google no relacionada con el resto de los sensores por razones de seguridad. Esto trae algunos problemas logísticos con respecto a la activación de nuevas cuentas, dado que necesitamos vincular cada nueva cuenta con un número de teléfono válido. Por lo tanto, no podemos activar más de dos (2) cuentas nuevas con el mismo número.
10. Es muy recomendable probar la compatibilidad entre el cable serial – USB y los teléfonos convencionales justo antes de implementar todo el sensor. En uno de los casos, la Organización de Coordinación Local había encontrado los teléfonos convencionales localmente, incluso del mismo proveedor que usamos para otras ciudades probadas. Sin embargo, una vez que llegamos allí, nuestro Cable Serial – USB no funcionó bien con esos teléfonos, por lo que tuvimos que quedarnos más tiempo del planeado y construir nuevamente los cables Serial – USB, que afortunadamente terminaron funcionando correctamente.
11. Una de las ciudades tuvo problemas con el despliegue de los sensores. Específicamente, un grupo de dispositivos antiguos (o teléfonos convencionales) tenía bloqueado el bootloader, lo que imposibilitó la instalación de firmware personalizado. Esto tuvo que ser resuelto junto con el equipo desarrollador de SEAGLASS, generando un entorno que permitiera actualizar este equipo para instalar un sistema operativo sin restricciones en el bootloader.
12. El sensor SEAGLASS configurado con el cable construído para conectar la carga y la transmisión de datos estuvo presentando problemas de funcionamiento. Esto podría deberse a la demanda eléctrica del teléfono inteligente y a la fragilidad física de los cables soldados, lo que hace que su uso sea más conveniente en términos de pasos para ejecutar el sensor, pero más propenso a errores que requieran la sustitución del cable o una mayor resolución de problemas.
13. Los colaboradores involucrados con el proyecto comentaron que la configuración del sensor SEAGLASS les resultaba engorrosa de operar, y que podría mejorarse migrando su arquitectura a un enfoque Raspberry Pi, en el que sea posible controlar el encendido el dispositivo. Otra sugerencia es proponer una estrategia utilizando solo un teléfono inteligente.
14. Consideramos una oportunidad para desarrollar análisis futuros sobre la infraestructura de red local actual, la cual pueda servir como insumo para proponer mejores prácticas y regulaciones para asegurar configuraciones de red más armónicas. Las líneas de base de seguridad y privacidad pueden beneficiar a los usuarios e investigadores, facilitando la detección de anomalías que pueden apuntar a una vigilancia ilegal.
15. Consideramos como una limitación que la metodología SEAGLASS ha sido diseñada solo para protocolos 2G / 3G. Hemos propuesto investigar formas de portar su tecnología a 4G / LTE y establecer las bases para los desarrollos de 5G. Esto también puede incluir el uso de diferentes partes del sensor, y también abordar las preocupaciones sobre las dificultades para encontrar equipos descontinuados.
16. Muchos de los teléfonos inteligentes adquiridos para construir los sensores y ejecutar el proyecto eran de la misma marca y modelo. Estos teléfonos tuvieron un incidente con respecto a una actualización de software que deshabilitó sus capacidades de red, por lo que tuvimos que informar a los Coordinadores Locales que no actualicen esos teléfonos hasta que se encuentre una solución o solución alternativa.
17. Una dependencia crítica utilizada por la canalización de análisis de datos del lado de Seaglass (Wireshark) tenía un error en una funcionalidad de uso poco frecuente que retrasó el proceso mientras se resolvía. El equipo de Seaglass tomó las acciones correctivas correspondientes y la parte afectada del proceso de análisis siguió funcionando sin problemas.

3. Período de prueba exclusivo

1.  Se debió entregar baterías y cables seriales USB de repuesto a la Organización Coordinadora Local para que suministren a los colaboradores en caso de ser necesario.
2. Algunos de los cables seriales USB tomados de una ciudad de interés a otra (con un modelo de adaptador serial USB) se dañaron durante un viaje. Se cree que el adaptador es sensible a los rayos X utilizados en los aeropuertos.
3. Algunos de los colaboradores locales pidieron no recibir ningún informe detallado del estado de la ubicación por motivos de seguridad; En respuesta a eso, decidimos revisar y cambiar la forma en que se creaban los informes para abordar el riesgo de compartir información de ubicación exacta.
4. La lectura de los datos fue extraordinariamente compleja y exigente a nivel computacional. Se sugiere desarrollar un plan de desarrollo detallado y progresivo, en el que no solo se monitorea la ubicación de los sensores en tiempo real para verificar que se recolectan los datos, sino también las zonas geográficas, para que la información pueda concluir tanto de las torres de telefonía móvil como de los potenciales receptores IMSI.
5. El análisis para determinar parte de la información requirió conocimientos medios o avanzados de tecnología móvil para interpretar valores específicos que actualmente no se encuentran referenciados en los manuales básicos.
6. Hubo muchas cosas con respecto a las implementaciones técnicas de los operadores que aprendimos durante este proyecto, especialmente que existe una disparidad considerable en cómo se construyen las redes de comunicación, incluso en el mismo país.
7. Las baterías de los teléfonos convencionales no duraban demasiado. Al profundizar en este problema en las ciudades en estudio, notamos un patrón en el que la altitud de los lugares monitoreados estaba relacionada con el momento en que los teléfonos convencionales se quedaron sin energía. La ciudad más alta dio como resultado una duración de la batería en los teléfonos convencionales de aproximadamente un 20% menos en comparación con las ciudades más cercanas al nivel del mar. Tras investigar el caso, encontramos algunas variables interesantes que podrían estar afectando el comportamiento de estas baterías:
   1. La altitud en sí no afecta directamente la duración de las baterías, ya que están selladas y la presión de las mismas es constante.
   2. La edad de las baterías desde su fabricación podría afectar a su duración, decayendo con los años y siendo bastante más sensibles a otras variables. Dado que este modelo de teléfono data de finales de 2005, suponemos que muchas de estas baterías se fabricaron hace al menos diez años.
   3. La cantidad de estaciones base también puede afectar cuando el teléfono busca una señal móvil y el tiempo de descarga. Sin embargo, dado que los teléfonos convencionales siempre están haciendo la misma tarea de encontrar nuevas estaciones base, esto no explica la diferencia en el tiempo de descarga entre las diferentes ciudades monitoreadas.
   4. La variable principal que puede afectar el tiempo de descarga de las baterías son las temperaturas extremas. En climas más fríos, las baterías pueden reducir su duración en una proporción considerable. Algunas fuentes incluso dicen que cada 5 grados por debajo de los 20 grados Celsius, el tiempo de descarga de la batería se reduce a la mitad.
   5. Para este escenario, recomendamos encarecidamente usar los sensores en un contexto dentro de temperaturas aceptables mientras se usan (20 a 35 grados Celsius). Esto se puede hacer llevando el sensor dentro de vehículos con temperatura controlada o cerca del cuerpo del operador si se usa para caminar, andar en bicicleta, etc.

4.  Procesamiento de datos

1. Fue increíblemente complejo en términos de tiempo el análisis masivo de datos. Para proyectos futuros, sugerimos requerir un método diseñado exclusivamente para lograr un procesamiento de datos más eficiente.
2. Dada la importante cantidad de datos recopilados por los sensores, hemos concluido que aún quedan muchas pruebas potenciales que se pueden desarrollar y mejorar para detectar anomalías en la red. Por ejemplo, análisis del código de área de ubicación, análisis de la intensidad de la señal para celdas específicas, estimación de la distancia de la torre, comparación con valores conocidos, entre otras.
3. Afrontamos varios desafíos con respecto al análisis de los resultados al procesar gran cantidad de datos en el marco de este proyecto. Se requirieron decisiones precisas en términos de eficiencia computacional y capacidad de la infraestructura utilizada. En este punto del análisis, el equipo de SEAGLASS toma muestras de datos, prueba diferentes metodologías de análisis, como flujos de trabajo básicos propuestos por un mismo grupo o modelos de entrenamiento de aprendizaje automático para evaluar su efectividad mediante la gestión independiente de los datos.
4. Durante los pasos iniciales de análisis de resultados, se encontró un error en una biblioteca de análisis de tráfico popular (Wireshark), que impedía el procesamiento efectivo de los paquetes de comunicaciones telefónicas. Dado que el análisis de este tipo de información es menos común, el error no se vio hasta ese momento.
5. Al analizar los datos correspondientes a diferentes entornos en cuanto a los lugares donde inicialmente se probó la metodología, se advirtió que existen múltiples disparidades en la trayectoria en la que se configuran las antenas celulares. Esto 1) hace que sea aún más difícil comprender la línea de base para detectar anomalías, y 2) abre una gran cantidad de posibilidades para encontrar otros tipos de anomalías que pueden conducir o no a la detección de IMSI-Catchers. Tales lecturas distintivas se recogieron, entre otras cosas, a las características de las propias infraestructuras de telecomunicaciones, dado que, en algunos casos, estas instalaciones habían superado varias décadas desde su instalación.
6. Durante la sesión de trabajo en la UW, se percibió que existen múltiples formas de detectar anomalías a partir de los datos recopilados del teléfono celular, muchas de las cuales necesitan tiempo para ser validadas antes de su integración en flujos de trabajo e informes de resultados públicos. Por eso decidimos que los resultados a publicar serán dinámicos, y se irían refinando y añadiendo nuevos casos a medida que se analizan y validan.
7. El servidor donde se centralizan los datos pertenece a la Universidad de Washington, lo que dificultó aumentar el volumen de datos (y con ello, la cantidad de lugares a monitorear). Tales datos son enviados porque en cierto modo dependemos de su personal para preparar las migraciones. Esto ralentizó la transmisión de grandes actualizaciones de bases de datos. Recomendamos abrir la fuente del servidor y agregar a la aplicación una opción para configurar un servidor de recepción de datos SEAGLASS auto hospedado.
8. Fue notable la diferencia en los datos recopilados entre las metodologías SEAGLASS y Crocodile Hunter. En el primero se recopilaron más de 300 campos de parámetros de red, mientras que en el segundo solo 19. Esto se debió probablemente a que Crocodile Hunter recopiló menos información y realizó varios procesamientos internos para calcular anomalías de forma automatizada durante el monitoreo.
9. Dado que necesitábamos reasignar sensores a nuevos operadores y ciudades, tuvimos que regenerar nuevos códigos de identificación “UUID” en la aplicación SEAGLASS para facilitar la futura separación de los datos recopilados por este dispositivo.

5. Promoción de metodología y resultados

1. Fue bastante desafiante definir qué tecnologías usar para construir el sitio web de modo que no hubiera incompatibilidades con los datos resultantes del análisis de la información recopilada. Para abordar esto, se decidió implementar herramientas que ofrezcan la flexibilidad necesaria para incluir código arbitrario dentro de las páginas que componen el sitio.
2. Durante el proyecto, uno de nuestros principales objetivos fue traducir los temas técnicos de la investigación a un lenguaje más sencillo para audiencias no técnicas, construyendo toda la documentación teniendo en cuenta la premisa de que los usuarios podrían no estar familiarizados con los conceptos básicos de las comunicaciones por teléfono móvil. Nos dimos cuenta de la necesidad de tener más información disponible para los actores directos involucrados.
3. Basado en una gran cantidad de preguntas, preocupaciones e interés de la audiencia, este tema parece ser fascinante no solo para investigadores académicos sino también para periodistas, medios de comunicación, activistas y ONG de libertad de expresión, dado el enfoque para usar esta metodología como herramienta para abogar contra el uso ilegal de prácticas de monitoreo.

Respecto a la metodología de Crocodile Hunter

Por cada etapa del proyecto:

 1. Formalización de alianzas y pruebas de configuración inicial

1. Si bien la convocatoria a participar como Organización Coordinadora Local fue bastante exitosa, solicitamos el compromiso dentro de las mismas en mantener el proyecto fuera del alcance de los medios de comunicación de cada país mientras se llevara a cabo el desarrollo del proyecto FADe.
2. Dado que estuvimos reutilizando los sensores SEAGLASS en esta segunda vuelta del proyecto, como complemento de los sensores Crocodile Hunter, se hizo necesario realizar algunos ajustes en la configuración del teléfono inteligente, tales como eliminar toda la información histórica que pudiera comprometer de cualquier forma la identidad de los antiguos operadores.
3. Dado que el código del sensor Crocodile Hunter se estuvo actualizando de manera continua, y las Raspberry Pis adquiridas por el proyecto funcionaron al límite de sus capacidades, consideramos medidas preventivas para “overclock” (forzar altas velocidades del procesador) las Raspberry Pi 4 e impulsar un plan de respaldo de sustitución con laptops. En el peor de los casos, en el que, en algún momento, las Raspberry Pis no fueran capaces de administrar las tareas del software de Crocodile Hunter.

2. Instalación e inicio de pruebas de campo

1. La configuración del software Crocodile Hunter cambió con el tiempo, lo que obligó al proyecto a adaptar el rediseño en términos de alcance, el equipo necesario y los requisitos de capacidad local.
2. Esta metodología no era compatible con el caso de uso de los operadores que trabajaban en las recolecciones de datos. Esto se debe principalmente a que se requiere una conexión a Internet activa, lo que pudo ser un desafío para garantizar cuando no es posible configurar el sensor en una instalación portátil sin los conocimientos técnicos. (puntos de acceso wifi, una configuración previa a un Hotspot y, potencialmente, conexión SSH). Recomendamos iteraciones futuras del software, incluido un modo offline, para capturar datos sin Internet, y que luego, el sensor se pueda encender y conectar a Internet con un cable, realizando las comprobaciones de recolección y pruebas que requieren conectividad.

3. Período de prueba exclusivo

1. Experimentamos cierto grado de flexibilización con respecto a las medidas de confinamiento (era Covid-19), lo que facilitó la construcción de rutas a través de las ciudades en estudio. Adaptamos nuestra estrategia a las medidas de cuarentena y mantuvimos todos los controles de seguridad sanitaria, confiando principalmente en lo posible en vehículos particulares para realizar la recolección de datos.
2. Descubrimos que el despliegue de sensores Crocodile Hunter (cubre 4G / LTE) era considerablemente más accesible en una variedad de configuraciones que los sensores SEAGLASS usados ​​anteriormente (cubren 2G / 3G). Por ejemplo, en vehículos, bolsos, y lugares estáticos como edificios.
3. Experimentamos algunas fallas al probar nuevos sensores. Después de investigar, vimos que los receptores GPS utilizados en el proyecto tienen una sensibilidad deficiente en interiores, incluso dentro de los coches a través del parabrisas. Por lo tanto, hicimos un parche interno en el proceso de instalación para configurar los sensores sin usar el receptor GPS y modificamos el posicionamiento de los sensores para que apunten al cielo abierto cuando están en funcionamiento.

4.Procesamiento de datos y generación de informes

1. La necesidad de los sensores Crocodile Hunter de tener acceso a Internet durante la medición resultó problemática en algunos casos en los que los operadores no tenían la habilidad técnica para conectar los sensores a puntos de red inalámbrica o cableada. Esto generó problemas con los datos y la verificación de las antenas en servicios de acceso público como OpenCellID. El análisis se realizó posteriormente de forma manual con este servicio y con la API de geolocalización de Google.
2. Fue notable la diferencia en los datos recopilados entre las metodologías SEAGLASS y Crocodile Hunter. En el primero se recopilaron más de 300 campos de parámetros de red, mientras que en el segundo solo 19. Esto se debió probablemente a que Crocodile Hunter recopiló menos información y realizó varios procesamientos internos para calcular anomalías de forma automatizada durante la recolección.
3. Recopilamos considerablemente menos datos que antes durante el monitoreo anterior. Según nuestro análisis, las razones podrían ser:
4. Un plazo de medición más reducido: dos meses frente a tres meses en el lote inicial de las ciudades.
5. Las medidas de confinamiento debido a COVID-19, recientemente implementadas por los gobiernos que nos impidieron hacer las rondas regulares en las ciudades de interés.
6. Las posibilidades reducidas de los colaboradores locales, que, dado el contexto actual, fueron capaces solo de albergar los sensores en lugares estratégicos pero fijos.
7. Algunos datos críticos recopilados y calculados por el sensor no tenían consistencia física, lo que dificultó el uso de los datos para el análisis. Por ejemplo, el valor de la distancia estimada es inconsistente al punto de ser ignorado en nuestro análisis, siendo un valor crítico en caso de que fuese confiable.
8. El sensor Crocodile Hunter almacenó una gran cantidad de parámetros en forma cruda y unificada (Toda la Información del Sistema Bloque 1 de la conexión con la torre telefónica), lo que dificultó el uso de esos datos para someterlos a análisis. Propusimos iteraciones futuras para ayudar al equipo de la Electronic Frontier Foundation para desarrollar el código necesario para analizar estos datos sin procesar, en docenas de parámetros que pueden elevar considerablemente la calidad del análisis.

5. Promoción de metodología y resultados

1. Fue bastante desafiante definir qué tecnologías usar para construir el sitio web de modo que no hubiera incompatibilidades con los datos resultantes del análisis de la información recopilada. Para abordar esto, se decidió implementar herramientas que ofrezcan la flexibilidad necesaria para incluir código arbitrario dentro de las páginas que componen el sitio.
2. Durante el proyecto, uno de nuestros principales objetivos fue traducir los temas técnicos de la investigación a un lenguaje más sencillo para audiencias no técnicas, construyendo toda la documentación teniendo en cuenta la premisa de que los usuarios podrían no estar familiarizados con los conceptos básicos de las comunicaciones por teléfono móvil. Nos dimos cuenta de la necesidad de tener más información disponible para los actores directos involucrados.
3. Basado en una gran cantidad de preguntas, preocupaciones e interés de la audiencia, este tema parece ser fascinante no solo para investigadores académicos sino también para periodistas, medios de comunicación, activistas y ONG de libertad de expresión, dado el enfoque para usar esta metodología como herramienta para abogar contra el uso ilegal de prácticas de monitoreo.