• diminution de nolog en 2007 — fermeture de la possibilité de création des comptes. 70 000 mails à gérer : c'est trop !
• Géro: idée du petit serveur local, nolog organise une réu en juin 2008 au Tanneries (Dijon): présentation des types de serveurs (10-50; 50-100 et plus), spamassassin, mailman, point de vue du droit;
• Pour favoriser l'essaimage de nouveaux serveurs, No-log proposent un hébergement pendant un an dans une baie (globnet ou marsnet), plutot marsnet dans le cas d'un serveur à Montpellier.

• David était ok pour faire l'admin, mais il est overbooké. J'ai envoyé un email sur les listes d'alternative34 pour créer un serveur. Il faut aller dans le sens de la défense des libertés.

• Première réu 19 déc. : discussion technique : TOR et chiffrage e-mail. Point de vue légal (contrainte : log gardés… faut il aller à l'étranger ?).

• Quelle différence entre crypter et chiffrer : crypter veut rien dire (abus de langage) ?
• Les motivations du projet ne sont pas figées et évolueront en fonction des participants-contribuants. Favoriser la venue d'une nouvelle personne doit être favorisée tout en gardant une histoire du groupe : faire un effort particulier pour fournir les infos.
• Démarrer progressivement. Rester local pour échange de savoir plus pratique avec réunions locales.

• proposer l'ouverture d'e-mails
• utilisateurs le plus locaux possibles (LR)
• favoriser la défense de la vie privé : beaucoup de formation.
• autogestion du groupe de fonctionnement.
• indépendance — appropriation de l'outil.
• Ne pas renforcer le réseau en étoile-centralisé. Participer à la décentralisation du réseau. internet : réseau décentraliser par essence. Solidité du réseau dépend de sa décentralisation. Internet : tolérance à la panne, tolérance aux attaques.
• Centralisations : gros risques sur la liberté individuelle.
• non-commercial : pas d'exploitation des données. Pas un échange entre eux et l'utilisateur.
• diffusion de l'information technique — en parallèle aux mails
• favoriser l'émergence d'autres collectifs et autres serveurs.

Discussion autour du fait de la sensibilisation et de la réelle utilisation. faire des « install party » pour installer enigmail et TOR.

Démarche pour venir à un serveur indépendant représente déjà un grand pas pour beaucoup de gens. est-ce qu'il faut leur demander plus ? peut-on forcer les gens à utiliser GPG et TOR ? Contraintes ? protection du serveur ? tout IP non cachée est mise à la poubelle simplement parce que manque de confidentialité. tout ce qui est stocké sur la machine : clé publique sur le serveur. chiffrage du serveur est-il illégal ? Pour les utilisateurs, « le serveur doit faire partie du tunnel mais pas leur maison ». Les gens doivent créer leur clé publique chez eux pas lors des « install party ». « install party » doivent servir à expliquer les logiques, les moyens de garantir la confidentialité (installation GPG, TOR, etc).

« en tant qu'individus isolés, la guerre est perdue ».

Expliciter « passe moi le sel »

Logique : est ce que tu veux que la technologie

le fait que pas de chiffrage, c'est toi qui met les trucs dans le domaine publique.

pas de raison pour que nos mail se retrouvent chez telle ou telle entreprise. Gmail : audimat de l'internet. Contribue à leur grossissement et leurs bénéfice. Google ne justifie pas le cout de la pub qu'ils demandent. Google vende un nombre de visualisation. La ligne en bas peut être enlevé.

Réponse : La poste ne joue pas le rôle d'hébergeur, la poste n'ouvre pas les lettre pour les lire et joindre de la pub. si c'est centralisé, on est dépendant. Si Google décide de ne plus transmettre tel ou tel utilisateur, c'est mort. Si Google décide de refuser GPG, c'est mort.

attention, partie chiffrement et partie signature (celui qui reçoit peut se servir des clés comme un moyen de faire tomber l'expéditeur). avec chiffrement : passage de l'indice à la preuve. OTR : off the record. Logiciel de messagerie instantanée. clés symétriques.

• différence entre les utilisateurs et les gestionnaires ?
• faire une mailing liste des gestionnaires et ceux qui veulent suivre la gestion du serveur.

qu'est ce qu'on appel « faire partie de ce collectif ? ». est-il judicieux de « faire partie d'un collectif ». Liste ou forum ?

• Objectif du fonctionnement : s'ouvrir. Prendre le temps de qu'est ce qu'on veut ? les choses sont évolutives, prête à changer dès qu'une nouvelle personne. Comment chercher les gens.
• Projet collectif… pas comment le logiciel libre avec un dictateur bienveillant. Ici, il y a des machines à gérer.
• Fondamentaux sont déjà présents. ensemble d'idées déjà présent.

En entrée : qui compte ? que veut on éviter ? (i) admin léger (ii) admin qui veut casser i.e. confiance et défence face à la mise en demeure de la confiance. Lautre.net : deux niveaux : d'abord spectateur et ensuite acceptation. Vote des admins présents pour la cooptation d'un nouveau ? admin de départ ? initiateurs du projet. Le nouveau : faire des propositions. contre l'admin mal-intensionné : traçage des commandes appartient à la vie publique. nom de domaine : acheter quelque part attaché à quelqu'un. une seule personne à laquelle s'est attaché. Mot de passe partagé. Fonctionnement au consensus est important pas au système majoritaire. On est libre de se barrer et de recommencer. l'état d'urgence : concentre les pouvoirs.

Comment faire pour prendre des décisions ? qui compte ? quelles modalités de prisers de décisions ? Posons un cas : décider d'accepter un admin ou refuser ? comment on fait ? décisions de groupe ou avec un super admin ? bof. tout dépend de la vitesse à laquelle on doit prendre la décision. Attention à la notion de temps et d'urgence L'urgnce se prévoit en amont. Le crash de no-log était à prévoir. où sont les objectifs ? connexion 24h/24 ? situation d'urgence est le plus souvent moins importante que l'objectif. Crash, saisie, etc… qu'est ce qu'on fait ? prévoir des protocoles. gestion communautaire. donner ordre de priorité dans le fonctionnement. Respecter le projet et le fonctionnement. d'origine, le serveur mail est avec plusieurs secours. réplication du serveur mail sur machines alternatives pour serveurs de secours. taille : retour des admins. taille dépend des moyens. niveau de sécurité, sauvegarde automatique. Faille de sécurité. quel espace pour chaque utilisateur.

Faire des réunions sur un seul thème technique. Utilisation du wiki.

admin quel nombre de mails ? charge dépend. à l'installation : 10 jours pleins… ensuite 1 jour par mois ? comment détecter les spams ? tout dépend de la distance à la distribution : dès qu'on commence à mettre des patchs, cela prend plus de temps… s'intégrer dans des réseaux mondiaux. Peur de s'éloigner des logiciels classiques. ON veut que ce soit transparents : admin doit donner son savoir. Problème de l'e-mail, être 100% présent. Tout au long de l'installation, faire des tutoriels. Donner les spécificités mots de passe admin : ne les donner qu'aux admin pas de mots de passe mais clés SSH. donner la clé publique. ?

GIT ou Mercuriel : versionning : qui et quand a fait les changements. versionnement est statique. objectifs : détecter les intrus ou augmenter la qualité du travail admin.

IMAP (consultation)? POP (aller-retour)? Webmail ? smtp ouvert ? smtp avec identification. e-smtp chiffrant entre l'utilisateur et le serveur. même le mot de passe est chiffré.

à discuter plus tard…

Comment faire connaître le projet ? pas via les médias main-stream. Live eTIC Party 9.03, radio ? Radio : faire une annonce (communiqué) ou interview (pb de la légitimité de celui qui est interviewé, et quoi dire) ? réseau marche mieux. linux.fr ou autre listes nationales ou locales… HAL ? Besoin de diversité…

mailing liste : archives sont publiques : à préciser en bas des mails.