Re: [GNU-linux-libre] Proposal to revise FSDG to exclude SaaSS-only software clients

[Adonay Felipe Nogueira]

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