English version
I wonder how including end-to-end encryption in a webapp, like corporations such as whatsapp, telegram, protonmail, tutanota and probably many others already do, could not be a bad idea even for less commercial projects like Mastodon, etc., basically for a very simple reason: every time a user’s browser connects to an url, it downloads from the server code (html, javascript, ecc.) that, despite showing a potentially identical interface to the user, can be different and do different things than the code the browser downloaded from the same url the previous time, so there’s no way for third parties to check that code and verify it doesn’t do malicious things, and even without big technical skills a malicious admin of a web server claiming to host a webapp implementing end-to-end encryption can alter it, even just for a short amount of time, so that the server, to make an example, will send to the browser of a single targeted user – let’s call him Pippo -, even just once, code that will make it do things which Pippo doesn’t want it to do, such as sending his private key, on first submission of a new post/message, to a mailbox owned by the admin, which would allow the admin, soon after that, to revert the webapp to its official version, having by then obtained the possibility to decrypt and thus read, since that very moment, all the posts or messages which Pippo will continue to consider accessible only to his recipients, as well as the possibility to impersonate him, without risking any longer Pippo noticing it before he possibly finds himself in big troubles, and maybe even later.
A false sense of security is worse than no security at all, thus i think it would be better to not implement end-to-end encryption in webapps, warning their users that anything they send will be potentially readable by the admins, and reserving end-to-end encryption to “classical” apps which are distributed by safer means like f-droid.
Versione in italiano
Mi chiedo in che modo implementare la crittografia end-to-end in una webapp, come già fanno aziendone quali whatsapp, telegram, protonmail, tutanota e chissà quante altre più piccole, potrebbe non essere una cattiva idea anche per progetti meno commerciali come Mastodon, ecc., fondamentalmente per un motivo molto semplice: ogni volta che il browser di un utente accede a una url, scarica dal server del codice (html, javascript, ecc.) che, pur mostrando all’utente un’interfaccia potenzialmente identica, può essere diverso e fare cose diverse rispetto al codice che il browser ha scaricato dalla stessa url la volta precedente, quindi non c’è modo per terze parti di controllare quel codice e verificare che non faccia cose cattive, e anche senza grandi conoscenze e capacità tecniche un admino malevolo di un server web che dichiari di ospitare una webapp che implementa crittografia end-to-end può alterarla, anche solo per un breve lasso di tempo, in modo che il server, per fare un esempio, mandi al browser di un singolo utente preso di mira – chiamiamolo Pippo -, anche una volta sola, del codice che gli farà fare cose che Pippo non vorrebbe facesse, come mandare la sua chiave privata a una mailbox dell’admino al primo invio, da parte di Pippo, di un nuovo post/messaggio, ciò che permetterebbe all’admino di ripristinare, subito dopo, la webapp ufficiale, avendo nel frattempo ottenuto la possibilità di decrittare e quindi leggere, da quel momento in poi, tutti i post o i messaggi che Pippo continuerà a presumere accessibili soltanto ai suoi destinatari, come pure quella di impersonarlo, senza più nemmeno il remotissimo rischio che Pippo se ne accorga prima di trovarsi magari in guai seri, e forse anche dopo.
Un falso senso di sicurezza è peggio di nessuna sicurezza, meglio quindi una webapp che non implementa crittografia end-to-end ma avverte gli utenti che qualsiasi cosa inviino tramite la stessa può essere letta dagli admin, riservando la crittografia end-to-end alle app “classiche” distribuite tramite sistemi più sicuri tipo f-droid.