Il problema che stai descrivendo non è ancora risolto completamente. Si concentra in gran parte su Audit di software il suo metodo di distribuzione e design di protocollo .
Progettazione del protocollo
Hai già detto che la crittografia deve essere eseguita sul lato client. Questo è già offerto da molti software di oggi. Le aziende che vendono un protocollo di crittografia sul lato client non possono facilmente costruire il loro modello di entrate per vendere i dati del cliente senza che questo diventi pubblico.
Audit di verifica del software
Anche con un protocollo ben progettato, è possibile che il client non lo segua. Per verificare che il client faccia ciò che dice il protocollo, il software deve essere controllato dal pubblico. Questo funziona più facilmente quando il software è accessibile in un formato che l'uomo può capire meglio: nel codice sorgente. Un software verificabile non deve essere open source o avere il suo codice sorgente pubblicamente disponibile come TrueCrypt, ma è un punto molto strong.
Quando il codice sorgente è stato controllato, si pone il problema trust fidato : qualcuno deve verificare che il binario corrisponde al codice sorgente. Questo può essere risolto con Build deterministici , che è un metodo nuovo e attualmente molto instabile.
È stato utilizzato per garantire l'integrità di software considerati importanti come il Tor Browser Bundle o vari client Bitcoin. Debian ha iniziato uno sforzo per rendere il suo intero repository applicativo costruito in modo deterministico (ultimo collegamento).
La quantità di software che deve essere verificata può essere ridotta seguendo un modello simile al DRM: una parte del software è closed-source e non attendibile, mentre un'altra parte che esegue la crittografia è open source e controllata. End-to-End ( repository , blog article ) in combinazione con il client jmail di gmail o con addon pubblicato da Mega sono dei buoni esempi per questo.
Questi approcci rendono difficile nascondere che la crittografia di tutti è ignorata, ma è ancora facile nascondere che la crittografia one è ignorata.
Metodo di distribuzione
Ci sono diversi modi per distribuire il software oggi. App store come Google Play Store o apt , il solito download HTTP e, sul Web , la soluzione HTTP / javascript.
Il metodo peggiore è HTTP / js: ogni volta che visiti la pagina, in pratica scarichi il software una nuova volta. Il server può fornire un contenuto dannoso e la volta successiva che si visita la pagina vengono eliminate tutte le tracce. Il modo migliore per proteggere una pagina Web è il metodo simile a DRM che ho descritto sopra.
Anche i download HTTP hanno molti problemi. Ti stai affidando a tutti i fornitori di download che non offrono software dannoso. Android ha una casella di controllo "fonti non attendibili" che è disabilitata per impostazione predefinita per evitare di installare tale software. Sto anche includendo PPA s in questo, ma non lo so di qualsiasi contenuto dannoso servito su PPA. Meglio è che ti fidi di una sola entità, attraverso i repository dei pacchetti.
Anche i repository di pacchetti ti danno un'entità di cui ti devi fidare: il maintainer del repository, google, debian o qualcun altro. Il software potrebbe essere controllabile e utilizzare un buon protocollo, ma la versione specifica fornita dal manutentore ha una backdoor.
Il problema è simile al problema di distribuzione del certificato, assicurando che tutte le persone vedano lo stesso, quindi si applicano soluzioni simili. Potrei pensare a un protocollo di gossip come quello descritto nel wiki End-to-End , o anche più decentralizzati come Namecoin , tuttavia puoi discutere di quanto sia decentralizzato Namecoin, quando l'hashing diventa centralizzato.
Per proteggerti dal solito cattivo, affidarti ad un fidato redattore di repository è abbastanza oggi, dato che la maggior parte delle persone continua a cadere nella trappola di download HTTP, e possono fare affari lì.