bon je vais te répondre, peut-être pas le mieux du monde car je me suis pas penché sur l'écriture d'un tel prog, mais en mettant sur le post les choses à gérer comme un premier jet (en fait qui me viennent à l'esprit là comme ça, à tête vide du problème).
Je vais parler uniquement de la partie si simple de "comptabiliser les votes", celle à laquelle tu fais mention, pour te montrer que sur une partie si simple, il y a plein de choses à vérifier. Je vais même pas parler de l'interface qui est super importante et probablement la chose qui doit nécessiter le plus de vérification et protection (à partir du moment où y a interaction avec un humain, ne jamais sous-estimer la capacité de ce dernier à faire le truc totalement inattendu auquel le développeur n'aurait jamais pensé, pas même imaginé possible!!!).
* Déjà une clé ou un mot de passe (voire les 2 en même tps), c'est pareil. C'est uniquement l'interface qui change, mais c'est tjrs géré au niveau logiciel. Surtout que si jamais c'était uniquement machine, imagine qu'on puisse "bypasser" (en français, on dirait quoi? Outrepasser?) le matériel par un bug quelconque? Le logiciel ne pourrait pas s'en rendre compte? Impensable! Le vote doit forcément être lié à une acceptation des autorités locales. Donc sans clé, le vote ne doit pas pouvoir être pris en compte.
* Le logiciel doit être capable de compter le nombre de votants et pas seulement les votes, ce de manière indépendante (c'est à dire qu'à chaque vote, tu incrémentes 2 variables distinctes, et indépendamment, pas une en fonction de l'autre). Il peut ainsi vérifier qu'y a pas plus de votants que d'habitants.
Le logiciel doit régulièrement faire des vérifications de consistance du genre. Prendre le nombre de votants pr chaque candidats, les additionner, vérifier que ça correspond aux votants totaux, etc.
* Le système de la variable est très mauvais pour diverses raisons.
La plus importante d'entre elle est qu'il faut sauvegarder!!! Imagine une coupure de courant, ben si on gardait simplement une variable en "runtime" (exécution), elle est mise à zéro à chaque reboot. Donc après chaque vote, elle doit être mise en mémoire dure (un fichier bien protégé, une base de donnée protégée par mot de passe, ou tout autre système), et ce AVANT d'affirmer au votant "votre vote a bien été pris en compte" (et non pas afficher un tel message alors qu'on est encore en train de sauvegarder). Ceci fait que du moment que cette phrase a été ne serait-ce qu'entraperçue, si le programme plante la seconde d'après, on sait qu'on peut reprendre là où ça en était au lancement suivant.
En fait, c'est pas tout à fait suffisant. Le programme doit "verrouiller" le fichier/la BDD sur laquelle il enregistre le vote tout en sauvegardant l'état précédent. Ainsi si jamais ça plante pendant l'enregistrement, en relançant, on voit que la base/fichier est verrouillé, donc que ça a planté en cours de sauvegarde. Les données st donc potentiellement corrompues ou simplement on est dans un état d'incertitude: le prog a-t-il eu le tps d'enregistrer le vote? Oui non? Au lieu de se demander, on prend la sauvegarde de l'état précédent et on demande au dernier votant de refaire son vote.
Donc dans l'ordre: verrouillage -> enregistrement -> confirmation écran -> déverrouillage. (y a d'autres méthodes, sauvegarder la variable séparée des votes totaux avant de sauver le vote effectif pour comparer au lancement)
En plus je doute que ce soit très bien de garder en mémoire vive (donc non protégée) les votes de façon continue parce que ce pourrait être plus facilement attaquable et manipulable par un programme pirate tiers qu'une mémoire qu'on a protégée (avec un mot de passe, de la cryptographie, etc.) sur le disque. Il vaut mieux une procédure qui dit simplement "ajoute 1 ici" (sans ramener l'info du nombre préalable) de manière abstraite que de rajouter 1 de façon visible à chaque fois.
* J'ai pas trop compris ton histoire de code correcteur d'erreur. Tu parles pas plutôt d'un truc de réseau là? A ce que j'ai compris, les machines sont hors réseau dans ce contexte, donc c'est pas le vrai problème.
* De manière spécifique au problème, il faut de façon logique une vérification "humaine" à plusieurs reprises. C'est à dire que l'humain vote d'abord. Puis avant de mettre en mémoire, on doit lui dire "vous votez pour un tel, est-ce bon?". Là il doit confirmer ou infirmer. Puis une fois le vote pris en compte, il faudrait une troisième vérification du type "vous avez bien voté pour un tel, vote pris en compte". Cette troisième vérification est là pr rassurer le votant, mais aussi pour la sécurité. En effet, sécuritairement, il faudrait qu'elle ne se base surtout pas sur la variable temporaire où on a enregistré le vote après la sélection du client mais qu'elle soit récupérée de la mémoire dure après coup, avec un appel du genre "récupérer dernier vote". Ca permet de récupérer après coup le vote qui a été effectivement inséré dans la base et ainsi de s'assurer par vérification humaine qu'il n'y a eu aucune erreur entre le moment où l'humain a sélectionné et le moment où une valeur a été effectivement insérée.
* Y a toujours plein de trucs à vérifier dans un programme, même les trucs "apparemment" infaillibles. Exemple comment sont définis les divers candidats ds le programme?
Imaginons que les programmeurs prendraient la décision de représenter les candidats par des entiers (ahahahahaha!!! Ce serait vraiment pas malin! Genre faire un "enum" C :p). Ben "a priori" (mais a priori seulement) puisqu'il y a un bouton par candidat et que chacun renvoie le bon num, il n'y a pas de raison de vérifier que le numéro est valable. Théoriquement si y a 5 candidats, on récup toujours un nombre entre 1 et 5. Mais non, on doit vérifier à chaque fois que le nombre est consistant en fonction du contexte (ou alors on a un langage comme l'Ada qui sait faire des types évolués et vérifie à notre place :-). C'est une règle de base pour ne pas se retrouver avec des erreurs d'inconsistance qui font planter ou pire... enregistreraient des données pour des candidats inexistants sans même se poser de questions!
Bon mon exemple est pas très malin car il faudrait vraiment que les programmeurs soient des bêtas pour coder ainsi des candidats (quoique...). Mais ce que je veux dire (et j'ai pris un exemple simple avec des entiers pour que ce soit plus facile à comprendre, mais c'est vrai pr tout), c'est qu'en programmation, il ne faut jamais sous-estimer les failles et se laisser aller au jeu du "c'est impossible, ça ne peut arriver". On doit toujours tout vérifier à chaque étape pour être sûr qu'y a aucun problème à l'exécution.
Evidemment ça dépend du type de programme qu'on fait. Si on veut une vraie sécurité des infos de bout en bout et repérer les erreurs à l'exécution, oui il faut le faire. Quand je fais des petits bouts de code pour moi, je me fais pas chier avec ces vérifs de choses qui peuvent pas arriver. Mais là c'est pas un petit bout de code pour moi. En fait ds un cas critique comme un vote, ça me paraît primordial de s'assurer que ça se passe bien à l'exécution, pas seulement algorithmiquement.
En fait, y a qd même un problème dans cette façon de penser. Ca signifie que si jamais on doit vérifier aussi à l'exécution que quelque chose "qui ne peut pas arriver" arrive quand même... c'est qu'on admet que le programme peut être buggué (car c'est la seule chose que ça signifiera si ça arrive), voire qu'en informatique, il peut parfois aussi arriver des choses inattendues. Si une telle chose que mon exemple arrive, le fonctionnement normal d'un programme aussi sensible devrait être de tout consigner dans un log, d'afficher un message d'erreur et d'arrêter le processus de vote.
Et je concluerais donc là-dessus en rappelant que pour ces raisons justement, le vote électronique ne doit pas être implémenté, mais que si jamais il doit l'être, alors de véritables programmeurs consciencieux devraient intégrer ce genre de vérifications à l'exécution (et donc mettre leur ego de côté) acceptant ainsi qu'il vaut mieux que le programme plante (de manière accompagnée et préparée par les dévs) pour sauver le bon déroulement d'un vote plutôt que de cacher les erreurs.
Voili voilà.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: MJs
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Êtes-vous favorable au vote électronique ?. Évalué à 3.
bon je vais te répondre, peut-être pas le mieux du monde car je me suis pas penché sur l'écriture d'un tel prog, mais en mettant sur le post les choses à gérer comme un premier jet (en fait qui me viennent à l'esprit là comme ça, à tête vide du problème).
Je vais parler uniquement de la partie si simple de "comptabiliser les votes", celle à laquelle tu fais mention, pour te montrer que sur une partie si simple, il y a plein de choses à vérifier. Je vais même pas parler de l'interface qui est super importante et probablement la chose qui doit nécessiter le plus de vérification et protection (à partir du moment où y a interaction avec un humain, ne jamais sous-estimer la capacité de ce dernier à faire le truc totalement inattendu auquel le développeur n'aurait jamais pensé, pas même imaginé possible!!!).
* Déjà une clé ou un mot de passe (voire les 2 en même tps), c'est pareil. C'est uniquement l'interface qui change, mais c'est tjrs géré au niveau logiciel. Surtout que si jamais c'était uniquement machine, imagine qu'on puisse "bypasser" (en français, on dirait quoi? Outrepasser?) le matériel par un bug quelconque? Le logiciel ne pourrait pas s'en rendre compte? Impensable! Le vote doit forcément être lié à une acceptation des autorités locales. Donc sans clé, le vote ne doit pas pouvoir être pris en compte.
* Le logiciel doit être capable de compter le nombre de votants et pas seulement les votes, ce de manière indépendante (c'est à dire qu'à chaque vote, tu incrémentes 2 variables distinctes, et indépendamment, pas une en fonction de l'autre). Il peut ainsi vérifier qu'y a pas plus de votants que d'habitants.
Le logiciel doit régulièrement faire des vérifications de consistance du genre. Prendre le nombre de votants pr chaque candidats, les additionner, vérifier que ça correspond aux votants totaux, etc.
* Le système de la variable est très mauvais pour diverses raisons.
La plus importante d'entre elle est qu'il faut sauvegarder!!! Imagine une coupure de courant, ben si on gardait simplement une variable en "runtime" (exécution), elle est mise à zéro à chaque reboot. Donc après chaque vote, elle doit être mise en mémoire dure (un fichier bien protégé, une base de donnée protégée par mot de passe, ou tout autre système), et ce AVANT d'affirmer au votant "votre vote a bien été pris en compte" (et non pas afficher un tel message alors qu'on est encore en train de sauvegarder). Ceci fait que du moment que cette phrase a été ne serait-ce qu'entraperçue, si le programme plante la seconde d'après, on sait qu'on peut reprendre là où ça en était au lancement suivant.
En fait, c'est pas tout à fait suffisant. Le programme doit "verrouiller" le fichier/la BDD sur laquelle il enregistre le vote tout en sauvegardant l'état précédent. Ainsi si jamais ça plante pendant l'enregistrement, en relançant, on voit que la base/fichier est verrouillé, donc que ça a planté en cours de sauvegarde. Les données st donc potentiellement corrompues ou simplement on est dans un état d'incertitude: le prog a-t-il eu le tps d'enregistrer le vote? Oui non? Au lieu de se demander, on prend la sauvegarde de l'état précédent et on demande au dernier votant de refaire son vote.
Donc dans l'ordre: verrouillage -> enregistrement -> confirmation écran -> déverrouillage. (y a d'autres méthodes, sauvegarder la variable séparée des votes totaux avant de sauver le vote effectif pour comparer au lancement)
En plus je doute que ce soit très bien de garder en mémoire vive (donc non protégée) les votes de façon continue parce que ce pourrait être plus facilement attaquable et manipulable par un programme pirate tiers qu'une mémoire qu'on a protégée (avec un mot de passe, de la cryptographie, etc.) sur le disque. Il vaut mieux une procédure qui dit simplement "ajoute 1 ici" (sans ramener l'info du nombre préalable) de manière abstraite que de rajouter 1 de façon visible à chaque fois.
* J'ai pas trop compris ton histoire de code correcteur d'erreur. Tu parles pas plutôt d'un truc de réseau là? A ce que j'ai compris, les machines sont hors réseau dans ce contexte, donc c'est pas le vrai problème.
* De manière spécifique au problème, il faut de façon logique une vérification "humaine" à plusieurs reprises. C'est à dire que l'humain vote d'abord. Puis avant de mettre en mémoire, on doit lui dire "vous votez pour un tel, est-ce bon?". Là il doit confirmer ou infirmer. Puis une fois le vote pris en compte, il faudrait une troisième vérification du type "vous avez bien voté pour un tel, vote pris en compte". Cette troisième vérification est là pr rassurer le votant, mais aussi pour la sécurité. En effet, sécuritairement, il faudrait qu'elle ne se base surtout pas sur la variable temporaire où on a enregistré le vote après la sélection du client mais qu'elle soit récupérée de la mémoire dure après coup, avec un appel du genre "récupérer dernier vote". Ca permet de récupérer après coup le vote qui a été effectivement inséré dans la base et ainsi de s'assurer par vérification humaine qu'il n'y a eu aucune erreur entre le moment où l'humain a sélectionné et le moment où une valeur a été effectivement insérée.
* Y a toujours plein de trucs à vérifier dans un programme, même les trucs "apparemment" infaillibles. Exemple comment sont définis les divers candidats ds le programme?
Imaginons que les programmeurs prendraient la décision de représenter les candidats par des entiers (ahahahahaha!!! Ce serait vraiment pas malin! Genre faire un "enum" C :p). Ben "a priori" (mais a priori seulement) puisqu'il y a un bouton par candidat et que chacun renvoie le bon num, il n'y a pas de raison de vérifier que le numéro est valable. Théoriquement si y a 5 candidats, on récup toujours un nombre entre 1 et 5. Mais non, on doit vérifier à chaque fois que le nombre est consistant en fonction du contexte (ou alors on a un langage comme l'Ada qui sait faire des types évolués et vérifie à notre place :-). C'est une règle de base pour ne pas se retrouver avec des erreurs d'inconsistance qui font planter ou pire... enregistreraient des données pour des candidats inexistants sans même se poser de questions!
Bon mon exemple est pas très malin car il faudrait vraiment que les programmeurs soient des bêtas pour coder ainsi des candidats (quoique...). Mais ce que je veux dire (et j'ai pris un exemple simple avec des entiers pour que ce soit plus facile à comprendre, mais c'est vrai pr tout), c'est qu'en programmation, il ne faut jamais sous-estimer les failles et se laisser aller au jeu du "c'est impossible, ça ne peut arriver". On doit toujours tout vérifier à chaque étape pour être sûr qu'y a aucun problème à l'exécution.
Evidemment ça dépend du type de programme qu'on fait. Si on veut une vraie sécurité des infos de bout en bout et repérer les erreurs à l'exécution, oui il faut le faire. Quand je fais des petits bouts de code pour moi, je me fais pas chier avec ces vérifs de choses qui peuvent pas arriver. Mais là c'est pas un petit bout de code pour moi. En fait ds un cas critique comme un vote, ça me paraît primordial de s'assurer que ça se passe bien à l'exécution, pas seulement algorithmiquement.
En fait, y a qd même un problème dans cette façon de penser. Ca signifie que si jamais on doit vérifier aussi à l'exécution que quelque chose "qui ne peut pas arriver" arrive quand même... c'est qu'on admet que le programme peut être buggué (car c'est la seule chose que ça signifiera si ça arrive), voire qu'en informatique, il peut parfois aussi arriver des choses inattendues. Si une telle chose que mon exemple arrive, le fonctionnement normal d'un programme aussi sensible devrait être de tout consigner dans un log, d'afficher un message d'erreur et d'arrêter le processus de vote.
Et je concluerais donc là-dessus en rappelant que pour ces raisons justement, le vote électronique ne doit pas être implémenté, mais que si jamais il doit l'être, alors de véritables programmeurs consciencieux devraient intégrer ce genre de vérifications à l'exécution (et donc mettre leur ego de côté) acceptant ainsi qu'il vaut mieux que le programme plante (de manière accompagnée et préparée par les dévs) pour sauver le bon déroulement d'un vote plutôt que de cacher les erreurs.
Voili voilà.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]