Come comunicare le aspettative di sicurezza agli utenti in un'app di chat crittografata end-to-end?

NB: si tratta di un problema di ricerca aperto e attualmente molte persone fanno ricerche sulla comunicazione della sicurezza fornita dalle applicazioni di chat crittografate end-to-end. Quindi non ci sono ricerche che vengono in nostro soccorso qui, solo pensando al design.

Un'altra nota: non esiste un compromesso tra sicurezza e usabilità. Esistono principi di progettazione, vincoli relativi alla sicurezza e, a ciò si aggiungono designer poveri e bravi designer.

Devi comunicare ai tuoi utenti il livello di sicurezza che dovrebbero aspettarsi. In questo caso, un approccio visivo è quello che consiglierei.

Quando pubblicizzi / installa / esegui l'app, mostrare una visualizzazione di due persone che comunicano su un canale sicuro (e possibilmente terze parti che non riescono a penetrare attraverso il canale) potrebbe aiutare gli utenti a concettualizzare che stanno parlando da pari a pari e in modo sicuro.

Quando le persone passano alla visualizzazione Web, questa volta dovrebbe essere visualizzata in modo visibile quando i messaggi transitano attraverso un server marchiato con l'identità del marchio della tua azienda, e dovresti mostrare che questo server è in grado di leggere / intercettare i messaggi (a seconda su ciò che effettivamente fa la tua soluzione).

Perché le visualizzazioni? L'idea è di fare affidamento sulla capacità umana di elaborare concetti spaziali senza razionalizzarli. Mostrando i confini tra gli utenti, il server di marca e le parti esterne, è possibile comunicare senza sforzo la sicurezza fornita. Vedi "Dove l'azione è: le basi dell'interazione incorporata" per un (lunga) spiegazione del perché questo potrebbe facilitare il compito dei sensitivi dell'utente.

Dovresti anche comunicare chiaramente i rischi associati alla registrazione / scambio di identità sul tuo sistema, se presenti. Sembra dalla tua presentazione succinta del tuo prodotto che ci sono molti aspetti che non sono stati pensati affatto.

Dato che l'attività è scoraggiante, consiglio vivamente di assumere designer . In particolare, un designer di esperienza interazione / servizio / informazione per curare la presentazione dei benefici e dei limiti dello strumento e le interazioni generali di sicurezza; e un grafico o un motion designer per lavorare su qualunque visualizzazione di sicurezza si possa desiderare.

Le persone sono addestrate a ignorare gli avvisi di testo. Abbiamo fatto un ottimo lavoro nel farlo negli ultimi 30 anni fornendo messaggi in gran parte opachi e difficili da capire che presuppongono che l'utente non sia a conoscenza. Quindi nessuno li legge perché in gran parte hanno sempre fornito informazioni inutili. Non importa quanto bene costruisci il testo, la maggior parte delle persone lo ignorerà per ottenere ciò che vuole fare.

Le persone sono molto più brave a imparare idee complesse attraverso la visualizzazione che attraverso il testo. Invece di lanciare un messaggio che tutti ignoreranno, su entrambe le interfacce utente fornisce una rappresentazione visiva di come il messaggio viene trasmesso in chiaro.

Questo è il meglio che posso trasmettere in ascii:

client +++ client

client server ++ ----- nube cliente ++

E in qualche modo rappresenta che il percorso all'interno (cloud del server) ha il potenziale di intercettazione da parte degli avversari.

Forniscilo su entrambe le interfacce utente, in modo che ogni persona sappia se l'altro utilizza un client web dove.

Penso che Steve DL abbia davvero una grande idea nell'assumere designer. I progettisti hanno un'idea molto migliore di come comunicare le idee visive.

L'idea generale qui è che tutto ciò che viene trasmesso anche se i tuoi server non sono criptati dovrebbe sembrare almeno un po 'rischioso. Le comunicazioni client-client dovrebbero apparire molto più sicure.

Qui farò la seguente ipotesi: non stai implementando la crittografia end-to-end nel browser web. Invii messaggi di testo non crittografato al tuo server web che li ricodificherà per il destinatario (fungerà da proxy di traduzione).

In questo contesto, dovresti fare quanto segue:

Metti un chiaro avvertimento sul fatto che il web client, a causa della sua natura aperta, non può implementare la crittografia end-to-end e quindi non dovrebbe essere usato per questioni molto delicate.

Invia questo avviso come un messaggio facile da identificare per ogni partito ogni momento anche uno di essi utilizza un client web.

Questo dovrebbe essere abbastanza. Potresti voler collegare a una pagina web che spiega i possibili problemi con il client web (MITM, "trasformando il male", ecc.) Per i tecnici, ma, per la maggior parte degli utenti, non hanno davvero bisogno di conoscere i dettagli: indicare il problema, a cosa dovrebbero fare attenzione e lasciare che prenda la loro decisione.

Il mio ragionamento è il seguente:

• Per la maggior parte delle comunicazioni, semplicemente non ha importanza.
• Per le comunicazioni sensibili, gli utenti hanno la possibilità di utilizzare un sistema più sicuro. (nota che ancora devono fidarsi di te a meno che tu non fornisca anche una versione del codice sorgente del tuo cliente e abbiano accesso alle competenze necessarie per verificare quel codice sorgente)
• Non puoi, tu stesso, capire se un dato messaggio è abbastanza sensibile da richiedere la protezione più strong: solo i tuoi utenti possono farlo.
• Hai già raggiunto un compromesso consentendo l'uso di un canale meno sicuro.
• Le persone sono davvero pessime quando scelgono quando fidarsi di qualcuno e pensano alle conseguenze di tale scelta (è normale: siamo più o meno cablati per scegliere l'usabilità rispetto alla sicurezza).

Quindi: hai deciso di concedere due diversi livelli di sicurezza, sai che non puoi decidere quale debba essere utilizzato in ogni singolo caso.

Pertanto, non hai scelta: devi deve fare affidamento sugli utenti per prendere quella decisione. Dal momento che non hai utenti con una formazione tecnica, dovresti inserire un avviso che sia facile da capire dove sei sicuro che lo vedranno. Non puoi fare niente di più: le persone non leggono il testo lungo, non capiscono le complesse discussioni tecniche quindi devi avere un avvertimento semplice con una chiara spiegazione su cosa dovrebbe essere fatto ( non usare il client web per cose veramente sensibili).