Tu ne fais pas mention explicite de SELinux par exemple […] par expérience personnelle, cette couche supplémentaire devient vite fastidieuse […]
La réponse est dans la question ! Si la sécurité est trop difficile à mettre en place, gérer ou comprendre, elle n'est pas efficace. Je ne jette pas la pierre à SELinux, c'est un problème extrêmement difficile.
Un petit point méthodologico-philosophique : j'ai tendance à avoir plus d'espoir en les approches où c'est le développeur lui-même qui choisit la politique de sécurité de son application, et pas un administrateur qui après coup ajoute une politique MAC par dessus l'application. Enfin je pense que les deux sont complémentaires (le développeur devrait faire des efforts pour minimiser les droits dont l'application a besoin, et l'administrateur peut ensuite retirer ce qu'il trouve inacceptable au risque de priver l'utilisateur de certaines fonctionnalités), mais que le gros du travail doit venir du programme lui-même, qui décide d'abandonner ses droits; aujourd'hui avec des outils comme SELinux ou AppArmor c'est tout fait de façon externe, et à mon avis c'est un déséquilibre regrettable.
Pour l'instant, madame Michu est contente de pouvoir refuser l'installation d'une appli "torche" qui demande l'ID de son téléphone et l'accès à ses SMS juste pour allumer son flash dans le noir. Ça semble être une sécurité suffisante
Sauf que si tu installes une application "remember pass" qui fait des exercices de mémoire pour que tu retiennes tes mots de passe que tu as peur d'oublier, et une application "SMS du ventre" qui texte automatiquement où tu vas au restaurant, et que les deux peuvent communiquer ensemble en écrivant dans le système de fichier, un pirate peut obtenir tes mots de passe par SMS sans que tu aies jamais validé à la fois les deux "lit le keyring" et "envoie des SMS" pour une seule application.
Des chercheurs en sécurité avaient trouvé comment transférer de l'information entre deux applications malicieuses en leur faisant manipuler le système silencieux/vibreur pour communiquer, ou le niveau de luminosité de l'écran. Ce genre de techniques expose le besoin d'une approche ambitieuse de la sécurité, qui essaie de prendre le plus de chose possible en compte et de minimiser au maximum les droits de chaque agent. Je ne pense pas qu'on puisse dire aujourd'hui que la sécurité des smartphones (encore moins des ordinateurs desktop) est "suffisante".
On connaît les techniques pour concevoir des systèmes sécurisés qui répondent à ce genre de problématiques. Une façon de faire par exemple est de donner à l'application, au moment du transfert du descripteur de fichier, un marqueur dont la sémantique est "j'ai le droit d'ouvrir ce fichier" (par exemple on peut imaginer que le fichier est chiffré par défaut sur le disque, et que le marqueur est la clé de chiffrement). Si l'application a obtenu le marqueur dans le passé, elle a le droit de s'en resservir ensuite pour rouvrir le fichier sans demander l'autorisation (ça sera indiqué au moment de l'ouverture à l'utilisateur par un message du style "l'application demande le droit de le réouvrir les prochaines fois", ou éventuellement une case cochable pour refuser ce droit). Elle est libre de stocker ce marqueur dans un fichier persistant (la playlist, la "liste de référence" de ton format pro, etc.) ou même de le communiquer aux sous-applications qu'elle appelle en arrière-plan (indistinguable de l'application du point de vue de l'utilisateur).
C'est encore mieux s'il y a possibilité de montrer à l'utilisateur quels "droits permanents" ont été accordés de la sorte et lui donner la possibilité de les révoquer (en fait non mon lecteur Mp3 a l'air buggué, je ne lui fait plus confiance). Ça commence à demander une conception très soigneuse du système de sécurité.
Pour revenir à la playlist MP3, l'idée est donc que tu peux ajouter des fichiers dans la playlist en utilisant un logiciel (pas forcement le lecteur audio, un utilitaire en ligne de commande peut le faire) qui demande un accès persistant au fichier (le système peut donc avertir l'utilisateur) et met le marqueur obtenu dans la la playlist.
Si demain tu viens avec un besoin encore plus sophistiqué qui n'est pas exprimable en l'état du système de sécurité, tu dois demander à faire tourner ton programme (ou au moins les parties qui ont ce besoin) en mode plus privilégié, en attendant que le système essaie de mieux comprendre ton besoin et de l'exprimer de façon plus sécurisée. Aujourd'hui on met tout en mode "privilège utilisateurs totaux" par défaut, donc c'est cette solution qu'on utilise.
J'aimerais bien que ma distribution Linux évolue elle aussi vers des modèles de sécurité plus fins que l'antique user/group/owner, sans être non plus complètement inutilisable.
Je détaille un peu plus : il existe de nombreuses projets qui vont dans cette direction, mais ils se concentrent souvent sur le champ de sécurité entre les droits utilisateurs (considérés "privilèges minimums") et les droits administrateurs. Tout ce qui va dans le sens par exemple d'autoriser un équivalent de "sudo" mais seulement sur certaines commandes bien choisies, PolicyKit étant un bon exemple de cette tendance.
À mon avis il y a déjà beaucoup à faire sur les droits de l'utilisateur. Quand on y pense les informations les plus précises qu'on a sur son ordinateur sont nos données personnelles, qui sont en général lues, éditées et parcourues par des applications tournant en droit utilisateur (et donc, dans le modèle actuel, que chacune des applications que je lance peut observer et modifier à mon insu). Alors certaines applications (Google Chrome par exemple) font des efforts pour faire tourner les parties les plus critiques sans aucun droit du tout, mais en réalité il y a une vaste jungle de droits intermédiaires (comme de pouvoir créer des répertoires temporaires locaux et y faire ce qu'on veut) qu'on pourrait contrôler.
Pour cela il faut des bonnes pratiques de compartementalisation des droits. Dans l'extrême majorité des cas, une application n'a aucun besoin de l'accès à tout mon $HOME, elle peut se contenter de lire seulement les fichiers que je lui donne (par l'intermédiaire d'un démon privilégié) et un répertoire de configuration/cache/stockage local qu'elle est la seule à pouvoir manipuler. Le problème est qu'aujourd'hui on conçoit des applications comme si elles devaient tout faire elles-mêmes, y compris implémenter le dialogue "ouvrir un fichier …", et à cause de cette erreur de conception on est forcé de lui donner beaucoup plus de droit que nécessaire, ce qui nuit à la sécurité.
Pour ça il n'y a pas de mystère, il faut que les mentalités changent et que les développeurs paient plus d'importance à ce genre d'aspects. Si le monde mobile les force à respecter de bonnes pratiques dans ce domaine, ce sera une bonne chose—même si je trouve dommage que l'innovation (voire le couteau sous la gorge) vienne de systèmes fermés (Apple) ou au développement fermé (Android). Mais bon c'est comme partout, "those who do the work decide".
Empêcher de lire des fichiers qui n'ont pas été sélectionnés par l'utilisateur est une excellente idée qui permettra de sécuriser les applications. Je comprends que le développeur ne veuille pas fournir les efforts nécessaires (en travail supplémentaire pour adapter son code ou au moins abandonner les features) pour respecter ce critère. Mais alors que la dépêche sous-entend que cette restriction est abusive, je pense qu'elle est au contraire adaptée et utile. Je suis un des premiers à critiquer Apple sur sa fermeture, mais dans la situation telle qu'elle est exposée ici je leur donne totalement raison.
Plus précisément: l'intérêt de cette restriction est de pouvoir interdire aux programmes de lire le système de fichier. Quand ils veulent ouvrir un fichier, ils appellent un widget système (à travers une API système) qui va interagir avec l'utilisateur, lui proposer de naviguer dans ses fichiers et d'en choisir un, ouvrir ce fichier (dans le mode demandé par l'application, lecture seule ou lecture+écriture) et renvoyer le descripteur à l'application. Tout l'intérêt tient dans le fait que le widget système peut être un processus différent qui tourne avec plus de privilèges, et qui est le seul à avoir ces droits sur le système de fichier.
Du coup, même si l'application est malicieuse ou bugguée (faille d'injection de code par exemple), comme elle n'a pas accès au système de fichier sa surface d'attaque du système est considérablement réduite (pas possible d'aller chercher les mots de passe stockés en clair dans ~/.config, d'aller écrire en douce dans le fichier de conf d'une autre application pour dire à la webcam de rediriger son flux vers un site pirate louche, de monter une "access race" sur les fichiers temporaires d'une troisième application, etc.). La quantité de code privilégié (trusted computing base) a fortement réduit, il suffit d'auditer le widget système pour vérifier qu'il est solide, au lieu de toutes les applications qui tournent avec les droits utilisateurs.
De plus, cette façon de forcer les accès privilégiés de l'application à passer par une couche de médiation liée à l'interface utilisateur permet de mettre en place de bonnes pratiques à la frontière entre sécurité et interaction. L'application ne peut pas par exemple mentir à l'utilisateur en lui demandant de lui désigner un fichier pour le lire, alors qu'elle compte en fait écrire dedans (corruption accidentelle ou malicieuse): c'est le widget système qui interagit avec l'utilisateur et a toutes les informations en main pour lui annoncer clairement et honnêtement quels droits on lui demande de fournir à l'application (elle veut le fichier en écriture). Cette façon de s'assurer que les informations montrées à l'utilisateur (donc son image mentale de la sécurité de son système) correspondent bien à la réalité renforce la sécurité.
J'invite les gens intéressés par ces considérations à regarder l'article "User Interaction Design for Secure Systems", de Ka-Ping Yee, 2002, que j'ai présenté dans ce billet. Il donne dix principes fondamentaux de l'interface sécurisée, le plus pertinent ici étant "Explicit Authority": "A user’s authorities must only be provided to other actors as a result of an explicit action that is understood by the user to imply granting."
Alors bien sûr, forcer ces restrictions au niveau d'un système entier restreint les possibilités (c'est la contrepartie à payer pour augmenter la sécurité : si on autorise tout ce qui était possible avant, on autorise toujours les attaques, donc on n'est pas plus sécurisé). Il faut travailler pour mitiger ces problèmes, et c'est là qu'il est peut-être possible de critiquer Apple :
Certaines applications (ici le "widget système de droit de fichier") ont par nature besoin de privilèges supérieurs; on va avoir plusieurs couches de droits, et dans un système libre on veut évidemment pouvoir avoir la possibilité d'exécuter, lire, comprendre et modifier les applications à tous ces niveaux de droit (sachant évidemment qu'exécuter des applications privilégiées va demander plus de droit, des confirmations à l'utilisateur, etc.). Si Apple force tous les app writers à se contenter du niveau le plus bas, et se réserve la possibilité d'écrire des applications privilégiées, et bien on peut faire moins de chose avec la plateforme et c'est dommage. Dans un système libre on voudrait pouvoir soumettre des applications à tous les niveau (mais en comprenant que le coût d'audit est d'autant plus élevé).
Il faut être prêt à faire évoluer des APIs un peu trop restrictives pour permettre des usages plus riches. Par exemple la fonctionnalité de "recherche automatique de sous-titre" pourrait être accommodée en ajoutant un appel système pour sélectionner non pas un fichier, mais un répertoire entier dans lequel le logiciel aurait le droit de lire tous les fichiers, donc les films et les sous-titres associés. Il faut comprendre que cet appel donne un peu plus de droits, et il faut que l'utilisateur le comprenne aussi, mais c'est un bon compromis entre "lire potentiellement tout son $HOME" et devoir choisir fichier-par-fichier. Je n'y connais rien, mais peut-être qu'Apple ne fait pas assez d'efforts pour faire évoluer ses APIs dans ce sens. Mais il faut aussi comprendre que toute modification des APIs donnant accès à ces privilèges demande un effort de conception et d'audit important, peut compliquer l'interface utilisateur ou le modèle de sécurité, etc.
Pour résumer, je ne plains pas trop le développeur et je trouve la démarche technique d'Apple intéressante. J'aimerais bien que ma distribution Linux évolue elle aussi vers des modèles de sécurité plus fins que l'antique user/group/owner, sans être non plus complètement inutilisable. Capsicum va dans la bonne direction, mais il faut un effort des projets/frameworks/etc. entre le kernel et l'utilisateur pour intégrer ces principes de conception sécurisée.
"Vous", c'est en fait l'ensemble des membres du site, ou en tout cas des gens qui s'identifient comme jouant un rôle important sur le site, s'y étant investis, et étant donc à même de pouvoir influer sur son identité. C'est un peu le même "vous" qui décide de faire des présentations aux RMLL sur LinuxFR (si ce "vous" n'existait pas, quelle serait leur légitimité ?), mais ça désigne plus de gens que seulement l'équipe de modération.
Ma position externe est la position d'un type qui n'a pas le temps de s'investir autant dans le site que toi ou les autres participants à la discussion, et qui est en train de se demander si ça vaut le coup pour lui d'y envoyer quand même du contenu qu'il juge intéressant. Est-ce que c'est un site que j'ai envie de soutenir et avec lequel l'interaction peut m'apporter quelque chose, ou est-ce que c'est en fait définitivement un repère de gens désagréables dans lequel je ne me sentirai jamais bien et qu'il vaut mieux que j'oublie de ma carte mentale d'internet ?
Les changements que je compte faire c'est, si j'ai l'impression que ça vaut le coup de persister sur LinuxFR, ben apporter un peu de contenu et influer un peu sur le comportement des gens en râlant quand je les trouve incorrects. Mais pour ça il faut que je m'assure que le fait de râler de la sorte est considéré par une bonne chose, et que ce n'est pas au contraire moi qui serait un casse-pieds externe en m'opposant à des usages reconnus et acceptés sur le site. Comme de toute façon je n'ai pas le temps de participer beaucoup, ce n'est certainement pas de moi que viendront d'éventuels effets positifs durables sur le long terme, mais de membres plus impliqués.
Tu parles de remettre en place les personnes ayant un mauvais comportement, mais comment savoir quels sont les comportements considérés comme mauvais ? À ma connaissance le "vous" ayant une légitimité sur le site n'a jamais pris de position sur ce qui est bien ou mauvais sur LinuxFR (y a-t-il une charte de comportement quelque part ?), et je ne me souviens pas particulièrement avoir vu des gens faire des reproches policés aux gens agressifs, rudes ou de mauvaise foi. Tout ce qu'il y a c'est un fil pour dire ici "il y a des problèmes", mais sans vouloir dire vraiment de quels problèmes il s'agit, à part une obscure histoire de tribune automatisant les comptes sexistes moinssés par une cabale secrète, dont je n'ai absolument rien à cirer.
À mon avis pour que la position évolue dans un sens raisonnable il faudrait qu'il y ait un relatif consensus, et une prise de position claire, sur la question suivante : "Quels sont les comportements raisonnables et désirés sur LinuxFR ?". Ce fil ou votre intervention à la RMLL aurait pu constituer une réponse à cette question, mais ce n'est clairement pas le cas pour l'instant—ou alors il faut m'expliquer plus clairement.
Si je me contentais d'essayer d'inférer une réponse en fonction des façons de discuter que j'observe réellement sur le terrain, j'obtiendrais un truc du genre (bon ok, je force un peu la dose pour l'exemple) "être un pédant agressif de mauvaise foi qui fait dérailler toute conversation, quelque soit son sujet, pour la ramener vers son troll de prédilection du moment (en évitant toutefois les insultes, blagues sexistes ou racistes et autres délits)". Et alors je peux facilement répondre à ta question "pourquoi est-ce que tu ne fais rien pour responsabiliser les gens pour qu'ils respectent ce comportement?": parce qu'il n'y a rien à faire, on est déjà en plein dedans. Content ou pas content ?
Ou il vient du fait que les personnes qui commentent refusent de débattre posément avec des arguments et préfèrent être virulents, agressifs, de mauvaise foi, etc.
Il est là, le problème que je vois moi. Comment avez-vous fait pour construire un groupe qui exhibe aussi fortement de tels comportements ? Qu'il y ait une fois tous les deux ans des propos négationnistes tenu dans un sous-canal de discussion spécifique tard le soir, c'est quelque chose qui peut arriver partout. Mais il y a des communautés où la norme n'est pas d'être virulent, agressif ou de mauvaise foi, et qui évitent ce genre de comportement. Quelle est la différence avec LinuxFR? Est-elle voulue, subie ? Avez-vous l'intention de faire des changements pour faire évoluer cette situation ?
Je me suis posé des questions de ce genre pour un blog perso auto-administré : est-ce que je mets un lien vers les images sur le serveur externe, ou est-ce que je les copie en local ?
Un aspect qui n'a pas été abordé dans cette dépêche est celui de la reconnaissance de la source : est-il toujours possible pour le visiteur de LinuxFR de savoir d'où vient l'image en question ? Que pensent les distributeurs de cette image de l'idée que vous les copiiez en local au lieu de leur envoyer du trafic ? Si le contenu est soumis aux droits d'auteurs (par exemple je donne un lien vers une belle photographie ou une bande dessinée amusante), quel est le statut de cette copie ?
Dans le cas de mon petit site, à faible traffic, j'ai jugé que ces problématiques éclipsaient largement les économie en bande passante pour le destinataire ou les problématiques de pérennité, et j'ai laissé les URLs vers des images distantes. Le bon choix pour LinuxFR est sans doute différent, mais je me demande quand même ce que vous en pensez.
Donc en gros le "problème" mystérieusement évoqué dans ces slides, c'est des débordements dans la tribune ? Moi je n'en ai rien à cirer, je n'y vais pas (pas le temps), donc je ne me sens pas trop concerné (il y a un journal à son sujet de temps en temps, on l'ignore et voilà, problème réglé). Tant mieux si c'est convivial, on y boit des bières, et tant pis si les gens y volent des bébés pandas.
Je croyais que c'était lié à des commentaires sur le site.
Je ne demande pas spécialement à avoir des noms, c'est juste que les transparents parlent plusieurs fois de "problèmes" et que je ne comprends pas de quoi vous voulez parler, ce qui me paraît un peu curieux. De quels problèmes s'agit-il ?
Les slides évoquent beaucoup de "pistes d'améliorations" et de "problèmes", et on comprend que c'est lié à la "modération", mais je n'ai trouvé aucun point précis sur ce qui vous posait problème, les cas qui se sont réellement produits, etc. J'imagine que ça a été dit oralement (ou alors tout le monde comprend la référence vague à "un événement en particulier au début de l'année" ? moi pas en tout cas), mais je serais intéressé par des détails pour comprendre ce dont vous parlez réellement.
Sur un point de vue tout à fait personnel, je ne suis pas satisfait de la communauté LinuxFR. J'ai découvert pendant la discussion sur l'édition des messages, mais aussi à d'autres reprises récemment, qu'une partie significative des membres ont une vision agressive voire violente de la façon dont on discute (où la mauvaise foi et les critiques sur la forme plutôt que le fond sont partout). Je ne suis pas à l'aise dans ce cadre, et c'est ce que je connais qui ressemble le plus à ce que des gens décrivent comme "les communautés pas accueillantes" (les autres sites, listes de discussion etc. que je fréquente sont plus agréables pour moi). En lisant l'annonce de votre intervention, je me suis demandé si c'était lié à ce dont vous alliez parler, et je m'attendais à trouver plus d'information me permettant de le savoir dans votre retour, mais ce n'est pas le cas. Vous pourriez en fait parler de tout à fait autre chose, voire même considérer que ce sont des comportements tels que le mien (des gens extérieurs au noyau dur de la communauté qui font des réclamations et ont des comportements qui ne font pas partie des traditions locales) qui posent problème !
Posté par gasche .
En réponse au journal Été meurtrier chez Mozilla.
Évalué à 4.
Dernière modification le 10 juillet 2012 à 14:23.
Mais si un pervers de chez Google reluque mes mails:
soit il le garde pour lui, ça n'a aucune conséquence observable, et je n'en ai essentiellement rien à foutre
soit un jour il se sert de ce qu'il a lu, d'une façon ou d'une autre, ou le communique à un tiers; avec une assez haute probabilité, il se fait coincer, et là les gens de Google ont peur pour leur réputation, le virent et prennent des mesures drastiques pour que ça n'arrive pas; avec haute probabilité ce pervers, qui a accès à un grand nombre de boîtes mails, a fait ses merdes sur la boîte d'un autre avant de se faire choper, donc il n'a même pas le temps d'arriver à la mienne
Si je dis qu'ils ont une charte de respect de la vie privée, c'est parce qu'une violation de cette charte, une fois rendue public, causerait beaucoup de tort à l'image de Google (il suffit de voir comment Facebook se fait attaquer par ses concurrents là-dessus). Donc ils n'ont pas du tout intérêt à ce que ça arrive, et donc ils ont intérêt à ce qu'aucune violation ne soit observable de l'extérieur. En pratique ça veut dire qu'il ne se passe rien qui me concerne et qui puisse être expliqué par la lecture de mes mails; ça me va.
C'est toute la différence avec le fait de donner ton mot de passe explicit aux gens de LinuxFR, qui n'ont jamais promis de ne pas faire de conneries avec, et donc une bonne partie serait suffisamment stupide pour effectivement faire des conneries avec, causant du tort à toi et à eux en même temps.
Tout ce que je dis est relativement évident et aurait pu être inféré à la lecture de mon message. Malheureusement:
JGO ne l'a visiblement pas compris
Juke est trop occupé à être de mauvaise fois pour faire l'effort de le comprendre
Zylabon préfère faire des blagues pas drôles
Dr BG se sent obligé, à chaque fois qu'il détecte un anglicisme, de le faire remarquer à tout le monde
Beaucoup de bruit pour rien. Au moins ta remarque a l'air de bonne foi.
Je ne vois pas le rapport. Google utilise des filtres automatisés pour miner des informations des messages, ce n'est pas comparable à une inspection personnelle par des pervers de LinuxFR. Je ne dis pas que c'est génial de stocker ses mails sur un serveur appartenant à autrui, mais il n'empêche que ton argument est mauvais. D'ailleurs Google a une charte de respect de la vie privée.
Oui, il y a des personnes externes; j'ai un collègue qui contribue un peu à Thunderbird, alors qu'il n'est pas chez Mozilla. Il parle de temps en temps du développement et ça m'a l'air tout à fait ouvert. En plus, le système d'extensions permet aux gens de développer des fonctionnalités sans même passer par le code du logiciel.
Je crée un journal sur un appel à l'"expression, accès, ouverture, innovation et vie privée" sur internet, qui génère une longue discussion…. sur l'endroit où citer les mails précédents dans une conversation. Merci tout le monde !
Je me suis demandé en lisant cette dépêche quel était le lien avec le notebook du projet Sage (un logiciel de calcul formel en Python). On peut trouver la réponse dans un billet très intéressant de l'auteur de IPython:
Tu as des sources sur cette utilisation d'Eagle par la police française, dans un cadre contrôlé par un juge ? Ça m'intéresse. L'article que j'ai mis en lien n'en parle absolument pas (il mentionne seulement des commandes obscur(ci)es du ministère de l'intérieur, qui n'a visiblement pas voulu répondre aux questions des journalistes à ce sujet).
let slot f x = fun () -> f x
let f1 x = print_endline "f1 called"; x
let f2 () = print_endline "f2 called"
let c1, c2 = slot f1 5, slot f2 ()
let () =
let x = c1 () in
Printf.printf "result: %d\n" x;
c2 ()
A moins que tu ne saches proposer un opérateur de comparaison universel qui donne le résultat que je veux quel que soit le type que je crée
Ce n'est pas possible en général (l'ordre dépend de la sémantique de la structure; le cas d'école étant les arbres balancés qui ne sont pas "canoniques", ie. deux arbres à la structure différente peuvent en fait représenter le même ensemble (balancé différemment), donc tu veux que la comparaison les considère comme égaux).
Tu répètes essentiellement des choses que tu as déjà dites. Cf. ma réponse du moment, je ne rebondis que sur deux petits points.
Ah, et je bosse dans une grosse boite de semiconducteurs, un secteur ultra-polluant dont la survie dépend beaucoup de la surconsommation (changer de portable tous les ans, de PC tous les 2 ans, de voiture tous les 5ans au moins, etc.).
Je ne connais pas les détails de ton métier, mais il me semble que la montée en performance, et la baisse des coûts, sur les équipements électroniques a constitué un progrès notable du demi-siècle dernier. Comme toute forme de changement elle a des avantages et des inconvénients (pollution, réduction des effectifs dans des boîtes qui font des gains de productivité…), mais il ne me semble pas qu'on puisse dire facilement que ce que tu fais, c'est clairement nuisible. À moins bien sûr que ton poste ce soit par exemple "faire activement de la désinformation sur la pollution de notre industrie" ou "faire du lobbying pour faire passer des lois exonérant notre industrie des taxes sur la pollution".
Encore une fois, c'est à toi de juger si tu estimes que ton boulot pose problème ou pas.
(Par ailleurs si tu veux en changer, je te conseille de regarder pour le télé-travail. Ça se fait de plus en plus en info, pas trop en France je crois, mais comme tu as l'air expatrié…)
"Moi je bosse sur un système qui détecte des mots-clés dans un flux d'information. On peut l'utiliser pour la lutte contre le terrorisme, pour la lutte contre le piratage. Ah j'ai appris qu'un de nos clients s'en sert aussi pour faire du contrôle politique."
Je me pose une question bien concrète : concrètement, ces logiciels ont été déployé combien de fois pour soutenir une dictature, et combien de fois pour lutter contre le piratage, le terrorisme ou (oui oui, je devine) la pédopornographie ? Je sais que ça pourrait arriver avec les législations qui se trament (bien aidée, j'imagine, par les branches lobbying des-dites entreprises), mais aujourd'hui où en est la situation ?
Une rapide recherche sur Google me dit que, dans le cas de Bull/Lybie, le service a aussi été vendu à des services d'espionnage français; on juge comme on veut, ça ne me paraît pas nécessairement criticable en soit (enfin il y a des gens à qui ça pose problème de travailler pour l'armée, d'autres non), ça ne me paraît pas non plus assez pour se dire "ouf en fait le système que je développer a aussi des effets très positifs dans le monde". Je suis preneur d'exemples de ce genre.
(J'ai entendu parler d'applications potentielles pour la sécurité informatique à l'intérieur d'une entreprise, je me demande quelle est la taille du marché pour ce secteur.)
Tu ne t'adresses pas à moi, mais je crois avoir (partiellement) répondu à la question laissée en suspens dans ce post:
Fais un boulot qui te plaît, qui te permet d'être heureux, et qui n'a pas pour finalité de nuire à autrui. Si tout le monde faisait ça nous serions dans un monde meilleur; et il me semble normal d'attendre ça des autres (même si la loi ne les y force pas).
Bien sûr ça ne suffit pas, il n'y a pas de recette miracle, tu peux nuire (ou profiter) aux autres dans d'autres circonstances que ton boulot, etc etc.; mais il y a des règles simples qui permettent d'éviter un certain nombre de chose. Et je ne parle même pas de les imposer aux autres, mais d'essayer de s'y tenir soi-même, et pourquoi pas de leur en parler.
Ce que tu cites constitue de bonnes raisons de rester, mais les nouvelles comme celle-ci sur LinuxFR sont des raisons de partir (et c'est pour ça à mon avis qu'elles peuvent jouer un rôle positif et ne se résument pas, comme le dit maclag, à un concert de vierges effarouchées). C'est peut-être justement l'occasion d'arrêter de faire comme s'il n'y avait pas de problème.
Je me permets de rajouter quelque chose : la vraie responsabilité, ce n'est pas le technicien ou l'ingénieur de FT qui la porte, à moins de mettre un zèle fou dans son travail. Les personnes vraiment responsables, vraiment coupables, ce sont celles qui sont dans le top20 de l'entreprise, celles qui touchent ton salaire annuel en un mois en justifiant cela par leurs responsabilités (alors que généralement, elles ne risquent rien du tout). Pour faire une analogie, dans l'armée, c'est le gars derrière la mitrailleuse qui te tue, mais pourtant, même s'il est sûrement un peu coupable, ce n'est qu'un exécutant. Le vrai responsable, c'est son général, le ministre de la défense, le chef de l'état qui ont décidé de cette guerre.
Ça me semble un peu trop simple comme manière de trancher une question vraiment complexe. Je ne suis pas expert en morale, étique, droit pénal ou droit des entreprises, et je pense qu'il y a plusieurs façons de traiter la question. Je me contenterai de dire que, plutôt que de chercher à désigner (et punir ?) un "vrai responsable", je pense plutôt qu'il s'agit d'un ensemble de gens qui ont participé à des degrés divers, et qui ont selon moi chacun une part de responsabilité ("vraie" ou non, ce n'est pas la question). Intuitivement j'aurais tendance à juger la participation de chacun selon sa finalité pour la réalisation du tout (le personnel de cantine du bâtiment qui développe ce soft a une part de responsabilité, mais très très indirecte (surtout s'ils ne savaient rien), l'ingénieur qui rajoute une fonctionnalité imprévue demandée par les Éthipiopiens est nettement plus impliqué, tout comme la personne qui a collé des adresses mails d'opposants Lybiens dans les documents de présentation/vente de Eagle). Mais après, c'est à chaque personne de réfléchir au rôle qu'elle a joué dans la machine, les bonnes et les mauvaises raisons de le faire, ce qu'il en pense et ce qu'il choisit de faire à l'avenir.
Mais après, chacun est adulte, chacun assume ses choix en connaissance de cause. Ce n'est pas de la rhétorique, chacun place le curseur du « tant pis » au « très grave » là où il veut. Peut-être que le mec qui code des outils de filtrage te dirait que t'es vraiment un pourri parce que tu pollues et tu détruits la planète avec ton transport et ta manière de consommer.
Je suis tout à fait d'accord avec ça, ça va dans le sens de ce que je dis : chacun fait des choix selon de nombreux paramètres et attache des importances différentes aux mêmes aspects. L'importance est de comprendre qu'il n'y a pas un seul critère à optimiser à tout prix.
Quant à la responsabilité plus directe, le gars qui travaille chez FT te dirait que c'est son commercial qui a signé le contrat et pas lui ; lui il aurait préféré développer des logiciels de gestion de vélos pour les Néerlandais.
Bien sûr, ce ne sont sans doute pas les techniciens/ingénieurs qui ont fait les choix de où et comment commercialiser (même s'ils doivent bien se douter que leur techno va majoritairement avoir des applications pour le moins discutables). Par contre, s'il préfère développer des logiciels de gestion de vélos, pourquoi ne va-t-il pas le faire ? Les gens qui développent du DPI sont bons techniquement, ils ont le niveau de compétence pour trouver facilement du boulot dans une autre boîte. Je suis sûr qu'il y a des néerlandais qui gèrent des vélos et qui embauchent.
(Dans le genre de boîtes qui embauchent et qui ont certainement des conditions de travail agréables, Google a ouvert un centre à Paris. Après on peut se demander si on a envie de bosser pour une boîte financée par la publicité en ligne, il y a des gens qui n'aiment pas, mais quand on vient d'une section d'aide aux dictatures la situation morale/éthique ne peut que s'améliorer, ou presque.)
[^] # Re: La politique de sécurité est bonne
Posté par gasche . En réponse à la dépêche Bref, MPlayerX quitte le Mac App Store. Évalué à 6.
La réponse est dans la question ! Si la sécurité est trop difficile à mettre en place, gérer ou comprendre, elle n'est pas efficace. Je ne jette pas la pierre à SELinux, c'est un problème extrêmement difficile.
Un petit point méthodologico-philosophique : j'ai tendance à avoir plus d'espoir en les approches où c'est le développeur lui-même qui choisit la politique de sécurité de son application, et pas un administrateur qui après coup ajoute une politique MAC par dessus l'application. Enfin je pense que les deux sont complémentaires (le développeur devrait faire des efforts pour minimiser les droits dont l'application a besoin, et l'administrateur peut ensuite retirer ce qu'il trouve inacceptable au risque de priver l'utilisateur de certaines fonctionnalités), mais que le gros du travail doit venir du programme lui-même, qui décide d'abandonner ses droits; aujourd'hui avec des outils comme SELinux ou AppArmor c'est tout fait de façon externe, et à mon avis c'est un déséquilibre regrettable.
Sauf que si tu installes une application "remember pass" qui fait des exercices de mémoire pour que tu retiennes tes mots de passe que tu as peur d'oublier, et une application "SMS du ventre" qui texte automatiquement où tu vas au restaurant, et que les deux peuvent communiquer ensemble en écrivant dans le système de fichier, un pirate peut obtenir tes mots de passe par SMS sans que tu aies jamais validé à la fois les deux "lit le keyring" et "envoie des SMS" pour une seule application.
Des chercheurs en sécurité avaient trouvé comment transférer de l'information entre deux applications malicieuses en leur faisant manipuler le système silencieux/vibreur pour communiquer, ou le niveau de luminosité de l'écran. Ce genre de techniques expose le besoin d'une approche ambitieuse de la sécurité, qui essaie de prendre le plus de chose possible en compte et de minimiser au maximum les droits de chaque agent. Je ne pense pas qu'on puisse dire aujourd'hui que la sécurité des smartphones (encore moins des ordinateurs desktop) est "suffisante".
[^] # Re: La politique de sécurité est bonne
Posté par gasche . En réponse à la dépêche Bref, MPlayerX quitte le Mac App Store. Évalué à 5.
On connaît les techniques pour concevoir des systèmes sécurisés qui répondent à ce genre de problématiques. Une façon de faire par exemple est de donner à l'application, au moment du transfert du descripteur de fichier, un marqueur dont la sémantique est "j'ai le droit d'ouvrir ce fichier" (par exemple on peut imaginer que le fichier est chiffré par défaut sur le disque, et que le marqueur est la clé de chiffrement). Si l'application a obtenu le marqueur dans le passé, elle a le droit de s'en resservir ensuite pour rouvrir le fichier sans demander l'autorisation (ça sera indiqué au moment de l'ouverture à l'utilisateur par un message du style "l'application demande le droit de le réouvrir les prochaines fois", ou éventuellement une case cochable pour refuser ce droit). Elle est libre de stocker ce marqueur dans un fichier persistant (la playlist, la "liste de référence" de ton format pro, etc.) ou même de le communiquer aux sous-applications qu'elle appelle en arrière-plan (indistinguable de l'application du point de vue de l'utilisateur).
C'est encore mieux s'il y a possibilité de montrer à l'utilisateur quels "droits permanents" ont été accordés de la sorte et lui donner la possibilité de les révoquer (en fait non mon lecteur Mp3 a l'air buggué, je ne lui fait plus confiance). Ça commence à demander une conception très soigneuse du système de sécurité.
Pour revenir à la playlist MP3, l'idée est donc que tu peux ajouter des fichiers dans la playlist en utilisant un logiciel (pas forcement le lecteur audio, un utilitaire en ligne de commande peut le faire) qui demande un accès persistant au fichier (le système peut donc avertir l'utilisateur) et met le marqueur obtenu dans la la playlist.
Si demain tu viens avec un besoin encore plus sophistiqué qui n'est pas exprimable en l'état du système de sécurité, tu dois demander à faire tourner ton programme (ou au moins les parties qui ont ce besoin) en mode plus privilégié, en attendant que le système essaie de mieux comprendre ton besoin et de l'exprimer de façon plus sécurisée. Aujourd'hui on met tout en mode "privilège utilisateurs totaux" par défaut, donc c'est cette solution qu'on utilise.
[^] # Re: La politique de sécurité est bonne
Posté par gasche . En réponse à la dépêche Bref, MPlayerX quitte le Mac App Store. Évalué à 9.
Je détaille un peu plus : il existe de nombreuses projets qui vont dans cette direction, mais ils se concentrent souvent sur le champ de sécurité entre les droits utilisateurs (considérés "privilèges minimums") et les droits administrateurs. Tout ce qui va dans le sens par exemple d'autoriser un équivalent de "sudo" mais seulement sur certaines commandes bien choisies, PolicyKit étant un bon exemple de cette tendance.
À mon avis il y a déjà beaucoup à faire sur les droits de l'utilisateur. Quand on y pense les informations les plus précises qu'on a sur son ordinateur sont nos données personnelles, qui sont en général lues, éditées et parcourues par des applications tournant en droit utilisateur (et donc, dans le modèle actuel, que chacune des applications que je lance peut observer et modifier à mon insu). Alors certaines applications (Google Chrome par exemple) font des efforts pour faire tourner les parties les plus critiques sans aucun droit du tout, mais en réalité il y a une vaste jungle de droits intermédiaires (comme de pouvoir créer des répertoires temporaires locaux et y faire ce qu'on veut) qu'on pourrait contrôler.
Pour cela il faut des bonnes pratiques de compartementalisation des droits. Dans l'extrême majorité des cas, une application n'a aucun besoin de l'accès à tout mon $HOME, elle peut se contenter de lire seulement les fichiers que je lui donne (par l'intermédiaire d'un démon privilégié) et un répertoire de configuration/cache/stockage local qu'elle est la seule à pouvoir manipuler. Le problème est qu'aujourd'hui on conçoit des applications comme si elles devaient tout faire elles-mêmes, y compris implémenter le dialogue "ouvrir un fichier …", et à cause de cette erreur de conception on est forcé de lui donner beaucoup plus de droit que nécessaire, ce qui nuit à la sécurité.
Pour ça il n'y a pas de mystère, il faut que les mentalités changent et que les développeurs paient plus d'importance à ce genre d'aspects. Si le monde mobile les force à respecter de bonnes pratiques dans ce domaine, ce sera une bonne chose—même si je trouve dommage que l'innovation (voire le couteau sous la gorge) vienne de systèmes fermés (Apple) ou au développement fermé (Android). Mais bon c'est comme partout, "those who do the work decide".
# La politique de sécurité est bonne
Posté par gasche . En réponse à la dépêche Bref, MPlayerX quitte le Mac App Store. Évalué à 10.
Empêcher de lire des fichiers qui n'ont pas été sélectionnés par l'utilisateur est une excellente idée qui permettra de sécuriser les applications. Je comprends que le développeur ne veuille pas fournir les efforts nécessaires (en travail supplémentaire pour adapter son code ou au moins abandonner les features) pour respecter ce critère. Mais alors que la dépêche sous-entend que cette restriction est abusive, je pense qu'elle est au contraire adaptée et utile. Je suis un des premiers à critiquer Apple sur sa fermeture, mais dans la situation telle qu'elle est exposée ici je leur donne totalement raison.
Plus précisément: l'intérêt de cette restriction est de pouvoir interdire aux programmes de lire le système de fichier. Quand ils veulent ouvrir un fichier, ils appellent un widget système (à travers une API système) qui va interagir avec l'utilisateur, lui proposer de naviguer dans ses fichiers et d'en choisir un, ouvrir ce fichier (dans le mode demandé par l'application, lecture seule ou lecture+écriture) et renvoyer le descripteur à l'application. Tout l'intérêt tient dans le fait que le widget système peut être un processus différent qui tourne avec plus de privilèges, et qui est le seul à avoir ces droits sur le système de fichier.
Du coup, même si l'application est malicieuse ou bugguée (faille d'injection de code par exemple), comme elle n'a pas accès au système de fichier sa surface d'attaque du système est considérablement réduite (pas possible d'aller chercher les mots de passe stockés en clair dans
~/.config, d'aller écrire en douce dans le fichier de conf d'une autre application pour dire à la webcam de rediriger son flux vers un site pirate louche, de monter une "access race" sur les fichiers temporaires d'une troisième application, etc.). La quantité de code privilégié (trusted computing base) a fortement réduit, il suffit d'auditer le widget système pour vérifier qu'il est solide, au lieu de toutes les applications qui tournent avec les droits utilisateurs.De plus, cette façon de forcer les accès privilégiés de l'application à passer par une couche de médiation liée à l'interface utilisateur permet de mettre en place de bonnes pratiques à la frontière entre sécurité et interaction. L'application ne peut pas par exemple mentir à l'utilisateur en lui demandant de lui désigner un fichier pour le lire, alors qu'elle compte en fait écrire dedans (corruption accidentelle ou malicieuse): c'est le widget système qui interagit avec l'utilisateur et a toutes les informations en main pour lui annoncer clairement et honnêtement quels droits on lui demande de fournir à l'application (elle veut le fichier en écriture). Cette façon de s'assurer que les informations montrées à l'utilisateur (donc son image mentale de la sécurité de son système) correspondent bien à la réalité renforce la sécurité.
J'invite les gens intéressés par ces considérations à regarder l'article "User Interaction Design for Secure Systems", de Ka-Ping Yee, 2002, que j'ai présenté dans ce billet. Il donne dix principes fondamentaux de l'interface sécurisée, le plus pertinent ici étant "Explicit Authority": "A user’s authorities must only be provided to other actors as a result of an explicit action that is understood by the user to imply granting."
Alors bien sûr, forcer ces restrictions au niveau d'un système entier restreint les possibilités (c'est la contrepartie à payer pour augmenter la sécurité : si on autorise tout ce qui était possible avant, on autorise toujours les attaques, donc on n'est pas plus sécurisé). Il faut travailler pour mitiger ces problèmes, et c'est là qu'il est peut-être possible de critiquer Apple :
Certaines applications (ici le "widget système de droit de fichier") ont par nature besoin de privilèges supérieurs; on va avoir plusieurs couches de droits, et dans un système libre on veut évidemment pouvoir avoir la possibilité d'exécuter, lire, comprendre et modifier les applications à tous ces niveaux de droit (sachant évidemment qu'exécuter des applications privilégiées va demander plus de droit, des confirmations à l'utilisateur, etc.). Si Apple force tous les app writers à se contenter du niveau le plus bas, et se réserve la possibilité d'écrire des applications privilégiées, et bien on peut faire moins de chose avec la plateforme et c'est dommage. Dans un système libre on voudrait pouvoir soumettre des applications à tous les niveau (mais en comprenant que le coût d'audit est d'autant plus élevé).
Il faut être prêt à faire évoluer des APIs un peu trop restrictives pour permettre des usages plus riches. Par exemple la fonctionnalité de "recherche automatique de sous-titre" pourrait être accommodée en ajoutant un appel système pour sélectionner non pas un fichier, mais un répertoire entier dans lequel le logiciel aurait le droit de lire tous les fichiers, donc les films et les sous-titres associés. Il faut comprendre que cet appel donne un peu plus de droits, et il faut que l'utilisateur le comprenne aussi, mais c'est un bon compromis entre "lire potentiellement tout son $HOME" et devoir choisir fichier-par-fichier. Je n'y connais rien, mais peut-être qu'Apple ne fait pas assez d'efforts pour faire évoluer ses APIs dans ce sens. Mais il faut aussi comprendre que toute modification des APIs donnant accès à ces privilèges demande un effort de conception et d'audit important, peut compliquer l'interface utilisateur ou le modèle de sécurité, etc.
Pour résumer, je ne plains pas trop le développeur et je trouve la démarche technique d'Apple intéressante. J'aimerais bien que ma distribution Linux évolue elle aussi vers des modèles de sécurité plus fins que l'antique user/group/owner, sans être non plus complètement inutilisable. Capsicum va dans la bonne direction, mais il faut un effort des projets/frameworks/etc. entre le kernel et l'utilisateur pour intégrer ces principes de conception sécurisée.
# Pourquoi changer ?
Posté par gasche . En réponse à la dépêche Akiban compte séduire les utilisateurs de MySQL avec une base de données Open Source. Évalué à 7.
Quels sont les avantages de cette base de donnée par rapport à MySQL/MariaDB ou PostGreSQL ?
[^] # Re: Quels sont les problèmes, concrètement ?
Posté par gasche . En réponse à la dépêche RMLL 2012 : LinuxFr.org, les réussites, les problèmes et les pistes d'amélioration. Évalué à 4.
"Vous", c'est en fait l'ensemble des membres du site, ou en tout cas des gens qui s'identifient comme jouant un rôle important sur le site, s'y étant investis, et étant donc à même de pouvoir influer sur son identité. C'est un peu le même "vous" qui décide de faire des présentations aux RMLL sur LinuxFR (si ce "vous" n'existait pas, quelle serait leur légitimité ?), mais ça désigne plus de gens que seulement l'équipe de modération.
Ma position externe est la position d'un type qui n'a pas le temps de s'investir autant dans le site que toi ou les autres participants à la discussion, et qui est en train de se demander si ça vaut le coup pour lui d'y envoyer quand même du contenu qu'il juge intéressant. Est-ce que c'est un site que j'ai envie de soutenir et avec lequel l'interaction peut m'apporter quelque chose, ou est-ce que c'est en fait définitivement un repère de gens désagréables dans lequel je ne me sentirai jamais bien et qu'il vaut mieux que j'oublie de ma carte mentale d'internet ?
Les changements que je compte faire c'est, si j'ai l'impression que ça vaut le coup de persister sur LinuxFR, ben apporter un peu de contenu et influer un peu sur le comportement des gens en râlant quand je les trouve incorrects. Mais pour ça il faut que je m'assure que le fait de râler de la sorte est considéré par une bonne chose, et que ce n'est pas au contraire moi qui serait un casse-pieds externe en m'opposant à des usages reconnus et acceptés sur le site. Comme de toute façon je n'ai pas le temps de participer beaucoup, ce n'est certainement pas de moi que viendront d'éventuels effets positifs durables sur le long terme, mais de membres plus impliqués.
Tu parles de remettre en place les personnes ayant un mauvais comportement, mais comment savoir quels sont les comportements considérés comme mauvais ? À ma connaissance le "vous" ayant une légitimité sur le site n'a jamais pris de position sur ce qui est bien ou mauvais sur LinuxFR (y a-t-il une charte de comportement quelque part ?), et je ne me souviens pas particulièrement avoir vu des gens faire des reproches policés aux gens agressifs, rudes ou de mauvaise foi. Tout ce qu'il y a c'est un fil pour dire ici "il y a des problèmes", mais sans vouloir dire vraiment de quels problèmes il s'agit, à part une obscure histoire de tribune automatisant les comptes sexistes moinssés par une cabale secrète, dont je n'ai absolument rien à cirer.
À mon avis pour que la position évolue dans un sens raisonnable il faudrait qu'il y ait un relatif consensus, et une prise de position claire, sur la question suivante : "Quels sont les comportements raisonnables et désirés sur LinuxFR ?". Ce fil ou votre intervention à la RMLL aurait pu constituer une réponse à cette question, mais ce n'est clairement pas le cas pour l'instant—ou alors il faut m'expliquer plus clairement.
Si je me contentais d'essayer d'inférer une réponse en fonction des façons de discuter que j'observe réellement sur le terrain, j'obtiendrais un truc du genre (bon ok, je force un peu la dose pour l'exemple) "être un pédant agressif de mauvaise foi qui fait dérailler toute conversation, quelque soit son sujet, pour la ramener vers son troll de prédilection du moment (en évitant toutefois les insultes, blagues sexistes ou racistes et autres délits)". Et alors je peux facilement répondre à ta question "pourquoi est-ce que tu ne fais rien pour responsabiliser les gens pour qu'ils respectent ce comportement?": parce qu'il n'y a rien à faire, on est déjà en plein dedans. Content ou pas content ?
[^] # Re: Quels sont les problèmes, concrètement ?
Posté par gasche . En réponse à la dépêche RMLL 2012 : LinuxFr.org, les réussites, les problèmes et les pistes d'amélioration. Évalué à 2.
Il est là, le problème que je vois moi. Comment avez-vous fait pour construire un groupe qui exhibe aussi fortement de tels comportements ? Qu'il y ait une fois tous les deux ans des propos négationnistes tenu dans un sous-canal de discussion spécifique tard le soir, c'est quelque chose qui peut arriver partout. Mais il y a des communautés où la norme n'est pas d'être virulent, agressif ou de mauvaise foi, et qui évitent ce genre de comportement. Quelle est la différence avec LinuxFR? Est-elle voulue, subie ? Avez-vous l'intention de faire des changements pour faire évoluer cette situation ?
# Et la reconnaissance de la source ?
Posté par gasche . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 7.
Je me suis posé des questions de ce genre pour un blog perso auto-administré : est-ce que je mets un lien vers les images sur le serveur externe, ou est-ce que je les copie en local ?
Un aspect qui n'a pas été abordé dans cette dépêche est celui de la reconnaissance de la source : est-il toujours possible pour le visiteur de LinuxFR de savoir d'où vient l'image en question ? Que pensent les distributeurs de cette image de l'idée que vous les copiiez en local au lieu de leur envoyer du trafic ? Si le contenu est soumis aux droits d'auteurs (par exemple je donne un lien vers une belle photographie ou une bande dessinée amusante), quel est le statut de cette copie ?
Dans le cas de mon petit site, à faible traffic, j'ai jugé que ces problématiques éclipsaient largement les économie en bande passante pour le destinataire ou les problématiques de pérennité, et j'ai laissé les URLs vers des images distantes. Le bon choix pour LinuxFR est sans doute différent, mais je me demande quand même ce que vous en pensez.
[^] # Re: Quels sont les problèmes, concrètement ?
Posté par gasche . En réponse à la dépêche RMLL 2012 : LinuxFr.org, les réussites, les problèmes et les pistes d'amélioration. Évalué à 2.
Donc en gros le "problème" mystérieusement évoqué dans ces slides, c'est des débordements dans la tribune ? Moi je n'en ai rien à cirer, je n'y vais pas (pas le temps), donc je ne me sens pas trop concerné (il y a un journal à son sujet de temps en temps, on l'ignore et voilà, problème réglé). Tant mieux si c'est convivial, on y boit des bières, et tant pis si les gens y volent des bébés pandas.
Je croyais que c'était lié à des commentaires sur le site.
[^] # Re: Quels sont les problèmes, concrètement ?
Posté par gasche . En réponse à la dépêche RMLL 2012 : LinuxFr.org, les réussites, les problèmes et les pistes d'amélioration. Évalué à 6.
Je ne demande pas spécialement à avoir des noms, c'est juste que les transparents parlent plusieurs fois de "problèmes" et que je ne comprends pas de quoi vous voulez parler, ce qui me paraît un peu curieux. De quels problèmes s'agit-il ?
# Quels sont les problèmes, concrètement ?
Posté par gasche . En réponse à la dépêche RMLL 2012 : LinuxFr.org, les réussites, les problèmes et les pistes d'amélioration. Évalué à 5. Dernière modification le 12 juillet 2012 à 11:18.
Les slides évoquent beaucoup de "pistes d'améliorations" et de "problèmes", et on comprend que c'est lié à la "modération", mais je n'ai trouvé aucun point précis sur ce qui vous posait problème, les cas qui se sont réellement produits, etc. J'imagine que ça a été dit oralement (ou alors tout le monde comprend la référence vague à "un événement en particulier au début de l'année" ? moi pas en tout cas), mais je serais intéressé par des détails pour comprendre ce dont vous parlez réellement.
Sur un point de vue tout à fait personnel, je ne suis pas satisfait de la communauté LinuxFR. J'ai découvert pendant la discussion sur l'édition des messages, mais aussi à d'autres reprises récemment, qu'une partie significative des membres ont une vision agressive voire violente de la façon dont on discute (où la mauvaise foi et les critiques sur la forme plutôt que le fond sont partout). Je ne suis pas à l'aise dans ce cadre, et c'est ce que je connais qui ressemble le plus à ce que des gens décrivent comme "les communautés pas accueillantes" (les autres sites, listes de discussion etc. que je fréquente sont plus agréables pour moi). En lisant l'annonce de votre intervention, je me suis demandé si c'était lié à ce dont vous alliez parler, et je m'attendais à trouver plus d'information me permettant de le savoir dans votre retour, mais ce n'est pas le cas. Vous pourriez en fait parler de tout à fait autre chose, voire même considérer que ce sont des comportements tels que le mien (des gens extérieurs au noyau dur de la communauté qui font des réclamations et ont des comportements qui ne font pas partie des traditions locales) qui posent problème !
[^] # Re: gmail
Posté par gasche . En réponse au journal Été meurtrier chez Mozilla. Évalué à 4. Dernière modification le 10 juillet 2012 à 14:23.
Mais si un pervers de chez Google reluque mes mails:
Si je dis qu'ils ont une charte de respect de la vie privée, c'est parce qu'une violation de cette charte, une fois rendue public, causerait beaucoup de tort à l'image de Google (il suffit de voir comment Facebook se fait attaquer par ses concurrents là-dessus). Donc ils n'ont pas du tout intérêt à ce que ça arrive, et donc ils ont intérêt à ce qu'aucune violation ne soit observable de l'extérieur. En pratique ça veut dire qu'il ne se passe rien qui me concerne et qui puisse être expliqué par la lecture de mes mails; ça me va.
C'est toute la différence avec le fait de donner ton mot de passe explicit aux gens de LinuxFR, qui n'ont jamais promis de ne pas faire de conneries avec, et donc une bonne partie serait suffisamment stupide pour effectivement faire des conneries avec, causant du tort à toi et à eux en même temps.
Tout ce que je dis est relativement évident et aurait pu être inféré à la lecture de mon message. Malheureusement:
Beaucoup de bruit pour rien. Au moins ta remarque a l'air de bonne foi.
[^] # Re: gmail
Posté par gasche . En réponse au journal Été meurtrier chez Mozilla. Évalué à 4.
Je ne vois pas le rapport. Google utilise des filtres automatisés pour miner des informations des messages, ce n'est pas comparable à une inspection personnelle par des pervers de LinuxFR. Je ne dis pas que c'est génial de stocker ses mails sur un serveur appartenant à autrui, mais il n'empêche que ton argument est mauvais. D'ailleurs Google a une charte de respect de la vie privée.
[^] # Re: Ils sont au bord de la banqueroute ?
Posté par gasche . En réponse au journal Été meurtrier chez Mozilla. Évalué à 3.
Oui, il y a des personnes externes; j'ai un collègue qui contribue un peu à Thunderbird, alors qu'il n'est pas chez Mozilla. Il parle de temps en temps du développement et ça m'a l'air tout à fait ouvert. En plus, le système d'extensions permet aux gens de développer des fonctionnalités sans même passer par le code du logiciel.
[^] # Re: LinuxFR et les trolls aussi improbables que sans intérêt
Posté par gasche . En réponse au journal Declaration of Internet Freedom. Évalué à 3.
Effectivement, je n'avais pas pensé à la situation de cette façon, mais c'est une explication plausible à la dérive du sujet. Merci.
# LinuxFR et les trolls aussi improbables que sans intérêt
Posté par gasche . En réponse au journal Declaration of Internet Freedom. Évalué à 5.
Je crée un journal sur un appel à l'"expression, accès, ouverture, innovation et vie privée" sur internet, qui génère une longue discussion…. sur l'endroit où citer les mails précédents dans une conversation. Merci tout le monde !
[^] # Re: Partagé
Posté par gasche . En réponse au journal Declaration of Internet Freedom. Évalué à 10.
Oui, ou du Mister Geek, un peu plus dodu et avec une barbe : "je veux la liberté de redistribuer ce programme à mes voisins", tout ça.
# Deux liens intéressants
Posté par gasche . En réponse à la dépêche Sortie de IPython 0.13. Évalué à 4.
Je me suis demandé en lisant cette dépêche quel était le lien avec le notebook du projet Sage (un logiciel de calcul formel en Python). On peut trouver la réponse dans un billet très intéressant de l'auteur de IPython:
The IPython notebook: a historical retrospective
Il y a aussi une intégration de IPython dans Emacs qui fait assez envie: Emacs IPython Notebook. En particulier, voici les captures d'écran.
[^] # Re: Encore une fois...
Posté par gasche . En réponse à la dépêche Nouvelles technologies à l’assaut de la démocratie éthiopienne. Évalué à 2.
Tu as des sources sur cette utilisation d'Eagle par la police française, dans un cadre contrôlé par un juge ? Ça m'intéresse. L'article que j'ai mis en lien n'en parle absolument pas (il mentionne seulement des commandes obscur(ci)es du ministère de l'intérieur, qui n'a visiblement pas voulu répondre aux questions des journalistes à ce sujet).
[^] # Re: void et les templates?
Posté par gasche . En réponse à la dépêche Le langage D. Évalué à 2.
Pour le plaisir, l'équivalent OCaml:
[^] # Re: Y'a-t-il encore besoin de nouveaux langages "bas niveau"?
Posté par gasche . En réponse à la dépêche Le langage D. Évalué à 1.
Ce n'est pas possible en général (l'ordre dépend de la sémantique de la structure; le cas d'école étant les arbres balancés qui ne sont pas "canoniques", ie. deux arbres à la structure différente peuvent en fait représenter le même ensemble (balancé différemment), donc tu veux que la comparaison les considère comme égaux).
[^] # Re: Encore une fois...
Posté par gasche . En réponse à la dépêche Nouvelles technologies à l’assaut de la démocratie éthiopienne. Évalué à 2. Dernière modification le 13 juin 2012 à 07:22.
Tu répètes essentiellement des choses que tu as déjà dites. Cf. ma réponse du moment, je ne rebondis que sur deux petits points.
Je ne connais pas les détails de ton métier, mais il me semble que la montée en performance, et la baisse des coûts, sur les équipements électroniques a constitué un progrès notable du demi-siècle dernier. Comme toute forme de changement elle a des avantages et des inconvénients (pollution, réduction des effectifs dans des boîtes qui font des gains de productivité…), mais il ne me semble pas qu'on puisse dire facilement que ce que tu fais, c'est clairement nuisible. À moins bien sûr que ton poste ce soit par exemple "faire activement de la désinformation sur la pollution de notre industrie" ou "faire du lobbying pour faire passer des lois exonérant notre industrie des taxes sur la pollution".
Encore une fois, c'est à toi de juger si tu estimes que ton boulot pose problème ou pas.
(Par ailleurs si tu veux en changer, je te conseille de regarder pour le télé-travail. Ça se fait de plus en plus en info, pas trop en France je crois, mais comme tu as l'air expatrié…)
Je me pose une question bien concrète : concrètement, ces logiciels ont été déployé combien de fois pour soutenir une dictature, et combien de fois pour lutter contre le piratage, le terrorisme ou (oui oui, je devine) la pédopornographie ? Je sais que ça pourrait arriver avec les législations qui se trament (bien aidée, j'imagine, par les branches lobbying des-dites entreprises), mais aujourd'hui où en est la situation ?
Une rapide recherche sur Google me dit que, dans le cas de Bull/Lybie, le service a aussi été vendu à des services d'espionnage français; on juge comme on veut, ça ne me paraît pas nécessairement criticable en soit (enfin il y a des gens à qui ça pose problème de travailler pour l'armée, d'autres non), ça ne me paraît pas non plus assez pour se dire "ouf en fait le système que je développer a aussi des effets très positifs dans le monde". Je suis preneur d'exemples de ce genre.
(J'ai entendu parler d'applications potentielles pour la sécurité informatique à l'intérieur d'une entreprise, je me demande quelle est la taille du marché pour ce secteur.)
[^] # Re: Encore une fois...
Posté par gasche . En réponse à la dépêche Nouvelles technologies à l’assaut de la démocratie éthiopienne. Évalué à 2.
Tu ne t'adresses pas à moi, mais je crois avoir (partiellement) répondu à la question laissée en suspens dans ce post:
Bien sûr ça ne suffit pas, il n'y a pas de recette miracle, tu peux nuire (ou profiter) aux autres dans d'autres circonstances que ton boulot, etc etc.; mais il y a des règles simples qui permettent d'éviter un certain nombre de chose. Et je ne parle même pas de les imposer aux autres, mais d'essayer de s'y tenir soi-même, et pourquoi pas de leur en parler.
[^] # Re: Encore une fois...
Posté par gasche . En réponse à la dépêche Nouvelles technologies à l’assaut de la démocratie éthiopienne. Évalué à 3.
Ce que tu cites constitue de bonnes raisons de rester, mais les nouvelles comme celle-ci sur LinuxFR sont des raisons de partir (et c'est pour ça à mon avis qu'elles peuvent jouer un rôle positif et ne se résument pas, comme le dit maclag, à un concert de vierges effarouchées). C'est peut-être justement l'occasion d'arrêter de faire comme s'il n'y avait pas de problème.
Ça me semble un peu trop simple comme manière de trancher une question vraiment complexe. Je ne suis pas expert en morale, étique, droit pénal ou droit des entreprises, et je pense qu'il y a plusieurs façons de traiter la question. Je me contenterai de dire que, plutôt que de chercher à désigner (et punir ?) un "vrai responsable", je pense plutôt qu'il s'agit d'un ensemble de gens qui ont participé à des degrés divers, et qui ont selon moi chacun une part de responsabilité ("vraie" ou non, ce n'est pas la question). Intuitivement j'aurais tendance à juger la participation de chacun selon sa finalité pour la réalisation du tout (le personnel de cantine du bâtiment qui développe ce soft a une part de responsabilité, mais très très indirecte (surtout s'ils ne savaient rien), l'ingénieur qui rajoute une fonctionnalité imprévue demandée par les Éthipiopiens est nettement plus impliqué, tout comme la personne qui a collé des adresses mails d'opposants Lybiens dans les documents de présentation/vente de Eagle). Mais après, c'est à chaque personne de réfléchir au rôle qu'elle a joué dans la machine, les bonnes et les mauvaises raisons de le faire, ce qu'il en pense et ce qu'il choisit de faire à l'avenir.
[^] # Re: Encore une fois...
Posté par gasche . En réponse à la dépêche Nouvelles technologies à l’assaut de la démocratie éthiopienne. Évalué à 3.
Je suis tout à fait d'accord avec ça, ça va dans le sens de ce que je dis : chacun fait des choix selon de nombreux paramètres et attache des importances différentes aux mêmes aspects. L'importance est de comprendre qu'il n'y a pas un seul critère à optimiser à tout prix.
Bien sûr, ce ne sont sans doute pas les techniciens/ingénieurs qui ont fait les choix de où et comment commercialiser (même s'ils doivent bien se douter que leur techno va majoritairement avoir des applications pour le moins discutables). Par contre, s'il préfère développer des logiciels de gestion de vélos, pourquoi ne va-t-il pas le faire ? Les gens qui développent du DPI sont bons techniquement, ils ont le niveau de compétence pour trouver facilement du boulot dans une autre boîte. Je suis sûr qu'il y a des néerlandais qui gèrent des vélos et qui embauchent.
(Dans le genre de boîtes qui embauchent et qui ont certainement des conditions de travail agréables, Google a ouvert un centre à Paris. Après on peut se demander si on a envie de bosser pour une boîte financée par la publicité en ligne, il y a des gens qui n'aiment pas, mais quand on vient d'une section d'aide aux dictatures la situation morale/éthique ne peut que s'améliorer, ou presque.)