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

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

One shouldn't mix different kinds of requirements to the software into a


From: KOLANICH
Subject: One shouldn't mix different kinds of requirements to the software into a single score
Date: Wed, 26 Feb 2020 11:05:59 +0300

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.



reply via email to

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