Autorizzazione di accesso alla rete locale

I dispositivi su una rete locale (LAN) sono accessibili a qualsiasi app che disponga dell'autorizzazione INTERNET. In questo modo, le app possono connettersi facilmente ai dispositivi locali, ma ciò comporta anche implicazioni per la privacy, ad esempio la creazione di un'impronta dell'utente e la funzione di proxy per la posizione.

Il progetto Protezioni rete locale mira a proteggere la privacy dell'utente limitando l'accesso alla rete locale tramite una nuova autorizzazione di runtime.

Impatto

Durante Android 16, questa autorizzazione è una funzionalità di attivazione facoltativa, il che significa che saranno interessate solo le app che la attivano. L'obiettivo dell'attivazione è consentire agli sviluppatori di app di capire quali parti della loro app dipendono dall'accesso implicito alla rete locale in modo da prepararsi a proteggerle con le autorizzazioni in una futura release di Android.

Le app saranno interessate se accedono alla rete locale dell'utente utilizzando:

• Utilizzo diretto o di libreria di socket non elaborati su indirizzi di rete locali, ad esempio Multicast DNS (mDNS) o Simple Service Discovery Protocol (SSDP).
• Utilizzo di classi a livello di framework che accedono alla rete locale, ad esempio NsdManager.

Dettagli dell'impatto

Il traffico da e verso un indirizzo di rete locale richiede l'autorizzazione di accesso alla rete locale. La seguente tabella elenca alcuni casi comuni:

Queste limitazioni sono implementate in profondità nello stack di rete e pertanto si applicano a tutte le API di rete. Ciò include i socket creati nella piattaforma o nel codice gestito, le librerie di rete come Cronet e OkHttp e qualsiasi API implementata sopra queste. Il tentativo di risolvere i servizi sulla rete locale che hanno un suffisso .local richiede l'autorizzazione di accesso alla rete locale.

Eccezioni alle regole precedenti:

• Se il server DNS di un dispositivo si trova su una rete locale, il traffico da / verso il server (sulla porta 53) non richiede l'autorizzazione di accesso alla rete locale.
• Le applicazioni che utilizzano Output Switcher come selettore in-app non avranno bisogno delle autorizzazioni di rete locale (ulteriori indicazioni verranno fornite in una release successiva).

Applicazione di Android 17

A partire da Android 17, le protezioni della rete locale sono obbligatorie e applicate alle app che hanno come target Android 17 o versioni successive.

Per verificare che la funzionalità dell'app non sia interrotta dopo l'applicazione forzata, le applicazioni che hanno come target l'SDK 37 o versioni successive devono adottare uno dei seguenti percorsi per gestire l'accesso alla rete locale:

Percorso A: utilizzo di selettori che tutelano la privacy

Per le attività di rilevamento e connessione mediate dal sistema, utilizza i selettori per evitare di richiedere l'autorizzazione di runtime generica. Utilizza i seguenti selettori in base al tuo caso d'uso:

• Streaming di contenuti multimediali:per le applicazioni che supportano Google Cast, è possibile utilizzare la funzionalità Selettore di output. In questo modo, gli sviluppatori possono consentire agli utenti di selezionare dispositivi di streaming specifici senza che l'app debba richiedere l'ampia autorizzazione ACCESS_LOCAL_NETWORK.
• Connettività generale:NsdManager include un selettore di servizi gestito dal sistema per l'individuazione mDNS. Anziché eseguire la scansione dell'intera rete, il sistema mostra una finestra di dialogo che consente all'utente di selezionare un singolo dispositivo a cui l'app può accedere.

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
    }
})

Percorso B: richiesta dell'autorizzazione di runtime (accesso ampio)

Questo percorso è necessario per casi d'uso complessi come la domotica o la gestione di dispositivi IoT che richiedono un accesso ampio e persistente alla rete locale.

• Dichiara l'autorizzazione nel manifest:dichiara esplicitamente ACCESS_LOCAL_NETWORK in AndroidManifest.xml.

• Richiedere l'autorizzazione in fase di runtime:prima di tentare qualsiasi accesso alla rete locale, le applicazioni devono verificare se l'autorizzazione è stata concessa. In caso contrario, deve chiamare Activity.requestPermission() per attivare il prompt di sistema standard.

• Scenario di pre-concessione:l'autorizzazione ACCESS_LOCAL_NETWORK fa parte del gruppo di autorizzazioni NEARBY_DEVICES. Se un utente ha già concesso un'altra autorizzazione in questo gruppo (ad esempio le autorizzazioni Bluetooth), non gli verrà richiesto nuovamente l'accesso alla rete locale.

• Gestione del rifiuto e della revoca: le app devono gestire correttamente i casi in cui l'utente rifiuta la richiesta o revoca l'autorizzazione in un secondo momento nelle impostazioni di sistema. In questi scenari, il traffico di rete locale verrà bloccato.

Strategia di reimpostazione del contatore delle richieste di autorizzazione

La piattaforma implementa una strategia di ripristino del contatore che affronta gli scenari in cui il precedente rifiuto di un'app del gruppo di autorizzazioni NEARBY_DEVICES (che ora include ACCESS_LOCAL_NETWORK) ha impedito all'app di chiedere l'autorizzazione dopo aver presentato in modo adeguato la sua motivazione. Questo meccanismo offre all'app ulteriori opportunità di richiamare l'API requestPermission(), azzerando di fatto il conteggio dei rifiuti per l'autorizzazione ACCESS_LOCAL_NETWORK. Ciò consente un coinvolgimento più sfumato dell'utente, soprattutto quando il rifiuto iniziale si è verificato prima che l'app potesse comunicare la necessità dell'accesso alla rete locale per la sua funzionalità principale.

Modello di autorizzazioni suddivise

L'autorizzazione di accesso alla rete locale utilizza una strategia di migrazione delle autorizzazioni suddivise per gestire in modo diverso le applicazioni nuove e legacy, in base all'SDK di destinazione

Strategia di portabilità del numero per caso d'uso

• Trasmissione:per le funzionalità di trasmissione dei contenuti multimediali, la strategia più appropriata e rispettosa della privacy è utilizzare lo switcher di output. Questo metodo consente al sistema di gestire la connessione e il rilevamento della rete locale per conto dell'utente, eliminando la necessità per l'app di richiedere l'autorizzazione ACCESS_LOCAL_NETWORK.

• Browser:la gestione degli errori richiede approcci diversi in base al protocollo. Gli errori UDP generano il codice di errore EPERM. Per le connessioni TCP, i browser devono utilizzare l'API NDK android_getnetworkblockedreason(int sockFd) per determinare se un pacchetto è stato bloccato da LNP. Questa API restituisce ANDROID_NETWORK_BLOCKED_REASON_LNP.

• Altri casi d'uso (ad esempio, IoT): le applicazioni che trovano dispositivi utilizzando mDNS devono utilizzare android.net.nsd.DiscoveryRequest#FLAG_SHOW_PICKER, che consente di trovare dispositivi senza l'autorizzazione, e NsdManager#registerServiceInfoCallback / NsdManager#resolveService per ottenere gli indirizzi IP. Le connessioni agli indirizzi IP ottenuti in questo modo non richiedono l'autorizzazione ACCESS_LOCAL_NETWORK.

Per le applicazioni che richiedono la comunicazione diretta con la rete locale e non possono utilizzare i selettori mediati dal sistema, l'approccio suggerito è quello di utilizzare la strategia del contatore di ripristino delle autorizzazioni. Se l'autorizzazione ACCESS_LOCAL_NETWORK viene revocata dall'utente, questo meccanismo offre ulteriori opportunità all'app di richiedere nuovamente l'autorizzazione, consentendo agli sviluppatori di presentare una motivazione più chiara per l'utente.

Indicazioni per Android 16

Per attivare le limitazioni di accesso alla rete locale:

1. Eseguire il flash del dispositivo con una build con Android 16 Beta 3 o versioni successive
2. Installa l'app da testare

3. Attiva/disattiva la configurazione Appcompat utilizzando adb

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. Riavvia il dispositivo

Ora l'accesso dell'app alla rete locale è limitato e qualsiasi tentativo di accedere alla rete locale genera errori di socket. Se utilizzi API che eseguono operazioni di rete locale al di fuori del processo della tua app (ad esempio NsdManager), queste non vengono interessate durante l'attivazione.

Per ripristinare l'accesso, devi concedere all'app l'autorizzazione per NEARBY_WIFI_DEVICES.

• Assicurati che l'app dichiari l'autorizzazione NEARBY_WIFI_DEVICES nel file manifest.
• Vai a Impostazioni > App > [Nome app] > Autorizzazioni > Dispositivi nelle vicinanze > Consenti.

Ora l'accesso dell'app alla rete locale dovrebbe essere ripristinato e tutti gli scenari dovrebbero funzionare come prima dell'attivazione dell'app. Ecco come viene influenzato il traffico di rete delle app.

Utilizza il seguente comando per disattivare la configurazione Appcompat

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Errori

Se una richiesta di accesso alla rete locale non va a buon fine a causa di un'autorizzazione mancante:

• Le connessioni TCP in genere generano un errore di timeout.

• Gli errori UDP e i negativi di autorizzazione generali in genere generano un codice di errore EPERM.

Bug

Invia bug e feedback per:

• Discrepanze nell'accesso alla LAN (non ritieni che un determinato accesso debba essere considerato "accesso alla rete locale")
• Bug in cui l'accesso LAN dovrebbe essere bloccato, ma non lo è
• Bug in cui l'accesso LAN non dovrebbe essere bloccato, ma lo è

Questa modifica non dovrebbe interessare:

• Accesso a internet
• Rete mobile