A draft of some HTML extensions and one “browser rule” to secure web end-to-end encrypted communications

[Last edited on Friday, May the 20th, 2022, 07:30]

Nowadays there’s a huge security problem with webapps claiming to provide end-to-end secure encryption. The problem does not reside into end-to-end encryption itself: it can be secure enough for every kind of end user, when it’s well implemented and its implementations are periodically enough audited by affordable third parties. The main and by far biggest problem with end-to-end encryption through webapps (that is, through web sites) currently resides in the fact that any webapp, with its javascript client-side code, is delivered to any user – that is you, me, anyone else – every time he/she/* opens a “page” (an URL). This means that there can’t be any effective auditing activity by affordable third parties to ensure a webapp claiming to be secure does what it should and does not what it shouldn’t, since any malicious actor with access to the web server(s) it runs on could at any time change the code to steal any (possibly targeted) user’s supposedly client-side-only and secure data.

Continua a leggere A draft of some HTML extensions and one “browser rule” to secure web end-to-end encrypted communications

Abbozzo di un protocollo di instant messaging basato su server federati, sicuro e facile da usare

Un pezzetto di internet, per esempio

Dato che uno scambio di dati che sia davvero peer-to-peer (che avvenga cioè tra due dispositivi senza passare attraverso altri dispositivi) su internet non avviene praticamente mai (vedi la figura qui sopra), e dato che comunque anche il “peer-to-peer” come lo intendiamo comunemente è sempre meno praticabile (su connessioni mobile è un delirio, perché i provider di connessione mobile non permettono – se non pochissimi e comunque tramite sbattimenti burocratici non indifferenti da parte dellə utentə – di avere un indirizzo IP pubblico sulla internet), e dato che comunque un server di relay che stia tra i client viene comodo per registrarci sopra i messaggi crittati end-to-end quando un@ dellə utentə destinatariə di un messaggio è offline, e al tempo stesso, grazie alla crittografia end-to-end, può essere altrettanto sicuro di un’immaginaria connessione realmente peer-to-peer tra client, e dato che la crittografia end-to-end sarebbe comunque necessaria per la privacy dellə utentə anche con il “peer-to-peer” come comunemente inteso, mi chiedo se non sarebbe fattibile un protocollo di instant messaging basato su server federati, in cui la crittografia end-to-end non è opzionale, in cui però l’id univoco di ciascun utentə non è legato a un particolare server-dominio, in cui lə utentə scambiano dati tra loro passando attraverso i server federati e sono i server federati a fare “peer-to-peer” tra loro sincronizzando un database distribuito con una tabella che contiene l’id e la chiave pubblica di ciascun utente (mentre quella privata rimane sempre sui loro dispositivi), più l’indirizzo IP del server su cui ciascun utente è loggat@ (se è loggat@, altrimenti NULL), e un’altra tabella che contiene gli indirizzi IP dei server federati e il loro stato (tipo un numero da 0=offline a 9=“non mi sta usando nessun*”), così che se un server va giù per qualsiasi motivo lə utentə possono continuare a scambiare dati attraverso gli altri server senza interruzione di servizio e senza che, se poi quel server non torna più su, debban fare un nuovo account su un altro server e comunicarne il nuovo id a tuttə l’altrə, e così che il carico di utentə sia sempre abbastanza equamente distribuito tra i server. Ogni release di un client dovrebbe includere la lista dei server disponibili al momento della sua compilazione, così che il bootstrap di ogni sessione del client sia facile per l’utentə (poi il client scaricherebbe periodicamente la lista aggiornata dei server dal server cui è connesso). Per l’anonimato, i client dovrebbero potersi collegare ai server tramite Tor. Il sito di presentazione di questo protocollo, e tutti i vari siti coinvolti, dovrebbero mettere in chiaro che, lato server, non deve essere reso disponibile via web, e che, lato utente, non deve essere utilizzato via web, quand’anche qualche server desse questa possibilità.
Mi chiedo se non sarebbe fattibile.