Google detalla la propuesta de diseño de SDK Runtime para Android Privacy Sandbox

Recientemente, hemos visto a Apple y Google esforzarse por crear un ecosistema más consciente de la privacidad cuando se trata de anuncios. Con Apple, fue con la introducción de un botón para evitar que las aplicaciones te rastreen, y con Google, ha sido la Iniciativa Sandbox de privacidad de Android. Si bien la información fue escasa durante su anuncio, han surgido más detalles en torno al "SDK Runtime" que abarca parte de la solución de Google para publicidad y privacidad.

Android Privacy Sandbox se compone de dos componentes principales: el tiempo de ejecución del SDK y las API de preservación de la privacidad, que se distribuirán como componentes del sistema modular, que quizás recuerde como Línea principal del proyecto. Desde entonces, Google ha publicado documentación para desarrolladores sobre SDK Runtime y cómo mejorará aún más la privacidad del usuario. La compañía dice que SDK Runtime permitirá que SDK de terceros se ejecuten en un entorno de ejecución dedicado en

androide 13, lejos del código de una aplicación.

En Android, cada aplicación se ejecuta en un entorno limitado con sus propios permisos y acceso variable al sistema según el acceso otorgado. Como dice Google, "si la aplicación A intenta hacer algo malicioso, como leer los datos de la aplicación B o marcar el teléfono sin permiso, se le impide hacerlo porque no tiene la privilegios de usuario predeterminados apropiados". SDK Runtime expande aún más ese espacio aislado para ejecutar SDK de terceros en un entorno de ejecución dedicado, lejos de cualquier aplicación.

Por qué existe el tiempo de ejecución del SDK

Google quiere evitar que los SDK de anunciantes recopilen datos a los que no debería tener acceso de forma maliciosa (o incluso sin darse cuenta) como resultado de compartir el entorno limitado de la aplicación anfitriona. Cuando se ejecuta un SDK de publicidad dentro de una aplicación, también tiene acceso a todo lo que hace la aplicación, y es posible que el desarrollador de la aplicación no sea completamente consciente de cuánto acceso realmente tiene. Al eliminar ese código de anunciante y ejecutarlo en su propio tiempo de ejecución, solo podrá acceder a los datos que el desarrollador comparte explícitamente con él.

Como resultado, Google dice que SDK Runtime proporciona las siguientes salvaguardias y garantías más sólidas en torno a la recopilación y el intercambio de datos de los usuarios:

• Un entorno de ejecución modificado
• Permisos bien definidos y derechos de acceso a datos para SDK

La primera versión de SDK Runtime se centra exclusivamente en SDK relacionados con la publicidad, incluidos los SDK que permiten la publicación de anuncios, la medición de anuncios, el fraude publicitario y la detección de abusos.

Cómo funciona el tiempo de ejecución del SDK

Actualmente, sin el tiempo de ejecución del SDK, el proceso de una aplicación llamará a un SDK y ese SDK se ejecutará dentro del mismo entorno limitado que el resto del código de la aplicación. Google quiere que los desarrolladores tengan una interfaz para un SDK que funcione en el proceso de primer plano de una aplicación. y esa interfaz puede luego conectarse y compartir datos específicos con el SDK que se está ejecutando. utilizado.

Antes

Después

El diagrama "antes" (primero) muestra que el código de llamada del SDK, junto con los SDK que reciben las llamadas de este código, residen en el proceso de la aplicación. Esto significa que el SDK puede acceder a todos los datos que tiene la aplicación. El diagrama "después" (segundo) muestra que, en el proceso de primer plano de la aplicación, el código de llamada del SDK se comunica con las interfaces del SDK. Luego, estas interfaces cruzan un límite de proceso hacia el proceso de tiempo de ejecución del SDK para llamar a los propios SDK. Esto significa que el SDK que se utiliza no puede simplemente acceder a lo que quiera, sino que solo puede recibir información de la aplicación con la que se ejecuta.

Nuevo modelo de distribución confiable para SDK

Actualmente, cuando descarga una aplicación con SDK de terceros, el desarrollador los incluye en la aplicación que se carga y distribuye en Google Play Store. En cambio, Google quiere que cuando instales una aplicación en tu teléfono que use esos SDK, se descarguen. por separado desde la propia aplicación. Eso significa que los desarrolladores de SDK podrían realizar cambios permanentes (es decir, ningún cambio en las API o su semántica) a sus SDK y distribuirlos a dispositivos sin ninguna participación de la aplicación desarrolladores.

A su vez, los cambios continuos del SDK se podrían implementar o revertir, sin necesidad de esperar. para que los desarrolladores de aplicaciones reconstruyan sus aplicaciones con los nuevos SDK, o esperar a que los usuarios finales actualicen sus aplicaciones. Los desarrolladores de aplicaciones aún tendrían que actualizar los cambios importantes que modifican las API y su semántica, pero los desarrolladores de SDK podrían obtener sus últimas novedades. cambios y correcciones más rápidas y uniformes para más personas a la vez, sin depender de un desarrollador de aplicaciones para actualizar su aplicación y paquete en el nuevo SDK.

Antes

Después

El diagrama "antes" muestra exactamente cómo se distribuyen ahora las aplicaciones con SDK. Están empaquetados en una aplicación y la aplicación es lo que se envía a Google Play Store. En el diagrama "después", los desarrolladores de SDK ya no colocarían sus SDK directamente en las aplicaciones; en cambio, los desarrolladores del SDK cargarían un SDK y lo publicarían en Google Play Store. Luego, Google Play Store se encargaría de la distribución de aplicaciones, junto con cualquier dependencia del SDK, a los dispositivos de los usuarios finales. Google también utiliza intencionalmente la frase "tienda de aplicaciones" en sus diagramas, ya que es una solución abierta y general que puede funcionar en otras tiendas.

Cambios en la forma en que se crean, ejecutan y distribuyen los SDK y las aplicaciones

La propuesta inicial para SDK Runtime propone una serie de cambios en cinco áreas clave:

• Acceso
• Ejecución
• Comunicaciones
• Desarrollo
• Distribución

Google quiere definir el siguiente conjunto de permisos para SDK Runtime:

• INTERNET: Acceso a internet para poder comunicarse con un servicio web.
• ACCESS_NETWORK_STATE: accede a información sobre redes.
• Permisos para acceder al API que preservan la privacidad, que brindan capacidades publicitarias básicas sin necesidad de acceso a identificadores entre aplicaciones. Los nombres de los permisos no se han finalizado, pero estas API estarían cerradas por el acceso de la aplicación a estos permisos.
• AD_ID: Posibilidad de solicitar el ID de publicidad. Esto también estaría bloqueado por el acceso de la aplicación a este permiso.
• BIND_GET_INSTALL_REFERRER_SERVICE: Capacidad para utilizar el API de referencia de instalación de Google Play para atribuir el origen de la instalación de una aplicación.

La compañía también quiere limitar el acceso que tienen los SDK a la memoria de una aplicación en ejecución, pero también evitar que una aplicación acceda a los propios datos de un SDK. Una aplicación no podría acceder directamente al almacenamiento de su SDK y, viceversa, el almacenamiento externo no sería abierto a SDK, y habría almacenamiento accesible para todos los SDK y almacenamiento privado para un determinado SDK.

En cuanto a cómo se ejecutarán los SDK, se ejecutarán con una prioridad ligeramente menor que la propia aplicación. Es decir, es muy probable que una aplicación finalice poco después de que se finalice un SDK Runtime si surgiera la situación de que el sistema tuviera que cerrarla. En el caso de que no se resuelva al mismo tiempo, o en el caso de que exista otro motivo, la propuesta ofrece métodos de devolución de llamada relacionados con el ciclo de vida a los desarrolladores de aplicaciones para que puedan manejar esta excepción y reinicializar el SDK. Tiempo de ejecución. Los SDK de tiempo de ejecución no podrán utilizar las API de notificaciones para enviar notificaciones al usuario en ningún momento.

Finalmente, Google señala que se trata de una propuesta general que no es exclusiva de ninguna tienda de aplicaciones en particular. Si bien es de suponer que se integrará en Google Play Store, no hay ninguna razón por la que otras tiendas de aplicaciones no puedan incorporar una estructura similar. Google dice que los siguientes beneficios son claros:

• Garantizar la calidad y coherencia de los SDK.
• Optimice la publicación para los desarrolladores de SDK.
• Acelere la implementación de actualizaciones de versiones menores del SDK en las aplicaciones instaladas.

El Sandbox de privacidad de Android parece prometedor

El cronograma de lanzamiento de Google es que el primer trimestre de 2022 incluye las propuestas de diseño iniciales y los comentarios e iteraciones del diseño. Las vistas previas para desarrolladores llegarán más adelante este año, con una versión beta a finales de año. Finalmente, en 2023 comenzarán las pruebas escaladas. Estas vistas previas y versiones beta serán independientes de la cadencia de lanzamiento de Android 13. También habrá controles orientados al usuario en la aplicación de configuración, una vez implementada.

En mi opinión, el Sandbox de privacidad de Android aspecto prometedor, pero tendremos que esperar y ver cómo lo implementa la empresa. Es muy posible que a los desarrolladores no les guste o que cause más problemas de los que resuelve. Se anima a los desarrolladores a leer la documentación que Google ha publicado para tener una mejor idea de lo que vendrá en el futuro de la privacidad de Android.

Actualmente se trata de una propuesta y no de una perspectiva definitiva sobre lo que exactamente Esto sucederá en una futura versión de Android, pero es probable que termine bastante cerca. ¡Estaremos atentos a cualquier novedad!

---

Fuente: Documentación para desarrolladores de Android