Le tecniche di questa famiglia hanno una caratteristica che le distingue da tutte le altre della serie: non aggirano nessuna protezione.
Il sistema dei permessi funziona correttamente, mostra le richieste, chiede conferma. La protezione viene superata perché l’utente la disattiva — convinto, distratto, o messo nella condizione di non poter fare altrimenti.
È quindi una famiglia di tecniche di persuasione più che di tecniche informatiche.
Approfondisce la raccomandazione controllare le autorizzazioni delle app.
1. L’app legittima che chiede troppo
Come funziona. Un’app reale e funzionante chiede permessi che eccedono la sua funzione, motivandoli con benefici plausibili: “per suggerirti contenuti”, “per migliorare l’esperienza”, “per condividere più facilmente”.
Perché funziona. L’app fa davvero ciò che promette, e la richiesta è formulata come un miglioramento. Non c’è nulla di visibilmente sbagliato.
Cosa ottiene. Dati che vengono usati per profilazione o ceduti a terzi. È il caso più frequente in assoluto, ed è largamente legale.
La difesa specifica. Le tre domande della raccomandazione: l’app funzionerebbe senza? Serve ora o sempre? Cosa succede se dico di no?
2. La richiesta annidata
Come funziona. Un permesso necessario viene chiesto per primo, e subito dopo ne viene chiesto uno non necessario, nella stessa sequenza.
Perché funziona. Il primo sì crea uno slancio: la seconda richiesta arriva in un momento in cui l’attenzione critica si è già abbassata.
Cosa ottiene. Un permesso che, chiesto isolatamente, sarebbe stato rifiutato.
La difesa specifica. Trattare ogni richiesta come indipendente. Un sì non implica il successivo.
3. La conquista dell’accessibilità
È la tecnica più seria di questa famiglia, e merita spazio.
Come funziona. L’app chiede all’utente di attivare il permesso di accessibilità, accompagnandolo passo per passo nelle impostazioni. La motivazione è sempre plausibile: “per proteggere il dispositivo”, “per bloccare la pubblicità”, “per far funzionare questa funzione”.
Perché funziona nonostante gli avvisi. Il sistema mostra un avviso esplicito, ma l’utente ha già deciso di installare quell’app e la considera affidabile. L’avviso viene letto come una formalità.
Cosa ottiene. Il controllo più ampio disponibile: leggere lo schermo e agire al posto dell’utente. Da lì è possibile vedere credenziali digitate, leggere messaggi, e compiere azioni dentro altre app.
La difesa specifica. Una regola senza eccezioni: l’accessibilità si concede solo a strumenti di ausilio per disabilità. Qualsiasi altra motivazione, per quanto convincente, non giustifica quel permesso.
4. La sovrapposizione ingannevole
Come funziona. Un’app con il permesso di disegnare sopra le altre mostra un finto modulo di accesso sopra un’app reale. L’utente digita le credenziali credendo di essere nell’app legittima.
Perché funziona. Visivamente è indistinguibile: la schermata sotto è quella vera.
Cosa ottiene. Credenziali digitate volontariamente.
La difesa specifica. Verificare quali app hanno il permesso di sovrapposizione. I sistemi recenti limitano molto questa possibilità durante l’inserimento di dati sensibili.
5. L’app che cambia dopo l’installazione
Come funziona. Un’app onesta e utile accumula installazioni. Poi viene venduta, o riceve un aggiornamento che introduce funzioni di raccolta. I permessi erano già concessi.
Perché funziona. Non c’è un momento di richiesta: il consenso era stato dato all’app di prima.
Cosa ottiene. L’accesso a tutto ciò che era già stato autorizzato, per un numero potenzialmente enorme di utenti.
La difesa specifica. La revisione periodica, che è l’unica cosa che intercetta un cambiamento avvenuto in silenzio. E, per le estensioni del browser, verificare che siano ancora mantenute dallo stesso autore.
6. L’app fuori dal negozio
Come funziona. Un’app viene distribuita al di fuori dei negozi ufficiali — tramite un collegamento, un messaggio, un sito. Per installarla occorre attivare il permesso di installazione da fonti esterne.
Perché funziona. La motivazione è quasi sempre buona: una versione anticipata, un’app non disponibile nella tua zona, uno strumento specifico.
Cosa ottiene. Un’installazione che non ha superato alcun controllo.
La difesa specifica. Non attivare quel permesso. È l’unico caso di questa famiglia in cui la regola può essere assoluta senza costi rilevanti per la maggior parte delle persone.
Quadro d’insieme
| Tecnica | Frequenza | Gravità | Cosa la ferma |
|---|---|---|---|
| App legittima che chiede troppo | Molto alta | Bassa-media | Le tre domande |
| Richiesta annidata | Alta | Media | Valutare ogni richiesta a sé |
| Conquista dell’accessibilità | Media | Massima | Regola senza eccezioni |
| Sovrapposizione ingannevole | Bassa | Alta | Verifica dei permessi speciali |
| App che cambia dopo | Media | Media-alta | Revisione periodica |
| App fuori dal negozio | Media | Alta | Non attivare il permesso |
Le due righe in evidenza definiscono le priorità: una regola da non violare mai, e un’abitudine da mantenere. Tutto il resto discende da lì.
Le formule ricorrenti nelle richieste
Poiché queste tecniche si basano sul convincere, vale la pena riconoscere le formulazioni che ricorrono. Non sono prove di malafede — molte app oneste le usano — ma sono i punti in cui vale la pena fermarsi.
| Formula | Cosa nasconde |
|---|---|
| “Per un’esperienza migliore” | Nessuna funzione specifica: è una motivazione generica |
| “Per suggerirti contenuti” | Profilazione |
| “Per condividere più facilmente” | Accesso alla rubrica |
| “Per proteggere il tuo dispositivo” | Spesso accompagna la richiesta di accessibilità |
| “Alcune funzioni non saranno disponibili” | Pressione, senza dire quali |
| “Consenti per continuare” | Il permesso presentato come obbligatorio |
| “Solo per questa volta” in una schermata di sistema | Confusione tra opzione del sistema e testo dell’app |
La quarta riga è la più importante da riconoscere: una richiesta di accessibilità motivata con la sicurezza è un’incoerenza, perché quel permesso serve all’accessibilità, non alla protezione.
La quinta e la sesta descrivono la stessa pressione: presentare un permesso facoltativo come necessario. Il modo di verificarlo è semplice — rifiuta e guarda cosa succede davvero.
L’ultima merita attenzione perché è sottile: alcune app scrivono testi che imitano le opzioni del sistema, per orientare la scelta. Le opzioni vere sono solo quelle nella finestra di sistema, riconoscibile dallo stile.
Perché queste tecniche funzionano
Vale la pena guardare il meccanismo comune, perché è lo stesso che ricorre in tutta la serie.
La richiesta arriva nel momento peggiore. Quando stai cercando di fare qualcosa, non quando stai valutando la sicurezza. L’attenzione è sull’obiettivo.
Il rifiuto ha un costo immediato e certo, il consenso un costo differito e incerto. È un’asimmetria che spinge naturalmente verso il sì.
La motivazione è sempre plausibile. Nessuna richiesta dice “voglio i tuoi dati”: dice “per servirti meglio”.
Non c’è un momento di verifica. Una volta concesso, nulla riporta il permesso all’attenzione — se non una revisione volontaria.
Da qui la ragione per cui questa raccomandazione insiste su due cose apparentemente banali: fermarsi cinque secondi al momento della richiesta, e guardare l’elenco ogni tanto. Non sono consigli generici: sono le uniche due contromisure alla struttura del problema.
Cosa non rientra in questa famiglia
Le vulnerabilità del sistema. Difetti che consentono di aggirare i permessi esistono e vengono corretti dagli aggiornamenti. Sono un’altra famiglia, e la difesa è tenere il dispositivo aggiornato.
Le app installate da altri sul tuo dispositivo. È un problema di accesso fisico, trattato nelle unità sul blocco schermo.
La raccolta dichiarata e consentita. Un’app che raccoglie ciò che ha dichiarato non sta abusando di nulla: sta facendo ciò per cui hai dato il consenso. Il rimedio è revocarlo, non è un incidente.
Il contesto in cui queste tecniche arrivano
Un elemento che vale la pena isolare: quasi mai una richiesta di permesso arriva da sola. Arriva dentro un percorso, e il percorso conta quanto la richiesta.
| Come sei arrivato all’app | Livello di attenzione |
|---|---|
| L’hai cercata tu nel negozio | Basso |
| Te l’ha consigliata una persona di cui ti fidi | Basso |
| L’hai trovata seguendo un link in un messaggio | Alto |
| Te l’ha suggerita un’assistenza che ti ha contattato | Massimo |
| L’hai installata per risolvere un problema urgente | Alto |
| Compare in una pubblicità che promette molto | Alto |
Le due righe in evidenza descrivono lo scenario più serio di questa famiglia: qualcuno che ti contatta, si presenta come assistenza — di un servizio, di una banca, di un operatore — e ti guida a installare uno strumento “per risolvere il problema”.
Quello strumento chiede l’accessibilità, e la richiesta arriva in un momento in cui una persona sta cercando aiuto e si fida di chi glielo sta dando.
La regola in questo caso è netta: nessuna assistenza legittima chiede di installare un’app di controllo remoto durante una chiamata non richiesta. Se accade, si chiude e si richiama il numero ufficiale del servizio.
Vale la pena aggiungere che questo scenario colpisce in modo sproporzionato le persone meno abituate agli strumenti digitali — ed è il caso in cui parlarne prima, in famiglia, vale più di qualsiasi impostazione.
Perché questa famiglia è la più difficile da difendere
Una considerazione finale che vale per tutta la serie.
Contro le altre famiglie di minacce esistono difese automatiche: la cifratura protegge senza che tu faccia nulla, il secondo fattore blocca chi non ha il codice, un aggiornamento chiude una vulnerabilità.
Qui no. Il sistema ha già fatto tutto il possibile: isola le app, richiede il consenso, rende scomodi i permessi potenti, mostra avvisi espliciti, segnala l’uso in tempo reale.
E poi chiede a una persona di decidere. A quel punto la protezione dipende da una risposta, e nessuna tecnologia può darla al posto suo.
| Difesa | Chi la esercita |
|---|---|
| Isolamento tra app | Il sistema |
| Richiesta di consenso | Il sistema |
| Avvisi sui permessi potenti | Il sistema |
| Indicatori di uso | Il sistema |
| La risposta alla richiesta | Tu |
È il motivo per cui questa unità non contiene configurazioni da attivare ma due comportamenti: fermarsi cinque secondi al momento della richiesta, e guardare l’elenco ogni tanto.
Ed è anche il motivo per cui, nel Framework Cyber Welfare, questa raccomandazione appartiene tanto al pilastro delle Competenze quanto a quello del Comportamento: non basta sapere cosa fa un permesso, serve l’abitudine di chiederselo nel momento giusto.
Collegamento al Framework Cyber Welfare
| Pilastro | Contributo di questo contenuto |
|---|---|
| Consapevolezza | Capire che qui non si aggira nulla: si ottiene un sì |
| Competenze | Riconoscere la richiesta annidata e la conquista dell’accessibilità |
| Comportamento Sicuro | Una regola assoluta sull’accessibilità, e la revisione periodica |
Livello di riferimento: FL3 — Autonomo.
Riepilogo
- Queste tecniche non aggirano il sistema: ottengono un consenso.
- La più seria è la conquista dell’accessibilità, e si ferma con una regola senza eccezioni.
- Un’app può cambiare dopo che le hai dato il permesso: solo la revisione periodica lo intercetta.
- La struttura del problema è che la richiesta arriva sempre nel momento peggiore.
Azione concreta da fare oggi. Decidi ora, a mente fredda, cosa risponderai la prossima volta che un’app ti chiederà di attivare l’accessibilità. La decisione presa adesso vale più di quella presa mentre stai cercando di far funzionare qualcosa.
Contenuti collegati
- Controllare le autorizzazioni delle app — la raccomandazione da cui nasce questo approfondimento
- Impatti dei permessi eccessivi — cosa consente ciò che si ottiene con queste tecniche
- Segnali di app che raccolgono dati — come riconoscerle prima e dopo
- Come rivedere le autorizzazioni concesse — la revisione che intercetta i cambiamenti
Risorse correlate
Inizia dal primo passo: il Programma “Proteggi la Tua Privacy Digitale” ti accompagna gratuitamente, una raccomandazione alla volta.
