Mémo – Projet SocialBeat
4 janvier 2012
No Comment
Projet SocialBeat :
Créer une plateforme semi-automatisée permettant de s’assurer de la présence (online) d’(h)activistes sans entraves ou obligation.
Cet article vise en particulier la sauvegarde du pad d’origine
Nom du projet :
SocialBeat, heartping, hackerwatch, Nodwatch …
Objectifs :
- pouvoir lancer rapidement une alerte plausible en cas de disparition inattendue d’un activiste
- donner les moyens de gérer au mieux une disparition « médiatique » volontaire
Formalisation du fonctionnement :
Architecture modulaire avec une ossature de base comprenant :
- des personnes
- une fonction : watched / watcher, chacun pouvant avoir les deux statuts, sans que ce soit une obligation
- des paramètres de base : mode d’accès à la plateforme, éléments d’identification éventuels
- un scénario général impliquant les plugins
- des notifications d’evenements externes entrants (causant par ex avec un plugin « twitter » disant « la dernière fois qu’il a parlé c’était tel jour à telle heure)
- divers niveau de visibilité (*, watcher, watchers ayant une notification similaire (même réseau))
- Des groupes fournissant des alertes internes au groupe
- un moteur de gestion de scénario
- des notifications sortantes (un plugin « demander la vérification humaine des watchers » par exemple)
Feature list :
Scan automatique de moyens de communication publics à la recherche de trace d’expression
- status.net
- irc
- mail (envoyer un mail à interval régulier ?)
- blog
- Analyse basique des comportements sur ces réseaux pour détecter d’eventuelles usurpations d’identités (méthodo ?)
- Heures de présence (genre, si je twitte jamais à 4h du mat, untwit à cette heure là est suspicieux)
- Repo sécurisé et redondé permettant de balancer une « assurance » ? (peut-être un peu hors scope ? A rattacher à des projets type wikileaks, streisand ou autre ?)
- Enregistrement chiffré de moyens de contact d’urgence (mail secret, par exemple), avec distributions de parties de la clé privée à des contacts de confiance ?
- Sécurité de l’ensemble (ça fait un magnifique répertoire d’activiste) : ça, capital
- GPG (et donc auth par GPG)(ça permet aussi de pouvoir réutiliser le WoT d’un user comme contacts)
- Pas forcément besoin de nom ou de pseudos, un hash peut suffire pour représenter une alerte
- Gestion des absences programmée avec double check pour ceux qui le souhaitent (que la déclaration d’absence ne soit pas faite par une personne usurpant l’identité)
- envoie de fake notifications en cas de menace(physique) avec une alerte envoyé à une seule personne de grande confiance
- nécessité de confirmer toute alerte (recoupements de capteur, prévalence des infos type personnelle sur privée sur publique)
- Possibilité d’indiquer à la plateforme (technique + watchers) un délai différent. Exemple « jusqu’à ce soir, si je ne donne pas signe de vie au moins une fois par heure, problème » ou au contraire « je ne reviens pas avant 48H ».
- Nécessité de profil (par exemple, la nuit, c’ets pas forcément nécessaire)
Limitation de la consultation des infos à un groupe (en dehors des membres du cluster, inutile de montrer l’état de chacun)
- données publiques = visible par tous (état des capteurs publiques, et du watched)
- données privées = visible que par les membres des mêmes canaux (si je suis pas sur l’IRC de groupA, je n’ai pas accès aux infos basées sur groupA)
- données personnelles = invisible, seul l’état du capteur l’est
Pouvoir définir des watched et des watchers
- Je surveille untel, et untel me surveille → twitter like, et établir des niveau d’info (genre, j’ai un numéro de téléphone direct pour telle personne à utiliser qu’en cas d’urgence)
Plusieurs niveaux d’info (publiques, privées, personnelle)
- publiques = monitoring à partir de données types twitter, FB, status.net public, n’importe qui peut voir létat de ces capteurs
- privées = monitoring à partir des infos internes du cluster (instances status.net interne, canaux irc, autre moyens bizarre type mailing-lists), accessible uniquement par des membres du même canal privé (l’information ne fuite pas)
- personnelle = lien pair à pair (pas forcément à double sens), visible uniquement par ces deux personne, et basé sur la confiance (ouais, j’ai vu untel en chair et en os, il y a 2 h, non je n’ai pas à vous dire où et comment)
- hardware = distribution de devices communicant dédiés (ie lecteur de ibutton ou autre truc du genre couplé à un arduino embarquant une clé quelconque) / (GSM jettable) / (bien, mais super cher et difficilement implémentable mbof .. arduino nano + ibutton = 40$ a tout péter, par personne à suivre / Faut trouver une autre fonction au device pour le rendre indispensable) / une yubikey suffirait pour identifier matériellement la personne ?
- panic button (et passphrase)
- Valence des liens (pas de twitter pendant 12h != disparition, par contre lien personnel de confiance qui s’inquiète, ça peut valoir le coup de fouiller
- Cette valence a une valeur par défaut qui peut-être définie par le watcher ou le watched
- Confirmation des alertes
- En cas d’alerte (quelle qu’elle soit), notification de tout les watchers du watched ET de ses éventuels clusters (qui sont des watchers aussi, ne l’oublions pas pour le jour où vous ferez de l’UML, mangez-vous l’héritage) pour confirmation
- Système de vote pondéré (la non-réponse n’est pas prise en compte, on pourrait même déclencher une alerte si non réponse d’un watcher au bout de n demandes)
- Propagation des alertes confirmées de manière rapide = alertes par mail, bot IRC, éventuellement SMS…
- Nécessité de confirmer les alertes
- Besoin de pouvoir contacter rapidement les watchers d’un watched
- Mobiliser rapidement les ressources personnelles (mails auto chiffré ou autre) et privée (demander à tous les watcher d’un watched)
- Moyenne pondérée par les valences (le lien vaut 0 ou 1 x valence)
- Décentralisation
- Système de pull de capteurs, avec un Auth éventuelles pour préserver les droits.
- Chaque watched publie et gère son noeud avec ses sondes
- Chaque watcher gère ses alertes et abonnement et publie les alertes qu’il a (genre machin disparu)
- Un cluster est un groupe de watched et est aussi un watcher fournissant des ressources internes (privées) de surveillance
- La disparition d’un noeud d’un watched est une alerte en soi (disont disparition pendant plus de x heures pour éviter les alertes à cause des pannes)
- Compatibilité avec des canaux différents: Téléphone (SMS), Internet, TOR, Freenet..
Base technique à adopter :
- From scratch ? (long)
- En se basant sur un soft de monitoring existant ? Sur un Diaspora modifié ? (peu de souplesse) Diaspora me semble être une mauvaise base technique, autant partir sur XMPP
- web app ?
- IRC Bot
- twitter Bot ?
- les 3 précédents IMO, il faut penser qu’on ne maîtrisera pas les situations d’urgence impossibilité de se logguer sur IRC, par exemple)(c’est surtout que l’alerte doit passer automagiquement sur le plus de plateforme possible pour être relayée, une sorte d’alerte Enfant Enlevé Vite Vite)
- Idéalement une techno de Base (XMPP par exemple / Thimbl) et des plugins gateway vers IRC/Twitter/…
Liens utiles :
Biblio sur le sujet :
Leave your response!