I'm not replying to anyone in particular, just giving a summary of what is discussed, perhaps helping other people grasp the situation, each of which divided in sections (look for lines beginning with “# ”).
# Remote untrusted code execution supposedly imposed by Telegram This was already moved by bill-auger to another thread. Please don't discuss it here. See [1] for the tip of the thread. # Is Telegram spyware? In this thematic axis, a section of the GNU FSDG against spyware (which it also describes as malware) is brought to light (as seen on [2]): > No Malware > > The distro must contain no DRM, no back doors, and no spyware. # Should the GNU FSDG foster decentralized communication technologies? I don't know how to summarize this argument enough, so I might be missing some context or terminology. All I can say from the study I made so far is that there seems to be a subgroup in the free/libre software movement that is fostering decentralized communication technologies. Now, their *recommendations* on *what* to foster diverges sometimes. For starters, they can conflict at the communication structure, for which (based on Katharina Nocun's work at [3]): * They can foster distributed decentralized technologies, where there is almost no server in between the clients, similar to torrents as long as you do use peer exchange, distributed hashtables and don't use torrent trackers. * Alternatively, they can be in favor of federated decentralized technologies, in which case there is at least two servers between clients and, by the nature of free/libre software, this would also allow the users themselves to host their servers. * There are people which defend both depending on context. In all the communication technology advocacy strategies mentioned there is agreement that each client or server must already have almost full interaction with other participants, that is to say that, it is not enough to understand HTTP GET or HTTP POST, since the client software or server software must be aware of the communication standards used by these players/participants of the network. To add to more complexity, if I understand correctly, there is another branching of the same bigger group (based on what Yochai Benkler pointed on [4]), which divides based on how the people want to address the regulatory or standardization of the protocol: * Traditionally there is the people who believe that the standardization or regulation must be discussed and evolved from within international standards body (forgive me if I give wrong examples, but I can think of: IETF, ISO, OASIS, W3C), workgroups called upon by these bodies (e.g.: Social Web Working Group created by W3C), or through assignment from existing international standards bodies to extension registration bodies, either optionally or mandatory (e.g.: latest XMPP standard proposed by IETF, where it states that, while any extension can be created, an optional registry can be done with XMPP Standards Foundation to foster interoperability). Some members of this group do recognize that, in the case of XMPP, registration with XSF should be changed in the IETF document so as to make it mandatory. Overall, proponents of this strategy find it important since a mass adoption may forbid players from making non-standardized interactions with the protocol, but for those who are against this strategy, these generally argue that either the standards track is too slow to follow the progress of technology or the international might be corrupted or impossible for the community to join. Examples of communication technologies that fit this overall item: Gopher, plain ActivityPub, XMPP (except OTR, also see notes in this very same item), e-mail (except Autocrypt), torrent (except WebTorrent). * There is part of the group which instead is in favor of self-standardized stuff, that is, not registering their full protocol with an international standards body, not even as a draft. This approach is seen as good if one is against slow moving decision structures, but is bad considering the fact that things could break for an existing participant (host, user, or developer) without reasonable time, or by some other person leveraging the customization ability to break compatibility with existing parties. As examples of protocols supported by this group, I can cite: Gemini, Tox, Matrix, Twister, ZeroNet, RetroShare, Secure Scuttlebutt, Delta Chat. * Finally, there is people which defend both depending on context. # References [1]: https://lists.nongnu.org/archive/html/gnu-linux-libre/2021-04/msg00024.html . [2]: https://www.gnu.org/distros/free-system-distribution-guidelines.html#no-malware . [3]: http://cdn.media.ccc.de/congress/2015/webm-hd/32c3-7403-en-de-A_New_Kid_on_the_Block_webm-hd.webm . [4]: https://downloads.softwarefreedom.org/2017/conference/0-keynote.webm . -- * Ativista do software livre * https://libreplanet.org/wiki/User:Adfeno * Membro dos grupos avaliadores de * Software (Free Software Directory) * Distribuições de sistemas (FreedSoftware) * Sites (Free JavaScript Action Team) * Não sou advogado e não fomento os não livres * Sempre veja o spam/lixo eletrônico do teu e-mail * Ou coloque todos os recebidos na caixa de entrada * Sempre assino e-mails com OpenPGP * Chave pública: vide endereço anterior * Qualquer outro pode ser fraude * Se não tens OpenPGP, ignore o anexo "signature.asc" * Ao enviar anexos * Docs., planilhas e apresentações: use OpenDocument * Outros tipos: vide endereço anterior * Use protocolos de comunicação federadas * Vide endereço anterior * Mensagens secretas somente via * XMPP com OMEMO * E-mail criptografado e assinado com OpenPGP
signature.asc
Description: OpenPGP digital signature
