Análisis estático del archivo instalable Android de miSCS, versión 2.03.01 (versionCode 81), realizado el 19 de octubre de 2026. Metodología: descompilación pasiva del archivo instalable público (jadx + volcado Dart), sin contactar con servidores de producción. Es verificable por cualquier persona que descomprima el APK, y no se contactó con ningún servidor: solo se leyeron rutas y configuraciones dentro del binario.
Alcance: este dossier describe la 2.03.01. La 2.03.02(versionCode 83) se detectó el 20 de octubre de 2026 y se revisó por comparación estática: el código Dart es idéntico, la superficie de servicio no varía y el único cambio material es el empaquetado de idiomas; su fecha de publicación no consta. El cambio se detalla en la observación 5.
Ficha técnica
Titular
Servicio Canario de la Salud, Gobierno de Canarias
Alrededor de 18 (es, en, fr, pt, ru, ar, zh, ja, ko, hi… y más)
Autenticación
Cl@ve (federada, estatal) y tarjeta sanitaria CIP+CSV, con acceso biométrico opcional
Qué puede hacer el servicio con la app
Dentro del binario se leen las rutas de los servicios que la aplicación consume, en dominios institucionales del Gobierno de Canarias y por HTTPS. La lista es la superficie real de lo que depende de la app:
Autenticación
Acceso con Cl@ve y verificación de identidad con tarjeta sanitaria (TSI)
Citas
Pedir, consultar y cancelar citas; disponibilidad por centro
Informes clínicos
Analíticas, antecedentes, diagnósticos activos, vacunas, informes PDF
Información clínica
Alergias, medicación, hábitos, constantes, plan de parto
Listas de espera
Consulta de posición
Medicación
Pastillero electrónico: confirmación de toma
Soporte
Envío de incidencias por correo desde la propia app
Notificaciones
Registro del dispositivo para avisos push de citas y comunicados
Lo que la app hace bien
Gran parte de la construcción técnica es correcta y va por delante de otras apps de administración. Reconocerlo es parte del rigor de este dossier:
Sin rastreadores de publicidad. No se detectan SDK de analítica publicitaria ni de terceros (ni Facebook, ni AppsFlyer, ni Google Analytics) dentro de la app; solo infraestructura de notificaciones. Es una práctica que otras administraciones podrían replicar.
Biometría bien implementada. El token de sesión se guarda en el almacenamiento cifrado del sistema (Keystore), ligado a la biometría, no en preferencias ni ficheros de texto.
Plataforma al día. Compila para Android 16 (targetSdk 36) y el artefacto analizado es de 2026: no es una app abandonada técnicamente.
Multilenguaje y accesibilidad integrada. Unos 18 idiomas, panel de accesibilidad dentro de la app y pictogramas de comunicación alternativa (tablero de comunicación para personas con dificultades de habla).
Sin telemetría comercial. No hay SDK de informes de caídas comerciales (Crashlytics, Sentry) que envíen información de la ciudadanía a terceros con fines de producto.
Lo que se observa, con su recomendación
Cinco observaciones divulgables, cada una con una mejora concreta. No son acusaciones: son hechos verificables mirando el APK y propuestas constructivas.
1. El canal para reportar errores solo existe dentro de la app
El único mecanismo para reportar fallos está en Ajustes → Soporte técnico → Sugerencias, es decir, tras iniciar sesión. La zona pública de la app (preguntas destacadas, búsqueda de centros, política de privacidad) no tiene ninguna entrada de incidencias.
Los errores más frecuentes de una app sanitaria son los de la propia puerta: Cl@ve que no responde, tarjeta rechazada, TSI caducada. En esos estados la persona no puede reportar su problema: tendría que estar dentro para comunicar que no puede entrar.
Pantalla de inicio de miSCS antes de iniciar sesión (versión 2.03.01, capturada el 19 de octubre de 2026). No hay ninguna entrada de reporte de incidencias.
El nombre «Catch-22». Procede de la novela de Joseph Heller: una norma imposible de cumplir porque sus dos condiciones se bloquean entre sí. Aquí: para reportar el fallo hay que estar dentro de la app, y lo que impide estar dentro es el fallo.
Recomendación. Añadir un botón «Reportar problema» en la propia pantalla de error (la app ya conoce el producto y el módulo afectados en ese momento) y una entrada de reporte en la zona pública.
2. La app ve los errores; el servicio, no siempre
No se detectan SDK de detección de fallos: un error que ocurre en un dispositivo no llega automáticamente al SCS; depende de que alguien lo comunique. Y los diálogos de error que ve la persona son genéricos, sin referencia al módulo o servicio afectado.
Recomendación. Errores con referencia (código de servicio, hora, módulo) y un canal de detección interna, de modo que el fallo se conozca aunque nadie lo cuente.
3. Tres proveedores de notificaciones para el mismo trabajo
La app se apoya en tres servicios de terceros distintos para las mismas notificaciones: Firebase Cloud Messaging (Google), OneSignal y Azure Notification Hubs (Microsoft), además de un canal en tiempo real en segundo plano. La mera recepción de un aviso ya revela que hay una citación médica.
Recomendación. Un único proveedor bajo el marco del RGPD (encargado del tratamiento identificado, garantías de transferencia internacional), y documentar en la política de privacidad, con nombre, el canal activo hoy en producción.
4. Permisos pedidos frente a los necesarios
La app pide, entre otros, permiso de estado del teléfono (READ_PHONE_STATE) sin función observable en ninguna pantalla analizada, y acumula alrededor de 15 permisos de «aviso con insignia» de fabricantes (Samsung, Huawei, Oppo, Sony…).
Recomendación. Revisión de minimización de permisos: menos es más, también en sanidad.
5. Notas de versión que no dicen qué cambia
La nota de versión de la 2.03.02 (versionCode 83, detectada el 20 de octubre de 2026) dice «Mejoras en la aplicación». La comparación estática 2.03.01 → 2.03.02 arroja lo contrario: el código Dart es idéntico, la superficie de servicio no varía, y el único cambio material es de empaquetado: la capa Android pasa de 18 paquetes de idioma a 5 (entre ellos el inglés y el malayo, añadido en esta versión). Se retiran quince idiomas sin mención alguna, incluido el paquete del español de esa capa; el español y el inglés se mantienen en la capa principal de la interfaz (recursos l10n de Dart).
Recomendación. Registro de cambios público por versión, con lo añadido y lo retirado; y anuncio previo de cualquier retirada de idiomas.
Lo reservado: coordinación CERT (CVD)
Hay más observaciones técnicas de gravedad baja o media (endurecimiento de red,enlaces profundos, claves embebidas) que no se detallan aquí todavía. Se notificaron de forma confidencial al Servicio Canario de la Salud (miscs.scs@gobiernodecanarias.org, su canal oficial de soporte) con copia testigo al CSIRT-CAN, el CERT del Gobierno de Canarias, según la Divulgación Coordinada de Vulnerabilidades (CVD, ISO/IEC 29147 y 30111).
Ventana de coordinación: desde la notificación y hasta 90 días, o hasta que el centro autorice la publicación. Cuando venza, cada detalle se publicará en esta página con su evidencia y su mitigación. Los temas reservados, sin su detalle:
Enlace profundo del acceso con Cl@ve y su manifiesto Android, sin detalles
Clave de API de Firebase embebida y sus restricciones
Cifrado de la base de datos local y estado del anclaje de certificados (pinning)
Qué se escribe en los registros exportables
Lo que nunca se publica: código descompilado, claves completas ni evidencias que ayuden a explotar un fallo. El objetivo es que se arregle, no exponerlo.
Marco legal y límites del análisis
Este análisis se ha realizado como auditoría ciudadana de una app descargada públicamente, amparada en la Directiva 2009/24/CE (derecho a estudiar el funcionamiento de un programa del que se dispone legítimamente). No se han atacado, interceptado ni cargado sistemas; no se han recogido datos personales de ninguna persona; no se publican la fuente descompilada ni credenciales.
La guía de reclamación está en Cómo reclamar; el contexto contractual que fija los niveles de servicio de esta app está en Contratos y cronología.
Preguntas sobre este análisis
¿Es legal descompilar una app?
Sí. La Directiva 2009/24/CE reconoce el derecho a observar y estudiar el funcionamiento de un programa del que se dispone legítimamente. Este análisis es exclusivamente estático: se estudia el fichero instalado en el propio dispositivo y no se conecta con redes del SCS.
¿Se le ha enviado esto al Servicio Canario de Salud?
Sí, de forma confidencial: notificación al email de soporte del Servicio Canario de la Salud y copia testigo al CSIRT-CAN (CERT regional del Gobierno de Canarias), según la Divulgación Coordinada de Vulnerabilidades, con una ventana de hasta 90 días antes de detallar públicamente lo reservado.
¿Y en iOS?
El análisis publicado cubre la versión Android 2.03.01. El método es idéntico en iOS (bundle IPA) y puede replicarse si se solicita. La aplicación es híbrida, así que gran parte del análisis cubre ambas plataformas.
