WIP : infrastructures

content/infrastructures/_index.md

@@ -9,7 +9,8 @@ extra:
 
 Ce manuel documente la dimension matérielle du numérique chez Deuxfleurs. On y recense les ordinateurs, le lieu où ils sont, les connexions réseaux nécessaires, l'énergie consommée, l'impact de fabrication, de fin de vie, etc.
 
-> Vu la quantité de logiciels et de machines impliquées, et la fâcheuse tendance de nos membres à déménager par-ci par-là, il est fort probable que les informations présentées ici soient **obsolètes**.\
+> Vu la quantité de logiciels et de machines impliquées (et la fâcheuse tendance de nos membres à déménager), il est fort probable que les informations présentées ici soient **obsolètes**.
 > Cependant, ces pages ont été vraies il n'y a pas si longtemps : leur lecture vous informera quand même sur notre pratique de l'hébergement de services numériques.\
+> Pour connaître l'état précis de nos infrastructures, il faudrait plutôt lire notre dépôt [`nixcfg`](https://git.deuxfleurs.fr/Deuxfleurs/nixcfg) – qui décrit techniquement nos machines et services à tout instant.
 > Bonne lecture !
 

content/infrastructures/logiciels.md

@@ -9,11 +9,15 @@ extra:
   parent: infrastructures/services.md
 ---
 
-Cette section recense les logiciels développés par Deuxfleurs pour les besoins spécifiques de son infra.
+Cette section recense les logiciels développés par Deuxfleurs pour les besoins spécifiques de son infrastructure.
 
 # Principes de conception
 
-Nou essayons de suivre plusieurs principes pour une conception qui correspond au besoin tout en ayant un ensemble de logiciels homogènes.
+Deuxfleurs reconnaît l'importance sociale des choix techniques.
+N'importe quel outil est imbibé de l'idéologie de la société qui l'a vu naître – et en retour, il impose son idéologie aux sociétés à venir.
+Sachant cela, on arbitre nos choix techniques en regardant en premier lieu ce qu'ils vont impliquer socialement.
+Cela fait de nos infrastructures une bizarrerie pour qui est habitué⋅e aux pratiques de l'informatique industrielle.
+Nous essayons de suivre plusieurs principes pour une conception qui correspond au besoin tout en ayant un ensemble de logiciels homogènes.
 
 ## Vie privée
 
@@ -25,46 +29,50 @@ Quelques propriétés en vrac qu'on peut, ou ne pas, désirer :
 
 ### Messagerie instantanée
 
-  - Je ne veux pas que le contenu de mes messages et des fichiers que je partage soient accessibles (eg. une photo que j'ai prise, mes réactions)
+  - Je ne veux pas que le contenu de mes messages et des fichiers que je partage soient accessibles à des tiers (_e.g._ une photo que j'ai prise, mes réactions).
-  - Je ne veux pas que les métadonnées autour de mes messages soient accessibles (eg. les salons de discussions auxquels je prends pars, l'horodatage des messages, les personnes avec qui j'échange)
+  - Je ne veux pas que les métadonnées autour de mes actions soient accessibles à des tiers (_e.g._ les salons de discussions auxquels je prends part, l'horodatage des messages, les personnes avec qui j'échange).
-  - Je ne veux pas que les métadonnées de communication soient accessibles (eg. quand je me connecte au service, depuis où, si j'intéragis sur le réseau, etc.), ces données permettent parfois d'inférer des métadonnées sur le protocole (autres personnes dans le salon de communication, horodatage, etc.)
+  - Je ne veux pas que mes métadonnées de communication soient accessibles (_e.g._ quand je me connecte à un service, depuis où, si j'intéragis sur le réseau, etc.), ces données permettent parfois d'inférer des métadonnées sur le protocole (autres personnes dans le salon de communication, horodatage, etc.).
 
-### Courrier électronique (de l'email au mixnet)
+### Courrier électronique (de l'e-mail au mixnet)
 
-  - Je ne veux pas que le contenu de mes emails et pièces jointes soit lisible (eg. le doc que j'ai joint)
+  - Je ne veux pas que le contenu de mes e-mails et pièces jointes soit lisibles par des tiers (_e.g._ le doc que j'ai joint).
-  - Je ne veux pas que les métadonnées autour de mon message soient accessibles (eg. le destinataire, l'expéditeur, l'horodatage, le client email utilisé, le sujet du mail, le dossier dans lequel il est stocké)
+  - Je ne veux pas que les métadonnées autour de mon message soient accessibles (_e.g._ le destinataire, l'expéditeur, l'horodatage, le client e-mail utilisé, le sujet du mail, le dossier dans lequel il est stocké).
-  - Je ne veux pas que les métadonnées de communication soient accessibles (eg. quand je me connecte au service email, depuis où, quand j'intéragis sur le réseau), ces données permettent parfois d'inférer des métadonnées sur le protocole (destinataires, présence de pièce jointe, etc.)
+  - Je ne veux pas que mes métadonnées de communication soient accessibles (_e.g._ quand je me connecte au service e-mail, depuis où, quand j'intéragis sur le réseau). 
+    Ces données peuvent permettre d'inférer des informations importantes sur mes correspondant⋅es et moi-même (destinataires, présence de pièce jointe, etc.).
 
 ### Synchronisation et collaboration sur des fichiers
-  - Je ne veux pas que le contenu de mes fichiers soit accessible
+  - Je ne veux pas que le contenu de mes fichiers soit accessible à des personnes non autorisées.
-  - Je ne veux pas que les métadonnées de mon fichier soient accessibles (eg. nom du fichier, dossier, format, taille, hash, etc.)
+  - Je ne veux pas que les métadonnées de mes fichiers soient accessibles (_e.g._ nom du fichier, dossier, format, taille, hash, etc.).
-  - Je ne veux pas que les métadonnées de communication soient accessibles (eg. quand j'accède au document, depuis où, qui d'autre, combien de fois, etc.), ces données permettent parfois d'inférer des métadonnées sur le protocole (taille, collaborateurs, type, etc.)
+  - Je ne veux pas que mes métadonnées de communication soient accessibles (_e.g._ quand j'accède au document, depuis où, qui d'autre, combien de fois, etc.).
+    Ces données peuvent permettre d'inférer des informations importantes sur mes correspondant⋅es et moi-même (taille, collaborateurs, type, etc.).
 
-## Attaquants
+## Modèles d'attaquants
 
-Quelques attaquants que l'on peut, ou ne pas, considérer :
+Dans le domaine de la sécurité, on commence toujours par décrire l'« attaquant » : ses capacités, le temps dont iel dispose... 
+Car il n'existe aucune défense qui protège de toutes les attaques : il faut donc savoir contre qui on est en mesure de se défendre, ou pas.
+Suivent quelques attaquants potentiels : 
 
-  - Hébergeur de la machine (eg. branche un clavier et un écran sur l'ordi et récupère un accès admin)
+  - Administrateur Système (_e.g._ utilise ses accès privilégiés pour accéder volontairement ou non à du contenu privé)
-  - Administrateur Système (eg. utilise ses accès privilégiés pour accéder volontairement ou non à du contenu privé)
+  - Hébergeur de la machine non administrateur (_e.g._ branche un clavier et un écran sur l'ordi et récupère un accès admin)
-  - Développeurs (eg. ajout d'une porte dérobée au moment de l'écriture du code)
+  - Développeurs (_e.g._ ajout d'une porte dérobée au moment de l'écriture du code d'un logiciel qu'on utilise)
-  - Chaîne logistique (eg. ajout d'une porte dérobée au moment de déployer l'app sur les serveurs ou le terminal de l'utilisateur)
+  - Chaîne logistique (_e.g._ ajout d'une porte dérobée au moment de déployer un logiciel sur les serveurs ou le terminal de l'utilisateur)
-  - Opérateur Internet (eg. Orange)
+  - Opérateur Internet (_e.g._ Orange), voit passer une partie de notre trafic
-  - Regroupement d'opérateurs internet (cf "Tor netflow")
+  - Regroupement d'opérateurs Internet (cf "Tor netflow")
-  - Personne externe via internet (eg. hacker)
+  - Personne externe via Internet (_e.g._ hacker)
-  - Personne externe physique (eg. voleur)
+  - Personne externe physique (_e.g._ voleur)
-  - Regroupement d'acteurs (eg. opérateurs internet, externe physique ET internet)
+  - Regroupement d'acteurs (_e.g._ opérateurs internet, externe physique ET internet)
-  - Utilisateurs (eg. pas de chiffrement sur son téléphone)
+  - Usager⋅es, qui peuvent se faire pirateur leurs données par ailleurs (_e.g._ téléphone non protégé)
 
 ## Un exemple de ce qu'on pourrait faire
 
 Prenons l'exemple de la messagerie instantanée. Pour l'instant, on peut définir les types de réseaux suivants :
 
 - centralisé, pas chiffré (Messenger)
-- centralisé, chiffé de bout en bout (avec toute une gamme d'implems, la meilleure étant peut-être Signal)
+- centralisé, chiffé de bout en bout (il y en a une grande quantité, la meilleure étant peut-être Signal)
-- fédéré, pas chiffré (E-mail, IRC, XMPP sans omemo, Matrix sans E2EE)
+- fédéré, pas chiffré (E-mail, IRC, Matrix sans chiffrement de boût en boût (E2EE), XMPP sans Omemo)
 - fédéré, chiffré (XMPP + Omemo, Matrix + E2EE)
 - distribué, chiffré (Tox, Retroshare)
-- distribué avec des mécanisme d'anonymat fort (Freenet, Mix networks, ...)
+- distribué avec des mécanisme d'anonymat fort (Freenet, Mix networks)
 
 Seule la dernière catégorie s'adresse au cas d'un "global passive attacker". On peut imaginer d'abandonner l'idée d'avoir une protection très efficace contre ce dernier car ça serait très contraignant sur le design et l'utilisabilité, et les cas où on en aurait vraiment besoin sont des cas particuliers où on peut faire l'effort d'utiliser une solution adaptée.
 

content/infrastructures/services.md

@@ -1,16 +1,18 @@
 ---
 title: "Les logiciels"
-description: "Annuaire des logiciels utilisés chez Deuxfleurs"
+description: "Annuaire des logiciels utilisés par Deuxfleurs"
 weight: 20
 extra:
   parent: 'infrastructures/_index.md'
 ---
 
-Cette page tente de recenser de façon exhaustive l'ensemble des services qui
+Cette page tente de recenser de façon exhaustive l'ensemble des applications qui assurent le fonctionnement de Deuxfleurs, et leurs rôles respectifs (production, support...).
-fonctionnent actuellement sur les machines de Deuxfleurs, dans les différents
+On détaille les logiciels que l'on développe nous-même à [la page suivante](@/infrastructures/logiciels.md).
-rôles identifiés : production, développement, expérimentation, etc.
 
-On détaille les logiciels que l'on a nous-même développés à [la page suivante](@/infrastructures/logiciels.md).
+> On répète que cette liste est condamnée à être obsolète, n'étant pas mise à jour à chaque modification de nos infrastructures.\
+> Si vous voulez connaître l'état du monde à l'instant _t_, équipez-vous d'une personne technicienne et allez plutôt lire notre dépôt [`nixcfg`](https://git.deuxfleurs.fr/Deuxfleurs/nixcfg) – qui décrit formellement l'état de toutes nos machines.
+
+C'est parti pour la liste à la Prévert :
 
 | Service | Rôle | Site | Description |
 | -- | -- | -- | -- |