For an anarchic International (an approximate manifesto)

Thursday, May 5, 2022

(last modified on
Thursday, July 14, 2022:
minor changes)

The pandemic of covid and its variations, that as of today directly caused more than 6 millions deaths in the world, and indirectly caused more than 15 millions, is for the most part a consequence of the environmental devastation caused by capitalist exploitation of the whole living [1] [2] [3], and of the material and cultural misery it determines and pursues.

The onset of new pandemics and their increasing frequency were foreseen by many scientists (see the previous links). Nonetheless, even in the richest countries, the pandemic stroke after a long period during which nothing was done by those who could do the most to reduce the risk that those predictions foresaw; instead, they weakened further the public health systems (the italian one, for example, had undergone massive cuts during the previous ten years, which were made by institutional right, center, left parties to almost identical extents: see [1] and [2]).

The anti-covid vaccines which are currently disposable in the richest countries do work: they are statistically very effective in preserving people who accept to get vaccinated from getting ill, although they provide a rather brief cover. But, despite the fact their development was financed to a great extent by rich states with money from tax payers, these same states in developed countries buy them at a price per dose that is up to 24 times its cost of production, while the states where the large majority of the people of the world lives can’t afford to buy them and the bosses of pharmaceutical multinationals producing them don’t remise, not even temporarily, to the related patents, and don’t publish the know-how that’s necessary to build the machines to produce them, nor are they disposable to help in building these machines and to train the people who could use them within less rich and poor countries.

This way, the covid and variants pandemic will never be defeated, and other, new pandemics will happen more and more frequently.
Continua a leggere For an anarchic International (an approximate manifesto)

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


La timeline locale di ogni istanza Mastodon porta solo i toot (i post) pubblici dellə utentə della stessa istanza. Sulla timeline locale è quindi facile, volendo, conoscere persone che ancora non si conoscono e che hanno account sulla propria stessa istanza. La timeline federata porta i toot pubblici della timeline locale più i toot pubblici di quellə utentə di altre istanze che sono seguitə (lə utentə, non le istanze) da qualcun* che sta sulla propria.
Continua a leggere Idefix

CTemplar, “the only really secure end-to-end encrypted webmail”, can’t be trusted (as any other)

It’s silly.
CTemplar is a recent player in “secure end-to-end encrypted webmail” field.
They claim: «Our mission is to provide an anonymous E2EE (End to End Encrypted) email. No one except you and your recipient can read the contents of your emails, not even us» (archived).
They also claim: «In November of 2018, Professor Kobeissi revealed that if JavaScript is required for encryption, it can also be used to hack users who use end-to-end encrypted email services. How Did We Solve This With Checksums? The checksums, released on GitHub after every update, allows our users to quickly compare the code served to their browser, with the code hosted on GitHub within 15-30 seconds. Usually, comparing code can take hours or days. With checksums, you can do it in seconds» (archived – you can read Kobeissi findings here).
They give instructions about how to “quickly compare the code served to their [the users’] browser, with the code hosted on GitHub within 15-30 seconds” here (archived).
But the fact is: all users should spend “15-30 seconds” (I spent at least one minute when trying) every time they access any URL serving CTemplar webmail service on, in order to maybe feel certain (and currently not to be certain: see below) that the Javascript code running in their browsers is actually the same as that published on github – which is evidently totally impractical for anyone.
And the fact is: when I tried, the login page to their webmail service (archived) was not the same as the login page they published on github (archived): it sourced some more Javascript code at the end.

CTemplar login page source

And the fact is: would have it been the same, I still could not have been certain the Javascript code running in my browser was the same as that published on github, since for example the browser-compatibility.js file (among many other files the index.html sourced) had two integrity checksums.

CTemplar login page source (2)

The checksum of the browser-compatibility.js file published on github actually matched the first one specified in the integrity attribute for browser-compatibility.js on the page I got from the server, but I actually could have received the other, unknown and different browser-compatibility.js that is not published on github and that matches the second checksum (the problem here is that SRI allows to specify more than one checksum for a given file).
What does this all mean?
This means and confirms that Services offering end-to-end encryption through web sites can’t be trusted.

Services offering end-to-end encryption through web sites can’t be trusted

A false sense of security is worse than no security at all

[Last modified on Tuesday, June 14, 2022, 14:54: added a paragraph summarizing the problem at the beginning of the first imaginary reply]

Whatsapp, Telegram, Element/Matrix, Protonmail, Tutanota are just the most known and widely used services, among many, offering end-to-end encryption not only through their apps, but also through their web sites.

Can users of these web sites be confident that the people behind these web sites’ servers can’t read their “end-to-end encrypted” contents?

No, they can’t.
Not because end-to-end encryption itself is not secure (it can be); just because the delivery model of web apps, and particularly of their client-side code (i.e. code that will be executed on the user’s device), is incompatible with security: on the server-side, the client-side code that will be executed on the user’s device can be changed at any time by anyone who has access to the server(s) with very little probability of anyone noticing (not the users, and less so a “targeted” user, and less so any “third parties”). It’s not a mistery: anyone with some knowledge of how a browser works knows this; and it’s not even much of a problem (arguably, but this is my opinion), when users trust their web app providers and don’t need to trust that their data are inaccessible to anyone, i.e. not even their web app providers and in general the people on its server(s) side; it is a problem, though, when users do need to be sure of this, and it’s even more a problem when they are told, by the service owners, that this is the case: that nobody, not even them, the service providers and the people on the server(s) side, can access users’ data, while that’s just not true with web apps.
First, let’s get rid of one possible misconception: HTTPS does not make your contents unreadable by the people behind these or any other web site’s servers, it just gives you and those people pretty good security against others who may try to read your contents on the path between your device and the web sites’ servers.
Then, to the point, let’s make an example. User John logs into and starts typing for his friend Bob, believing Whatsapp claims that what he will send through Whatsapp servers will only be readable by Bob and nobody else, not even the people at Whatsapp, since it is always end-to-end encrypted. Jimmy, an admin at, could have set the servers so that they included into the web “page” that John is using a little javascript key-logging function that sends what John is typing to Whatsapp servers, unencrypted; and Jimmy could have set it just for John, and just for a few hours.

Is there something John can do, when using web sites offering end-to-end encryption, to be sure the people behind the servers actually won’t read what they are not meant to read?

In order to be sure of that, John should read the whole content his browser gets on each “page” (URL) access and understand what its client-side code actually does, which is totally impractical for anyone.

Could Jimmy-the-admin get to know John’s password too?

If Jimmy worked for Element/Matrix, Protonmail or Tutanota, I’m sure he could, since all these service providers’ web sites have a login page with a password field; their login pages usually include javascript code that, on users’ login, hashes users’ passwords before sending these hashes to the provider’s servers; when this is the case, the people behind these web sites servers actually can’t get to know their users’ passwords, but at any time these people can omit the password-hashing javascript code from any (“targeted”, in case) user’s login page, or include the usual password-hashing javascript code with just a few changes making it do absolutely nothing; this way they can receive any user’s password in clear text.

What can they do, once they get to know a user’s password, say John’s password?

Once they know John’s password, without doing any more “tricks”, they can decrypt John’s private key, that, if John has used one of these web sites even just once, has been stored on their servers (this is declaredly the case with Protonmail, see; page is archived here:; I’m almost certain it’s the case also with Element/Matrix, Tutanota and all the other providers offering end-to-end encryption through their web sites without requiring their users to pick a local file containing the private key each time it is needed); once they have decrypted John’s private key, they can save it unencrypted on their side and, since that very moment, they can read any encrypted content John received that is still on their servers; they can read any encrypted content John will receive; they can read any encrypted content John has sent that is still on their servers, if John encrypted it with his own public key as well as with his recipients’ ones (which is common practice); they can read any encrypted content John will send, if John will encrypt it with his own public key too ––– and, since that very moment, they can do all of this not only when John is using their web sites, but also when he’s using their applications, because any content John receives and sends, even when using their applications, always passes through their servers; last but not least, they can also send encrypted and-or signed contents on John’s behalf.
I’m also sure
that even the people behind the servers at Whatsapp, Telegram, and any other provider whose web site’s login page uses a login method not requiring a password, can get to know, on each login (authentication) John does with their web sites, a “secret” of John’s allowing them to unlock his private key, since in any case they need to do it without requiring John to pick a file with his private key every time it is needed; and in any case, as I wrote above, they can read what he’s writing (and what other “targeted” John’s friends are writing, too) with a simple javascript keylogger.

– Do you think these security issues have been exploited yet?

I can’t be sure, of course, but there are many suspicious cases: see here and here, for example. In these cases, involving Telegram and Protonmail, it’s not clear and not explained whether Telegram and Protonmail provided authorities with just users’ metadata or even users’ data (conversations contents), but they surely could, in spite of what the already linked Wikipedia page is currently telling: it’s just not true, currently, that «Due to the encryption utilized, Proton Mail is unable to hand over the contents of encrypted emails under any circumstances», as it’s just currently not true in any other case of services offering end-to-end encryption through their web sites.

[Update: I wrote a post showing how end-to-end encryption could safely be implemented into web browsers]

[Update: CTemplar have the same issues, but blows more smoke in our eyes]

[I wrote this post in the guise of a dialogue and using male imaginary characters for the sake of comprehensibility and readability]

[My advice to anyone who wants or needs to do instant messaging with affordable end-to-end encryption, that is privacy, is to use Briar, XMPP with OMEMO, or Signal; for affordable e-mail end-to-end encryption on the desktop I suggest using Claws mail with its PGP plugins relying on GnuPG; there may be other affordable desktop e-mail clients (you can see here, although I don’t trust that page suggestions – more on this below), but I have not tested them; for affordable e-mail end-to-end encryption on Android I suggest using K-9 Mail or FairEmail, although they both rely on OpenKeychain for encryption: OpenKeychain is a good project, but sadly it is no longer actively developed since 2018; again: there may be others, but I have not tested them and I don’t trust suggestions since they state that «No security audits have been done by us and, thus, we cannot provide any security guarantees» and also because, in regard to webmail “clients” like Protonmail, Tutanota, etc., they just state a mild «some people don’t consider these “end-to-end secure”» while they have all the means to understand, and could and should declare, that services offering end-to-end encryption through web sites pose a huge security threat to their users]

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.

Ciao “metaverso” ciao

Ho chiuso i miei account facebook e instagram e per quanto riguarda i social userò solo il fediverso. Zuckerborg lascia la possibilità di annullare la cancellazione degli account sulle sue piattaforme per 30 giorni, e i miei non sono ancora passati, ma a ’sto giro non ci ricadrò, non cederò ai ricatti affettivi di parenti e amic* tipo “eh ma io qui ci ho tutt* lə miə amic* poi come faccio”, “eh ma io non le so usare quell’altre robe lì son complicate e così poi non ci si sente più”: potrebbero iniziare a farsi un account sul fediverso e poi magari fare un post di saluto nel “metaverso” linkandolo, come ho fatto io, e nella stragrande maggioranza dei casi non avrebbero difficoltà a imparare quel poco di diverso all’uso che c’è. Così, in un post di saluto su facebook, ho scritto ciò:

«Ciao ciccett*, chiudo l’account facebook e instagram e non ci rimetto più piede: facebook fa schifo, lo sappiamo, per tanti motivi. Per i messaggi privati vorrei chiudere anche whatsapp e usare solo signal e xmpp, che già uso, ma tropp* amic* usano ancora solo whatsapp, perciò per ora lo tengo.
Per quanto riguarda la mia presenza più o meno “pubblica” in rete tengo solo il blog,, e tre account nel fediverso: due su mastodon (una piattaforma “simile a twitter” nel fediverso), uno dei quali sta qui,[mio_nome_e_cognome], mentre il secondo, che uso molto di più, preferisco non linkarlo qui; e un terzo su pixelfed (la piattaforma “simile a instagram” nel fediverso) per postare le foto:
Perché questo post sia visibile ancora per un po’, per poterci salutare e magari se vi va seguirmi nel fediverso, la procedura di disiscrizione da facebook la farò domani.
Qui trovate un motore di ricerca di istanze (nodi) mastodon che consiglia alcune istanze italiane buone,, e ha una buona guida su mastodon che spiega anche un po’ in generale cos’è il fediverso:
Abbracci sparsi :)»

L’account su con nome e cognome me lo sono fatto apposta per non spaventare ai parenti e perché non mi va che quello che uso abitualmente sia troppo riconducibile a me-persona-fisica.

NetworkManager: come cambiare i DNS

Cambiare i DNS con NetworkManager, il “gestore di rete” di gran lunga più usato su Linux, magari per aggirare la censura di qualche sito italiano, è facile.

Per prima cosa si tratta di cliccare con il tasto destro del mouse sull’iconcina di rete che sta nella “system tray” del desktop e, dal menu che compare, cliccare col tasto sinistro su “Modifica connessioni…”.

NetworkManager - Cambiare i DNS - 1

Dalla finestra “Connessioni di rete” che compare bisogna selezionare la connessione che si sta utilizzando, nel mio caso “Ethernet”, e poi cliccare sull’iconcina con l’ingranaggio.

NetworkManager - Cambiare i DNS - 2

Dalla nuova finestra che compare bisogna selezionare la scheda “Impostazioni IPv4”.
Se il “Metodo” è impostato su “Automatico (DHCP)”, bisogna cambiarlo in “Automatico (DHCP) solo indirizzi”. Se invece, come nel mio caso, è impostato su “Manuale”, va già bene così. Nella casella di testo “Server DNS” bisogna specificare i DNS che si vuole usare (se sono più di uno basta separarli con uno spazio, o con virgola e poi spazio), poi cliccare sul pulsante “Salva”.

NetworkManager - Cambiare i DNS - 3

Ora si può chiudere anche la finestra “Connessioni di rete”.
Poi, perché il cambiamento di DNS sia effettivo, bisogna (almeno sul mio sistema), disattivare la connessione in uso cliccando col tasto sinistro sull’iconcina di rete e poi su “Disconnetti”…

NetworkManager - Cambiare i DNS - 4

…per poi riattivarla cliccando di nuovo col tasto sinistro sull’iconcina di rete e poi sul nome della connessione.

NetworkManager - Cambiare i DNS - 5

Ecco fatto.

Me nell’internet