Pour moi au contraire c'est la seule façon de faire les choses correctement : c'est l'utilisateur qui a les informations pour faire les choix de sécurité concernant ses données. Le modèle Unix est conçu pour protéger le système partagé de tous les utilisateurs, et les utilisateurs les uns des autres; il ne protège pas un utilisateur de ses propres programmes.
L'utilisateur, il cliques sur Ok pour que son application marche. Il ne cherche tres rapidement plus a comprendre pourquoi une application lui demande quelque chose. Il veut que ca marche et qu'on ne l'ennuie pas avec des questions superflues ! En ergonomie, chaque cliques augmentent de 50% les chances de perdrent l'utilisateur. Donc toutes questions de securite resulte en une mauvaise ergonomie. Ce n'est pas une solution !
En très grossier plus un modèle de sécurité est fin, plus il est difficile à faire comprendre à l'utilisateur—et donc paradoxalement il peut en être d'autant moins efficace. Pour un niveau de finesse donné il y a des efforts à faire pour obtenir un modèle à l'interface compréhensible. Il n'y a pas de secret, on y arrive en travaillant sur ces questions par itérations successives. Le modèle smartphone actuel de "le programme demande tel genre de capacités grossières, est-ce que ça vous semble raisonnable ?" est déjà un pas en avant. À mon avis on peut faire encore beaucoup plus fin en étant grossièrement aussi clair. Il faut repenser les interfaces pour que les concepts et bordures d'interface qui sont claires à l'utilisateur (par exemple "Mes Documents" et "Documents Partagés") correspondent aux bordures du système de sécurité.
Vu qu'on melange dans cette discussion deux problemes, comment interagir avec l'utilisateur et le proteger des applications malveillante et comment le proteger des failles de securite. Pour le proteger des failles de securite, c'est une problematique technique et un arsenal technique va clairement aider. Noyau et linker permettant de faire de l'adressage memoire aleatoire, canarie, analyse statique du code, privilege super fin de l'application (definit par le developpeur) et definition des sorties (en gros, quand il y a des donnees privees dans un fichier que l'application cree, le systeme en est informe et prend les mesures necessaires), virtualisation, secure boot et trusted computing. Avec ca le potentiel d'une attaque sur un systeme aillant une faille devient tres difficile et a aucun moment l'intervention de l'utilisateur a ete necessaire. Donc aucune problematique d'ergonomie.
J'aime aussi assez bien l'idee de faire payer les droits demander aux developpeurs. Plus il en demande, plus c'est chere… Mais ca, ca ne marche pas avec le logiciel libre.
Maintenant, pourquoi est-ce que l'utilisateur doit-il intervenir dans le process ? Le seul moment ou il a une decision a prendre, c'est quand il a installe une application. Et ca decision est simple, quel est le rating de l'application et combien de personne l'on installe ? Apres si il pousse un peu le truc, il lira aussi quelques reviews. A cette etape, il faut exposer l'information pertinente, savoir si l'application a ete auditer, si les droits sont logiques, si personne n'a eu de souci. Je ne vois pas pourquoi on ne fait pas la difference entre les utilisateurs qui ne comprennent rien a la securite et ceux que cela interresse. Je pense que vu qu'on cherche a resoudre un probleme humain, des gens qui ecrivent du code malicieux, il faut une solution qui implique des etres humains. Donc c'est au moment de l'installation que les informations pertinentes doivent etre afficher pour prendre une decision. Et il faut que ce soit simple a comprendre !
Et oui, je fais fondamentalement la difference entre un comportement attendu et l'utilisation d'une faille dans un logiciel existant.
Je ne vois pas trop ce que ça change du point de vue des dégâts causés à l'utilisateur, tu peux développer plus sur ce point ?
Le probleme est fondamentalement different meme si le resultat peut etre le meme. Dans un cas, tu as une tracabilite, avec la possibilite juridique d'intervenir dans l'autre tu es dans un cas anonyme et il faut des recherches plus ou moins pousser pour trouver un coupable. Plus le developpeur comprend que si il fait volontairement une betise, il sera identifie et penalement poursuivit, moins il prendra de risque sur la plateforme. Comme c'est un probleme different, il demande des reponses differentes. Et a aucun moment, on peut compter sur l'utilisateur pour prendre la bonne solution surtout sur une question complique.
En faisant cette difference, tu peux agir de maniere plus simple pour l'utilisateur sans le mettre en danger pour autant.
[^] # Re: La politique de sécurité est bonne
Posté par cedric . En réponse à la dépêche Bref, MPlayerX quitte le Mac App Store. Évalué à 3.
L'utilisateur, il cliques sur Ok pour que son application marche. Il ne cherche tres rapidement plus a comprendre pourquoi une application lui demande quelque chose. Il veut que ca marche et qu'on ne l'ennuie pas avec des questions superflues ! En ergonomie, chaque cliques augmentent de 50% les chances de perdrent l'utilisateur. Donc toutes questions de securite resulte en une mauvaise ergonomie. Ce n'est pas une solution !
Vu qu'on melange dans cette discussion deux problemes, comment interagir avec l'utilisateur et le proteger des applications malveillante et comment le proteger des failles de securite. Pour le proteger des failles de securite, c'est une problematique technique et un arsenal technique va clairement aider. Noyau et linker permettant de faire de l'adressage memoire aleatoire, canarie, analyse statique du code, privilege super fin de l'application (definit par le developpeur) et definition des sorties (en gros, quand il y a des donnees privees dans un fichier que l'application cree, le systeme en est informe et prend les mesures necessaires), virtualisation, secure boot et trusted computing. Avec ca le potentiel d'une attaque sur un systeme aillant une faille devient tres difficile et a aucun moment l'intervention de l'utilisateur a ete necessaire. Donc aucune problematique d'ergonomie.
J'aime aussi assez bien l'idee de faire payer les droits demander aux developpeurs. Plus il en demande, plus c'est chere… Mais ca, ca ne marche pas avec le logiciel libre.
Maintenant, pourquoi est-ce que l'utilisateur doit-il intervenir dans le process ? Le seul moment ou il a une decision a prendre, c'est quand il a installe une application. Et ca decision est simple, quel est le rating de l'application et combien de personne l'on installe ? Apres si il pousse un peu le truc, il lira aussi quelques reviews. A cette etape, il faut exposer l'information pertinente, savoir si l'application a ete auditer, si les droits sont logiques, si personne n'a eu de souci. Je ne vois pas pourquoi on ne fait pas la difference entre les utilisateurs qui ne comprennent rien a la securite et ceux que cela interresse. Je pense que vu qu'on cherche a resoudre un probleme humain, des gens qui ecrivent du code malicieux, il faut une solution qui implique des etres humains. Donc c'est au moment de l'installation que les informations pertinentes doivent etre afficher pour prendre une decision. Et il faut que ce soit simple a comprendre !
Le probleme est fondamentalement different meme si le resultat peut etre le meme. Dans un cas, tu as une tracabilite, avec la possibilite juridique d'intervenir dans l'autre tu es dans un cas anonyme et il faut des recherches plus ou moins pousser pour trouver un coupable. Plus le developpeur comprend que si il fait volontairement une betise, il sera identifie et penalement poursuivit, moins il prendra de risque sur la plateforme. Comme c'est un probleme different, il demande des reponses differentes. Et a aucun moment, on peut compter sur l'utilisateur pour prendre la bonne solution surtout sur une question complique.
En faisant cette difference, tu peux agir de maniere plus simple pour l'utilisateur sans le mettre en danger pour autant.