La documentación de Android en Grupos de permisos indica que
Si una aplicación solicita un permiso peligroso listado en su manifiesto, y la aplicación ya tiene otro permiso peligroso en el mismo grupo de permisos, el sistema otorga el permiso inmediatamente sin ninguna interacción con el usuario. Por ejemplo, si una aplicación solicitó y recibió previamente el permiso READ_CONTACTS , y luego solicita WRITE_CONTACTS , el sistema inmediatamente otorga ese permiso.
¿No es esto un riesgo de seguridad? Leer los contactos para que la aplicación me permita compartir algo con amigos es menos riesgoso que alterar los contactos existentes, que pueden usarse maliciosamente, por ejemplo, para cambiar la dirección de correo electrónico de cada contacto a algo parecido al correo electrónico original, pero que en realidad lleva a la cuenta del atacante, que puede continuar reenviando el intercambio de correo electrónico, sin el conocimiento de ambas partes.
La documentación enfatiza el punto más abajo:
Una vez más, el sistema simplemente le dice al usuario qué grupos de permisos necesita la aplicación, no los permisos individuales
El grupo PHONE incluye CALL_PHONE y también READ_CALL_LOG .
Nuevamente, se debe permitir que una aplicación similar a Yelp llame a una empresa, o una aplicación de pedidos puede realizar una llamada legítimamente a la persona de entrega, pero eso significa que la aplicación también puede leer en silencio los registros de llamadas privadas del usuario y enviarlos a sea cual sea el adware incluido, ya que INTERNET es una permiso normal que no requiere el consentimiento del usuario. Los registros de llamadas a ciertos números se pueden usar como base para chantajear al usuario, o (probablemente más comúnmente) pueden servir como información muy valiosa para que los anunciantes descubran el perfil demográfico y la red social del usuario.
Varios informes han demostrado que un un número asombroso de aplicaciones en el hogar con datos que el usuario no esperaba. ¿Por qué, entonces, los permisos de Android son tan ásperos?
La conveniencia del usuario (es decir, no molestar demasiado al usuario en el sistema de permisos de tiempo de ejecución de Android M) parece ser una razón débil. Las aplicaciones legítimas sin una razón para leer el registro de llamadas no solicitarán el permiso, por lo que todas las opciones a continuación solo se lo preguntarán al usuario una vez, pero tienen diferentes resultados de seguridad:
- "Esta aplicación puede hacer una llamada telefónica" (permiso individual)
- "¿Puede esta aplicación acceder al teléfono, redirigir las llamadas salientes (!), y lea su lista de contactos "(permiso de grupo actual con una redacción precisa, pero innecesariamente atemorizante, ya que la mayoría de las aplicaciones solo realizan llamadas)
- "Permitir que [esta aplicación] haga y administre llamadas telefónicas" (redacción para el permiso de grupo en Android M, innecesariamente vago)
Lo mismo para CALENDAR: el permiso de solo escritura para crear eventos es relativamente inocuo , pero leer los eventos privados del usuario mucho menos. Etc.
¿Hay buenas razones por las que los permisos no necesitan ser más granulares?