Autorisation d'accéder au réseau local

Les appareils d'un réseau local (LAN) sont accessibles par toutes les applications disposant de l'autorisation INTERNET. Cela permet aux applications de se connecter facilement aux appareils locaux, mais a également des implications en termes de confidentialité, comme la création d'une empreinte digitale de l'utilisateur et le fait de servir de proxy pour la localisation.

Le projet Local Network Protections vise à protéger la confidentialité de l'utilisateur en limitant l'accès au réseau local par le biais d'une nouvelle autorisation d'exécution.

Impact

Sur Android 16, cette autorisation est une fonctionnalité optionnelle, ce qui signifie que seules les applications qui l'activent seront concernées. L'objectif de l'activation est de permettre aux développeurs d'applications de comprendre quelles parties de leur application dépendent de l'accès implicite au réseau local afin qu'ils puissent se préparer à les protéger par des autorisations dans une future version d'Android.

Les applications seront affectées si elles accèdent au réseau local de l'utilisateur à l'aide des éléments suivants :

• Utilisation directe ou de bibliothèque de sockets bruts sur des adresses de réseau local, par exemple Multicast DNS (mDNS) ou Simple Service Discovery Protocol (SSDP).
• Utilisation de classes au niveau du framework qui accèdent au réseau local, par exemple NsdManager.

Détails de l'impact

Le trafic vers et depuis une adresse réseau locale nécessite l'autorisation d'accès au réseau local. Le tableau suivant liste quelques cas courants :

Ces restrictions sont implémentées en profondeur dans la pile réseau et s'appliquent donc à toutes les API réseau. Cela inclut les sockets créés dans la plate-forme ou le code géré, les bibliothèques réseau telles que Cronet et OkHttp, ainsi que toutes les API implémentées par-dessus. Pour résoudre les services sur le réseau local qui ont un suffixe .local, vous devez disposer de l'autorisation du réseau local.

Exceptions aux règles précédentes :

• Si le serveur DNS d'un appareil se trouve sur un réseau local, le trafic vers et depuis celui-ci (sur le port 53) ne nécessite pas d'autorisation d'accès au réseau local.
• Les applications qui utilisent le sélecteur de sortie comme sélecteur intégré n'auront pas besoin d'autorisations pour le réseau local (d'autres conseils seront disponibles dans une prochaine version).

Application des règles d'Android 17

À partir d'Android 17, les protections du réseau local sont obligatoires et appliquées aux applications ciblant Android 17 ou version ultérieure.

Pour vérifier que les fonctionnalités de l'application ne sont pas affectées après l'application de la règle, les applications ciblant le SDK 37 ou une version ultérieure doivent adopter l'une des approches suivantes pour gérer l'accès au réseau local :

Chemin A : Utiliser des sélecteurs respectueux de la confidentialité

Pour les tâches de découverte et de connexion gérées par le système, utilisez des sélecteurs pour éviter de demander l'autorisation d'exécution générale. Utilisez les sélecteurs suivants en fonction de votre cas d'utilisation :

• Streaming multimédia : les applications compatibles avec Google Cast peuvent utiliser la fonctionnalité de sélecteur de sortie. Cela permet aux développeurs d'autoriser les utilisateurs à sélectionner des appareils de streaming spécifiques sans que l'application ait besoin de demander l'autorisation générale ACCESS_LOCAL_NETWORK.
• Connectivité générale : NsdManager inclut un sélecteur de services exécuté par le système pour la découverte mDNS. Au lieu que l'application analyse l'ensemble du réseau, le système affiche une boîte de dialogue permettant à l'utilisateur de sélectionner un seul appareil auquel l'application peut accéder.

val discoveryRequest = DiscoveryRequest.Builder("_http._tcp")
    .setFlags(DiscoveryRequest.FLAG_SHOW_PICKER)
    .build()

nsdManager.registerServiceInfoCallback(discoveryRequest, executor, object : NsdManager.ServiceInfoCallback {
    override fun onServiceUpdated(serviceInfo: NsdServiceInfo) {
        // Handle the user-selected and discovered service
        // NsdServiceInfo.getHostAddresses() can now be connected to
        // without ACCESS_LOCAL_NETWORK permission
    }
})

Chemin B : Demander une autorisation d'exécution (accès étendu)

Ce chemin d'accès est requis pour les cas d'utilisation complexes, tels que l'automatisation de la maison ou la gestion des appareils IoT, qui nécessitent un accès étendu et persistant au réseau local.

• Déclarer l'autorisation dans le fichier manifeste : les développeurs doivent déclarer explicitement ACCESS_LOCAL_NETWORK dans AndroidManifest.xml.

• Demander l'autorisation au moment de l'exécution : avant de tenter d'accéder à un réseau local, les applications doivent vérifier si l'autorisation a été accordée. Sinon, il doit appeler Activity.requestPermission() pour déclencher l'invite système standard.

• Scénario d'autorisation accordée au préalable : l'autorisation ACCESS_LOCAL_NETWORK fait partie du groupe d'autorisations NEARBY_DEVICES. Si un utilisateur a déjà accordé une autre autorisation dans ce groupe (par exemple, les autorisations Bluetooth), il ne sera pas invité à nouveau à autoriser l'accès au réseau local.

• Gestion du refus et de la révocation : les applications doivent gérer de manière appropriée les cas où l'utilisateur refuse la demande ou révoque ultérieurement l'autorisation dans les paramètres système. Dans ce cas, le trafic réseau local sera bloqué.

Stratégie de réinitialisation du compteur de demandes d'autorisation

La plate-forme implémente une stratégie de réinitialisation du compteur qui traite les scénarios dans lesquels le refus antérieur par une application du groupe d'autorisations NEARBY_DEVICES (qui inclut désormais ACCESS_LOCAL_NETWORK) a empêché l'application de demander l'autorisation après avoir présenté de manière adéquate sa justification. Ce mécanisme offre à l'application des opportunités supplémentaires d'appeler l'API requestPermission(), ce qui réinitialise le nombre de refus pour l'autorisation ACCESS_LOCAL_NETWORK. Cela permet un réengagement plus nuancé avec l'utilisateur, en particulier lorsque le refus initial s'est produit avant que l'application puisse expliquer la nécessité d'accéder au réseau local pour sa fonctionnalité principale.

Modèle d'autorisation fractionné

L'autorisation Réseau local utilise une stratégie de migration des autorisations fractionnées pour gérer différemment les applications nouvelles et anciennes, en fonction de leur SDK cible.

Stratégie de conservation des numéros par cas d'utilisation

• Casting : pour les fonctionnalités de casting de contenus multimédias, la stratégie la plus appropriée et la plus respectueuse de la confidentialité consiste à utiliser le sélecteur de sortie. Cette méthode permet au système de gérer la découverte et la connexion au réseau local au nom de l'utilisateur, ce qui élimine la nécessité pour l'application de demander l'autorisation ACCESS_LOCAL_NETWORK.

• Navigateurs : la gestion des erreurs nécessite différentes approches en fonction du protocole. Les erreurs UDP entraînent le code d'erreur EPERM. Pour les connexions TCP, les navigateurs doivent utiliser l'API NDK android_getnetworkblockedreason(int sockFd) pour déterminer si un paquet a été bloqué par LNP. Cette API renvoie ANDROID_NETWORK_BLOCKED_REASON_LNP.

• Autres cas d'utilisation (IoT, par exemple) : les applications qui trouvent des appareils à l'aide de mDNS doivent utiliser android.net.nsd.DiscoveryRequest#FLAG_SHOW_PICKER, qui permet de trouver des appareils sans l'autorisation, et NsdManager#registerServiceInfoCallback / NsdManager#resolveService pour obtenir des adresses IP. Les connexions aux adresses IP obtenues de cette manière ne nécessitent pas l'autorisation ACCESS_LOCAL_NETWORK.

Pour les applications qui nécessitent une communication directe sur le réseau local et ne peuvent pas utiliser les sélecteurs gérés par le système, l'approche suggérée consiste à utiliser la stratégie de compteur de réinitialisation des autorisations. Si l'autorisation ACCESS_LOCAL_NETWORK est révoquée par l'utilisateur, ce mécanisme offre à l'application des possibilités supplémentaires de redemander l'autorisation, ce qui permet aux développeurs de présenter une justification plus claire à l'utilisateur.

Conseils concernant Android 16

Pour activer les restrictions d'accès au réseau local :

1. Flasher votre appareil avec une version incluant la version bêta 3 d'Android 16 ou une version ultérieure
2. Installer l'application à tester

3. Activer/Désactiver la configuration Appcompat à l'aide d'adb

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. Redémarrez l'appareil.

L'accès de votre application au réseau local est désormais limité. Toute tentative d'accès au réseau local entraîne des erreurs de socket. Si vous utilisez des API qui effectuent des opérations sur le réseau local en dehors du processus de votre application (par exemple, NsdManager), elles ne sont pas affectées lors de l'activation.

Pour restaurer l'accès, vous devez accorder à votre application l'autorisation NEARBY_WIFI_DEVICES.

• Assurez-vous que l'application déclare l'autorisation NEARBY_WIFI_DEVICES dans son manifest.
• Accédez à Paramètres > Applications > [Nom de l'application] > Autorisations > Appareils à proximité > Autoriser.

L'accès de votre application au réseau local devrait maintenant être rétabli, et tous vos scénarios devraient fonctionner comme avant l'activation de l'application. Voici l'impact sur le trafic réseau de l'application.

Utilisez la commande suivante pour désactiver la configuration Appcompat :

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Erreurs

Si une demande d'accès au réseau local échoue en raison d'une autorisation manquante :

• Les connexions TCP entraînent généralement une erreur de délai d'attente.

• Les erreurs UDP et les refus d'autorisation généraux entraînent généralement un code d'erreur EPERM.

Bugs

Signalez les bugs et envoyez vos commentaires concernant :

• Différences concernant l'accès au réseau local (vous pensez qu'un certain accès ne devrait pas être considéré comme un accès au réseau local)
• Bugs où l'accès au réseau local devrait être bloqué, mais ne l'est pas
• Bugs où l'accès au réseau local ne devrait pas être bloqué, mais l'est

Les éléments suivants ne devraient pas être affectés par ce changement :

• Accès à Internet
• Réseau mobile