Il faut savoir que la majorité des urnes fabriquées sont constituées de milliers de lignes de code informatique (environ 25000 plus précisément)
25000 lignes de codes pour faire ça !?
déjà 100, ça me semble beaucoup, logiquement, je me serais attendu que le programme soit le plus simple possible pour être le plus sûr possible
si clique sur, candidat a = candidat a + 1
pareille pour les autres et au final sum(a) et des autres
déjà 100 lignes, ça me semble beaucoup mais là, je serai curieux de voir ce qu'ils ont bien pu pouvoir mettre dans toutes ces lignes de codes (à moins que toutes ces lignes passent dans l'interface graphique)
Je pense que pour dire ça, tu dois pas être programmeur. Les lignes de code, ça monte très vite, et ce pour pas mal de raison.
L'une d'elles est la lisibilité par exemple, laquelle fait qu'un programmeur va avoir tendance à sauter souvent les lignes par exemple, et à laisser des lignes vides aussi.
Et pis y a les commentaires aussi, très important et qui prennent une bonne part du code.
En plus là il ne s'agit pas d'un programme texte sans précaution.
C'est un programme qui apparemment requière une identification (j'ai lu une histoire de clé à insérer sur un autre post linuxfr), qui doit avoir des mesures de protection diverses, qui -- comme tu le dis -- a une interface graphique... en plus cette interface est avancée puisque j'ai cru comprendre que c'était écran tactile, etc. En outre là est-ce du matos spécifique? Si c'est le cas, y a sûrement des trucs à gérer en bas niveau pr accéder au matos. Enfin bon y a plein de trucs à régler.
Faut pas rigoler, 100 lignes, on les explose dès qu'on se met à écrire un petit script un peu plus compliqué que d'habitude et qu'on fait du code propre.
Enfin je voudrais avancer que pr ces raisons, les lignes s'écrivent vite en programmation, donc ça n'a pas le même sens qu'en littérature... sinon pr impressionner le chaland.
Ensuite on peut toujours s'amuser à faire du concours de "faire le prog le plus court possible pour un but donné", mais souvent ça implique peu de sécurité du prog, peu de gestion des erreurs, une illisibilité assez logique, etc. Ca c'est juste un truc de geek ce genre de concours.
Et oui très probablement aussi qu'il eut été faisable de développer le même soft avec la même sécurité, les mêmes fonctionnalités et la même lisibilité en moins de lignes... mais bon franchement... c'est pas plus un signe de sûreté. D'ailleurs tu parles un moment de simplicité, mais la simplicité n'implique pas la brièveté de code (ni la réciproque). En fait la taille du code et la simplicité des algorithmes n'ont tout simplement aucun rapport.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je ne suis en effet pas programmeur, mais je programme quand même un peu.
J'avais fait une interface php de gestion de base de données (gestion de clients et stocks) et c'est vrai que j'étais vite arrivé à 1000 lignes de codes.
Bon pour les 100 lignes, j'ai du passé un peu trop de temps à Marseille (n'ayez pas peur, je m'en suis exilé).
Cependant :
>> 100 lignes, on les explose dès qu'on se met à écrire un petit script un peu *plus compliqué* que d'habitude
C'est justement là mon questionnement où tu m'as mis un doute. Est-ce que le compliqué le rend plus simple. je m'explique.
Mon exemple précédent était simple, on a une fonction choix_client qui récupère le choix du votant (au niveau de cette fonction, je ne pense pas qu'on ai à mettre un code correcteur d'erreur, l'information étant trop basique pour être vérifiée)
Ensuite viens le stockage des données. J'avais fait très simple :
choix = choix_client() ;
switch res in choix {
case a : a++ ;
case b : b++ ;
}
bon un truc dans le genre, ça fait longtemps que je n'ai pas codé, surtout en c et la syntaxe est peut-être complètement fausse.
J'en viens à ma question (une vrai question, je ne connais pas la réponse)
Y a-t-il des risques dans un cas aussi simple que a, b et les autres contiennent des erreurs ? à quel taux ?
Le fait de le compliquer en essayant de détecter des erreurs (j'ai juste abordé le sujet des codes correcteurs d'erreurs à la fac, surtout pour les transmissions réseaux, donc je sais de quoi ça parle mais sans être spécialisé dedans).
Là, on a juste n valeur suivant le nombre de candidats que va détecter le correcteur ?
À la rigueur, on met 5 circuits électronique séparés et quand on presse, le traitement est fait sur les 5 et à la fin on vérifie qu'il soit tous identique (j'ai pris 5 parce que je trouve ça quand même plus sûr que 3).
Je ne vois pas ce qu'on peu faire de plus fiable de façon logiciel.
Ensuite viens l'aspect de l'interface, peut-être que toutes ces lignes vont dans la fonction choix_client(), mais bon j'en doute quand même.
Et le dernier point, c'est la sécurité, la clef et tout. Pensez-vous vraiment que ça doit être le rôle du programme ?
Je vois plus ça de façon "mécanique" vu qu'il me semble avoir vu qu'il met une clef dans la machine et pas qu'il tape un code (bon, il fait peut-être les deux), mais même si c'est le cas, le dispositif de verrouillage devrait me semble-t-il être complètement séparé.
Alors pour les 100 lignes, c'était peut-être exagéré, mais pensez-vous que le programme se doit d'être vraiment plus compliqué que ça ?
C'est une vrai question, parce que le sujet m'intéresse. J'ai fait des études d'électronique et d'informatique (bon sans aller très loin ni dans l'un ni dans l'autre) mais j'ai quand même de bonnes notions dans les deux domaines et si l'on m'avait demandé de faire une telle chose, j'aurais sans doute procédé à peu près comme ça (mais je ne suis pas spécialiste).
Alors pour les 100 lignes, c'était peut-être exagéré, mais pensez-vous que le programme se doit d'être vraiment plus compliqué que ça ?
Et la valeur de ton "choix_client()", elle vient d'ou ? Ah, de l'electronique... Mince, va falloir un driver pour s'interfacer avec... Et l'affichage sur l'ecran LCD ? Mince, un autre driver. Et l'impression des resultats ? Merde, encore un autre. Et la mémoire dans laquelle on met les valeurs, s'il y a un bit cassé ? Bon, ben on va devoir faire de la vérification de ce coté aussi.
Ou alors tu consideres que tu utilises un systeme existant qui a déja tous les drivers dont tu as besoin. Seulement quelques dizaines ou centaines de milliers de ligne en plus a auditer...
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 ]
25000 lignes de codes pour faire ça !?
Ben moi ca me parrait peu : t'es censé avoir des controlleurs d'erreur. Tu dois aussi ne pas stoker linéairement en memoire les votes (de sorte que si quelqu'un dumpe la memoire apres le vote et connait l'ordre de passage des votants, il ne puisse pas deduire qui a voter quoi)
et plein d'autre fonctionnalité dans le meme genre.
tu crois sincerement que les machines de vote a 20 000 euros implemente cela, nan la machine de vote c'est une technique pour se faire un max de pognon. Assez facilement.
On pourrait se dire que les gens de ce site étant plutôt geeks, fans de nouvelles techno, ils seraient attirés par ces systèmes ultra modernes top moumoute que sont les machines à voter. Eh bah non, je n'ai jamais vu plus de virulence envers ces machines qu'ici.
A mon avis, c'est pour une raison simple : les linuxfriens sont plus au courant que la moyenne des risques, mieux informés...
Il serait sans doute bon de faire prendre conscience aux politiques (et aux gens !) de ce côté qui semble paradoxal, mais qui est pourtant plutôt logique.
> On pourrait se dire que les gens de ce site étant plutôt geeks, fans de nouvelles techno, ils seraient attirés par ces
> systèmes ultra modernes top moumoute que sont les machines à voter. Eh bah non, je n'ai jamais
> vu plus de virulence envers ces machines qu'ici.
C'est oublier une caractéristique fondamentale du geek: sa propension à la paranoïa.
Peut-on considérer ce sondage comme crédible quand on voit le résultat de la question : "Le bilan du ministre de l'Intérieur est-il positif ?" avec 49% de oui ?
C'est une question piège ! si je réponds oui je me fais moinsser, si je réponds non je me fais moinsser aussi :-)
Bien sûr que je remettrais en question le résultat de l'élection... avec toutes ses machines à voter sous le contrôle de mon ennemi public n°1 (c'est bien lui qui est charger d'organiser les élections).... :-)
Son copain ? Plutôt son padawan ^^. Si on fait la personne qui ne sait pas se servir de la technologie moderne, vous croyez qu'ils vous montrent comment l'utiliser en appuyant sur le bouton N.S. ?
euh, les machines à voter ne sont pas sous le contrôle du ministère de l'intérieur, mais celui de la mairie. Le ministère ne fait qu'homologuer des modèles de machines (avec l'aide d'organismes comme VERITAS). Il me semble aussi que ce n'est pas lui qui entreprose ou distribue les machines, mais c'est sous la responsabilité des mairies.
L'argument selon lequel c'est le ministère qui contrôle tout, est tout simplement faux. (Et puis il n'y a pas que des mairies UMP qui ont des machines à voter, si tu vois ce que je veux dire...)
Merci donc de rester crédible dans ce débat important qu'est le vote éléctronique. C'est pas ce genre de FUD à 2 balles (ouuu l'état ou sarko le méchant ) qui va aider à faire prendre conscience des véritables dangers du vote électronique.
Tu m'excuseras mais tu peux penser que c'est un FUD à 2 balles, mais je continue à penser qu'il peut y avoir des manipulations faites sur les machines en provenance du Ministère de l'Intérieur (Sarkozy ou son successeur, ou le successeur de son successeur...) car c'est ce ministère qui est en charge de l'organisation des élections. Il pourrait très bien demander au constructeur de changer les puces électroniques des machines pour une soi-disante mise à jour. Pourquoi s'en méfieront-on vu que cette demande émanerait du ministère chargé d'organiser les élections ?
Si tu crois que le danger ne peut venir que d'un endroit, alors tu es mauvais en sécurité.
Enfin, à la limite, on ne devrait pas avoir à se poser ces questions là.
Il suffit de se rendre compte qu'on ne peut rien savoir de la machine sans faire confiance à une longue chaîne d'intermédiaires dont on ne sait rien, et dont chaque maillon est soit intéressé, soit corruptible, soit pourra l'être un jour, pour se dire que le système est bon pour la poubelle.
Ce n'est pas le ministère qui distribue les machines ! Ce n'est pas le ministère qui achète les machines. Donc il ne peut y avoir des manipulations/trafiquotage directes faites en provenance du ministère.
La manipulation dont tu parles ne pourra se faire que si l'état devient corrompue et change les rêgles du jeu (les lois) (une dictature quoi). Ce n'est pas le cas aujourd'hui.
Au pire le ministère pourrait donner des consignes en douce, aux maires de son partie, pour trafiquer les machines, mais il y a de fortes chances qu'il y ait des maires qui ne les suivent pas (tous ne sont pas pourris hein) et donc qu'il y ait des fuites. Remarque, ce serait pas mal : ce serait la mort des machines à voter. Sans compter la mort politique des personnes concernées.
Les vrais risques, ce sont les maires pourris qui de leur propre initiative, trafiquent les machines à l'insu de leurs électeurs, surtout aux élections législatives. C'est beaucoup plus facile que d'organiser une triche au niveau national, puisque ce sont les mairies qui sont en charge d'acheter et stocker les machines.
Tu pars dans l'idée que le Ministère mets les maires au courant de la tricherie. Et s'il ne le disait pas ? On pourrait imaginer pleins de scénarios, du genre : le ministère homologue les machines à voter uniquement avec telle version du firmware. Les maires devront donc mettre a jour les machines, à travers un prestataire choisi (homologue, certifié) par le ministère, le prestataire installant une version spéciale du firmware donnée par les bons soins du ministère qui peut dire l'avoir reçu du fabricant..... C'est peut être de la science fiction, mais ça pourrait peut être arriver.
Quand tu mets à jour ton ordinateur ou un logiciel, l'éditeur pourrait très bien rajouter une backdoor sans te le dire. Toi tu vas penser que c'est une mise à jour de sécurité importante.
Ce que je dis n'arrivera sûrement jamais. Mais le reste n'est pas nul.
Au fond, le problème principal est qu'il existe avec les machines à voter des zones d'ombres dangereuses pour la démocratie, zones d'ombres qui n'existent pas avec le système de vote actuel qui est complètement transparent.
Les Etats-Unis utilisent le vote électronique depuis pas mal d'années déjà, et avec plus ou moins de bonheur. Ceux qui lisent slashdot peuvent voir régulièrement des articles au sujet de Diebold (fabricant de machines à voter) et de failles de sécurité (la plus basique que j'ai lue c'était le mec qui a moulé une clé permettant d'ouvrir une de leurs machines à voter, en se basant une une (petite) photo dispo sur le site internet de Diebold).
Il y est question d'un texte de loi sur le "e-voting" qui pourrait bien passer devant le congrès, et qui stipule entre autres :
- obligation pour les machines à voter d'imprimer un bulletin papier de confirmation, vérifié par l'électeur (avec message de la machine rappelant explicitement à l'électeur de vérifier son bulletin),
- le bulletin papier est le seul qui fasse réellement foi,
- audit obligatoire d'au moins 3% des urnes électroniques après vote,
- interdiction pour ces machines de disposer de connectivité aux réseaux sans fil, ou de tout moyen de se connecter à Internet
- code source rendu public
On ferait bien d'en prendre de la graine en France...
Bravo ! Là, ça commence à devenir de la machine sérieuse. Cela éliminerait les principales critiques.
Resteraient quelques critiques secondaires :
- moins besoin de personnel pour dépouiller veut dire aussi moins d'implication du citoyen... c'est ce qui me gênerait encore le plus
- un vote confirmé électroniquement devrait faire automatiquement tomber le bulletin papier dans l'urne (histoire de limiter les divergences artificielles dues à des boulets qui préfèrent garder leur bulletin pour eux !). Enfin, je ne pense pas non plus que le phénomène puisse être significatif à l'échelle statistique.
- problème des personnes qui ont du mal avec les machines... bon oui, c'est embêtant, mais là je pense que c'est juste une question d'habitude et que ça viendra (au pire ce sera ok dans une génération)
- désacralisation du vote... beaucoup de gens avancent cet argument contre les machines à voter, mais personnellement, je n'y suis pas sensible. Machine ou pas, le vote reste sacré. "Peu importe le flacon tant qu'il y a l'ivresse !"
- enfin, problème de coût. Même si à terme on aura besoin de moins de personnel, les machines coûtent cher et doivent être entretenues. Je ne pense pas qu'on s'y retrouve financièrement.
Enfin, je pense que ce système serait acceptable pour l'exercice de la démocratie. Cela dit, globalement, je ne vois toujours pas trop l'intérêt par rapport au vote 100% papier, ou alors au vote papier à code barre et comptage optique.
Pourquoi se compliquer la vie quand le système actuel marche bien et que les avantages du nouveau système ne sautent pas aux yeux ? Est-ce un nouveau concept de démocratie Shadok ?
# Non
Posté par GCN (site web personnel) . Évalué à 10.
Bon, je suis plus là...
[^] # Re: Non
Posté par Narishma Jahar . Évalué à 10.
# voter
Posté par Etre-ange . Évalué à 8.
D'autant plus que je trouve ça risible de poser une question sur un avis sur le vote électronique en faisant un (sondage-)vote via une page web ...
M'enfin, m6 ...
# MJs
Posté par jemore . Évalué à 4.
http://www.mjsfrance.org/article.php3?id_article=809
(attention, c'est un site politique qui n'a rien a voir avec le libre...)
[^] # Re: MJs
Posté par seginus . Évalué à 2.
25000 lignes de codes pour faire ça !?
déjà 100, ça me semble beaucoup, logiquement, je me serais attendu que le programme soit le plus simple possible pour être le plus sûr possible
si clique sur, candidat a = candidat a + 1
pareille pour les autres et au final sum(a) et des autres
déjà 100 lignes, ça me semble beaucoup mais là, je serai curieux de voir ce qu'ils ont bien pu pouvoir mettre dans toutes ces lignes de codes (à moins que toutes ces lignes passent dans l'interface graphique)
[^] # Re: MJs
Posté par Jehan (site web personnel, Mastodon) . Évalué à 9.
Je pense que pour dire ça, tu dois pas être programmeur. Les lignes de code, ça monte très vite, et ce pour pas mal de raison.
L'une d'elles est la lisibilité par exemple, laquelle fait qu'un programmeur va avoir tendance à sauter souvent les lignes par exemple, et à laisser des lignes vides aussi.
Et pis y a les commentaires aussi, très important et qui prennent une bonne part du code.
En plus là il ne s'agit pas d'un programme texte sans précaution.
C'est un programme qui apparemment requière une identification (j'ai lu une histoire de clé à insérer sur un autre post linuxfr), qui doit avoir des mesures de protection diverses, qui -- comme tu le dis -- a une interface graphique... en plus cette interface est avancée puisque j'ai cru comprendre que c'était écran tactile, etc. En outre là est-ce du matos spécifique? Si c'est le cas, y a sûrement des trucs à gérer en bas niveau pr accéder au matos. Enfin bon y a plein de trucs à régler.
Faut pas rigoler, 100 lignes, on les explose dès qu'on se met à écrire un petit script un peu plus compliqué que d'habitude et qu'on fait du code propre.
Enfin je voudrais avancer que pr ces raisons, les lignes s'écrivent vite en programmation, donc ça n'a pas le même sens qu'en littérature... sinon pr impressionner le chaland.
Ensuite on peut toujours s'amuser à faire du concours de "faire le prog le plus court possible pour un but donné", mais souvent ça implique peu de sécurité du prog, peu de gestion des erreurs, une illisibilité assez logique, etc. Ca c'est juste un truc de geek ce genre de concours.
Et oui très probablement aussi qu'il eut été faisable de développer le même soft avec la même sécurité, les mêmes fonctionnalités et la même lisibilité en moins de lignes... mais bon franchement... c'est pas plus un signe de sûreté. D'ailleurs tu parles un moment de simplicité, mais la simplicité n'implique pas la brièveté de code (ni la réciproque). En fait la taille du code et la simplicité des algorithmes n'ont tout simplement aucun rapport.
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 seginus . Évalué à 2.
J'avais fait une interface php de gestion de base de données (gestion de clients et stocks) et c'est vrai que j'étais vite arrivé à 1000 lignes de codes.
Bon pour les 100 lignes, j'ai du passé un peu trop de temps à Marseille (n'ayez pas peur, je m'en suis exilé).
Cependant :
>> 100 lignes, on les explose dès qu'on se met à écrire un petit script un peu *plus compliqué* que d'habitude
C'est justement là mon questionnement où tu m'as mis un doute. Est-ce que le compliqué le rend plus simple. je m'explique.
Mon exemple précédent était simple, on a une fonction choix_client qui récupère le choix du votant (au niveau de cette fonction, je ne pense pas qu'on ai à mettre un code correcteur d'erreur, l'information étant trop basique pour être vérifiée)
Ensuite viens le stockage des données. J'avais fait très simple :
choix = choix_client() ;
switch res in choix {
case a : a++ ;
case b : b++ ;
}
bon un truc dans le genre, ça fait longtemps que je n'ai pas codé, surtout en c et la syntaxe est peut-être complètement fausse.
J'en viens à ma question (une vrai question, je ne connais pas la réponse)
Y a-t-il des risques dans un cas aussi simple que a, b et les autres contiennent des erreurs ? à quel taux ?
Le fait de le compliquer en essayant de détecter des erreurs (j'ai juste abordé le sujet des codes correcteurs d'erreurs à la fac, surtout pour les transmissions réseaux, donc je sais de quoi ça parle mais sans être spécialisé dedans).
Là, on a juste n valeur suivant le nombre de candidats que va détecter le correcteur ?
À la rigueur, on met 5 circuits électronique séparés et quand on presse, le traitement est fait sur les 5 et à la fin on vérifie qu'il soit tous identique (j'ai pris 5 parce que je trouve ça quand même plus sûr que 3).
Je ne vois pas ce qu'on peu faire de plus fiable de façon logiciel.
Ensuite viens l'aspect de l'interface, peut-être que toutes ces lignes vont dans la fonction choix_client(), mais bon j'en doute quand même.
Et le dernier point, c'est la sécurité, la clef et tout. Pensez-vous vraiment que ça doit être le rôle du programme ?
Je vois plus ça de façon "mécanique" vu qu'il me semble avoir vu qu'il met une clef dans la machine et pas qu'il tape un code (bon, il fait peut-être les deux), mais même si c'est le cas, le dispositif de verrouillage devrait me semble-t-il être complètement séparé.
Alors pour les 100 lignes, c'était peut-être exagéré, mais pensez-vous que le programme se doit d'être vraiment plus compliqué que ça ?
C'est une vrai question, parce que le sujet m'intéresse. J'ai fait des études d'électronique et d'informatique (bon sans aller très loin ni dans l'un ni dans l'autre) mais j'ai quand même de bonnes notions dans les deux domaines et si l'on m'avait demandé de faire une telle chose, j'aurais sans doute procédé à peu près comme ça (mais je ne suis pas spécialiste).
[^] # Re: MJs
Posté par imalip . Évalué à 3.
Et la valeur de ton "choix_client()", elle vient d'ou ? Ah, de l'electronique... Mince, va falloir un driver pour s'interfacer avec... Et l'affichage sur l'ecran LCD ? Mince, un autre driver. Et l'impression des resultats ? Merde, encore un autre. Et la mémoire dans laquelle on met les valeurs, s'il y a un bit cassé ? Bon, ben on va devoir faire de la vérification de ce coté aussi.
Ou alors tu consideres que tu utilises un systeme existant qui a déja tous les drivers dont tu as besoin. Seulement quelques dizaines ou centaines de milliers de ligne en plus a auditer...
[^] # Re: MJs
Posté par Jehan (site web personnel, Mastodon) . É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 ]
[^] # Re: MJs
Posté par rewind (Mastodon) . Évalué à 8.
> switch res in choix {
> case a : a++ ;
> case b : b++ ;
> }
il faut espérer que les ingénieus Nedap ne sortent pas un code comme ça, sinon b risque de gagner facilement...
[^] # Re: MJs
Posté par Christophe HENRY (site web personnel) . Évalué à 2.
Voilà ce qui se passe lorsqu'on fait un break trop long dans une carrière de programmeur.
[^] # Re: MJs
Posté par M . Évalué à 3.
Ben moi ca me parrait peu : t'es censé avoir des controlleurs d'erreur. Tu dois aussi ne pas stoker linéairement en memoire les votes (de sorte que si quelqu'un dumpe la memoire apres le vote et connait l'ordre de passage des votants, il ne puisse pas deduire qui a voter quoi)
et plein d'autre fonctionnalité dans le meme genre.
[^] # Re: MJs
Posté par Anonyme . Évalué à 3.
# Une remarque
Posté par Moogle . Évalué à 6.
A mon avis, c'est pour une raison simple : les linuxfriens sont plus au courant que la moyenne des risques, mieux informés...
Il serait sans doute bon de faire prendre conscience aux politiques (et aux gens !) de ce côté qui semble paradoxal, mais qui est pourtant plutôt logique.
[^] # Re: Une remarque
Posté par ouah (site web personnel) . Évalué à -1.
> systèmes ultra modernes top moumoute que sont les machines à voter. Eh bah non, je n'ai jamais
> vu plus de virulence envers ces machines qu'ici.
C'est oublier une caractéristique fondamentale du geek: sa propension à la paranoïa.
# Crédibilité du sondage ?
Posté par Matthieu . Évalué à 1.
[^] # Re: Crédibilité du sondage ?
Posté par farib . Évalué à 0.
[^] # Re: Crédibilité du sondage ?
Posté par Matthieu . Évalué à 3.
Bien sûr que je remettrais en question le résultat de l'élection... avec toutes ses machines à voter sous le contrôle de mon ennemi public n°1 (c'est bien lui qui est charger d'organiser les élections).... :-)
[^] # Re: Crédibilité du sondage ?
Posté par pastro . Évalué à 3.
[^] # Re: Crédibilité du sondage ?
Posté par travisnux . Évalué à 0.
[^] # Re: Crédibilité du sondage ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
L'argument selon lequel c'est le ministère qui contrôle tout, est tout simplement faux. (Et puis il n'y a pas que des mairies UMP qui ont des machines à voter, si tu vois ce que je veux dire...)
Merci donc de rester crédible dans ce débat important qu'est le vote éléctronique. C'est pas ce genre de FUD à 2 balles (ouuu l'état ou sarko le méchant ) qui va aider à faire prendre conscience des véritables dangers du vote électronique.
[^] # Re: Crédibilité du sondage ?
Posté par Matthieu . Évalué à 1.
Si tu crois que le danger ne peut venir que d'un endroit, alors tu es mauvais en sécurité.
Après si tu politises le sujet....
[^] # Re: Crédibilité du sondage ?
Posté par Aldoo . Évalué à 4.
Il suffit de se rendre compte qu'on ne peut rien savoir de la machine sans faire confiance à une longue chaîne d'intermédiaires dont on ne sait rien, et dont chaque maillon est soit intéressé, soit corruptible, soit pourra l'être un jour, pour se dire que le système est bon pour la poubelle.
[^] # Re: Crédibilité du sondage ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
La manipulation dont tu parles ne pourra se faire que si l'état devient corrompue et change les rêgles du jeu (les lois) (une dictature quoi). Ce n'est pas le cas aujourd'hui.
Au pire le ministère pourrait donner des consignes en douce, aux maires de son partie, pour trafiquer les machines, mais il y a de fortes chances qu'il y ait des maires qui ne les suivent pas (tous ne sont pas pourris hein) et donc qu'il y ait des fuites. Remarque, ce serait pas mal : ce serait la mort des machines à voter. Sans compter la mort politique des personnes concernées.
Les vrais risques, ce sont les maires pourris qui de leur propre initiative, trafiquent les machines à l'insu de leurs électeurs, surtout aux élections législatives. C'est beaucoup plus facile que d'organiser une triche au niveau national, puisque ce sont les mairies qui sont en charge d'acheter et stocker les machines.
[^] # Re: Crédibilité du sondage ?
Posté par Matthieu . Évalué à 1.
Quand tu mets à jour ton ordinateur ou un logiciel, l'éditeur pourrait très bien rajouter une backdoor sans te le dire. Toi tu vas penser que c'est une mise à jour de sécurité importante.
Ce que je dis n'arrivera sûrement jamais. Mais le reste n'est pas nul.
Au fond, le problème principal est qu'il existe avec les machines à voter des zones d'ombres dangereuses pour la démocratie, zones d'ombres qui n'existent pas avec le système de vote actuel qui est complètement transparent.
# L'expérience de nos voisins...
Posté par qstone . Évalué à 3.
Et justement dans /. cette info hier : http://politics.slashdot.org/article.pl?sid=07/04/02/2314237
Il y est question d'un texte de loi sur le "e-voting" qui pourrait bien passer devant le congrès, et qui stipule entre autres :
- obligation pour les machines à voter d'imprimer un bulletin papier de confirmation, vérifié par l'électeur (avec message de la machine rappelant explicitement à l'électeur de vérifier son bulletin),
- le bulletin papier est le seul qui fasse réellement foi,
- audit obligatoire d'au moins 3% des urnes électroniques après vote,
- interdiction pour ces machines de disposer de connectivité aux réseaux sans fil, ou de tout moyen de se connecter à Internet
- code source rendu public
On ferait bien d'en prendre de la graine en France...
[^] # Re: L'expérience de nos voisins...
Posté par Aldoo . Évalué à 3.
Resteraient quelques critiques secondaires :
- moins besoin de personnel pour dépouiller veut dire aussi moins d'implication du citoyen... c'est ce qui me gênerait encore le plus
- un vote confirmé électroniquement devrait faire automatiquement tomber le bulletin papier dans l'urne (histoire de limiter les divergences artificielles dues à des boulets qui préfèrent garder leur bulletin pour eux !). Enfin, je ne pense pas non plus que le phénomène puisse être significatif à l'échelle statistique.
- problème des personnes qui ont du mal avec les machines... bon oui, c'est embêtant, mais là je pense que c'est juste une question d'habitude et que ça viendra (au pire ce sera ok dans une génération)
- désacralisation du vote... beaucoup de gens avancent cet argument contre les machines à voter, mais personnellement, je n'y suis pas sensible. Machine ou pas, le vote reste sacré. "Peu importe le flacon tant qu'il y a l'ivresse !"
- enfin, problème de coût. Même si à terme on aura besoin de moins de personnel, les machines coûtent cher et doivent être entretenues. Je ne pense pas qu'on s'y retrouve financièrement.
Enfin, je pense que ce système serait acceptable pour l'exercice de la démocratie. Cela dit, globalement, je ne vois toujours pas trop l'intérêt par rapport au vote 100% papier, ou alors au vote papier à code barre et comptage optique.
Pourquoi se compliquer la vie quand le système actuel marche bien et que les avantages du nouveau système ne sautent pas aux yeux ? Est-ce un nouveau concept de démocratie Shadok ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.