Programmation
(Il peut y avoir des approximations.)
- PHP ou Rust ?
Sondyn reste un programme décentralisé écrit en Rust. L'utilisation de PHP avec MariaDB n'est qu'une solution temporaire avant de porter le code définitivement en Rust (ou autre langage plus performant).
La programmation doit donc continuer d'être réfléchie comme décentralisée.
- Pourquoi ne pas utiliser de système centralisé ? Pas de confiance à la centralisation ?
Même si nous étions les mieux intentionnés, -1- nous ne sommes pas à l'abri d'être piratés. Et -2-, nous sommes toujours faillibles : par exemple j'ai des problèmes avec des policiers français en ce moment qui veulent m'arrêter. S'ils me promettaient d'arrêter leurs poursuites contre un simple échange de la base de données, qu'est-ce que je ferais ? (Je rappelle que transmettre des données n'est pas un vol, puisque les données d'origine restent accessibles. Et la transmission de telles données se font un nombre considérable de fois tous les jours, à chaque fois que vous vous connectez sur des sites avec les cookies, les pixels-espions etc. C'est un marché juteux et, malheureusement, légal)
Il ne faut pas du tout faire confiance à des systèmes centralisés (et encore moins les Gafam, Facebook, Google, etc).
En créant un système décentralisé, c'est-à-dire qu'il n'y a pas une personne (physique, ou morale = une entreprise) qui détient les données, la récupération de données sensibles (là, ce sont des opinions politiques, mais il peut en être de même avec des données médicales, etc.) devient très fortement compliquée.
- Comment fonctionnera la première connexion ?
Dans un système centralisé classique, on se connecte avec un navigateur qui se rend à une adresse type nomdedomaine.com qui renvoie à une adresse IP, celle d'un serveur centralisé qui crée une page web côté serveur et l'affiche sur le navigateur.
Pour notre modèle décentralisé, il ne doit pas y avoir de nom de domaine mais des adresses IP temporaires, celles de quelques personnes qui auront laissé leur serveur ouvert. (À la toute première connexion, il y aura bien sûr une adresse avec nom de domaine pour expliquer les étapes et présenter quelques liste d'IP accessibles. Mais par « première connexion », je veux dire quand quelqu'un déjà inscrit allume son ordi ou son téléphone.)
Les données de l'utilisateur devront donc être stockées sur plusieurs serveurs et non pas sur le poste unique de l'utilisateur (que se passerait-il s'il perdait son téléphone…). Pour des raisons de confidentialité, ces données devront non seulement être codées (« chiffrées ») mais aussi découpées en plusieurs fichiers que seul l'utilisateur pourra raccorder ensemble grâce à son adresse mail et son mot de passe.
- Quel est ce fichier de connexion ?
Rappel : un fichier texte qui inclut les lignes « CREATE [base et tables] … INSERT INTO [tables et champs] » est suffisant pour créer les fondements nécessaires aux données de connexion et aux premières connexions avec les autres utilisateurs.
C'est donc ce fichier qui sera créé, découpé, distribué sur plusieurs autres serveurs. Le nom sera chiffré (ou plutôt haché) à partir de l'adresse courriel de l'utilisateur et de son mot de passe.
Exemple : le hachage du mot de passe + adresse mail de l'utilisateur donne une chaîne A1B2C3D4E5F6.
On va mettre les données de l'utilisateur dans un fichiers (qu'on va chiffrer) puis qu'on va scinder en 2 fichiers plus petits, l'un qui s'appellera A1B2C3 et l'autre qui s'appellera D4E5F6. Ces 2 fichiers seront dupliqués en suffisamment de fois et répartis sur le réseau.
Quand l'utilisateur se connecte, avec sa chaîne, il sait qu'il doit retrouver ces 2 fichiers. Par contre, quelqu'un de l'extérieur ne saura pas quels fragments de fichiers rassembler ni dans quel ordre.
C'est un peu « galère » et un peu risqué (qu'une partie du fichier disparaisse à jamais) mais c'est là une sécurité pour que les données de l'utilisateur ne soient pas centralisées. (Éviter que certains utilisateurs mal intentionnés ne trafiquent leurs propres données et les déversent sur le réseau.)
.
J'ai schématisé avec 2 fichiers, mais on pourra en utiliser 3 (d'une chaîne de longueur 32 caractères, on retient que les 27 premiers). Ainsi, si quelqu'un récupère tous les fichiers sur le réseau, il ne saura pas lesquelles appartiennent à qui... Ce fonctionnement représente une forte sécurité.
- Quels seront les fichiers indépendants qui seront stockés sur les serveurs individuels ?
Les tables et méthodes se répartissent suivant 4 catégories :
- l'utilisateur (données là encore séparées en 2, d'un côté les données de connexion et d'identification, et d'un autre côté les données relatives à la participation de l'utilisateur au réseau) ;
- les groupes (groupements d'utilisateurs ou de groupes entre eux, selon affinités) ;
- les sondages ou questions posées ;
- la sûreté de l'ensemble.
- En quelle langue orale le programme est-il expliqué (français, anglais…) ? Est-il prévu de l'étendre à d'autres langues ?
Le programme est écrit initialement en français, y compris les noms de variables. Il est documenté en français.
Maintenant, il est possible de l'ouvrir à d'autres langues, suivant les pays où il devra être déployé, par ex. en espagnol, allemand, etc. Pour des alphabets non latins, la question sera laissée aux auteurs.
Réticences par rapport à la langue anglaise : en tant qu'initiateur du programme (moi-même Lionel Aubert), je ne souhaite pas trop l'utilisation de la langue anglaise si celle-ci n'est pas justifiée par un déploiement certain dans un pays anglophone. Plusieurs raisons à ce choix :
- L'application Sondyn, dans sa manière de présenter les sondages ou questions, veut promouvoir la variété des idées et des opinions, et non-pas « ranger » tout le monde dans les choix de la majorité. Pour les langues, il en va de même : promouvoir la diversité. Si des pays francophones, par exemple africains, utilisent également des langues locales, celles-ci peuvent être utilisées à la place du français.
- La langue anglaise déploie des programmes centralisés tels que Facebook, Google-Youtube, etc, centralisation contre laquelle nous nous battons. Symboliquement, le refus de la langue anglaise va en ce sens. Toujours sur les symboles, les États-Unis et dans une moindre mesure le Royaume-Uni organisent une répression contre des lanceurs d'alertes, tels que Julian Assange ou Edward Snowden (mais ils ne sont pas les seuls, loin de là, ne l'oublions pas). En soutien, nous montrons des réticences à utiliser la langue de ceux qui les oppressent.
Concernant le nom des variables, nous pouvons nous pencher sur une utilisation approximative de noms génériques courants dans les trois langues occidentales restantes (français, espagnol et allemand) ainsi que dans des bases latines, grecques, arabes si l'orthographe est latinisé. En attendant on peut garder le français.