[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.
- One shouldn't mix different kinds of requirements to the software into a single score,
KOLANICH <=