j-c_32 a écrit 1462 commentaires

Ca prend pas 3 minutes, mais c'est tres tres loin d'etre infaisable.

Et PERSONNE n'a été capable de le faire, y compris les personnes que tu cites plus loin.

Skype a ete construit de maniere specifique a etre difficile a decompiler et comprendre

Et le type qui crée une backdoor va faire en sorte que ça soit facile ? Comme je le disais: tes arguments ne marchent que si le type qui crée la backdoor est un abruti fini.

et pourtant au final des gens y sont arrives

Tiens, prenons une autre présentation du même gars, donnée 4 mois plus tôt:
https://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-biondi/bh-eu-06-biondi-up.pdf
Slide 96:
"Jams traffic, can't be distinguished from data exfiltration"
"No way to know if there is/will be a backdoor".
Merci de donner un lien d'une présentation d'un type qui confirme que tu as tort.

Croyance ? Tu m'excuseras. J'ai passe 10 ans dans le champs d'activite dont on parle ici (securite), sur l'OS dont on parle, avec les sources. Et tu veux venir m'expliquer que pendant 10 ans moi et mes collegues, dont certains sont des pontes reconnues dans l'industrie, on s'est fourvoye comme des idiots ? Un peu de serieux mon cher.

En quoi ce fait te donne-t-il la moindre légitimité sur l'évaluation de la difficulté de procédure dans un environnement dont tu ne connais pas le fonctionnement ?
Pour faire une analogie foireuse, c'est comme si tu disais: "ça fait des années que je bosse dans l'industrie des centrales au charbon, et acheter les matières premières ne pose pas de problème. Donc crois moi, l'augmentation de difficulté à acheter de l'uranium est négligeable".

Et c'est IDEM dans du code libre !

Mysql -> MariaDB, OpenSSL -> LibreSSL, GnomeShell -> Xfce pour BIEN MOINS QUE ÇA.
Tu as beau répéter ça sur tout les tons, le fait est qu'avec du libre, le code est séparé du développeur et ce n'est pas le cas avec le proprio.
C'est un fait, c'est le résultat objectif de la licence qui d'un côté dit: le code est la propriété du développeur et de lui seul, et de l'autre dit: si vous voulez, vous pouvez prendre le code et le confier à un autre développeur.

Tu montres le code assembleur ou Skype lit les favoris, les encode, et les envoie. Aussi simple que ca. C'est irrefutable, tout le monde peut des lors verifier que ce que tu dis est vrai.

Et personne n'est capable de le faire. On est capable de pointer du doigt le code qui lit les favoris (mais ce n'est pas utile, car strace suffit pour le prouver), on est capable de pointer du doigt les fonctions d'encodage et d'envoi (évidemment, vu que c'est ce que skype fait normalement pour les messages). Entre les deux, il y a 500 millions d'instructions assembleurs.

Franchement, s'il suffisait de suivre l'assembleur, comment tu expliques les difficultés pour le protocole utilisé par Skype pour être compris ? Une recherche sur "skype reverse engineering" montre que c'est très loin d'être une partie de plaisir.
Du coup, même si tu pointes la faille du doigt, il faudra des années pour montrer que ce que tu pointes du doigt est bel et bien malveillant.

Evidemment que non, si c'est un simple buffer overflow.

Sauf si le buffer overflow a été placé là exprès pour servir d'élévation de privilège pour installer un cheval de troie. C'est donc une backdoor.

Toutes tes explications ne marchent que dans le cas où le type qui met la backdoor est un abruti: une backdoor facilement visible dans l'assembleur et qui est totalement différente d'une faille.

Justement si, dans l'exemple Skype.

Biensur que non: lire l'assembleur ne permet même pas de comprendre la partie "encodage" (cela requiert une spécialisation et des années de travail), comment peux-tu ensuite prétendre qu'on puisse comprendre "encode" + "tout le reste".

qu'il est bien mieux je ne le crois pas du tout.

Exactement: c'est une question de croyance. Donc, quand quelqu'un dit "le code ouvert est bien mieux que le code fermé", tu dois lui répondre "ma croyance est différente de la tienne, donc, tu es objectivement un idiot qui n'a rien compris à l'informatique et ce que tu dis n'est que du marketing mensonger". Ce qui a le mérite de mettre en évidence que tes accusations sont parfaitement illégitimes.

Quitter Windows revient a changer totalement d'OS oui, maintenant le jour ou il y a une backdoor dans le noyau Linux (on est dans l'hypothetique toujours), j'attends de voir a quoi les forks font ressembler, a quel point il y aura incompatibilites avec l'existant au bout d'un an ou deux, etc… Tu n'as aucune assurance que les choses iront bien.

On s'en fout, c'est totalement hors-sujet: le mouvement (qu'on regrettera p-e ensuite, mais peu importe) sera lancer et ce sera suffisant pour "punir" les gens qui ont laissé entrer la backdoor -> les développeurs ont peu d'incitants pour introduire une backdoor et beaucoup d'incitant pour les combattre (y compris en démissionnant ou en faisant fuiter les infos s'ils sont forcés, car ils seront récompensés pour ça).
Comme démontré, dans un code proprio, il suffit de créer une faille intentionnelle, et si elle est découverte, les conséquences seront NULLES (à la limite, on vire 2-3 boucs émissaires qui n'étaient de toutes façons pas en position de dire quoi ce soit lorsque la backdoor a été mise).
C'est comme si tu me disais: entre une société où les voleurs sont arrêtés par la police et où les voleurs ne sont pas arrêtés, c'est pareil, parce que finalement, qui nous dit que les prisons ne vont pas couter de l'argent aux contribuables ?

J'ai déjà répondu au reste, et tu ne réponds pas aux points qui montrent que tu ne comprends pas.
Par exemple, imagine un monde parallèle où Skype EST muni d'une backdoor. Tu VOIS que Skype fouine dans les favoris du navigateur. Tu VOIS que Skype se connecte avec un serveur central et transmet des informations codées. Montres moi le code assembleur où se trouvent la faille ?
Tu ne réponds pas non plus sur ce point: je découvre une faille 0-day sur Windows. Je montre donc le code assembleur. Est-ce que ça implique que MS a collaboré avec la NSA ?

Bref, montrer le code assembleur, ÇA NE SERT STRICTEMENT À RIEN.
(à la limite, tu me montrerais le code source, ça signifierait que je peux recompiler une fois corrigé)

Pour la difficulté supplémentaire (j'imagine que c'est de ça que tu parles avec tes 5 minutes / 10 minutes), c'est bien beau de minimiser les points qui font mal à ta religion, reste que le code ouvert est forcément aussi bien et sans doute mieux que le code fermé.
J'ai pas trop envie d'essayer de te convaincre vu que ça sert à rien et que tout le monde ici a compris (j'imagine que tu vois ça comme une preuve de plus que linuxfr est un repère d’extrémistes barbus. si ça t'amuse).

Une backdoor chez Redhat profite a Redhat avec pratiquement 0 inconvenients (car meme si on la decouvre, on dira que c'est une faille et puis c'est tout, les utilisateurs ne bougeront pas pour ca)

Premièrement, l'important est que le client ait la possibilité de bouger facilement (s'il ne souhaite pas bouger, tant pis pour lui). Ce qui n'est pas possible sous Windows sans devoir repartir "from scratch". Si tu te formes pour gérer des Windows ce que tu as appris ne peut être utilisé QUE si tu utilises des outils MS. Si tu te formes pour linux, quitter Redhat ne posera aucun problème.

Ensuite, il y a plein d'exemples où l'incitant au changement était bien moins important. Par exemple le rachat de Sun par Oracle qui a fait bouger vers MariaDB et LibreOffice, ou les critiques du code, qui a créé Wayland ou LibreSSL, ou juste niveau gout avec l'abandon de certaines distributions ou environnement de bureau "parce qu'on aime pas".

LOL, mais si c'est une backdoor dans l'OS, pas besoin de powerpoint, le code est la, sur la machine de monsieur tout le monde, la verification est claire, nette et sans aucun doute !

'faudrait savoir: tu dis par ailleurs qu'on ne peut pas dire sans aucun doute qu'une backdoor n'est pas une faille.
Donc, oui, quoi que tu fasses, il restera TOUJOURS une doute en cas de backdoor.

Un morceau qui a l'air suspect ? Mais mon cher, une faille/backdoor, ca l'est ou ca ne l'est pas. C'est pas 'suspect'. Tu peux montrer comment elle est utilisee/exploiter, c'est irrefutable a ce moment la.

Windows a souvent été compromis par des virus.
Donc, en prenant une faille 0-day qui vient d'être annoncée, je peux montrer un code qui utilise cette faille.
Donc, c'est irréfutable: je viens de prouver que MS a collaboré avec la NSA.

Deja, si c'est demontre a l'aide de code decompile, nul besoin de code source, aucun contrat de viole.

Le contrat peut préciser: "à cause des préjudices graves que pourrait subir la marque en cas de découverte d'une faille, vous êtes tenu de communiquer la découverte de faille avec MS uniquement et de collaborer avec lui jusqu'à ce que la faille soit fixée" (et c'est relativement raisonnable comme condition).
Donc, pas besoin de dévoiler le code pour violer le contrat.

Quand a dire que c'est une faille, oui tout a fait, mais c'est idem sous Linux. Quand une faille critique est trouvee dans Linux, tu sais si c'est une backdoor qui avait ete inseree consciemment ou une faille innocente ? Non evidemment.

C'est ce que je me tue à te dire: la différence n'est pas dans la preuve de la backdoor ou pas, la différence, c'est qu'on peut changer de développeurs quand on perd la confiance.
L'exemple de LibreSSL est un très bon exemple: personne ne peut prouver que l'erreur dans OpenSSL n'est pas une backdoor. Mais en s'en fout. Malgré le fait que peu de gens croient que c'est le cas, ça n'empêche pas que la perte de confiance à générer des initiatives gérées différemment pour rétablir la confiance.

Tu te fous de moi. Les donnees transmises tout le monde peut les voir, il n'y a AUCUN probleme a intercepter la transmission de donnees sur un canal SSL et le voir non-encrypte, c'est le BA-BA de la securite informatique ca.

Et tu peux aussi ouvrir une lettre. Si j'ai écris mon texte en inuit, tu ne sauras quand même pas ce qu'il veut dire.
Avec Apple, la question était de savoir si les données contenaient un identifiant qui permettait de le relier à l'acheteur. Il suffit de faire "codage avec une clé spécifique(id de l'acheteur + nombre aléatoire)" et il est IMPOSSIBLE de différencier ça d'un ID purement aléatoire en interceptant les données (si par exemple tu collectes les données pendant 10'000 nuits (27 ans), il sera encore possible de trouver une clé qui permette de tomber sur toujours le même ID alors que cet ID est aléatoire)

Plus simplement: dans ce cas, tu n'as qu'à me détailler le contenu de ces données. Personne n'a pu le faire.

Si les details techniques sont la, c'est irrefutable. C'est au minimum une faille critique, au pire une backdoor.

Et des failles critiques, il y en a partout dans tout les programmes. Si une faille critique serait suffisant pour "donner un coup a l'economie US en represailles", les USA seraient déjà dévastés.
Comme je me tue à le dire: on ne peut pas différencier une faille critique d'une backdoor. Là n'est pas le problème. Le problème, c'est qu'en cas de perte de confiance, si tu veux continuer à utiliser Windows, tu es obliger de faire confiance à Microsoft. Ce n'est pas le cas avec du libre: plus confiance en OpenSSL -> LibreSSL, plus confiance en X11 -> Wayland, plus confiance en Redhat -> OpenSuse, plus confiance dans le noyau -> le noyau alternatif qui apparaitra quand la confiance dans linux aura été ébranlée, …

Controverse ? Mais controverse chez qui ? Chez les pekins de linuxfr qui veulent y voir ce qu'ils veulent oui.

Dans ce cas, il suffit de montrer étape par étape dans l'assembleur pour PROUVER que ce n'est pas le cas.
Personne ne l'a fait. Pourquoi ? Parce que ce n'est pas possible. CQFD

Dans la communaute securite tout le monde a rigole car il etait vite vu que c'etait de la merde en boite qui n'avait aucune signification de point de vue de la securite

Pareil pour Skype et les accusations de fouinages dans l'historique des navigateurs: les gens rigolent de la théorie du complot, mais PERSONNE n'a pu prouver quoi que ce soit en montrer l'assembleur étape par étape.
Pareil pour Opera où certains ont remarqué un code suspect: on peut aussi rire de la paranoïa de ces gens, le fait est que PERSONNE n'a pu prouver que ce code est inoffensif en montrant l'assembleur étape par étape.

Exactement. Tu viens de demontrer pourquoi ouvrir le code ne changera rien. Meme en imaginant que la NSA ait un controle total sur les source de Windows, ils sont pas cons, ils n'insereront jamais une backdoor qui ressemble a une backdoor.

Es-tu sérieusement en train de dire que parce qu'il existe des pinces coupantes, placer un cadenas est stupide ?
Le fait est qu'avec un code source ouvert, placer une backdoor est plus compliqué (pas forcément techniquement, mais également auprès de la communauté de développeur en justifiant qu'on veut committer un code en particulier), la maintenir, encore plus compliqué, la justifier, encore plus compliqué (les discussions ci-dessus n'auront même pas lieu d'être si le code avait été ouvert).
Cet ajout de complication justifie largement que le code source soit considéré comme un meilleur atout.

Lire les sources de Windows ou Linux a la recheche de backdoor c'est une connerie, c'est impossible. Comme je l'ai dit plus bas, les sources ouvertes pour eviter les backdoors, c'est de la connerie marketing et rien d'autre.

Qui prétend que l'ouverture du code source va réduire les backdoors "parce que les gentils Mme Michu vont passer leur temps à lire le code à la recherche de backdoor" ?
Cela fait des années que plus personne de sérieux ne dit ça (et si tu as cru qu'un noobie de passage reflétait l'opinion de la communauté, c'est pas très flatteur pour tes capacités d'analyse).
Par contre, l'ouverture du code fait:
- que des personnes lisent le code. PAS POUR CHERCHER LES BACKDOORS. Mais pour comprendre le mécanisme (pour le développer chez eux ensuite par exemple), pour améliorer les performances, pour comprendre un comportement suspect (tout les exemples que j'ai donné plus haut: _NSAKEY, iphone, skype, opera, n'auraient JAMAIS existé avec du code ouvert, car la personne qui remarque ça aurait pu vérifier exactement si le comportement suspect est réel ou pas), …
- qu'on voit des développeurs avec des intérêts différents travailler sur le projet, avec des discussions ouvertes et publiques.
- qu'on augmente le besoin de ne pas briser la confiance (si je n'ai plus confiance chez RedHat, je vais chez un autre avec ~0 difficultés de portage. Si je n'ai plus confiance en MS, ben j'ai qu'à serrer les fesses).

Bref, une backdoor chez MS profite à MS avec pratiquement 0 inconvénients (car même si on la découvre, on dira que c'est une faille et puis c'est tout, les utilisateurs ne bougeront pas pour ça). Une backdoor dans un système open source ne profite qu'à une petite poignée de contributeur et a plein d'inconvénient (car même si on prétend que c'est une faille, le résultat est que s'il reste un soupçon, les clients migreront facilement et les réputations seront entâchées. Ça implique que les contributeurs qui ne profitent pas de la backdoor sont d'autant plus poussés à vérifier qu'elle n'existe pas car si elle existe, ils perdent beaucoup sans avoir rien gagné en échange).

Chaque fois que je vois un idiot prétendre que "l'ouverture ne sert à rien parce que la recherche de backdoor ne se fait pas en lisant le code", j'ai l'impression d'entendre "la libre concurrence, ça ne sert à rien, parce que c'est le vendeur qui écrit le prix sur l'étiquette, donc, il choisit lui-même le prix"

Dans ce cas, pourquoi y a-t-il eu la controverse _NSAKEY ou des données nocturnes de l'iphone ?
La vérité, c'est que décompiler le code te donne un truc trop complexe pour pouvoir dire quoi que ce soit d'intéressant.
Il suffit alors de pointer du doigt une partie qui a l'air suspecte, comme il y en a plein dans tout les programmes conséquents, pour obtenir, selon toi, une preuve.

edit:
Parler de preuve est STUPIDE: il sera toujours impossible, que ce soit un code ouvert ou fermé, de prouver qu'une backdoor intelligemment placée est une backdoor intentionnelle ou une faille critique.
C'est pour ça que le code ouvert est meilleur: si on trouve un tel truc, on donne le code à quelqu'un d'autre parce qu'on a perdu la confiance dans le développeur originel. C'est pas possible avec le code fermé.

Mais evidemment que c'est pour l'opinion publique, mais regarde ce que Snowden a fait, cela a un impact certain sur l'opinion, et sur les societes US.

Sauf que c'est Snowden qui l'a fait: un citoyen américain qui maintenant est en exil.
Si ça avait été le gouvernement chinois ou russe tout le monde aurait crié à la tentative de manipulation et aux documents falsifiés (franchement, si la Chine te propose 4-5 transparents powerpoints, tu vas en conclure que c'est une preuve ?).

Justement non, si la backdoor est dans le code, tu peux la montrer clairement, contrairement a un service en ligne.

Donc, il suffit à la Russie ou la Chine d'ouvrir notepad et d'écrire une backdoor dans le code, et ça y est, voilà la preuve que MS a une backdoor.
Quant à pointer du doigt du code compilé, il suffit de choisir un morceau qui a l'air suspect comme il y en a dans tout les logiciels conséquents.
Pareil pour une procédure d'exploitation de la backdoor: MS répondra: c'est une faille critique (et pourra p-e même porter plainte pour avoir dévoilé la faille alors que le contrat qui va avec le code l'interdit, par exemple).

Si les details techniques viennent avec alors non, ce sera plutot clair et net et la presse en fera ses choux gras.

Détails techniques impossible à vérifier.
Par exemple cette histoire de données transmises par l'iphone pendant la nuit. Apple a justifié ça comme étant des données anonyme utiles, mais personne (à ma connaissance) n'a réussi à prouver quoi que ce soit sur le réel contenu et le réel fonctionnement de ces données.
Preuve que le code compilé est trop complexe pour pouvoir vérifier, et qu'il suffit d'inventer des détails techniques crédibles après avoir trouvé un bout de code qui pourrait correspondre à ce qu'on veut faire croire.
Inversement, s'il y a vraiment un code malveillant, il existe des tas de possibilité d'excuse (qui vont du: "ce code ne sert pas à ça" à, dans le pire des cas, "c'est une faille critique")

Quant aux choux gras de la presse: elle en a fait plein sur cette histoire d'iphone ou de _NSAKEY. Conséquences ? Aucune !

Si demain la Chine ou la Russie fait une telle déclaration, tu seras le premier à rigoler en disant que c'est évidemment une lamentable tentative de FUD (preuve que la Chine et la Russie seraient idiots de se lancer dans la solution 1).

Ce genre de discours de la part d'un état a uniquement pour but de manipuler l'opinion publique, et est un combat de popularité.
Surtout que personne ne peut rien prouver (car les preuves peuvent être créées de toutes pièces)
Si les USA disent que Huawei espionne, les pays occidentaux vont avoir tendance à soupçonner Huawei.
Si la Chine ou la Russie dit que MS espionne, les pays occidentaux vont avoir tendance à soupçonner la Chine ou la Russie de vouloir discréditer les USA.

Bref, ce que les USA ont fait avec Huawei se trouve dans un contexte totalement différent de ce que pourrait faire la Chine et la Russie pour MS.
Au final , les USA avaient plein d'incitant à faire ça, incitant qui n'existent pas en Chine ou en Russie:
- le fait que la Chine a déjà mauvaise réputation et que les gens auront tendance à croire les grands gentils USA.
- le fait que les citoyens US ont tendance à croire les USA super fort et donc n'aiment pas donner du fric à la NSA. C'est un très beau coup de pub pour ça: vous voyez, donnez nous du fric, on n'espionne pas nos concitoyens on vous protège des méchants chinois.
- le FUD sur une entreprise non US, qui au final sera accepter par le grand public (la Chine aurait fait ça, tout le monde aurait dit "pfff, encore une tentative de FUD envers les USA").
- le fait que les autres pays font confiance à MS (ou ont des accords secrets) et préféreront aller dans le sens des USA plutôt que d'avouer s'être fait avoir.
…

Bref, l'option 1 dans le contexte actuel me parait être une connerie non réfléchie.

C'est pas tout simplement:

c = (s_ligne+1)*10+(s_colonne)

qui devrait en fait être

c = (s_ligne+1)*10+(s_colonne-1)

(vu les autres lignes "c = (s_ligne…" qui ont l'air symétriques +1-1, +1+1, -1-1, -1+1) ?

(sinon en effet, mieux vaut créer un fonction pour gérer ces blocs quasiment identiques, ça aurait été encore plus facile à trouver)

Sauf qu'aujourd'hui il y a de plus en plus un espèce de tabou sur la remise en question du comportement des gens qui votent FN.
Ils sont de plus en plus considérés comme "mal informés", "poussés à voter ça parce que pas entendus par ailleurs", … Bref, des tas d'excuses pour éviter de dire ce qui est: penser qu'il existe un héro qui va résoudre tout les problèmes et être soudainement déçus que ce ne soit pas le cas, c'est être un abruti.
(c'est p-e le retour de balancier d'une trop grande diabolisation, mais cela ne veut pas dire que c'est intelligent: ce n'est pas parce que qlq'un avait un argument stupide que la solution opposée à sa conclusion est la bonne)

Je ne pense pas qu'il faille ouvrir un débat constructif: un vrai débat constructif implique que tu expliques que leur comportement est con, ce qui les pousseront à se braquer de toutes façons.
Par contre, je pense qu'il faut établir dans le grand public l'idée que les politiciens ne sont pas des héros et que c'est stupide de leur demander l'impossible et d'après pleurnicher parce que les élus ont promis l'impossible mais ne l'ont pas fait (le fait que les élus ont promis l'impossible est de la faute de l'électeur: c'est lui qui a fait en sorte que l'élu doit promettre ça).
Si on fait ceci, les prochaines générations + une partie qui aura doucement vu leur opinion changer sans qu'ils ne s'en rendent compe, seront naturellement moins poussées à voter FN, sans avoir eu de "débat constructif".

Selon moi, il y a 3 groupes de politiciens:
sachant que la réalité politique n'a rien à voir avec les fantasmes du grand public (l'attente du seau de pognon comme le dit arnaudus):
A) ceux qui disent qu'ils vont faire de leur mieux et qui ne promettent pas la lune: ceux-là n'existent pas longtemps, car ils ne sont jamais soutenu par les électeurs.
B) ceux qui disent qu'ils sont des héros et qui savent que ce n'est pas vrai: les électeurs qui ne sont pas cons comprennent que c'est juste "un mensonge nécessaire" pour ne pas disparaitre dans la catégorie A, et en plus, ils ont les autres électeurs qui veulent voter pour un héro et puis s'étonnent que ce ne soit pas le cas.
C) ceux qui disent qu'ils sont des héros et le pensent vraiment: ce sont les "extrêmes" (le terme n'est p-e pas bien choisi, vu que le parti pirate est dedans), qui n'arrivent à rien une fois au pouvoir à part foutre un peu la merde.

J'imagine que tu penses que le meilleur, c'est le groupe A. Or, c'est justement le plus opposé à ce que tu proposes dans le message dans lequel je réponds.

Perso, je pense que la meilleure façon de sortir du problème, ce n'est pas de taper sur B, mais de taper sur les électeurs qui VEULENT que les politiciens fassent des trucs impossibles. À la limite, on peut faire les deux en même temps. Mais ne taper uniquement sur B, ça ne changera absolument rien et ça mettra en avant C.
Donc, oui, dire aux électeurs du FN qu'ils sont cons, c'est effectivement quelque chose d'utile: ils basent leur vote sur des objectifs impossibles, ils seront au mieux déçus (au BIEN MIEUX) au pire, leur choix auront des conséquences graves (et ils seront déçus au final).

Parlant d'histoire, on peut aussi regarder les cas où l'extrême droite est arrivée au pouvoir. C'est le cas en Autriche avec Haider.
Si je ne m'abuse, le résultat a été que Haider a été écarté et que tout les échec de l'extrême droite ont été mis sur son dos, mais aux élections suivantes, l'extrême droite (divisée en 2 partis) a fait un score tout aussi élevé (un petit peu plus, même, si je me souviens bien).
Bref, j'entends souvent: pour lutter contre l'extrême droite, il suffit qu'elle aille au pouvoir pour que les électeurs voient qu'ils sont incapables.
Or, dans le cas de l'Autriche, on a vu que cette méthode ne marche pas aussi bien: les échecs ne sont pas associés au parti ou aux idées, mais à certains individus qui sont ensuite écartés. Inversement, cela "normalise" les revendications de l'extrême-droite et voter pour eux devient plus facile.
Donc, finalement, p-e que ceux qui prônent la politique d'exclusion sont conscients de ça et se comportent de manière bien moins stupides qu'on pourrait le croire.

(Perso, je ne prétends pas qu'une solution est meilleure qu'une autre)

Je vois pas le rapport.

qlq'un: la neige est bleue
moi: non non, la neige n'est pas bleue
toi: la question n'est pas de savoir si la neige est bleue, mais si elle est froide.

À part ça, ne perdons pas de vue que le bilan global de l'impact des DRM dépends fortement de l'idéologie:
- les DRM ont un impact sur différent aspect social, l'importance de ceux-ci dépend de l'idéologie (culture de masse vs micro-culture, accès à la culture pour le grand public vs financement des créateurs, …)
- les impacts des solutions dépendent aussi de l'idéologie (selon un anti-DRM, sans les DRM on a x% de culture en plus, selon un pro-DRM, sans les DRM on a y% en plus, avec y << x)

Je vois pas trop pourquoi tu me dis ça: quelqu'un disait: "les DRM ne permet de financer aucune création", quelqu'un a répondu "pas totalement" et j'ai juste donné un exemple (et du coup je comprends pas trop pourquoi ce commentaire qui ne correspond pas à la discussion et apporte une information évidente est jugé pertinent par certains, mais bon, peu importe).

La culture n'a pas besoin de DRM pour exister.
Par contre, dire que les DRM ne permet pas à certains "créateurs culturels" de gagner de l'argent, c'est juste un mensonge qu'on répète pour se rassurer.
La réalité est ni toute noire ni toute blanche: les DRM sont stupides, mais ils ont permis des transferts d'argent qui n'auraient pas eu lieu sinon et qui ont aidé les créateurs.
Les tenants des DRM utiliseront cet argument. Si tu réponds à ça "non, tout l'argent va dans la poche des ayants droits", alors, tu montres juste que tu ne sais pas de quoi tu parles et ça décrédibilise les vrais arguments.

En effet, sans les DRM, on n'aurait pas eu de 4éme saison pour Arrested Development (ni le futur film ?).

Donc, d'après toi, lorsque 2 partis politiques font une coalition, c'est parce chacun de ces 2 partis n'aimerait pas avoir le pouvoir pour lui tout seul ?
Non, simplement, entre rien du tout et un peu de pouvoir (qui permet de placer ses pions pour gagner encore plus de pouvoir au prochain tour), le type intelligent choisit le deuxième, même s'il aurait préféré s'en passer.
Et tu notes que personne ne met de flingue sur la tempe de personne. Dingue non ?

Ton raisonnement "puisqu'il l'a fait, c'est qu'il soutient" est faux et il y a un millier d'exemples qui montre que cette logique est foireuse.

(après, pour Jobs, je sais pas. Je dis juste que ta logique est foireuse)

impératif catégorique vs argument utilitariste.

Et si une des deux méthodes étaient meilleure que l'autre, ça se saurait.
Perso, je ne suis pas suffisamment présomptueux pour traiter d'idiots ceux qui n'ont pas la même stratégie que moi (à vrai dire, je suis idéologue, je n'aurais certainement pas pris la décision qu'a pris Mozilla).
Je suis capable de comprendre que tout le monde n'a pas les mêmes sensibilités, et que les miennes ne sont pas meilleures que les autres.
En plus de ça, je comprends la logique de Mozilla, même si je ne la soutiens pas. Mais par honnêteté intellectuelle, je reconnais qu'il y a des arguments qui expliquent la stratégie.

Surtout quand le moyen va exactement à l'encontre de l'objectif.

Comme je l'ai dit, il y a plein d'exemple historique où des concessions à court terme a permis au final d'atteindre l'objectif tandis que ceux qui étaient bêtement resté bloqués sur leur position de principe n'arrivent à rien.
Un exemple flagrant sont les politiques de médiation dans les cités: la tolérance zéro est souvent beaucoup moins efficace qu'une approche de proximité, même si ça implique que la lutte contre la délinquance soit relachée.
On a un moyen (tolérer un certain degré de délinquance, notamment en diminuant la présence policière) qui va exactement à l'encontre de l'objectif (l'objectif est plus de sécurité, et on diminue les moyens de lutte contre la criminalité).
Pourtant, ça permet mieux d'atteindre l'objectif que l'impératif catégorique.

Pour en revenir à la stratégie de Mozilla, j'ai toujours pensé que le libre est un système où, s'il y a un besoin de la part de l'utilisateur, il faut qu'un outil pour celui-ci apparaisse naturellement. Voilà pourquoi, même si je préfère KDE, je défends certains environnements de bureau quand je constate que ceux-ci répondent à un besoin d'un groupe d'utilisateur.
C'est pareil ici: le monde est constitué de pragmatique et d'idéologue. Ayons donc 2 navigateurs open source ayant pour même objectif les idéaux défendus par le libre: un utilisant la technique "pragmatique" et un utilisant la technique "idéologique". Deux solutions:
- soit "firefox" devient "idéologique", et on crée un nouveau navigateur "pragmafox". Combien de personnes "pragmatique" qui quittent firefox vont passer de "firefox" à "pragmafox" ? Sans doute 0%: s'ils changent de navigateur, vu que ce sont des personnes "pragmatiques", ils préfèreront un navigateur reconnu.
- soit "firefox" devient "pragmatique" (il l'est déjà: plugin flash, …), et on crée un nouveau navigateur "ideolofox" (ça existe déjà: iceweasel ?). Combien de personnes "idéologiques" qui quittent firefox vont passer de "firefox" à "idéolofox" ? Sans doute 100%: aucun autre navigateur ne satisfait leurs attentes.

Pour moi, la question n'est pas de savoir quelle est la meilleure stratégie entre idéologie et pragmatisme: c'est une question idiote où on n'a pas compris qu'on ne peut pas répondre à cette question. La question est de savoir comment on fait pour avoir un écosystème libre dans lequel chacun y retrouve son compte.
Dire "les pragmatiques ne devraient pas exister" n'est pas une solution selon moi. Et si on accepte que les pragmatiques peuvent exister, alors, il faut accepter qu'il existe un navigateur qui fonctionne de la façon qu'aimeraient les pragmatiques. C'est le rôle naturel de firefox, il est dans une position où ne pas tourner vers ça serait se compliquer la vie pour rien.

La question de l'objectif et du moyen est une très vieille question.
Elle est très très présente en politique.

Par rapport a ce qui a déjà été rappelé, j'aimerais bien rajouter les éléments suivants:
1) Si Firefox perd des parts de marché à cause de l'absence de gestion des DRM, ce ne sera surement pas un transfert d'utilisateur vers un navigateur ayant une mentalité open-source (vu que si un tel navigateur existe, il n'implémentera pas la gestion des DRM qui font que les utilisateurs ont quitté Firefox). Ce sera plutôt vers un navigateur qui inculquera des valeurs telles que "la meilleure façon d'être en sécurité, c'est d'utiliser un logiciel qui utilise un appstore fermé, car un appstore ouvert, c'est dangereux".
2) Si Firefox perd des parts de marché à cause de l'absence de gestion des DRM, il ne récupérera JAMAIS ces parts de marché. Le marché des navigateurs s'étant réveillé, les concurrents sont réactifs et jamais Firefox ne pourra proposer une nouvelle killer-feature qui prendra de cours les concurrents … sauf sur les éléments idéologiques open-source. Or les parts de marché perdues auront été faites parce que les utilisateurs ont estimé que les DRM (et les problèmes de boîtes noires, vie privée, …) n'étaient pas un gros problème pour eux.

La question est donc:
mieux vaut-il perdre des capacités à gagner d'autres batailles en refusant les DRM
ou mieux vaut-il compromettre ses principes mais être capable d'avoir un poids important pour la prochaine bataille

Je ne sais personnellement pas quoi répondre. Je doute que quelqu'un d'intelligent puisse prétendre qu'une de ces deux solutions est évidente.

Historiquement, on trouve de tout:
des cas similaires où ceux qui ont parié sur le respect de leur principe ont ensuite atteint une conclusion pas mauvaise, mais également des cas où ça a mené à une catastrophe, et pareil lorsqu'on regarde ceux qui ont choisi l'autre stratégie.
Bref, c'est juste une question politique.
Si tu es plus idéologue que pragmatique, tu es plus idéologue que pragmatique, et voilà. Cela ne veut pas dire que qlq'un qui est plus pragmatique que idéologue n'est pas en réalité plus utile que toi à la cause que tu défends.

C'est ce que je fais aussi.
Et Gnome Web permet de faire ça (comme expliqué, apparemment, il suffit de cliquer sur le texte de l'url pour pouvoir le changer).
Mais cet usage ne justifie pas vraiment le fait d'avoir une url éditable tout le temps. Une interface avec un champ éditable tout le temps signifie: vous devez éditer ce champ pour utiliser l'outil dans son usage courant.
Le fait d'avoir une zone de saisie lors de l'ouverture de l'onglet et puis transformer ça en texte simple qui peut être réédité lorsqu'on le demande me parait plus cohérent avec les habitudes des interfaces graphiques.
Pensez notamment aux noms de dossier: ils sont éditables exactement de la même façon que l'URL sous Gnome Web, alors que changer un nom de dossier est plus courant que de devoir éditer une url à la main.

Une zone de saisie signifie: avant de terminer votre action, vous devrez sans doute modifier ce champ.
Ici, l'URL correspond plutôt: en général, sauf rare cas, vous ne devez pas toucher ce champ.
Alors que la présence d'une zone de saisie devrait envoyer le message opposé (la non-modification est rare).
Du coup, le choix de Gnome Web me parait plutôt malin.

Je pense que cette déviation de l'usage du champ de saisie vient du web lui-même: il est compliqué dans une page web d'avoir un texte en dur et de le transformer en champ de saisie en cliquant sur une option. Du coup, même si c'est rare, un élément que l'utilisateur pourrait éventuellement vouloir modifier est un champ. Mais cela ne devrait pas être le cas dans les interfaces plus évoluées.

Mouais, si tu pensais réellement que cette question méritait une réponse, il va falloir revoir la façon dont j'explique mon avis sur ce site.

À part ça, je pense qu'une interface bien pensée au niveau de l'utilisabilité met en avant les outils qui facilitent l'usage.
Éditer l'url dans ton cas est clairement un usage peu pratique (que tu peux préférer, mais ça reste peu pratique) alors qu'il y a une série d'outils qui existe pour empêcher ça. Le fait que Gnome Web fasse inconsciemment remarquer à l'utilisateur qu'éditer l'URL n'est pas la "première" méthode (même si elle reste possible) est selon moi une très bonne idée.

Je ne vois pas trop le problème d'utilisabilité (ou de découvrabilité).
Une fonction très secondaire (qui a besoin d'éditer l'url lorsqu'il surfe ?) a été implémentée différemment, mais elle n'est certainement pas moins intuitive à trouver (il y a une flèche à côté de l'url, ce qui signifie clairement que c'est là qu'on doit cliquer pour faire une action liée à l'url).
Je comprends que tu ais été troublé par tes habitudes, mais cela n'implique en rien qu'il y a un problème d'utilisabilité.
Ce qui me dérange, c'est qu'aujourd'hui, dès que qlq'un voit quelque chose qui le surprend, il en conclut forcément que c'est l'interface qui a été mal conçue, et tente de justifier ça n'importe comment. J'ai l'impression que le comportement "normal" qui consiste à ce dire "hm, j'ai p-e pas compris comment ça marche" a disparu, et je trouve ça dommage.

Le mot « utile » était mal choisi, il faudrait le remplacer par principal.

J'avais compris: "c'est cette partie la partie la plus importante, qu'il faut mettre en avant pour garantir une bonne ergonomie".
Je suis totalement en désaccord avec ça: une bonne ergonomie implique une considération du flux de pensée, et surtout pas favoriser la tâche comme plus importante (il arrive que considérer le flux de pensée implique qu'on favorise la tâche, mais l'inverse est faux).

Comme toutes les images, tu l'utilise dans le sens qui te conviens. Je pourrais répliquer que sur ton bureau tu met les document sur les quels tu travail au milieu et les papier que tu souhaite pouvoir facilement accéder dans un coin avec un rangement en tiroir (je sais pas comment s'appele les organiseurs en plastique qui s'empilent).

Non, de nouveau, cela dépend d'où tu places la limite subjective.
Je ne dis pas qu'une interface où ne figure que la région claire de la capture d'écran est une mauvaise interface. Je dis que dire que pour créer une bonne interface, "le plus important est la région claire" est une mauvaise méthode.

En gros, ce que je te reproche est de dire: "pour faire de bonnes crêpes, il faut 300g de farine", alors que je pense que "pour faire de bonnes crêpes, il faut un œuf tout les 100g de farine".
Avec la souris, je te donne un exemple qui montre clairement que "toujours 300g" est foireux. Tu me réponds: oui mais tu choisis l'exemple qui t'arrange, regarde dans cet autre cas, 300g est parfait.
Peu importe, car non seulement ton autre exemple n'est pas incompatible avec ma règle, mais le contre-exemple qui montre que ta règle est foireuse existe toujours.

L'exemple de la souris est un exemple qui prouve que les éléments hors-tâches restent très importants. Ensuite, que tu choisisses de cacher certains éléments ou pas, c'est une question subjective d'où tu places ta limite.

Sur la capture, je trouve que ça empiète sur la manière de choisir son thème.

Si cette capture correspond à quelque chose qui n'est pas à ton goût, dis simplement: moi, j'aime pas.
Par contre, dire: "c'est une mauvaise façon de faire, la bonne façon de faire est de penser à la tâche principale", c'est selon moi une phrase dangereuse (car tu oublies de souligner que les éléments hors-tâche peuvent être très importants) ou juste fausse (si tu dis ça sans être conscient que les éléments hors-tâche peuvent être très importants)

Qu'est-ce que ça a à voir avec ton explication lors de ton premier commentaire avec la charge utile ?
Dans le contexte du premier commentaire, la partie que tu laisses en clair est considérée comme suffisante. Tes explications sur la bonne méthode (se concentrer sur la charge utile) sont juste dangereuses: il ne faut PAS se concentrer sur la charge utile, il faut trouver le bon compromis entre charge utile et le reste, mais surtout pas penser que le reste est inutile, ce que ton commentaire disait.
Si tu ne penses pas ça, très bien, mais dans ce cas, tu as bel et bien très mal expliqué ta position lors de ton premier commentaire (ou du moins, ton premier commentaire semble montrer que c'était pas clair du tout dans ta tête).

Mon commentaire était également là pour éviter que d'autres qui lisent ça soient induits en erreur par ton explication qui oublie le rôle très important de la volonté de ne pas briser le flux de pensée.

Au final, j'aurais bien voulu avoir une réaction sur mes explications avec la souris. Est-ce que tu es d'accord pour dire que ranger la souris dans le tiroir chaque fois qu'on passe au clavier est très perturbant (et au final fatiguant) pour l'utilisateur lorsqu'il veut revenir à la souris ?
Si c'est le cas, tu comprends pourquoi je trouve que ton explication sur la charge utile de ton commentaire initial est stupide et dangereuse, car c'est au contraire une bonne façon de faire des interfaces pas ergonomiques du tout.

Si. Si l'utilisateur l'utilise, oui, c'est une interface ergonomique.

Non, le chemin le plus court n'est pas forcément le moyen le plus ergonomique.
Démonstration: rempli un écran de 100 icones d'applications de 24x24px, avec les applications les plus utilisées qui se placent automatiquement sur le point chaud de la souris de l'utilisateur.
C'est une diminution optimale du chemin: 1 seul clic, déplacement de la souris minimisé.
C'est pas du tout ergonomique: avoir juste ~10 icones tiroirs dans lesquels on range les applications et qui ne bougent pas, c'est sans contexte déjà bien plus ergonomique.

Le nombre de clics n'est pas un argument en soi, c'est un argument seulement si c'est justifié (si par exemple on réduit le nombre de clics sans rien changer d'autre). Ça me désole un peu de voir que ce genre d'argument pseudo-objectif est utilisé à tort et à travers pour "démontrer" que truc est plus ergonomique que machin. Cela ne fait que montrer que ceux qui l'utilisent n'ont rien compris à l'objectif.

Et tu trouve que …

Sauf que ça n'arrive pas en pratique (du moins pas à moi). De la même manière, je n'ai pas de perte de flux de pensée lorsque je passe de mon clavier à ma souris. Si par contre je range à chaque fois ma souris dans mon tiroir, oui, je dois briser mon flux de pensée à chaque fois.
Je le répète: tu dis: "voilà la bonne solution". Moi, je constate qu'elle ne marche pas avec moi, et pas parce que c'est ce que je souhaite (comme déjà dis, je préfère visuellement les interfaces épurées. Si ça marchait, je les utiliserais volontiers).

Je veux bien voir de quoi tu parle

Je parle de ton image ici: http://linuxfr.org/nodes/101819/comments/1531142

Tu dis: "voilà la recette pour faire quelque chose d'ergonomique: le truc à afficher, c'est l'action courante".
J'ai juste répondu que c'est faux, de la même manière que faire disparaitre la souris lorsqu'on utilise le clavier n'est pas efficace parce qu'on perd le flux de pensée lorsqu'on doit la récupérer alors qu'on ne le perd pas si elle reste à porter de la main.

Moi je pars d'une chose simple

Si c'est ça ton problème, ton explication en image au commentaire précédent n'a plus lieu, et c'est sur cette explication que je réagis.
Tu as dis: "voilà ce qui est important, le reste de ce qui est sur la capture d'écran originale n'a pas lieu d'être". C'est faux: le fait que ça soit là est totalement justifié.

C'est de ça que je parle depuis le début quand je dis que l'objectif de l'utilisateur c'est de configurer et pas de passer son temps à faire des sauts d'un bout à l'autre de la configuration. La charge utile, c'est la réponse à la question : qu'est ce qui dans l'interface permet à l'utilisateur d'accomplir sa tâche ?

C'est une MAUVAISE MÉTHODE, tout comme dire: "l'utilisateur veut taper au clavier, alors, rangeons automatiquement la souris dans le tiroir". Car si l'utilisateur veut changer de tâche ou simplement faire quelque chose que tu n'avais pas prévu, il est obligé de briser le flux de sa pensée, ce qui est 100x plus grave que de devoir faire 5 clics. C'est le flux de pensée qui est important: le briser fatigue l'utilisateur, bien plus que les clics. Laisser la souris à porter de main (ou laisser les catégories à porter de main) fait toute la différence.

Non il n'y a pas à être maximaliste (c'est aussi stupide) que d'être minimaliste.

Ce que je décris n'est PAS maximaliste. Si la limite subjective de ton choix de politique d'interface est très basse, alors, l'application sera fortement épurée. D'ailleurs, ce que tu décris peut être construit avec ma méthode.
La différence, c'est que ton explication oublie ce point essentiel et prétend qu'un point essentiel est quelque chose d'autres, alors que c'est faux.

La tâche de l'utilisateur c'est de configurer X, pour ça on peut savoir (par étude des utilisateurs par exemple) qu'il y a X', X", X"' et qu'il arrive que l'utilisateur veuille aussi toucher à Y, Z' et J voir à n'importe quoi d'autres.

Donc, tu es d'accord: dire que l'important c'est X et le reste est inutile, c'est stupide. C'est tout ce que je voulais faire remarquer.
Ensuite, tu prétends que X doit être mis en avant, alors que ça ne sert à rien de le mettre en avant s'il l'est déjà, surtout si ça implique qu'on rogne sur des trucs utiles.

Je ne dis pas que la navigation est inutile, juste qu'elle ne devrait pas prendre plus de place à l'écran que l'information principal

Pourquoi ? Si la tâche principale requiert peu d'espace et les autres éléments beaucoup, pourquoi forcer la tâche principale à prendre tout l'espace. Surtout si les éléments annexes sont présents avec cette taille par ailleurs: conserver la même taille partout est très important: l'utilisateur s'y retrouve alors beaucoup plus vite (voilà pourquoi la liste des catégories doit toujours rester la même).
En tout cas, dans le cas qui nous concerne, l'espace pris par la tâche principale est largement suffisant. La mise en avant est faite par le fait que c'est l'élément central et que c'est l'élément qui apparait lorsque l'utilisateur change de catégorie.

Si tu a une interface qui permet d'être parfaitement efficace (utilisation du chemin le plus court) pour une bonne quantité de tes utilisateurs tu as gagné, si tu le fait avec un chemin dans le pire cas correct, alors il n'y a rien à redire.

L'utilisation du chemin le plus court n'est pas synonyme d'interface ergonomique. Une interface ergonomique est celle qui est utilisé par l'utilisateur sans que celui-ci ait à "briser son flux de pensée". Pour ça, il est bien possible qu'une interface qui positionne tout les éléments toujours à la même place et dans le même ordre soit plus efficace.
J'ai l'impression que tu pars d'une interface qui te plais (ou ne te plais pas) et que tu essaies ensuite de trouver des éléments objectifs pour justifier ton choix.
Personnellement, je n'aime pas l'apparence des applications KDE, trop chargée, mais je constate que quand j'utilise des applications "qui utilise la charge utile" comme tu le décris, je me retrouve à devoir m'arrêter de m'occuper de ce que je fais pour devoir me poser la question: "tiens, c'est où, ça, encore ?" ou "comment je fais ça ?" ou "ça a modifié quoi, maintenant ?".

Un peu comme l'organisation en arbre qui est imposée et qui n'est pas forcément évidente pour l'utilisateur notamment parce que il y a pleins de choses qui pour lui pourrait aussi bien aller dans 2 cases différentes.

Oui, et dans ta proposition initiale de "charge utile", non seulement tu as l'organisation en arbre, mais également ta restriction à ta "charge utile" qui est une contrainte.
Je rapelle que c'est de ça que je parle: je critique ta notion de "charge utile" qui est selon moi une méthode pour obtenir des interfaces pourries.
Si tu proposes qlq chose d'autres pour l'arbre, pas de problème, mais ça n'a rien à voir avec le fait que le raisonnement "il faut se concentrer sur la charge utile" est stupide: il ne faut pas se concentrer sur la charge utile, il faut se concentrer sur la tâche et le contexte de la tâche et intégrer le maximum de possibilités utiles jusqu'au moment où on atteint la limite subjective où l'application n'est pas inutilement trop chargée.
C'est une limite subjective et c'est pour ça qu'il y a plusieurs interfaces.
Mais dire: il y a une valeur objective qui est la charge utile tel que tu l'as définie, c'est juste se tromper (il se peut que pour toi, la limite corresponde à ta charge utile, mais cela n'est pas un bon critère pour créer une bonne interface)

Je parle d'y mettre des informations utiles

Et j'ai déjà expliqué pourquoi ce que toi tu exclus comme inutile, je considère ça comme bien plus utile que la possibilité de comparer par exemple. Bref: si on faisait comme tu le souhaites, quelqu'un d'autres dira: pfff, interface mal conçue, il y a plein de trucs inutiles et plein de trucs utiles manquants.

Au passage

Ce qui n'a rien à voir avec ton histoire de "charge utile" où tu prétends qu'une bonne interface doit se concentrer sur ça, alors que pour moi, c'est stupide. J'ai répondu sur ça et juste sur ça.