#MAVOIX Plateforme de Vote

Présentation au sujet: "#MAVOIX Plateforme de Vote"— Transcription de la présentation:

1 #MAVOIX Plateforme de Vote
17/11/2016 – Lyon @promethe42

3 Fonctionnement Général

4 Le “contrat” de vote Unique Secret/anonyme Dépouillable/vérifiable
On veut un vote en ligne qui apporte les mêmes garanties que le votes classiques

8 Exemple : intégration dans LaPrimaire.org

9 Intégration dans LaPrimaire.org
Tous le processus de vote est géré par Cocorico, intégré dans LaPrimaire.org de façon transparente et sécurisée. Une confrontation frontale aux réalités techniques/humaines Premier tour du 26 octobre au 6 novembre Au total, ce sont votants qui ont enregistré plus de votes. 5 votes par votant, scrutin par jugement majoritaire. Des Français des 4 coins du monde ont pu voté (5,7% hors de métropole). Deuxième tour après mi-décembre ! Nous aurons démontré que le numérique est un levier crédible pour un « coup d’état citoyen ». L’integration au sein de LaPrimaire.org est complètement générique : toutes les autres plateformes civictech qui veulent intégrer une fonction de vote peuvent le faire. Certaines initiatives ont d’ailleurs déjà fait part de leur intérêt. Première initiative CivicTech concrete de cette envergure. Première mondiale / historique !

10 La “preuve de vote”

14 Nouveautés depuis 3 semaines
Des améliorations ont été apportées Depuis le premier tour de LaPrimaire.org

15 Attention Gestion des webhooks Ajout d’un firewall Support de Safari
Meilleure sécurisation du smart contract de vote Réécriture du service d'inscription des bulletins de vote sur la blockchain Traitement multi-processus des bulletins de vote Résilience du service de traitement des bulletins de vote Création d'un framework de test Embryon de tests pour l'application Web Ajout de traductions Attention 1. Gestion des webhooks Les plateformes tierces (ex : LaPrimaire.org) qui intègrent la plateforme de vote peuvent maintenant suivre le déroulé d'un vote sans se fier au navigateur de l'utilisateur. Les webhooks permettent une communication serveur/serveur entre Cocorico et la plateforme tierce. 2. Ajout d'un firewall Le serveur limite maintenant l'accès aux seuls ports suivants : 8 (ping) 22 (ssh) 80 (http) 443 (https) 3. Support de Safari Le navigateur Safari est maintenant supporté à partir de la version 9.1. 4. Meilleure sécurisation du smart contract de vote Le smart contract (le code exécuté sur la blockchain) a été modifier pour gérer plusieurs états et permettre certaines actions en fonction de cet état : open : le vote est "ouvert", les fonctions registerVoter(), vote() et close() peuvent être appelées, la fonction getResults() ne peut pas être appelée close : le vote est "fermé", les fonctions registerVoter(), vote() et close() ne peuvent pas être appelées, la fonction getResults() peut être appelée En gros, on peut voter tant que le vote est "ouvert", mais pas avoir les résultats. Et inversement quand le vote est "fermé". Pour des raisons de sécurité, on peut "fermer" un vote, mais pas le rouvrir. Ceux sont des choix d'implémentation à débattre avec des implications énorme qui vont jusqu'à remettre en question la constitutionnalité du vote (rien que ça...). Le smart contract a également été modifié pour mieux remonter les erreurs. 5. Réécriture du service d'inscription des bulletins de vote sur la blockchain Ce service souffrait de nombreux défauts, qui pouvaient entraîner des bulletins de vote dans un état indéterminé. Le service a été entièrement réécrit pour être plus fiable et mieux tirer partie de l'architecture multi-processus. La gestion des erreurs a également été améliorée et permet d'avoir un suivi de toutes les erreurs qui se sont manifestées lors du traitement d'un bulletin en particulier. 6. Traitement multi-processus des bulletins de vote Les bulletins de vote ne sont plus gérés par un seul mais plusieurs processus. Chaque processus passant quasiment tout son temps à attendre/ne rien faire, cela n'a que peu d'impact sur les performances. Mais cela permet de distribuer le risque de panne. Ces processus pourraient tourner sur des machines séparées, voir sur les machines de citoyens volontaires qui hébergeraient déjà la blockchain. Il en est de même pour tous les autres services, comme les webhooks. 7. Résilience du service de traitement des bulletins de vote Jusqu'ici, lorsque ce service plantait, il fallait le redémarrer à la main. Lorsqu'un des processus de traitement des bulletins tombe, il va automatiquement être relancé après 30 secondes. 8. Création d'un framework de test Le code qui est en commun avec tous les différents tests (API, app, etc...) a été mis dans un package commun pour en augmenter la maintenabilité. Ce framework permet de tester toute la procédure de vote en simulant la création de votes et l'envoie d'un nombre donné de bulletins en 50 lignes de code. 9. Embryon de tests pour l'application Web Début de travail sur l'automatisation du lancement et du pilotage d'un navigateur Web qui va aller tester l'application Web. Ces tests vont simuler l'utilisation de l'application Web dans des conditions quasi réelle (vrai navigateur, vrais clicks, vrai formulaires à remplir, etc...) mais piloté par du code pour tester la procédure de vote et en valider le bon déroulé. Ces tests seront automatisés pour permettre de vérifier que chaque modification du code ne cause pas de régression sur la procédure de vote telle qu'elle sera suivie par les vrais utilisateurs. 10. Ajout de traductions Certains éléments de l'interface - notamment les boutons pour imprimer/télécharger la preuve de vote - ont été traduits en français.

16 C’est pas fini ! Nouvelles options de configuration de la blockchain
Configuration explicite de la langue/locale Logs en JSON pour l'API Web Configuration de déploiement extensible Automatisation du déploiement/renouvellement des certificats SSL Correction d'un bug sur le nombre de propositions par vote Automatisation des backups Passage à l'échelle Cache entre l'API Web et la blockchain Modération automatique C’est pas fini ! 11. Nouvelles options de configuration de la blockchain La configuration de la plateforme permet maintenant de déclarer la "target gas limit", une valeur qui permet d'influencer le nombre de transactions qui pourront être stockées dans un block de la blockchain. Augmenter cette valeur permet de traiter plus de transactions dans un même temps, et donc de mieux répondre aux problématiques de charge. 12. Configuration explicite de la langue/locale Il est maintenant possible de forcer la locale utilisée en ajoutant le paramètre "lang" dans une URL (par exemple pour forcer le français). La locale sélectionnée est alors enregistrée dans un cookie pour que la navigation reste cohérente tout le temps de la session. 13. Logs en JSON pour l'API Web L'API Web écrit maintenant ses logs en JSON pour permettre l'automatisation de leur traitement. Ces logs sont également plus verbeux pour permettre un meilleur suivi du fonctionnement de l'API. 14. Configuration de déploiement extensible La configuration de la plateforme peut maintenant être étendue/surchargée sans modifier la configuration principale. Cela permet par exemple de créer une/des instances privées/dédiées de la plateforme sans modifier la configuration originale. C'est ce qui a été utilisé pour déployer Les configurations additionnelles peuvent ainsi être versionnées sur un dépôt séparé, notamment pour des raisons de confidentialité. 15. Automatisation du déploiement/renouvellement des certificats SSL Le(s) certificat(s) SSL sont obtenus et renouvelés automatiquement grâce à let's encrypt. 16. Correction d'un bug sur le nombre de propositions par vote Un bug limitait le nombre de propositions (valeurs de bulletin) possibles pour chaque vote à 3. Ce bug a été résolu pour permettre par exemple à LaPrimaire.org d'implémenter le jugement majoritaire avec 5 propositions ("très bien", "bien", etc...). 17. Automatisation des backups Il est maintenant possible d'automatiser le déploiement d'une machine qui sera dédiée au backup automatique des données de la plateforme. Cette sauvegarde intervient automatiquement toutes les heures de façon incrémentale. Il est donc possible de revenir à n'importe quelle date dans le temps, heure par heure. Les données sauvegardées sont : tous les logs (API Web, blockchain, services...) la blockchain les files de traitement 18. Passage à l'échelle De grosses portions du code ont été réécrites pour répondre à des problèmes de performance/passage à l'échelle. Notamment le service qui gère l'enregistrement des bulletins de vote dans la blockchain (cf 7.). Au final, le 1er tour aura permis d'effectuer votes, soit presque transactions blockchain. C'est l'équivalent de 3 jours complets de fonctionnement mondial de la blockchain Ethereum. Ce qui classe très probablement ce 1er tour dans le top des plus "grosses" applications blockchain réalisées à ce jour. 19. Cache entre l'API Web et la blockchain Une fois le vote terminé, la récupération des résultats et l'exploration de l'urne numérique était relativement lente/couteuse : chercher/trouver/récupérer plusieurs milliers de transactions blockchain a chaque affichage de page s'est révélè être trop couteux. Un système de cache a été mis en place pour éviter que chaque chargement de page de résultat aille interroger directement la blockchain. Ce cache ne concerne que la lecture des données de la blockchain une fois le vote terminé. 20. Modération automatique Plusieurs attaques ont été constatées pendant le déroulement du 1er tour de LaPrimaire.org. Je ne rentrerais pas dans les détails ici, mais pour faire simple : deux vecteurs d'attaque ont été décelés dans l'API Web, notamment pour tenter de forger de fausses identités, probablement dans le but de bourrer les urnes; un autre, plus générique, a été décelé dans des tentatives de bruteforce pour se connecter aux serveurs en tant qu'administrateur ; enfin, il y'a également eu des tentatives de vol de mon compte Facebook ou d'autres comptes (Dropbox, ) des organisateurs de LaPrimaire.org. Bien qu'aucune de ces attaques n'aie à priori réussie, elles représentaient un risque inutile et, surtout, utilisaient énormément de ressources. Certaines IPs avaient par exemple tenté plusieurs dizaines de millier d'authentifications invalides... Un système de modération automatisée a été mis en place pour couper le traffic venant d'adresses IP "suspicieuses". La documentation correspondante est ici. Il est également possible de blacklister/whitelister manuellement des adresses IP via l'interface d'admin.

17 Quoi ! Encore des nouveautés !
Gestion du temps de vie des sessions Support d'Opéra Rotation des fichiers de log Réécriture complète du service d'enregistrement des bulletins sur la blockchain Réécriture en ES6 D’autres nouveautés probablement aujourd’hui même lors du 5ème HACKATHON qui a lieu à la Plaine Saint Denis. 29 projets Civic Tech y participent parmi lesquels on trouve le projet MAVOIX  Quoi ! Encore des nouveautés ! 21. Gestion du temps de vie des sessions Pour des raisons de sécurité, les utilisateurs avaient 10 minutes pour voter. Au delà de cette limite, leur jeton d'identité n'était plus valide. Ce cas précis n'était pas géré dans l'interface, et un vote effectué avec un jeton d'identité périmé - bien que n'étant jamais enregistré - faisait entrer l'application Web dans un état dégénéré. Cela a également provoqué un certain nombre de faux positifs de modération automatisée, et certains utilisateurs (une infime minorité) ont été blacklistés à tort (ils ont ensuite été dé-blacklistés à la main). Pour éviter ces deux problèmes, l'application Web détecte maintenant que le jeton d'identité est périmé et prévient l'utilisateur qu'il n'a pas/plus le droit de voter. 22. Support d'Opéra Opéra est maintenant supporté en version 41. 23. Rotation des fichiers de log Les fichiers de logs sont aujourd'hui archivés jour par jour, pour éviter d'avoir des fichiers de log de plusieurs Go (pendant le 1er tour, certains fichiers de log ont atteints plus de 30Go). 24. Réécriture complète du service d'enregistrement des bulletins sur la blockchain En cas de plantage, l'implémentation précédente du service d'enregistrement des bulletins de vote sur la blockchain n'était pas très résiliente. Par exemple, les bulletins en cours de traitement lors du plantage avaient de forte chance de ne pas être traités correctement lorsque le service récupérait/redémarrait (un certain nombre de sécurités étant en place, ça ne pouvait pas donner lieu à un double vote mais plutot à des bulletins bloqués). Une infime minorité de bulletins sont concernés (ça a relativement peu planté vu que je ne dormais quasiment pas pour tout mettre sur pause au moindre problème ). Mais, au delà d'un plantage éventuel, il était primordial de pouvoir redémarrer ce service (après une mise à jour par exemple) sans avoir ce genre de soucis. Le traitement de chaque bulletin de vote est maintenant divisé en étapes bien séparées et indépendantes, et lorsque le service redémarre il peut reprendre à l'étape correspondante pour chaque bulletin. 25. Réécriture en ES6 Le code de l'API Web et des services a été entièrement réécrit en EcmaScript6, un standard JavaScript plus moderne, pour une meilleure lisibilité/maintenabilité.

18 Et ensuite ?

20 Projet Dredd – “La Loi, c’est moi !”
Data generator for the-law-factory project Service pour mettre à disposition des développeurs les textes, les projets de loi et leurs métadonnées en temps réel à des formats permettant d’en automatiser le traitement. Alpha : décembre Beta : février : avril 2017

21 Merci !