English version
(Italian version below)
Implementing end-to-end encryption in a webapp, as companies such as WhatsApp, Telegram, ProtonMail, Tutanota, and who knows how many other smaller ones already do, is a very bad idea even for less commercial projects such as Mastodon, etc., for a very simple reason: every time a user’s browser accesses a URL, it downloads code (JavaScript, etc.) from the server which, while showing the user a potentially identical interface, may be different and do different things than the code the browser downloaded from the same URL the previous time, so there is no way for third parties to check that code and verify that it doesn’t do bad things, and even without extensive technical knowledge and skills, a malicious administrator of a web server hosting a webapp that implements end-to-end encryption can replace the webapp, even for a short period of time, with a modified version, so that the server, for example, will send to browsers code that will make the browsers do things that users would not want them to do, such as sending their passwords in plain text to the admin’s mailbox when they log in. Immediately after obtaining the passwords that the admin wants (let’s say it is just one: Goofy’s password), a script written by the admin could detect the success of the operation and restore the official webapp, having obtained in the meantime the ability to decrypt Goofy’s private key and thus read, from that moment on, all the posts or messages that Pippo will continue to consider accessible only to him and his recipients, as well as impersonating him, without even the slightest risk that Pippo will notice before finding himself in serious troubles, and perhaps even after. (If the private key is not on the server, but only in the browser storage on Pippo’s PC or cell phone, the admin could modify the webapp so that it sends him the private key too, with the same results).
A false sense of security is worse than no security at all, thus i think it would be much 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
Implementare la crittografia end-to-end in una webapp, come già fanno aziendone quali WhatsApp, Telegram, ProtonMail, Tutanota e chissà quante altre più piccole, è una cattiva idea anche per progetti meno commerciali come Mastodon, ecc., per un motivo molto semplice: ogni volta che il browser di un utente accede a una URL, scarica dal server del codice (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 admin malevolo di un server web che ospita una webapp che implementa crittografia end-to-end può sostituire la webapp, anche solo per un breve lasso di tempo, con una versione modificata in modo che il server, per fare un esempio, mandi ai browser del codice che gli farà fare cose che lə utentə non vorrebbero facessero, come mandare, al momento del login, le loro password in chiaro a una mailbox dell’admin. Subito dopo aver ottenuto le password che interessano all’admin (facciamo che è una sola: quella di Pippo), uno script fatto dallo stesso admin potrebbe rilevare il successo dell’operazione e ripristinare la webapp ufficiale, avendo nel frattempo ottenuto la possibilità di decrittare la chiave privata di Pippo e quindi di leggere, da quel momento in poi, tutti i post o i messaggi che Pippo continuerà a considerare accessibili soltanto a sé e 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. (Nel caso in cui la chiave privata non fosse sul server, ma solo nello storage del browser sul PC o sul cell di Pippo, l’admin potrebbe modificare la webapp in modo che gli mandi anche la chiave privata, con gli stessi esiti).
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.