O problema: confianza ás cegas
Cando instalas unha aplicación de vixilancia de bebés, dálle acceso a un lugar moi privado: o cuarto do teu bebé. A aplicación escoita e, ás veces, tamén observa. Ao mesmo tempo, as familias adoitan non saber o que ocorre en segundo plano: as transmisións pasan por servidores de terceiros, recóllense datos de uso, quen pode acceder tecnicamente a algo?
A resposta sincera é que, con moitas aplicacións, non o sabes. O código está pechado e a arquitectura queda nunha simple afirmación. Ao final, pídenche que creas no provedor.
Código pechado, puntos vulnerábeis
Nos últimos anos houbo abondos casos de monitores de bebés pirateados. Descoñecidos podían escoitar, mover cámaras ou falar polos altofalantes. A maioría das veces non eran ataques sofisticados, senón fallos graves: conexións sen cifrar, contrasinais predeterminados ou falta de autenticación.
Co software propietario, as persoas alleas adoitan descubrir esas debilidades só despois de que pase algo. Investigadores de seguridade, desenvolvedores independentes e familias examinan un produto acabado desde fóra. Para un dispositivo no cuarto do bebé, é un modelo pouco sólido.
A transparencia como principio de seguridade
A seguridade da información ten unha regra antiga e útil: o principio de Kerckhoffs. A seguridade non debe depender de que o deseño se manteña secreto. Un sistema debería seguir sendo seguro mesmo cando alguén sabe como está construído.
Que o código estea documentado abertamente non fai que un programa sexa seguro por si só. Pero permite comprobar as afirmacións. As persoas que coñecen o ámbito poden revisar os fluxos de datos, a derivación de claves e as regras, en vez de limitarse a ler textos de márketing.
O enfoque de Timmy: un núcleo de seguridade separado
En Timmy, agora separo con moita claridade as partes que son realmente críticas para a seguridade. Non todas as liñas da interface determinan se o produto merece confianza. As pezas decisivas son a lóxica do backend, os contratos de sinalización, a criptografía de emparellamento e que datos chegan a un servidor.
Por iso, o núcleo de seguridade está agora no repositorio público baby-monitor-timmy-core. O código completo da aplicación non é público neste momento. Os compoñentes críticos para a seguridade sepáranse da interface e da lóxica do produto para poder documentalos e revisalos por separado.
Que significa isto na práctica?
- Límites claros: os compoñentes de seguridade están separados da interface e da lóxica do produto.
- Fluxos de datos auditábeis: o emparellamento, a sinalización e as interfaces do backend poden documentarse por separado.
- Sen rastreadores ocultos: os percorridos críticos conteñen unicamente o que lles corresponde tecnicamente.
- Mantemento a longo prazo: un núcleo separado é máis doado de revisar ca un monolito sen estrutura.
Conclusión: as familias merecen transparencia
Cando unha aplicación ten acceso ao cuarto do bebé, debería responder con claridade ás preguntas críticas: que datos se xeran? A onde van? Quen os pode ler? As familias merecen máis ca un distintivo de privacidade no pé de páxina.
Baby Monitor Timmy quere demostrar que un bo produto e unha seguridade auditábel poden ir da man. Para min, iso non significa facer público cada recuncho da aplicación. Significa abrir as partes que determinan o emparellamento, a sinalización, o acceso ao backend e os fluxos de datos.