A mediados del año pasado Apple hizo un anuncio del cual no pude ma s que hacerme eco. Frente a un ecosistema cada vez ma s interesado en los beneficios del tratamiento de datos, la compañía pretendía competir con un machine learning limitado basado en el paradigma de la privacidad diferencial.
(La privacidad diferencial es) un sistema estadístico que separa identidad de contenido, de manera que a priori es posible explotar información sin exponer la identidad de quien la ha generado.
Para ello hace uso de técnicas de ofuscación como el hasing (cifrado) de datos, el subsampling (hacer uso únicamente de parte de los mismos) y la inyección de ruido, que permite anonimizar volúmenes de información, como expliqué en su día.
El término fue acuñado ya por 2006 por los investigadores Cynthia Dwork, Frank McSherry, Kobbi Nissim y Adam Smith en un paper (EN/PDF) bajo la tutela de Microsoft, y es aplicado a día de hoy en numerosos entornos, aunque de manera muy específica, como ocurre con el sistema RAPPOR (EN) o la Navegación Segura utilizada por Chrome para compartir información de consumo de manera anónima.
Ya en su momento comenté que la medida me parecía todo un acierto. Es importante que empresas de la talla de Apple apuesten por acercar a la electrónica de consumo la tecnología de machine learning sin que ello suponga un lastre para los derechos de privacidad del usuario.
Sin ir ma s lejos, la semana pasada aplaudía la decisión de algunos trabajadores de Google al plantearse la creación de sistemas de inteligencia artificial en local, con una funcionalidad muy limitada y capaz de operar en hardware de bajo rendimiento.
Ahora bien, el problema sigue siendo el mismo de siempre:
El presentar un entorno de explotación de datos anónimo con fines identificativos (ofrecer inteligencia al usuario en base a sus datos es un ejemplo) supone una carga considerable de recursos y una merma de la eficiencia de todo el sistema.
Si a ello sumamos la intención de, en la medida de lo posible, realizarlo dentro de los límites del hardware local, el problema aumenta exponencialmente, al afectar negativamente al uso del mismo, y aumentar considerablemente el gasto de batería según el uso que vayamos a darle.
En fin, que vuelvo al tema después de leer estos días un estudio presentado en colaboración de la Universidad del Sur de California, la de Indiana y la de Tsinghua, cuyo paper puede consultar por aquí (EN/PDF), y que viene a señalar un handicap ma s en la estrategia de los de Cupertino: al parecer la privacidad diferencial implementada en los sistemas operativos de Apple no es tan privada como pudiera pensarse.
Épsilon
Para demostrarlo, hicieron ingeniería inversa al código de distintas versiones de MacOS e iOS para entender cómo en la pra ctica estaban aplicando la privacidad diferencial.
El software inyecta ruido pseudo-aleatorio en la información (por ejemplo, uso de emojis o datos de HealthKit como ruido para el historial de navegación y consultas) antes de enviar esos datos a los servidores de la compañía, lo que en efecto complica que un tercero (o la propia Apple) pueda identificar al usuario sin que por ello no pueda seguir tratando los datos (la funcionalidad buscada en los servidores de Cupertino).
Hasta ahí todo correcto. El problema surge cuando intentamos medir cua nto de privacidad diferencial tenemos implementado en el sistema. O, dicho de otra manera, cómo de explícito es un dato como para que sea identificativo de la persona. Esto se determina mediante una variable llamada “para metro de pérdida de privacidad” o, en el argot técnico, “épsilon”. En un mundo feliz épsilon debería tener un valor cercano a 1. Sin embargo, estos investigadores aseguran que MacOS tiene 6, iOS10 tiene 14, y lo ma s preocupante, la beta de iOS11 (el estudio es de justo antes de que saliera a la luz la versión final) es de 43. Muchísimo ma s por encima de lo recomendable.
Adema s, puesto que los datos se envían al menos una vez al día, el riesgo va aumentando con cada envío. Lo explicaba muy bien uno de los investigadores:
“Digamos que alguien le ha dicho a la aplicación de salud de su teléfono que tienen una condición médica de presente en uno de cada millón de usuarios, y su teléfono carga esos datos al creador del teléfono (Apple) diariamente, usando la privacidad diferencial con un épsilon de 14. Después de una carga ofuscada con una inyección de datos al azar, los analistas de datos de la empresa serían capaces de averiguar con un 50 por ciento de certeza si la persona tenía esta condición. Después de dos días de subida, los analistas sabrían acerca de esa condición médica con pra cticamente el 100 por ciento de certeza. Incluso después de un solo día, su privacidad ya podría haber sido comprometida”
Apple, por supuesto, ha salido a desmentir la investigación, asegurando que utiliza diferentes niveles de ruido para diferentes tipologías de datos, siendo especialmente sensibles con los datos referentes a HealthKit. Al utilizar diferentes correlaciones, se complicaría bastante ma s la identificación, así que el debate esta servido.
Sea como fuere, sigo reiterando que me parece el mejor camino a seguir. Por ejemplo, hace tiempo que un estudio sobre el épsilon de RAPPOR (EN/PDF/llevado a cabo por investigadores de la compañía, ojo), el sistema de privacidad diferencial utilizado en Chrome, lo posicionaba como un E2 para cualquier dato enviado a la compañía, y con un límite de 8 o 9 en el ciclo de vida de ese dato en el cliente. Descontando que RAPPOR es auditable por terceros, por lo que cualquier cambio que pudiera afectar a épsilon llamaría ma s la atención que en un software privado como son los SO de Apple.
De Facebook o de Microsoft poco se sabe. Y es curioso, porque precisamente fueron investigadores de Redmond los que en su día acuñaron el término…
De lo que se quejaba el equipo Korolova, precisamente, era de esta opacidad ya habitual en Cupertino. Implementan algo, lo anuncian, pero no dan datos sobre cómo lo han hecho y qué tan seguro o privado puede llegar a ser.
La estrategia de Apple siempre se ha basado en el ma s puro oscurantismo y en la confianza de marca. Algo que les ha funcionado históricamente, que les sigue funcionando, y que quiero pensar que en algún momento les deje de funcionar.