repo-criteria-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: One shouldn't mix different kinds of requirements to the software in


From: Ian Kelling
Subject: Re: One shouldn't mix different kinds of requirements to the software into a single score
Date: Wed, 26 Feb 2020 09:39:43 -0500
User-agent: mu4e 1.3.6; emacs 28.0.50

KOLANICH <address@hidden> writes:

> Hi. I have looked into https://www.gnu.org/software/repo-criteria.en.html and 
> I dislike that you mix different kinds of requirements into a single score. I 
> think the method should be redesigned.
>
> I propose to separate the requirements listed there into the following 
> different axes, each one having a separate grade:
>
> 1. Client-side technical privacy and security requirements. Workability 
> without allowing access to the features of browsers that are known to be 
> possible to utilize to violate privacy. I.e. workability without JavaScript 
> goes here.
> 2. Measures to protect privacy and security of user's data from the server 
> itself. I mean replacing features requiring sensitive data collection and 
> storage with the features that require collection of less sensitive data or 
> don't require collection and storage at all. Signup without a email (i.e. 
> using alternative messagging systems with better privacy), signup without a 
> contact contact, crypto-authentication (compared to password authentication), 
> and stuff like that goes here.
> 3. Server-side technical and organizational privacy and security 
> requirements. Measures taken to protect the servers themselves againist 
> external Advanced Persistent Threats. Using a HSM, server-side encryption 
> goes here.
> 4. Technical freedom issues: how much the platform restricts user's and 
> admin's choice. I mean that every such aspect must be configurable.
> 5. Requirements to a purely political position of projects devs. Such as 
> promoting Linux-based OSes with GNU userspace utils instead of promoting 
> Linux-based OSes with toybox userspace utils.
> 6. Possibility to encourage end users of the software to follow the practices 
> recommended by FSF. Requiring users to have a license and requirements like 
> that goes here. And IMHO - each (anti)feature here must be configurable by an 
> admin (failing to do it should lower technical freedom score).
>
> It is because 1-3 are extremily important, but differently for each 
> individual, 4 is very important, 5 is unimportant and 6 is highky 
> controversal.

I don't agree with your assessment of what is important, and I don't
think it would make sense to further complicate the system in much of
any way, much less axes. My main concern is that we are missing
evaluations of notabug.io, pagure.io, sr.ht, codeberg.org and that
gitlab.com is out of date. I intend to work on completing those in the
coming weeks.

-- 
Ian Kelling | Senior Systems Administrator, Free Software Foundation
GPG Key: B125 F60B 7B28 7FF6 A2B7  DF8F 170A F0E2 9542 95DF
https://fsf.org | https://gnu.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]