El escaneo del lado del cliente examina contenido en el dispositivo del usuario, donde puede ser legible antes de enviarlo o después de recibirlo. Por tanto, puede crear una vía de divulgación fuera del canal de entrega cifrado. Comparar la suma de comprobación de un APK no demuestra que una aplicación no contenga código de escaneo. Responde a una pregunta más limitada: si los bytes seleccionados coinciden con un resumen concreto.
Separar estas afirmaciones hace más útiles tanto el cifrado como la verificación del software.
Por qué el escaneo en un dispositivo cambia el límite de privacidad
Una aplicación debe manejar texto en claro para mostrar un mensaje o preparar una foto para enviarla. Una función de escaneo puede actuar en ese punto, aunque el mensaje posterior por la red esté cifrado de extremo a extremo. Lo que sale del dispositivo depende del diseño del escáner: podría informar de una coincidencia, subir contenido seleccionado o enviar otra información derivada.
El artículo de investigación Bugs in our Pockets examina riesgos como los abusos, los falsos positivos y una mayor superficie de ataque. Son razones para examinar los flujos de datos y la gobernanza de un sistema de escaneo propuesto. No demuestran que toda función en el dispositivo sea vigilancia ni que una ley concreta haya impuesto un requisito universal de escaneo.
Una función local bajo el control del usuario no equivale automáticamente a una notificación obligatoria. Pregunta quién elige el análisis, qué lo activa, quién puede actualizar sus reglas y qué datos pueden salir del dispositivo.
Cuatro formas distintas de evidencia sobre el software
| Comprobación | Qué puede demostrar | Qué no puede demostrar por sí sola |
|---|---|---|
| Suma de comprobación SHA-256 | El archivo coincide con un resumen de referencia fiable | Que el programa de referencia sea seguro o coincida con el código fuente |
| Verificación de la firma del APK | La firma del paquete se verifica e identifica un certificado de firma | Que el firmante sea fiable o que el código no tenga comportamientos no deseados |
| Compilación reproducible | Un código fuente y unas entradas de compilación especificados pueden producir los artefactos esperados | Que el código fuente esté libre de vulnerabilidades o lógica dañina |
| Revisión y pruebas independientes | Hallazgos sobre una versión y un alcance definidos | Una garantía permanente que cubra todas las actualizaciones futuras |
La documentación de apksigner de Android explica la verificación de paquetes y la presentación de información sobre certificados. La definición de Reproducible Builds explica por qué el código fuente, el entorno de compilación y las instrucciones importan al reproducir un artefacto.
Un archivo de código fuente y una suma de comprobación mostrada a su lado no son, por sí solos, un resultado de compilación reproducible. Del mismo modo, una firma válida en una versión maliciosa sigue siendo una firma válida.
Cómo comprobar una descarga sin sobreinterpretar el resultado
Primero identifica la versión deseada y obtén su APK y el resumen esperado por una vía de distribución fiable. Calcula el resumen localmente. Si difiere, no instales el archivo mientras no se explique la discrepancia: una versión diferente, una descarga incompleta o una manipulación pueden producir una falta de coincidencia.
Si coincide, registra la versión y el resultado. Has establecido la igualdad de bytes respecto a esa referencia, no la ausencia de escaneo del lado del cliente. Si el mismo atacante puede sustituir la descarga y la suma mostrada, la comparación puede seguir dando un resultado correcto. Las referencias independientes, la continuidad de la clave de firma y la transparencia de las versiones ayudan a abordar distintas partes de ese problema de confianza.
Para una afirmación de correspondencia entre código fuente y binario, busca instrucciones de compilación documentadas y resultados reproducidos de forma independiente para la versión concreta. No deduzcas esa propiedad de las palabras «código abierto».
Las actualizaciones siguen siendo importantes
La distribución de software puede sufrir ataques, pero evitar indefinidamente las actualizaciones de seguridad no es una buena defensa general. Las actualizaciones también reparan vulnerabilidades explotables. Utiliza un canal de actualización fiable, revisa los avisos de seguridad relevantes y verifica las evidencias de la versión cuando tu riesgo lo justifique. Una versión antigua con un fallo conocido no es más segura solo porque su suma de comprobación coincidiera una vez.
Qué demuestra el Proof Lab de Livara
El Proof Lab de Livara ofrece una comparación local del resumen de un APK y demostraciones criptográficas en el navegador. La página indica que no ejecuta los mecanismos de ratchet completos de LVR1/LGS1 ni constituye una auditoría del protocolo. Su modelo de amenazas también explica la limitación cuando un atacante puede sustituir tanto un archivo como su resumen esperado.
Estas comprobaciones son útiles dentro de su alcance. No prueban que un teléfono con la aplicación instalada esté libre de malware, que Livara tenga versiones reproducibles de forma independiente ni que su aplicación no pueda contener comportamientos no declarados. Lee por separado la documentación de seguridad para conocer los límites declarados de la protección de mensajes.
La pregunta correcta no es si un distintivo dice «verificado». Es qué afirmación se comprobó, frente a qué referencia fiable y para qué versión exacta.
