La confianza en desarrollos de terceros y la seguridad

La noticia de estos días ha sido sin duda la exposición de servicios tan masificados como Android o Chrome a estafas basadas en desarrollos de terceros vendidos al mejor postor.

Google-Chrome

Comenzábamos a finales de la semana pasada con la entrada escrita (EN) en el blog del creador de “Add to Feedly“, Amit Agrawal, que relataba cómo había recibido cuatro cifras por la venta del desarrollo de su aplicación para Chrome, con miles de usuarios activos, por una empresa de dudosa procedencia. 

No pasó mucho tiempo hasta que la supuesta empresa modificara la aplicación para que en vez de enviar el artículo a Feedly, posteara en las redes sociales del usuario publicidad no deseada. A esto, únanle lo que ha pasado recientemente con otra aplicación, “Tweet this Page” (desde ayer fuera de circulación (EN)), y a los problemas que están presentando servicios tan socorridos como Xposed Framework (EN), una capa adicional para Android que permite en muchos casos instalar diferentes herramientas con privilegios de superadmin y modificar elementos sensibles del SO sin tener que instalar una nueva ROM o ser Root.

Y todo condicionado por lo mismo: La confianza que volcamos en el desarrollo. Una confianza en que el servicio seguirá en su línea, actualizándose con frecuencia y ofreciendo nuevas mejoras. Cosa que ocurre con asiduidad hasta que o bien el proyecto escala y se abre a nuevos partners, o bien directamente se vende a otros.

Tal y como tenemos estructurada la cesión de permisos en la mayoría de herramientas actuales (llámelo sistemas operativos, llámelo programas), nos encontraremos con situaciones tan inverosímiles como que de la noche a la mañana esa herramienta que servía tan bien para un propósito pueda ser usada para robar nuestros datos o generar un nuevo vector para campañas de spam. Y el desarrollador que la alzó al estrellato no tener ni siquiera la culpa.

Una confianza ciega en el roadmap esperable de un proyecto que cambia de manos, o que pasa a gestionarse por proyectos de terceros, sean buenos o malos. Una confianza que permite a estos nuevos entes entrar hasta las entrañas de nuestros sistemas, aprovecharse de la buena fortuna de un tiempo pasado, y operar a sus anchas hasta que unos cuantos usuarios se dan cuenta y la cosa llega a mayores.

Lo peor de todo es que no se me ocurre una solución sencilla. Quien hace la regla hace la trampa. Imposible tachar a los desarrolladores iniciales de culpables. Es un negocio, y si existe un exit o prefieren abrirlo a desarrollos de terceros se hace porque así el proyecto prosperará con más vitalidad. Imposible gestionarlo acertadamente desde las plataformas, más cuando estos tratos en muchos casos se hacen de puertas para adentro. Imposible fijar la responsabilidad en el usuario, ya que a fin de cuentas se basa en la experiencia, y la experiencia dice que todo tiende a estancarse o ir a mejor. Incluso imposible en algunos casos señalar a los nuevos desarrolladores, que forman a su vez de un entorno más amplio, y cuyos fallos de seguridad pueden venir motivados por fallos de seguridad en las tecnologías que se usan para el propio desarrollo.

La mutación y corrupción del funcionamiento de un ecosistema de servicios. Ese pequeño tumor entre la bastedad del paraíso que pone en jaque los nexos que lo mantienen en la cúspide.