• 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écentralisé 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 d'autres serveurs.

Discussion autour de la sensibilisation et de la réelle utilisation. faire des « install party » pour installer enigmail (ou autre façon d'utiliser GPG) et TOR.

La démarche pour venir vers 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 ? Quelles sont les contraintes ? Comment doit être protégé le serveur ? Toute IP non cachée est mise à la poubelle simplement pour manque de confidentialité. Tout ce qui est stocké sur la machine : clé publique sur le serveur. Le chiffrage des données sur le 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 permette à d'autre l'accès à tes données personelles?

En l'absence de chiffrage, c'est toi qui met les trucs dans le domaine public.

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

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. C'est à dire qu'il peut utiliser la signature comme preuve de la réception d'un message de l'expéditeur.

Si le message est chiffré, l'indice devient une preuve.

OTR : off the record. Il existe un moyen de rendre indéchiffrable une communication après coup même si on possède les clés des deux correspondants. On peut utiliser cette technique en messagerie instantanée. Elle consiste à fixer une clé symétrique par le canal chiffré par clés asymétriques. Une fois cette clé symétrique connue des deux parties, des messages peuvent êtres échangés dans un canal chiffré par la clé symétrique. Pour que ce système soit efficace, il faut renouveler la clé symétrique souvent et SURTOUT effacer cette clé une fois qu'elle ne sert plus. Cette technique se nomme

• Quelles doivent être les différence entre les utilisateurs et les gestionnaires ?
• Faire une mailing liste des gestionnaires. La rendre accessible à ceux qui veulent suivre la gestion du serveur.

qu'appelle-t-on « faire partie de ce collectif ? ». Est-il judicieux de « faire partie d'un collectif »? Mailing list ou forum ?

• Objectif du fonctionnement : s'ouvrir. Prendre le temps de savoir ce qu'on veut ? Les choses sont évolutives, prêtes à changer dès qu'une nouvelle personne surgit. Comment chercher les gens? Doit on chercher des gens ou bien juste informer de l'existence du collectif?
• Projet collectif… pas comme le logiciel libre avec un dictateur bienveillant. Ici, il y a des machines à gérer.
• Les fondamentaux sont déjà présents. Un ensemble d'idées est déjà présent.

En entrée :

• Qui compte ?
• Que veut on éviter ? i.e. confiance et défence face à la mise en demeure de la confiance.
  • (i) admin léger
  • (ii) admin qui veut casser 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'urgence se prévoit en amont. Le crash de no-log était à prévoir.

Où sont les objectifs ? Doit on s'imposer de maintenir le service 24h/24 ? La 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. (tatooine possible)

Taille : retour des admins. La taille dépend des moyens.

Niveau de sécurité, sauvegarde automatique, faille de sécurité. Quelle peut être la taille de chaque espace utilisateur?

On pourrait faire des réunions “exceptionelles” sur un seul thème technique à la demande de quelqu'un.

Utilisons le wiki!!!

admin quel nombre de mails ? charge dépend. charge de travail pour les admins : à 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 transparent : Un admin doit donner son savoir. Problème de l'e-mail, être 100% présent.

Tout au long de l'installation, faire des tutoriels. Documenter les parties spécifiques du boulot accompli.

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 Mercurial : versionning : qui et quand a fait les changements. objectifs : détecter les intrus ou augmenter la qualité du travail admin.

IMAP (consultation)? POP (récupération)? Webmail ? smtp ouvert (pas conseillé ;) ) ? smtp avec identification (pas mal). e-smtp chiffrant entre l'utilisateur et le serveur (encore mieux). 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 (on a plus ou moins dit que nous n'avions rien à faire là bas)

, 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 list : archives sont publiques : à préciser en bas des mails.