“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.

E2ee and the web

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.

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