“The dawn of everything”, the “always turn the other cheek” Christian commandment, the Anarchic International and immersive fiction

In their The dawn of everything, David Graeber and David Wengrow prove with archaeological evidence that, in a relatively distant past, there were big cities where people already knew and practiced agriculture, and where, in some cases for more than one millennium, decisions and rules about the commons were taken in open assemblies; thus, they also had good levels of equality in distribution of wealth and resources.

At some point in the book they ask themselves, and obviously their readers too, why, at least now, there is no archaeological evidence of later examples of such big societies which worked that way, and they make an hypothesis: that when three issues or “traits” of centralized accumulation of power and wealth and resources, which i won’t summarize here (read the book! 🙂), intertwine in a given society (like our present societies, since very long time), it’s very difficult to get back, or forward, to equality in distribution of power, work, wealth and resources.

They also emphasize that it is an hypothesis, and that more studies should be done to prove it more, or modify it, or extend it.

Anyway, i have an hypothesis about something that has probably worsened the situation: the Christian commandment to “always turn the other cheek” when anyone treats you bad: although i guess nobody can sincerely tell to really always behave like that, i think it’s a commandment which worked and still works a lot as a moral condemnation of some of the most effective actions any oppressed people can implement against their oppressors, and as a self-justification of fear of implementing it or, sometimes, even of thinking about it.

This bugs me a lot, also because i think that today it would be much easier to build equal societies, after an Anarchic International like this, i.e. after taking the lands to cultivate them without polluting, and the industrial facilities to shut down the polluting ones and build the sustainable alternatives while consuming less and better, which would also save our species and many others from the already ongoing decimation and the otherwise very probable future extinction caused by the current ecological catastrophe and-or the equally severe risks of the ongoing and future wars that the ecological catastrophe itself is very intertwined with: after an Anarchic International like this, in the liberated context it could foster (i.e. a global context of many federated little-to-medium sized communities where decisions and rules about the commons would be defined and refined in open assemblies, and thus we would have very good levels of equality in distribution of work, wealth and resources too, and where two or more communities would settle about exchanges of resources and products with inter-communal assemblies which could be made through the internet), tomorrow we would also have a hugely wider possibility to access and share all knowledge, and to build fictional worlds, with or without fictional stories, using open hardware and software produced by the communities, and to virtually live some time there, and to play and fight and love and build there, with or without other avatars of others’ selves, thus sublimating our dark sides in creativity and lashing them out in almost or totally harmless ways to an extent and with an immersivity that we, as a whole, never had before.

This is what arts have always been about, and tomorrow it would be just freely accessible for all.

Reasons why Meta joining the Fediverse is very bad, how to mitigate the damage, and an idea to save the Fediverse as a new and safer web space

[Last edited on Tuesday, 16 January 2024]

Although i’m sure it won’t avoid most of the damage, i strongly support the Anti-Meta Fedi Pact, and urge Fediverse admins to block Meta’s Threads (currently, the threads.net domain) at their Fediverse instances’ level, because Meta, the producer of Facebook, Whatsapp, Instagram and Threads, is known to do such things as:

  1. profiling users for targeting advertisements [e.g.: 1, 2];
  2. controlling their users emotions;
  3. spreading misinformation and conspiracy theories about November 2020 presidential election in USA;
  4. censoring political organizations – mostly, and by far, of the global left [1, 2], while not censoring political organizations of the most far right (e.g.: italian neofascist organizations like Casapound, Forza Nuova, Lealtà e Azione all have many pages and profiles on Facebook);
  5. facilitating a genocide;
  6. super-exploiting moderators;
  7. censoring wildfires news stories from Canada to Canadian users;
  8. systemically censoring Palestine contents on Instagram and Facebook;
  9. and so much more;

But most Fediverse platforms’ instances, especially most or all of the most populated, are not blocking and won’t block threads.net; thus, using those instances, will be less and less different than using Meta’s products, in terms of data scraping by Meta and users’ privacy, because those instances expose their users to the risk of giving complete access to their “private” messages (messages addressed to “Mentioned people only”, on Mastodon) just by unknowingly or thoughtlessly mentioning Threads accounts in such messages, and to complete access by Meta to their “less public” posts (posts addressed to “Followers only”, on Mastodon), when Threads users will get the possibility to follow other Fediverse platforms accounts, that is soon going to be implemented by Threads developers. Meta has scraped even “less public” posts and “private” messages on its platforms in the past, and it is most probably still doing it, in spite of some court cases that accounted it guilty of doing it and “punished” it, much later than when each one of those abuses was made, with financial penalties that were ludicrous to Meta, because of its huge financial wealth.

To mitigate these risks, users of Fediverse platforms instances that have not blocked the threads.net domain at instance level can still block it by themselves and for themselves only (on Mastodon’s official web frontend, this can be done by clicking on the three dots icon in the lower right corner of any post and choosing Block domain from the popup menu); or they can set their accounts to prompt for their confirmation whenever another account tries to follow theirs (on Mastodon’s official web frontend, this can be done by going to Preferences > Public profile > Privacy and reach tab, and unchecking the Automatically accept new followers checkbox), and then paying attention to not mention any Threads account in their non-public posts (“Followers only” and “Mentioned people only” posts, on Mastodon).

Still, to ensure that the Fediverse won’t become a big barrel from which Meta, and probably other big and medium commercial players in the future, will scrape not only data from public posts, but also from “less public” and “private” posts, the most safe way would be to write a new social networking protocol specification, that could be named FreeSocialProtocol, and to put it under a license or a patent that (1) would prohibit any use of the protocol itself in products that are not open source, and (2) would prohibit its use in products that also use other protocols that are under no licenses, or that are under licenses not prohibiting their use in non-open source products (point 2 would make it a viral license/patent, like the GPL, but only on the open source condition; and necessarily so, because otherwise, this license/patent very purpose would be defeated).

I have no illusion that a new protocol with such a license or patent would be used by many from the start, and maybe it would take long for it to gain traction, or maybe it would never exit the “niche” status, but it would be good all the same even in these cases, and i think there is the possibility that it would gain a lot of traction, soon or later. But, again, i think it would be just and good if it existed even if it was never to exit the “niche” status.

Note 1: i’m trying to verify whether it is possible to create such a license, or such a patent, and to apply it to the specification of a social networking protocol: on Friday, 22 December 2023, i wrote an e-mail to the FSF (using the licensing@fsf.org e-mail address) asking just this; and on Saturday, 6 January 2024, i’ve written to the European section of the FSF too, at its licence-questions@fsfe.org e-mail address, without receiving any answer from both as of today, Tuesday, 16 January 2024.

Note 2: on this topic, you may want to read these ongoing discussions i’m having: the first one with a Fediverse protocols and platform (Streams) developer, the second one with an Akkoma developer (Akkoma is another Fediverse platform, a fork of Pleroma). I think they’re both at least very useful, clarifying and instructive.

End-to-end encryption and the web

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.

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

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.

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