Bonjour Serge, Serge Leblanc <[EMAIL PROTECTED]> writes: > Je pense au contraire, qu'il faut, dès à présent, prendre en compte les > contraintes spécifiques de sécurité que nécessitent Demexp. Ne pas les > incorporer maintenant dans la conception augmente le risque de se > retrouver dans une impasse plus tard. Peux-tu être plus explicite ? Pour moi, prendre en compte les contraintes de sécurité suppose de connaître exactement ce que l'on veut protéger. Hors, en l'occurence, ce n'est pas le cas, notamment à cause de la délégation encore en devenir.
Oui, mais une fois que tu as bien cerné ce que tu veux protéger, il est probable que les mesures de sécurité t'obligeront à modifier conceptuellement la délégation ainsi que son implémentassions.
Par définition, les contraintes de sécurité et de scalabilité sont importantes dans le projet Demexp. Il est important de les prendre rapidement en considération dans la phase de conception. Quitte à interdire des fonctionnalités proposer parce qu'il est probable que des contraintes sécuritaires et des fonctionnalités soient antagonistes.
> Laisse tomber Windows ! 99% des utilisteurs sont sous Windows. > il est préférable de développer un client Web multiplateforme avec des > technologies comme XUL, AJAX, etc... Réponse pratique : - le client qui a l'interface la plus complète, que ce soit pour l'administration que pour l'utilisateur, est le client GTK ;
Très bien, cela n'est pas surprenant étant donné que tu es le majoritaire développeur-contributeur (merci pour le travail réaliser). Si ce client est un outil d'administration, il n'est pas choquant qu'il soit uniquement sous GTK. Il pourra êtres installés dans toutes les mairies et lieu de vote par des agents compétents.
- améliorer l'interface web nécessite de gros efforts de développement, donc concrètement c'est prendre 1 ou 2 ans de retard. Évidemment, si quelqu'un ce colle à faire une interface web correcte, ça peut aller beaucoup plus vite.
L'interface Web peut être rudimentaire et limitée à l'_expression_ des votes.
Réponse « sécuritaire » : - le seul moyen de garantir que les algorithmes de sécurisation sont bien implémenté, c'est d'avoir un client sûr, en local ;
Rien n'interdit de permettre un accès (limité aux fonctionnalités de vote) à ce client via une interface web.
Dans ce cas, qu'il soit sous Linux à peu d'importance pour les utilisateurs finaux.
- bien sûr, on peut télécharger du Java ou _javascript_ côté client, mais je ne connais aucun moyen qui permet à un client de s'assurer que le code téléchargé est bien un code correct.
Cela n'est pas spécifique à java ou _javascript_. Lors que je download des paquets Debian signés, je suis dans la même situation. Le doute peut-être levez par la possibilité qui m'est fournie de relecture et de vérification avec d'autres personnes de confiance. De plus le client web ne justifie pas des plugins java ou autres pour exprimer un vote. Des formulaires Xform suffisent amplement.
> d'autre part je ne vois pas aujourd'hui l'utilité d'un serveur Demexp > sous Windows. C'est juste le client que je cherche à compiler, pas le serveur.
Franchement, laisse tomber le client Windows et favorise l'émergence une interface web sur le client GTK.
Si des personnes veulent un client Windows, ils n'ont qu'à participer à l'effort de développement ou le financer. De plus les utilisateurs finaux souhaitent ne rien avoir à charger sur leur machine (surtout le propriétaire de Windows), pas de plugin, pas de download, juste un navigateur standard.
Cordialement,
|
-- Serge Leblanc <[EMAIL PROTECTED]> GnuPG id: 1024D/73791C2B 2002-09-30 Primary key fingerprint: 8E0C 0D6D E026 A278 9278 BF4F 1A93 D552 7379 1C2B |
signature.asc
Description: This is a digitally signed message part
