Firefox : une faiblesse dans le gestionnaire de mots de passe depuis 9 ans

Firefox : une faiblesse dans le gestionnaire de mots de passe depuis 9 ans

Firefox : une faiblesse dans le gestionnaire de mots de passe depuis 9 ans

Wladimir Palant, l’auteur d’Adblock explique sur son blog que le gestionnaire intégré de mots de passe ne fait qu’une seule passe de fonction de hachage SHA-1 sur la clé de chiffrement, alors qu’il en faudrait au moins 10 000.

Le résultat serait une vraie faiblesse face à des tentatives d’attaques par force brute. Il rappelle qu’une GeForce 1080 GTX est en mesure de calculer 8,5 milliards d’empreintes (hash) SHA-1 par seconde. Selon un article cité de Microsoft, les mots de passe ne font en moyenne que 40 bits de long, soit cinq caractères. L’article a 11 ans, mais montre qu’il ne faudrait que 2^39 essais, soit moins d'une minute avec le matériel cité.

Le problème existe depuis neuf ans chez Mozilla et rejaillit sur Thunderbird. Il ne représente un danger bien sûr que si les utilisateurs se servent du gestionnaire intégré. S’ils possèdent une solution de type LastPass, Dashlane ou 1Password, ils ont tout intérêt en effet à désactiver la fonction intégrée du navigateur, quel qu’il soit – ne serait-ce que pour éviter les demandes doublons.

En attendant une réponse de Mozilla (le débat reste ouvert), Palant propose diverses solutions, dont l’augmentation des passes de SHA-1 jusqu’à 100 000 (comme le fait notamment LastPass). Il estime surtout que SHA-1 devrait faire place à une autre fonction de dérivation de clé, comme Argon2, conçue justement pour résister aux attaques soutenues par des GPU, notamment en faisant exploser la quantité de mémoire requise.

Mozilla devra donc sans doute prendre une décision, maintenant que l’attention des médias a été attirée.  En attendant, les utilisateurs se voient conseillés par Palant de se tourner vers une autre solution pour les mots de passe, et de couper la fonction intégrée de Firefox. Un conseil rapide, mais pas si simple, car il implique de nouvelles habitudes et éventuellement un abonnement.

On notera enfin que Mozilla travaille depuis un moment sur un gestionnaire de mots de passe indépendant. Nommé Lockbox, il est actuellement disponible en version alpha, donc bien loin d’être prêt pour le grand public, en plus de n’être disponible que pour les moutures desktop du navigateur.

Commentaires (47)


J’utilise Sync pour synchroniser mes différentes utilisation de firefox, est ce que le gestionnaire de mot de passe utilisé par Sync est bien le gestionnaire intégré et cité dans l’article ?


Ça craint vraiment ce genre de choses… Content d’utiliser Kee pour le coup. <img data-src=" />


Ça se casse comment ?

Je veux dire, comment un pirate doit-il s’y prendre pour récupérer nos mots de passe ? Car c’est là aussi que tout se joue.


C’est uniquement Firefox qui est touché ? Chrome, Edge, Opera, Vivaldi et les autres nagivateurs utilisent autre chose que le SHA-1 pour leurs gestionnaires de mot de passe respectifs ?


“cassable” depuis une page web ?


Ca m’a également toujours étonné qu’on puisse les faire apparaître en clair dans les options… Ça ne choque personne?


Je ne suis pas sûr de comprendre, on parle du hashage du mot de passe qu’on utilise pour le gestionnaire de mot de passes de Firefox ?

Et il faudrait hasher le mot de passe plein de fois pour qu’il serve de clé de chiffrement (des mots de passe), c’est ça ?









deportivo35 a écrit :



Ca m’a également toujours étonné qu’on puisse les faire apparaître en clair dans les options… Ça ne choque personne?





Pas moi en tous cas. Pratique de pouvoir les récupérer.

Et sinon ma machine est protégée par mot de passe, comme les vôtres j’imagine.









deportivo35 a écrit :



Ca m’a également toujours étonné qu’on puisse les faire apparaître en clair dans les options… Ça ne choque personne?





Bah pourquoi ? C’est pratique de recuperer certains trucs par ce biais.

Et puis s’ils sont dispo en clair par le navigateur c’est qu’ils sont ecrits en clair quelque part sur le disque. Ce qui peut etre dangereux si le systeme de fichier n’est pas chiffree notamment en cas de vol.









deportivo35 a écrit :



Ca m’a également toujours étonné qu’on puisse les faire apparaître en clair dans les options… Ça ne choque personne?





Non, puisque:

&nbsp;- le navigateur doit pouvoir les décrypter pour les injecter dans les formulaires




  • tu peux les protéger par un mot de passe maître&nbsp;



Si les choses sont un minimum bien faites, le fait que les mots de passes apparaissent en clair dans le navigateur ne veut pas dire qu’ils sont stockés en clair sur l’ordinateur, chiffrement du système de fichier ou non.



Par exemple dans Chrome sous windows, quand tu veux voir un mot de passe en clair, il te demande une authentification de ton compte (qui, en gros, constitue la clé de chiffrement).

Et comme Chrome démarre avec le compte logué ça explique pourquoi il ne te le demande pas quand il rempli le formulaire.



En 2018 je pensais que tous les soft modernes proposaient un minimum de sécurité pour ses mots de passe…








MrKuja a écrit :



En 2018 je pensais que tous les soft modernes proposaient un minimum de sécurité pour ses mots de passe…





Je profite juste de l’occasion pour mentionner que Filezilla stocke les mdp en clair à un emplacement statique du disque (et les devs refusent de le changer), donc, bah, non, c’est toujours un problème de mentalités



Or, un mdp root, ça peut être plus grave qu’un mdp dans firefox.



En base64 plutôt, non ? Bon d’accord, c’est comme si c’était en clair <img data-src=" />


Oui c’est bien celui-là, mais ça concerne le mot de passe maître de FF (un mot de passe pour chiffrer les mots de passe du gestionnaire). Par défaut, il n’y a pas de chiffrement des mots de passe qui sont tous en clair dans un beau fichier.



Il y a 3 ou 4 ans, j’avais lu (dans un MISC je crois), un comparatif des méthodes de stockage des mots de passe des navigateurs. A l’époque, il n’y avait qu’Opéra (version &lt;12) qui chiffrait nativement les mots de passe (avec quelle clé ?). Les navigateurs comme chrome ou IE ne les chiffraient pas du tout, mais dans le cas de Windows utilisait des emplacements systèmes avec droits restreints pour les stocker (ce qui était mieux que rien).&nbsp;

D’après les commentaires au dessus, cela semble avoir changer sur chrome, donc sans doute de même pour les navigateurs basés sur chromium.








Vekin a écrit :



En base64 plutôt, non ? Bon d’accord, c’est comme si c’était en clair <img data-src=" />





si si, en clair dans le fichier des connexions rapides (me souvient plus son nom, il est dans %appdata%)

M’en suis déjà servi au moins deux fois au taff <img data-src=" />



Est-ce que le gestionnaire est attaquable depuis une page web, ou faudrait-il passer par un malware qui devrait être installé sur la machine avant qu’un tiers puisse récupérer les mots de passes ?








Sabinoo a écrit :



Je profite juste de l’occasion pour mentionner que Filezilla stocke les mdp en clair à un emplacement statique du disque (et les devs refusent de le changer), donc, bah, non, c’est toujours un problème de mentalités




  Or, un mdp root, ça peut être plus grave qu'un mdp dans firefox.











WereWindle a écrit :



si si, en clair dans le fichier des connexions rapides (me souvient plus son nom, il est dans %appdata%)



  M'en suis déjà servi au moins deux fois au taff <img data-src=">








 *Va dans %AppData%/Roaming/FileZilla*       

*Ouvre le fichier bien nommé recentservers.xml*

*Voit son mdp*

*Efface FileZilla et tous ses enfants de la surface de la terre son PC*






 Ce fut une expérience enrichissante. <img data-src=">


&nbsp;De 2 choses l’une:




  • Soit chrome stocke les password dans une sorte de keyring local chiffre auquel cas le contenu est protege au meme titre qu’un systeme de fichier chiffre, et le master password (qui peut etre le mdp de session) dechiffre le conteneur

  • Soit il s’agit simplement d’un mecanisme de protection d’acces a une zone du disque dur (comme la gestion du fichier SAM pour l’authentification) auquel cas acceder aux donnees est parfaitement possible en montant le disque dur en secondaire



    Je ne sais pas comment chrome fonctionne mais si tu n’as pas un conteneur chiffre - dechiffrable avec un mot de passe maitre - alors tes mots de passes sont stockes en clair sur le DD. Ce conteneur peut prendre la forme d’un systeme de fichier (exemple: dm-crypt) ou d’un fichier (exemple: gnome-keyring, keepass, etc.).



    Je ne suis pas du tout sur que windows vault chiffre ses conteneurs par defaut. Donc mefiance.


En même temps, si quelqu’un peut y accéder à distance, tu as déjà un problème suffisamment important (et s’il peut y accéder en local, le concept de sécurité ne s’applique déjà plus depuis le moment où il a accédé à ta machine) <img data-src=" />








Carpette a écrit :



qu’un systeme de fichier chiffre





à prononcer à haute voix 10 fois assez vite, c’est rigolo <img data-src=" />









WereWindle a écrit :



En même temps, si quelqu’un peut y accéder à distance, tu as déjà un problème suffisamment important (et s’il peut y accéder en local, le concept de sécurité ne s’applique déjà plus depuis le moment où il a accédé à ta machine) <img data-src=" />





Ouais enfin non. C’est pas compliqué d’utilisation la session de l’utilisateur pour chiffrer/déchiffrer des données.



Ça existe sur tous les OS depuis quoi, 20 ans au moins ?









Carpette a écrit :



Je ne suis pas du tout sur que windows vault chiffre ses conteneurs par defaut. Donc mefiance.






En effet, d'ailleurs c'est pour ça qu'il y a Vault (coffre) dans le titre, c'est parce que la porte reste toujours ouverte, à tout le monde. C'est évident.   





<img data-src=" />



Je serai toi je ne ferais pas trop le malin, j’ai une VM windows sans mot de passe qui tourne et qui a des mdp stockes dans vault donc aucun master password et donc aucune protection.








Carpette a écrit :



Je serai toi je ne ferais pas trop le malin, j’ai une VM windows sans mot de passe qui tourne et qui a des mdp stockes dans vault donc aucun master password et donc aucune protection.





C’est pas parce que tu laisses trainer la clé du coffre qu’il n’a pas de porte ;)



Arrete ta poesie 2 minutes et soit un peu concret. Tu m’expliques ou est la protection dans le scenario que je viens de te decrire ?








Carpette a écrit :



Arrete ta poesie 2 minutes et soit un peu concret. Tu m’expliques ou est la protection dans le scenario que je viens de te decrire ?





Faudrait préciser ton scénario. L’attaquant aurait accès au .vhd en clair ?



Si oui, sans bitlocker d’activé (ou équivalent comme truecrypt sur disque système) tu n’as aucune protection. Ni la session ni Vault n’ont quoique ce soit à voir avec ça, ils ne sont pas destiné à protéger contre les accès locaux.



C’est ce que je precisais dans mon premier message.



Donc effectivement vault ne protege rien du tout.


Non, tu as dis que Vault ne chiffrait pas ses conteneurs. C’est faux.



Tu aurais du dire que le chiffrement des conteneurs, tel que Vault peut le faire, ne protège pas d’absence de sécurité dans les niveaux inférieurs. Ça c’est vrai.



Tu as toi-même dis qu’il fallait être concret, tâche de l’être.


J’ai bien dit “par defaut” ou systematiquement si tu preferes.

Un comportement sain serait d’exiger un mot de passe a partir du moment ou tu decides d’utiliser vault. Avis personnel cela dit.



Le point original de mon message etait bien de demontrer que les mots de passe delegues a un systeme de keyring ne sont pas pour autant proteges.








Carpette a écrit :



J’ai bien dit “par defaut” ou systematiquement si tu preferes.





Par défaut tu as un mot de passe et l’attaquant ne vol pas le disque dur lui-même. Sans ces comportements, qui sont devenus exceptionnelles même chez Mme Michu depuis que Win10 pousse à l’utilisation d’un compte MS, Vault fait son boulot.



Donc non, “par défaut” c’est bien une faute du développeur que de ne pas utiliser l’API système pour protéger ses informations sensibles, surtout que ça ne coute rien du tout.



Non. Windows te laisse parfaitement cree un mot de passe juste en cliquant sur le bouton ignorer lors de la prmeiere mise en route. La preuve je l’ai encore fait sur ma derniere install windows 10 il y a 3j. Et franchement on peut pas dire que les sessions sans mdp soient aussi rares que de l’or.



De plus, le vol d’ordinateur n’est pas une pratique eteinte a ce que je sache et quand tu connais la valeur de certains comptes (paypal, banque etc.), tu preferes qu’ils ne soient pas stockes en clair.

&nbsp;

D’autre part tu n’es pas a l’abris d’un petit malin qui vient faire tourner un live CD ou mieux (ou pire selon le cas) une attaque directement depuis l’intel ME qui, avec la bonne configuration notamment les gammes pro, peut acceder aux disques durs.



Je ne parlerais pas des cas d’ordinateurs qui se baladent dans la nature ou qui sont decomissiones sans formattage.



Donc non, je suis desole, l’API systeme en tant que telle n’offre pas assez de garantie. Sinon mozilla ne s’emmerderait pas a developper son propre gestionnaire de mots de passe et a inciter a la creation d’un mot de passe maitre.








Carpette a écrit :



Donc non, je suis desole, l’API systeme en tant que telle n’offre pas assez de garantie. Sinon mozilla ne s’emmerderait pas a developper son propre gestionnaire de mots de passe et a inciter a la creation d’un mot de passe maitre.





Oui, si tu veux imposer des sécurités que l’utilisateur refuse, l’API système ne fait pas le job. Et oui, je suis bien d’accord, Mozilla a bien raison d’avancer sur le sujet avec son Lockbox. Enfin, pourrait avoir raison, car ça n’a pas l’air d’être une priorité pour eux, ils font quand même passer Quantum avant, donc bon…



Mais en aucun cas ça n’excuse le fichier en clair de FileZilla. Ou t’as quelque chose, ou tu utilises le système par défaut. Ne rien faire n’est pas défendable, et ce n’est pas parce qu’un système est insuffisamment contraignant à ton avis qu’il faut se retrouver à ne rien faire du tout. C’est mieux que rien, comme dit l’expression.



Je pense qu’on a 2 visions differentes. Je ne cherche pas necessairement a forcer l’utilisateur a avoir un mdp maitre. Personnellement je deteste quand un OS me force a faire des trucs.



Mais ce serait fortement appreciable que l’utilisateur soit au moins mis au courant. Par exemple dans le centre de securite qui affiche l’etat des trucs principaux genre AV, firewall et maj, il serait fort appreciable d’avoir un rappel pour un mdp maitre. Voire une notification.



Filezilla effectivement offre la pire des solutions.


Moi j’ai juste sur Mozilla un mot de passe maitre à 16 caractères que j’ai tapé complétement au hasard, sans aucun sens avec des minuscules, majuscules et caractère spéciaux. Ça devrait suffire non?

J’ai eu du mal à le retenir de tête.








alucard57 a écrit :



Moi j’ai juste sur Mozilla un mot de passe maitre à 16 caractères que j’ai tapé complétement au hasard, sans aucun sens avec des minuscules, majuscules et caractère spéciaux. Ça devrait suffire non?

J’ai eu du mal à le retenir de tête.





en espérant que tu sois pas obligé de le changer suite aux conneries de Mozilla. ^^

sinon y’a Keepass qui tourne très bien et qui utilise Argon2, lui. ^^









Carpette a écrit :



Mais ce serait fortement appreciable que l’utilisateur soit au moins mis au courant. Par exemple dans le centre de securite qui affiche l’etat des trucs principaux genre AV, firewall et maj, il serait fort appreciable d’avoir un rappel pour un mdp maitre. Voire une notification.





Je suis pas sur de voir l’intérêt. Ça dirait quoi exactement ?



Que sans mot de passe sur la session, tous les mots de passe stocké en local sont exposé à l’air libre ?

Que de toute façon sans identification forte sur la session type Windows Hello, la session est à risque car les mots de passe windows peuvent être brute-force (les rainbow tables fonctionnent encore sur Win10, en tout cas à sa sortie on pouvait récup le mdp comme ça) si on a accès au disque ?

Que sans chiffrage global avec un mot de passe fort y aura toujours des trucs à piquer car les devs sont des flemmards à ne pas chiffrer (filezilla), ou à chiffre avec des algo insuffisant (firefox) ?

Qu’il suffit d’un site malveillant exploitant une faille sur le navigateur pour qu’un keylogger s’invite chez vous et nique toutes vos protections ?



Je pense que l’utilisateur lambda s’en fout, et que l’utilisateur avancé s’en sera rendu compte ou le sait déjà au moment ou la machine/session démarre.



Sur, tu es peut-être dans l’entre-deux, à vouloir savoir qu’est-ce qui est sécurisé et qu’est-ce qui l’est pas, selon les cas et tout, mais ça c’est beaucoup trop complexe pour tenir en une ligne sur un panneau de sécurité. Y a des formations d’un an pour couvrir les bases, et après tu peux renquiller pour te spécialiser, alors…



Je pense que tu demandes l’impossible mais tu t’en ais pas encore rendu compte <img data-src=" />









alucard57 a écrit :



Moi j’ai juste sur Mozilla un mot de passe maitre à 16 caractères que j’ai tapé complétement au hasard, sans aucun sens avec des minuscules, majuscules et caractère spéciaux. Ça devrait suffire non?









hellmut a écrit :



en espérant que tu sois pas obligé de le changer suite aux conneries de Mozilla. ^^





L’algo utilisé pour protéger les mots de passe uniques est dépassé, et donc on peut déduire le mot de passe maitre en testant toutes les combinaisons sur la version chiffrée d’un des mots de passe unique. Après faut pouvoir testé chaque version du mot de passe unique, hors souvent ceux-ci sont derrière des protection anti-brute force…



Du coup la faille est pour moi assez théorique là, elle demande deux conditions qui ne sont pas sensé se produire, même seules.



Je ne pense pas que c’est impossible mais ca ne repondra a toutes les problematiques que tu as citees. D’ailleurs la discussion ne pretendait pas les solutionner.



Le principe etant d’avoir un message type “Les mots de passe stockes sont a l’air libre et ne seront proteges qu’une fois un mot de passe maitre etabli”. Au moins on attaque un maillon et pas des moindres. vault c’est quand meme les mdp IE, les connexions RDP et probablement tout un autre tas de conneries autour.



Franchement un mec qui vole un disque dur peut trouver du lourd. Note: c’est arrive dans l’etablissement d’un de mes proches. Le vol etait cible et visait des ordinateurs de certains metiers.



Apres si l’algo de chiffrement est correct ainsi que le mdp (disons au moins 8 caracteres) personne ne dechiffrera le conteneur en un temps humain.

Par exemple, bonne chance pour casser un fichier keepass ou gnome-keyring.



Sur mes ordis perso la solution est choisie depuis longtemps: la partition entiere est chiffree. De plus j’utilise linux qui a un decoupage des privileges tres net et bien sur mon systeme est a jour.








Carpette a écrit :



Le principe etant d’avoir un message type “Les mots de passe stockes sont a l’air libre et ne seront proteges qu’une fois un mot de passe maitre etabli”. Au moins on attaque un maillon et pas des moindres. vault c’est quand meme les mdp IE, les connexions RDP et probablement tout un autre tas de conneries autour.






 Vault n'est qu'une goutte d'eau dans l'océan des possibilités associé avec une session sans mot de passe. Tous les droits associés avec cet utilisateur que ça soit en locale (admin ou non) ou sur le réseau connecté sont aussi accessibles.   






Tu vois le problème par un certain coté, mais il est bien plus vaste, et pour le coup l’absence de mot de passe sur la session de l'utilisateur est peut-être l'un des plus petit, car pas si facile à exploiter (faut ouvrir une session à distance, ou prendre le disque, ou être admin local, ...).


Je crois qu’un collègue avait installé une connerie ou un Filezilla vérolé sur un poste au boulot. Tous nos sites se sont trouvés avec une injection de code pourri (portes dérobées, extraction de données serveur, etc.).

Pas de bol on était une agence web, avec les accès de prod…

Depuis, et surtout autres avoir lu que le développeur ne mettrait pas en place un mécanisme de protection “délibérément”, je suis aller voir pour une autre crèmerie. Les conneries ça va 5mn (“houuuu, regardez j’ai mis du base64 sur les mots de passe, truc de guedin !!”). Je ne sais pas si ça a changé récemment, mais c’est du foutage de gueule pour un projet utilisé par autant de monde.



Pour Vaut, je pensais que le conteneur offrait un mécanisme plus compliqué quand même :/.








MrKuja a écrit :



Je crois qu’un collègue avait installé une connerie ou un Filezilla vérolé sur un poste au boulot. Tous nos sites se sont trouvés avec une injection de code pourri (portes dérobées, extraction de données serveur, etc.).

Pas de bol on était une agence web, avec les accès de prod…

Depuis, et surtout autres avoir lu que le développeur ne mettrait pas en place un mécanisme de protection “délibérément”, je suis aller voir pour une autre crèmerie. Les conneries ça va 5mn (“houuuu, regardez j’ai mis du base64 sur les mots de passe, truc de guedin !!”). Je ne sais pas si ça a changé récemment, mais c’est du foutage de gueule pour un projet utilisé par autant de monde.



Pour Vaut, je pensais que le conteneur offrait un mécanisme plus compliqué quand même :/.





Huhu.



Je cite le dev admin de Filezilla, dans un post de forum de 2017:



“A master password does not offer any additional security. It is no more secure than not saving passwords at all, functionality that has already been in FileZilla for many years.Technically using a master password isn’t even as secure. If not saving passwords, keylogging malware can only intercept those passwords that are entered while the malware is running. With master passwords, it immediately gets access to all encrypted passwords as soon a the master password is entered.”&nbsp;Pour défendre une MAJ où, si l’on n’autorise pas le programme à stocker les mdps en fichier .xml (et en clair, toujours), il faut désormais les saisir deux fois de suite à la connexion.Un lien, en espérant que les numéros de page sont les mêmes pour tout le monde:https://forum.filezilla-project.org/viewtopic.php?t=64&start=1020



Winscp ftw :)



le problème avec cet argument c’est qu’évidemment si l’adversaire a accès à la machine et un key-logger t’es pwned, du coup ça milite pour le non stockage des passwords, donc pour des passwords faibles ou notés sur un post-it.

ça adresse pas du tout les autres menaces comme par exemple un accès fortuit à la machine (session laissée ouverte, password de session faible, etc…).

Donc il est bien gentil, mais l’argument du “pas de stockage de pass vaut mieux qu’un password maitre” est totalement débunké depuis des lustres. c’est totalement stupide, et dangereux.



il faut un password de session + un gestionnaire de pass style keepass avec un password maitre fort.

et si t’as un keylogger de toute manière t’es pwned, que les pass soient stockés ou pas.








hellmut a écrit :



le problème avec cet argument c’est qu’évidemment si l’adversaire a accès à la machine et un key-logger t’es pwned, du coup ça milite pour le non stockage des passwords, donc pour des passwords faibles ou notés sur un post-it.

ça adresse pas du tout les autres menaces comme par exemple un accès fortuit à la machine (session laissée ouverte, password de session faible, etc…).

Donc il est bien gentil, mais l’argument du “pas de stockage de pass vaut mieux qu’un password maitre” est totalement débunké depuis des lustres. c’est totalement stupide, et dangereux.



il faut un password de session + un gestionnaire de pass style keepass avec un password maitre fort.

et si t’as un keylogger de toute manière t’es pwned, que les pass soient stockés ou pas.





Je ne défendais pas Filezilla et la philosophie de son admin, bien au contraire ^^



Même s’il est acquis que la sécurité est potentiellement compromise dès qu’un accès physique est possible, il n’est pas excusable de baisser totalement les bras et faciliter au maximum la tâche aux gens malintentionnés.









Sabinoo a écrit :



Je ne défendais pas Filezilla et la philosophie de son admin, bien au contraire ^^





oui oui j’avais bien compris. <img data-src=" />



Je n’attend plus rien de Mozilla de toute façon depuis un pépin sans grande incidence mais qui révèle le manque considérable de sérieux de leurs équipes de développement.




 J'ai juste voulu déplacer mon profil d'une partition à l'autre... Mais je remarque que certains addons semblent "perdus" par ce changement parce que pour eux, les chemins étaient stockés en absolus. Pas grave, il suffit de les corriger dans le fichier de config qui s'occupe de ça, non ?       






 Sauf que... le fichier en question fait partie des QUATRE SEULES fichiers qui sont compréssés dans un format très récent nommé LZ4. Et en supplément, ils ont utilisé une ALPHA du LZ4 de l'époque dont même l'entête n'était PAS finalisée ! Et ils n'ont jamais updaté depuis alors que LZ4 est finalisé depuis un bail ! Du coup même le logiciel officiel du format s'y casse les dents ! Il faut passer par des scripts conçus par des gens extérieurs pour y parvenir.       






 Et selon les développeurs qui ont répondu au bugreport de gens qui se demandait WTF SERIOUSLY, cela prendrait trop de temps de retirer tout ça.&nbsp;    Ce qui en plus est extrémement douteux car c'est juste une étape de compression/décompression à supprimer !   






 Non mais sérieusement, pourquoi avoir ajouté un format non finalisé à l'époque pour seulement 4 fichiers de moins de CINQ KO CHACUN ?       






 Je n'attend plus rien de Mozilla simplement parce que les devs sont clairement des idiots.

Un post de ce type serait compréhensible en visant Microsoft, par exemple, ou une autre boîte privée. Pour Mozilla, on est dans de l’open source, donc dire que les dév sont idiots c’est un peu… idiot. Les dév ont peut-être d’autres priorités au niveau du projet, mais ils sont certainement ouverts à toute contribution qui permettrait d’améliorer l’appli. Faut juste s’y mettre, c’est un peu plus compliqué que critiquer…


Olà, les dévs de Microsoft en prennent pour leurs grades avec moi. J’ai toujours en travers du gosier le besoin pour eux d’aller au Nigéria afin de réaliser que la fibre 10 Gbit/s n’existait qu’à Seattle, et donc que les updates sans restriction de vitesse pouvaient géner. Comme si on disait des conneries en feedback…




  En fait c'est plutôt une tendance de fond, on dirait que les développeurs savent coder... mais ils ne savent pas UTILISER un ordinateur. Ou alors c'est la croyance que l'utilisateur ne sait pas véritablement ce qu'il veut (ça s'est diffusé à partir des années 2000), ou le développement de la méthode AGILE qui considère plus ou moins la même chose, je ne sais pas.        






   C'est vrai que si ma connexion est limitée, je n'ai absolument pas besoin d'un moyen de contrôler la dépense en BP mais d'une nouvelle app inutile, bande de gros dé[Censuré] de [Censuré] de m[Censuré] <img data-src="> du coup on jette le feedback utilisateur à la poubelle...        






  Pour mon histoire de fichiers Firefox, j'ai mis une bonne heure à trouver. Ça aurait été plus rapide de recréer le profil mais forcément au début je pensais que c'est un petit souci qui se corrigerait vite <img data-src="> ... et l'on ne réalise qu'à la fin à quel point ça a été improductif... tout ça pour une fonction que le bon sens statue comme "inutile" et surtout avec un format de compression ALPHA alors que le bon sens OBLIGE à attendre une v1 MINIMUM !  Si c'était le cas, je n'aurai mis que 5 mn à résoudre mon souci...   






  Alors oui, je pourrais tenter de contribuer... Mais je me vois mal passer dérrière une gaffe que le bon sens aurait dû empêcher dès le départ, ce qui demanderait ENCORE PLUS de temps. En ce moment j'ai l'impression de perdre pas mal de temps à compenser les gaffes qu'à exploiter mon PC. Compresser des fichiers de config de taille réduite, il faut vraiment être idiot pour faire ça, je persiste et SIGNE. Et quand bien même il aurait été prévu de tous les compresser (databases sqlite avec), ça pourrirait la vie des utilisateurs avancés ou motivés qui auraient besoin de les modifier. Il ne faut pas avoir fait une école d'ingénieurs pour le penser. Juste pour gratter quelques micro-secondes en utilisant la RAM pour la chargement... Un logiciel, ça se pense avant de se coder, on ne sort pas des fonctions ridicules pour la beauté du geste façon Wifi-Sense de Windows 10.       






  De plus, ce ne sont pas les projets qui manquent et qui auraient aussi besoin de développeurs de façon plus criante. Classic Shell par exemple est maintenant open-source... parce que son concepteur n'en pouvait plus, et personne ne suit car ça touche à l'infra Windows avec mass appels win32, arg... A titre personnel j'ai un logiciel INDISPENSABLE qui n'est plus suivi mais qui demande une haute connaissance de l'infra Windows aussi ainsi que du C++, j'aimerai contribuer mais c'est trop ardu pour un newbie en C#...

sur le fond, tu as raison, et je confirme en étant dans le métier que très souvent, les développeurs oublient que ce qu’ils font est censé être utilisé. Peut-être même par des vrais gens, sans connaissance technique :)


Fermer