Firefox 50 Cent

81
17
nov.
2016
Mozilla

La 50e version majeure de Firefox est sortie le 15 novembre 2016.
Raccourcis claviers, démarrage plus rapide, Emojis, Let’s encrypt, 27 failles corrigées mais aussi des projets plein la tête !

Logo de Firefox gold : http://www.dailyfreepsd.com/icon/software-icon/awesome-gold-silver-firefox-icon.html
     Design par Jeferson « wsaconato », sans licence explicite.

Sommaire

Les nouveautés de la version 50

Version bureau

  • Firefox 50 propose ses propres Emojis si le système d’exploitation ne contient aucune police avec Emoji (Windows 8.0 et inférieur, GNU/Linux) ;
  • l’outil de recherche de texte aura une option pour chercher sur les mots entiers de la page au lieu de chercher le texte partout (même en milieu de mot) ;
  • un paramètre permet de modifier le raccourci Ctrl + Tab pour parcourir les onglets dans leur ordre d’utilisation récente au lieu de parcourir, par position, dans la barre d’onglets : Paramétrage de l’option Accessible via about:preferences#general ;
  • 98 % des utilisateurs de Windows 7 ou supérieur peuvent utiliser WebGL ;
  • pour les utilisateurs de Windows et de Mac OS X, les vidéos EME peuvent utiliser le format WebM ;
  • protection lors du téléchargement contre un large panel d’exécutables sous GNU/Linux, Mac OS X et Windows ;
  • Ctrl + Alt + R permet d’activer le « mode lecture » depuis n’importe quelle page compatible ;
  • le démarrage est plus rapide, grâce à des performances accrues pour les extensions.

Du côté de chez GNU

La version GNU/Linux ne repose plus sur les bibliothèques logicielles libgnome et libgnomeui qui sont, de fait, obsolètes depuis longtemps (leurs fonctionnalités ont été consolidées dans GTK+ dans le cadre du projet Ridley qui préparait GTK+ 3) [bogue no 694570].

Notons par ailleurs que, du côté de Debian, on retente GTK+ 3 à l’occasion de cette version !

Et le mode multi‐processus, on en est où ?

L’avancement du projet Electrolysis dépend pour une bonne part du test des extensions pour s’assurer de leur compatibilité (et, le cas échéant, de leur modification pour fonctionner dans ce mode).

Vous voulez aider le projet à avancer plus vite ? Indiquez les extensions qui fonctionnent (ou pas) avec l’extension officielle Add‐on Compatibility Reporter. Une fois l’extension installée, une icône représentant une pièce de puzzle (le symbole habituel des extensions dans Firefox) apparaît à droite de la boîte de recherche sur le Web. Après avoir testé le comportement de vos extensions, cliquez sur cette icône pour :

  1. vérifier en bas du panneau que le mode multi‐processus est bien activé ;
  2. signaler quelles extensions fonctionnent et lesquelles dysfonctionnent (comme indiqué en détail ici).

Cela permet d’alimenter la base de données Are we e10s yet?.

Rappelons que les extensions s’appuyant sur la nouvelle API de WebExtension sont directement compatibles. D’après le calendrier, Mozilla souhaite augmenter, dans Firefox 50, la proportion d’utilisateurs utilisant Electrolysis de 6 à 12 % selon le calendrier.

Autorité de certification Internet Security Research Group : arrivée du certificat racine de Let’s Encrypt

Firefox 50 reconnait le certificat racine de l’Internet Security Research Group : ISRG Root X1. Auparavant, c’était Digital Signature Trust Co qui signait les certificats via Let’s Encrypt Authority X1 Let’s Encrypt Authority X3, pour qu’ils soient reconnus dans tous les navigateurs.
De plus amples explications sont disponibles sur le site letsencrypt.org.
Schéma de la chaîne de certification

Version Android

Au menu de la version 50 pour Android :

Communs à la version de bureau et mobile

Failles de sécurité

Vingt‐sept failles de sécurité ont été corrigées pour Firefox 50 : 3 critiques (CVE-2016-5296, CVE-2016-5289 et CVE-2016-5290), 12 élevées, 10 modérées et 2 basses. Six failles sont aussi corrigées pour Firefox ESR 45.5 : deux critiques (CVE-2016-5290 et CVE-2016-5296), deux élevées et deux modérées.

Pour les développeurs

Les développeurs bénéficient des améliorations suivantes :

Console Web

La console Web de Firefox 50 apporte les nouveautés suivantes :

  • possibilité de comprendre source maps (mais désactivé par défaut) bogue no 1289570 ;
  • les Memory Tools sont activés par défaut ;
  • amélioration du storage inspector pour IndexedDB ;
  • box model a désormais son propre onglet séparé de Computed View (note : pas chez moi, version 50) ;
  • amélioration de Web Console au niveau de Call Stack lors des requêtes XHR ou Fetch.

Installer Firefox

Les utilisateurs de versions Windows 32 bits (XP SP2 minimum), Windows 64 bits (Windows 7 minimum), Mac OS X en 32 ou 64 bits (version 10.9 Mavericks minimum) et GNU/Linux en 32 ou 64 bits peuvent installer cette nouvelle version de Firefox [source].

Idem pour les utilisateurs d’Android (version 4.0 Ice Cream Sandwich minimum, jusqu’à la dernière AOSP 7.1) sur x86 ou ARM (ARMv7 minimum) (page de téléchargement).

Firefox 50 AOSP 7.1

Une version spécifique (non basée sur le moteur de rendu développé par Mozilla) existe également pour iOS (version 8.2 minimum) [source].

Prochaines versions

Version 51

Firefox 51 bêta teste l’impact d’une restriction plus stricte de SHA-1 [source].

Version 52 ESR

Il s’agira de la dernière version dont la compatibilité sera assurée avec Windows XP et Vista. S’agissant d’une version ESR, les utilisateurs concernés auront jusqu’en mai 2018 pour trouver une solution. Ensuite, Windows 7 sera le point d’entrée de Firefox 53 du côté des aficionados du système d’exploitation de Redmond. À noter que LibreOffice, de son côté, réfléchit à laisser de côté Windows XP après la série 5.2.x.

L’API HTML5 BatteryManager permettant de connaître l’état de la batterie sur un ordinateur sera retirée de cette version. En effet, son usage est détourné pour pister les utilisateurs.

Cette version prendra en charge requestIdleCallback [source].

Ce sera aussi la dernière version à pouvoir faire tourner les greffons NPAPI (sauf le greffon Flash qui continuera d’être pris en charge encore un moment). Nous verrons dans la suite de la dépêche que Mozilla pourrait ne pas s’arrêter là pour la gestion des greffons. Vous pouvez lire une revue plus globale sur Flash dans la dépêche LinuxFr.org dédiée à cette technologie.

Version 53

Gecko faisait les contrôles sur la sécurité des contenus avant d’envoyer les requêtes que traitait Necko (API indépendante de la plate‐forme et ayant des fonctionnalités dans le réseau).
contrôle de sécurité dans Gecko
Dans Firefox 53, cette responsabilité de contrôle des contenus va être transférée de Gecko à Necko. Mozilla a publié un papier lors de la IEEE Cybersecurity Development 2016 [source].

Futures versions

Abordons à présent le futur de Firefox :

  • Mozilla cherche à améliorer la sécurité sur le Web, Firefox affichera une icône d’un cadenas barré quand vous rentrez un mot de passe sur un site n’utilisant pas la couche de sécurité TLS. Cela compliquera la possibilité de récupérer des mots de passe à l’aide d’une attaque d’homme du milieu : Cadenas barré Plus d’informations sur le billet Plus de mots de passe à travers HTTP, SVP ! (en anglais) ;
  • l’impression d’une page utilisera l’affichage « Mode de lecture » (proposé depuis Firefox 38.0.5) ; on peut espérer que les publicités d’une page Web ne seront plus imprimées [bogue no 962433] ;
  • le greffon Flash ne sera plus déclaré au site Web auquel Firefox se connecte [bogue no 1186948] ; pour cela, il faudra que le comportement du greffon soit à « Demander pour activer » (comportement par défaut depuis quelques versions) ;
  • amélioration du Debugger rewrite en HTML et de Console rewrite en HTML ;
  • le travail est toujours en cours dans Nightly pour permettre enfin l’accélération matérielle du rendu des pages Web via OpenGL sur la plate‐forme GNU/Linux. Il est prévu, avant qu’elle ne soit lancée dans Aurora/Beta/Release, de n’activer cette fonctionnalité que pour un certain nombre de pilotes testés comme ne posant pas de problème. C’est le travail en cours sur le [bogue no 1294232], basé sur l’extension GLX_MESA_query_renderer qui a été assez récemment ajoutée à Mesa 3D (version 10.3).
  • lors de l’échange de clés Diffie-Hellman, si votre site web utilise une clef ≤ 1 023 bits, Firefox refusera la connexion source ;
  • Firefox pourrait proposer de compartimenter votre navigation Web. Vous pourrez ouvrir une page de Facebook, Google ou autres traqueurs de vie privée, ces pages Web ignoreront les autres pages que vous avez ouvertes dans la même session ; ce sont les onglets contextuels dans Firefox Nightly et les conteneurs : Utilisation des conteneurs Peut‐être une piste d’évolution pour marier interface utilisateur innovante et vie privée et, par là même, se démarquer des autres navigateurs. Espérons que ce projet arrive rapidement et vivra plus longtemps que les groupes d’onglets Panorama.

Test Pilot : l’expérimentation continue

Trois extensions sont proposées par Mozilla pour avoir des retours utilisateurs :

  • Page Shot, pour une « capture d’écran » de la page Web ;
  • Min Vid, pour avoir la vidéo en cours toujours au premier plan ;
  • Tracking Protection, pour limiter l’action des pisteurs (trackers) qui cherchent à vous suivre sur la Toile.

WebExtension

Firefox 51 bêta voit arriver différentes mises à jour des WebExtensions (WebExtension a été introduite dans Firefox 48). Une de ces mises à jour apporte à l’API la gestion du multi‐processus. Les extensions pourront bénéficier à terme du bac à sable et du parallélisme en étant exécutées dans un processus distinct. Toutefois, aucune date d’échéance n’est donnée pour son arrivée dans Firefox stable (bogue de suivi et une vidéo de deux heures sur le travail effectué).

Autre amélioration, une désinstallation supprimera les données enregistrées localement [bogue no 1213990]. Il est possible de demander de conserver ces données locales, mais il faudra l’indiquer [bogue no 1220494].

Enfin, cette mise à jour de WebExtension apporte Native messaging, le wiki de Mozilla indique :

« Native messaging enables a WebExtension to exchange messages with a native application installed on the user’s computer. This enables native applications to provide a service to add‐ons without needing to be reachable over the Web. One common example here is password managers: the native application manages storage and encryption of passwords, and communicates with the add‐on to populate Web forms. Native messaging also enables add‐ons to access resources that are not accessible through WebExtension APIs, such as some particular piece of hardware._ »

Ce qui peut être traduit par :

« La messagerie native permet à WebExtension d’échanger des messages avec une application native installée sur l’ordinateur de l’utilisateur. Cela permet aux applications natives de fournir un service aux modules complémentaires sans devoir être accessibles sur le Web. Un exemple courant est celui des gestionnaires de mots de passe : l’application native gère le stockage et le chiffrement des mots de passe et communique avec l’extension pour remplir les formulaires Web. La messagerie native permet également aux modules complémentaires d’accéder à des ressources qui ne sont pas accessibles par l’intermédiaire d’API WebExtension, comme certains éléments matériels particuliers. »

[source]

Un billet de blog de Mozilla revient sur la migration en cours du système actuel des extensions vers le futur nouveau système basé sur WebExtension. Si les développeurs ont majoritairement contribué sur leurs besoins propres (documentations, corrections de bogues, retours d’utilisation), ce billet appelle aux bonnes volontés d’autres aspects :

  • rendre les API les plus agnostiques possibles, en effet, à terme, WebExtensions devraient fonctionner aussi bien sur Chrome et Opéra que sur Firefox (certaines rumeurs disent que Microsoft pourrait intégrer les WebExtensions à Edge) ; le billet rappelle ainsi qu’il ne sera plus nécessaire de connaître le fonctionnement particulier de Firefox ;
  • créer les API manquantes, si vous avez besoin d’une API n’hésitez pas à ouvrir un rapport de bogue à ce sujet. Les API les plus complexes en cours de traitement sont affichées sur un Kaban dédié [source].

Le site Are we WebExtensions yet? estime que la compatibilité des WebExtensions avec le Chrome Store est passée de 38,71 %, le 31 mars 2016, à 45 %, le 9 septembre 2016.

Projet Mortar

Le projet Mortar, qui signifie mortier en anglais, s’intéresse à deux points techniques dans Firefox :

PPAPI

Mozilla s’interroge sur le remplacement du système de greffons Netscape Plugin API (NPAPI), hérité de Netscape, par celui de Chrome Pepper Plugin API (PPAPI) . Est‐ce que la documentation de PPAPI est cette fois suffisante, claire et indépendante du moteur de rendu de Chrome pour Mozilla ? (conditions qui ont jusque‐là justifié le refus).

PDFium

De même, ce projet s’intéresse à PDF.js qui réalise la lecture des documents PDF au sein de Firefox (et qui peut être aussi utilisé au sein un site Web pour proposer des PDF en HTML). Mozilla pourrait le remplacer par PDFium, le lecteur de PDF de Chrome. Ce dernier permet de remplir les formulaires PDF (ce que ne sait pas faire PDF.js).

Révision en profondeur de Gecko

Arrivée du mode multi‐processus et des WebExtensions, purge du code spécifique à Firefox OS, abandon programmée de l’interface des greffons NPAPI, prochain abandon des versions XP et Vista de Windows… Quelque chose de gros serait‐il en train de se préparer ?

Nouvelle étape, majeure : le projet Quantum, ou l’hybridation Gecko‐Servo

Alors que le projet Electrolysis tend vers sa conclusion (basculement progressif de tous les utilisateurs), Mozilla dévoile le projet Quantum qui consiste à utiliser des portions de code cruciales en termes de performances et de sécurité du moteur de rendu Servo (programmé en Rust) dans le moteur de rendu actuel Gecko.
Mozilla espère que cela rendra son moteur de rendu plus véloce, capable d’utiliser au mieux le parallélisme des processeurs et aussi des processeurs graphiques [source].

Le projet Quantum est subdivisé en quatre sous-projets :

  • Quantum CSS, pour rendre le moteur CSS le plus parallélisable possible ;
  • Quantum DOM va rendre Gecko plus adaptatif, particulièrement dans le cas où de très nombreux onglets sont ouverts en arrière‐plan ;
  • Quantum Compositor, pour améliorer le code qui interagit avec les processeurs graphiques ;
  • Quantum Rendering remplacera le sous‐système de rendu graphique de Gecko par celui de Servo avec, là aussi, une place importante pour le processeur graphique.

Plus d’informations, notamment sur Quantum DOM sur tech.mozfr.org.

Derrière ce projet, Mozilla évoque éclairement la prochaine génération de moteur de rendu (Servo, le moteur de rendu codé en Rust, a toujours été déclaré comme une expérimentation : il n’est pas appelé à remplacer Gecko). Et c’est pour demain !

L’équipe de développement de Servo s’en réjouit (et fournit quelques chiffres spectaculaires à l’appui) !

Techniquement, les premières briques sont déjà posées :

La prochaine étape pourrait être la concrétisation dans quelques mois de Quantum CSS (alias le projet Stylo, permettant l’intégration du moteur de style de Servo dans Gecko).

Autour de Firefox

Mozilla : comment nous protégeons Internet avec votre aide

Ce billet de blog de Mozilla, traduit en français sur blog.mozfr.org, revient sur les différents actions de Mozilla pour la sécurité appuyée par sa communauté et les différents partenaires d’Internet. C’est un billet orienté grand public qui a le mérite de brosser toutes les initiatives de Mozilla dans ce domaine, mais la plupart sont sûrement connues des lecteurs de LinuxFr.org : Mozilla : comment nous protégeons Internet avec votre aide.
Lire aussi en complément, concernant le fonctionnement du Secure Open Source Fund ou SOS Fund : Le fonds de Mozilla qui sécurise l’open source et le Net.

Autorité de certification WoSign

Cette autorité de certification a joué au plus malin en anti‐datant des certificats pour leur permettre d’utiliser SHA-1, qui a été abandonné par les différents navigateurs Web. Les gens de Mozilla viennent de s’en apercevoir et ils n’apprécient pas du tout [source].
Bien sûr, les autres navigateurs ont été alertés et tout ce petit monde va sûrement se concerter pour savoir comment punir le fautif (la base de son métier est de fournir de la confiance, pas de jouer au malin) [source].

Servo/Rust

La feuille de route a été mise à jour pour inclure les objectifs du 4e trimestre et jeter quelques idées préliminaires pour 2017.

Après Firefox, c’est GNOME que Rust pourrait oxyder. Alors qu’une réflexion est en cours pour utiliser Rust dans les parties les plus exposées de GStreamer, Builder, l’environnement de développement intégré de GNOME permet dorénavant de travailler avec ce langage. Par ailleurs, Alberto Ruiz a récemment publié une réflexion sur l’utilisation principale de Rust dans GNOME.

À noter qu’il existe Corrode, un outil soutenu par Mozilla de traduction du code C en code Rust.

B2G OS

Firefox OS est mort et ses portions de code vont être retirées de Gecko, obligeant le projet communautaire Boot to Gecko (B2G) à réaliser un fork de Gecko pour survivre.

WebAssembly alias wasm

Ce format binaire dont les spécificités seront garanties par leur ouverture et leur standardisation, continue de progresser au sein de Chrome, EDGE et Firefox. Tous ces navigateurs invitent leurs utilisateurs à tester ce nouveau format (encore en phase de test) et à leur faire part de leurs retours. Ils espèrent figer la première au cours du premier trimestre 2017 et l’activer par défaut sur leur navigateur respectif.
Dans Firefox, pour activer WebAssembly, il faut aller dans about:config et activer javascript.options.wasm [source].

Aller plus loin

  • # B2G OS - l'esprit est encore là :)

    Posté par  (site web personnel) . Évalué à 10.

    (premier com' sur LinuxFR :) )

    Petite précision par rapport à B2G OS: le fork de Gecko n'est pas le seul choix, en fait, humainement (voir techniquement) c'est tout simplement intenable de maintenir un fork, à jour, qui suivrait les évolutions de Gecko (sinon, le code serait resté dans mozilla-central ^ ).

    Donc la solution envisagée actuellement pour garantir l'avenir de cet OS, où plutôt de ça philosophie (on ne bouterai pas directement sur Gecko, mais on garde le système de web app basée sur des standards, un code libre, respectueux de la vie privée, etc) tout en passant sur une base plus proche d'Android. Je m'explique:
    Au lieu d'avoir la base actuelle, gonk (noyau linux/android, HAL, …) + gecko qui démarre à la suite, on partirait sur une base d'AOSP ou de CyanogenMod (au besoin) sans SystemUI, avec juste un java runtime minimal (oui je sais, java, bref :D) qui lancerai l'apk qui serait en fait Fennec, ou Firefox pour Android.
    Le but c'est de récupérer Gecko par ce biais, donc pas de fork. Et de reconstruire par dessus, avec les fameuses web app standards (qui sont bien évidement supportées par Gecko/Firefox).
    Pour l'utilisateur ça serait transparent, pas de trace visuelle d'Android.
    Ça ressemble un peu à B2Gdroid, dans l'approche, même si techniquement y'a quelques couches en moins.

    C'est encore en phase d'expérimentation, toutes les bonnes volontés, notamment avec un peu d'expérience dans tout ce qui est bidouillage d'android, sont les bienvenues :)

    • [^] # Re: B2G OS - l'esprit est encore là :)

      Posté par  (site web personnel) . Évalué à 6.

      Ah tiens, ça semble pas une mauvaise idée ça :)

    • [^] # Re: B2G OS - l'esprit est encore là :) avec le saint esprit

      Posté par  . Évalué à 3. Dernière modification le 18 novembre 2016 à 01:11.

      Sur le thread officiel je n'avais pas tres bien compris l'idée, cela devient un peu plus clair avec ces explications. Cependant j'ai encore quelques doutes sur le fonctionement global du bouzin.

      FxOS serait donc une application qui tournerait sur une base Android. En somme un mobile sous Android amputé du machin SystemUI, avec une couche java. Donc la partie noyau Linux aux oubliettes ?

      J'espere me tromper et j'espere aussi que d'autres possibilites sont a l'études. Cependant si le projet part dans cette direction et je le sens vraiment pas ce truc, je pense vraiment laisser tomber.

      Je lis depuis un moment les discussions et j'ai la sensation qu'il manque en fait de personnes compétentes sur ce projet de grande envergure, qu'aucuns des développeurs ne semble encore avoir compris. C'est FirefoxOS koa ! C'est tout de meme du lourd, a tout les niveaux.

      Depuis le début je n'ai pas vu le moindre plan, aucun dessin au sens propre sur la direction que le projet devait prendre, et cela semble etre parti sur la meme voie actuellement pour la suite.
      Ajouté a cela, une exposition au monde exterieur égale a /dev/null, pas de site web dédié donc aucune entrée d'argent via de possibles dons, donc aucune chance de pouvoir attirer de nouveaux devs, ou l'attention des lecteurs.

      Le plus malheureux dans tout cela est que ce travail avait été proposé par plusieurs personnes aptent a s'investir dans ces objectifs, mais recroquevillé dans le code, le reste étant devenu secondaire, toute communication vers le monde exterieur interrompue, au final il ne restera que du code avec des devs ou des devs avec du code.

      attention chérie ça va moinsser

      • [^] # Re: B2G OS - l'esprit est encore là :) avec le saint esprit

        Posté par  . Évalué à 6.

        Je vais juste répondre sur ta première question: Firefox OS (pour sa partie gonk) a toujours utilisé la partie bas-niveau d'Android: noyau Linux, modules noyaux spécifiques Android, démons provenant d'Android. Donc pas de changement ici.

        Le changement concerne l'étape au-dessus. Dans Firefox OS, Gecko appelait directement les démons bas-niveau et les modules noyaux; par exemple pour afficher des pixels très rapidement. C'est ça que l'équipe se propose de changer en prenant le runtime dalvik (et ses classes standard donc) pour faire cela, comme sur un Android.

        • [^] # Re: B2G OS - l'esprit est encore là :) avec le saint esprit

          Posté par  . Évalué à 2. Dernière modification le 18 novembre 2016 à 13:56.

          Ca va ressembler a quelque chose comme ca ?

          ( Gonk: linux/android ) <-> ( AOSP ou Android sans systemUI ) <-> ( Dalvik ) <-> ( Fennec: FirefoxOS pour Android )

          attention chérie ça va moinsser

          • [^] # Re: B2G OS - l'esprit est encore là :) avec le saint esprit

            Posté par  . Évalué à 2.

            Je pense, oui. (Après, je ne suis pas dans le projet, je dis peut-être n'importe quoi :) )

          • [^] # Re: B2G OS - l'esprit est encore là :) avec le saint esprit

            Posté par  (site web personnel) . Évalué à 4.

            Gonk faisait partie de modifications de Gecko.
            Donc pas exactement: en gros, tu peux un android/CM classique, tu vire toute la partie système et interface (systemUI), en gardant le runtime Java qui interface avec le noyau & co (mais réduit au minimum syndical) et tu lance Fennec par dessus. Et les webapps tournent comme de simples pages web dedans (mais ça ressemble toujours au système, c'est transparent, comme avant)

            PS: coquille révélatrice: tu as écris FirefoxOS pour Android :P

      • [^] # Re: B2G OS - l'esprit est encore là :) avec le saint esprit

        Posté par  (site web personnel) . Évalué à 5.

        FxOS serait donc une application qui tournerait sur une base Android. En somme un mobile sous Android amputé du machin SystemUI, avec une couche java. Donc la partie noyau Linux aux oubliettes ?

        Petite précision: depuis la transition début avril, ce n'est plus Firefox OS, en tant que marque, on reparle de B2G, le nom de code du projet (deux noms pour la même chose, mais on n'utilise pas la marque, et ça permet de faire la différence). Sachant que le nom de Boot2Gecko peut devenir "impropre" si on ne boot plus directement sur gecko.
        Firefox OS / B2G est basé sur un noyau Android (=Linux avec quelques modifs), une couche HAL, + de la tambouille maison, en faible quantité, en relatif) rassemblés sous l'appellation Gonk.
        La différence ici, c'est qu'au lieu d'avoir Gecko directement par dessus, on a le Runtime Java (aussi minimal que possible), qui lance Gecko (via Fennec, Firefox pour Android, l'apk), et derrière, tout le système habituel.
        En gros, on rajoute le Runtime java entre deux, et ce n'est pas directement Gecko mais Fennec.

        Je lis depuis un moment les discussions et j'ai la sensation qu'il manque en fait de personnes compétentes sur ce projet de grande envergure, qu'aucuns des développeurs ne semble encore avoir compris. C'est FirefoxOS koa ! C'est tout de meme du lourd, a tout les niveaux.

        Au contraire, depuis le début on parle de ce problème de contribution, technique, là ou niveau com'/test/doc/traduction il a du monde, bien plus que de dévs'. Car oui il y a beaucoup de boulot, même si le système était déjà arrivé à un bon niveau de maturité (je veux dire, la base d'un smartphone est là, comparé à la concurrence on est loin niveau fonctionnalités, mais on pas vraiment pas de rien)
        Sauf qu'on ne les obtient pas en claquant des doigts.

        Depuis le début je n'ai pas vu le moindre plan, aucun dessin au sens propre sur la direction que le projet devait prendre, et cela semble etre parti sur la meme voie actuellement pour la suite.

        Depuis Firefox OS ou depuis la transition vers le projet communautaire ?
        Car on avait déjà un plan à court~moyen terme, repartir sur une base complète de standards libres, pour pouvoir profiter des progrès de l'écosystème (=des webapps développées pour les autres systèmes). Pas de plan précis sur du plus long terme, il fallait déjà passer ce cap pour tracer une route pour la suite.
        (et rassure-toi, beaucoup de contributeurs discutaient de la suite, de monts et merveilles, mais c'était trop tôt pour l'envisager sérieusement).
        On parlait aussi de définir la "vison commune du projet", le but de l'OS, en quelque sorte un manifeste, les grandes lignes de ce que l'on voulait en faire. Une philosophie en sorte, qui servirait à guider le projet, à définir un cap… à détailler quand on en aurait la possibilité.
        Idem actuellement: on en est à une phase de prototypage, pour savoir si on peut réellement faire survivre le projet (il semble que oui). Inutile de faire des plans sur la comète avec roadmap pour deux ans…

        Ajouté a cela, une exposition au monde exterieur égale a /dev/null, pas de site web dédié donc aucune entrée d'argent via de possibles dons, donc aucune chance de pouvoir attirer de nouveaux devs, ou l'attention des lecteurs.

        Des dons pour quoi ? Avec quelle base d'utilisateur alimenter/maintenir le site, avec quelles informations ?
        Alors oui on a beaucoup discuter de ça, la conclusion systématique c'était: on n'a rien de bien tangible à montrer qui puisse motiver un crowdfunding un peu important (pour payer des dévs, …).
        Tu payerai pour un projet qui te dis: on est en train de faire une transition depuis Firefox OS, en repartant sur des standards, mais rien de "+" (= de nouveau) pour l'utilisateur final avant quelques temps.
        Vu la taille de la communauté, les critiques massives sur le projet et mozilla, je pense qu'on serait allé au mur (+ perte de temps et d'efforts plus utiles ailleurs). Bonus: quelle structure pour accueillir les dons ? (et les utiliser) On créé une fondation/association/… avec toute la lourdeur que ça implique, si tôt ?
        Pour la com' du site, même problème. On avait déjà MDN, le wiki, discourse, etc. C'est amplement suffisant pour des contributeurs, et les utilisateurs (on ne visait pas encore le grand public, bien trop tôt).

        Justement, viser le grand public, aucune chance, bien trop tôt - c'était déjà pas encore possible pour Firefox OS.
        Viser les libristes et potentiels contributeurs ? /dev/null ? C'est quoi ça ? https://wiki.mozilla.org/B2G/Transition_Project/Call_For_Contribution#Version_Fran%C3%A7aise
        On a passé pas mal de temps sur les réseaux sociaux, ici, sur le forum FR de Firefox OS, sur le discourse de mozilla, bref, y'avait de la com', appelant à venir soutenir et participer au projet. Pour un résultat relativement mitigé (sur la fin ça commençait à décoller).
        (et beaucoup de bashing)

        Le plus malheureux dans tout cela est que ce travail avait été proposé par plusieurs personnes aptent a s'investir dans ces objectifs, mais recroquevillé dans le code, le reste étant devenu secondaire, toute communication vers le monde exterieur interrompue, au final il ne restera que du code avec des devs ou des devs avec du code.

        "Recroquevillé dans le code", pardon, mais qu'est ce qu'il ne faut pas entendre. Une dizaine de dévs, ~ 200 membres (dont quelques dizaines actives), beaucoup trop peu de contributions au code (d'où la lenteur d'avancement), alors que niveau doc/com' on a passé beaucoup de temps dessus (on était bien plus nombreux, c'est plus accessible) - en étant toujours limité par l'avancement technique. C'est un projet en manque de dév (viendez :D), pas un projet de dév enfermés entres eux.
        Tiens, un exemple: pendant ces deux phases j'étais un des membres les plus actifs, pas écrit une ligne de code. J'ai fais de la com interne/externe, de la doc, des traductions, des tests, mais pas de code. Comma la majorité des contributeurs. Et c'était ça le frein, le monde de contributions techniques.

        • [^] # Re: B2G OS - l'esprit est encore là :) avec le saint esprit

          Posté par  (site web personnel, Mastodon) . Évalué à 3.

          Petite précision: depuis la transition début avril, ce n'est plus Firefox OS, en tant que marque, on reparle de B2G, le nom de code du projet (deux noms pour la même chose, mais on n'utilise pas la marque, et ça permet de faire la différence).

          Y a une raison précise à cela? Mozilla n'autorise pas la communauté à développer le projet sous ce nom et leur a donc retiré le droit d'usage de la marque?
          Si c'est le cas, c'est un peu dommage, notamment car — comme tu le précises — le terme "Boot2Gecko" risque de devenir "impropre" techniquement (si ça ne boote plus directement sur Gecko justement), mais aussi car le nom FirefoxOS a quand même un peu fait parler de lui ces dernières années (alors certes pas jusqu'au très grand public, mais au moins chez tous ceux qui suivaient — ne serait-ce que de loin en lisant des articles — les news high-tech).

          Et puis c'est un peu plus classe (probablement car "Firefox", tout le monde connaît; "OS", au moins les gens un minimum au courant de la technique voit à quoi ça fait référence, notamment car d'autres boîtes utilisent le terme pour leur propre OS, genre "MacOSX/MacOS"; alors que "Gecko", faut être un geek qui suit Mozilla de près en particulier pour savoir qu'il s'agit d'un moteur de rendu).

          Donc si Mozilla vous autorise le nom de la marque, ce serait préférable à mon avis. :-)

          Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

          • [^] # Re: B2G OS - l'esprit est encore là :) avec le saint esprit

            Posté par  . Évalué à 5.

            Moi je trouve que c'est le nom Firefox OS qui est impropre depuis le début. Quand je vois la grande confusion qui existe déjà entre Cyanogen OS et CyanogenMod, je ne peux que penser que ce sera aussi foutoir de leur côté (rapports de bug dans le mauvais projet, "j'ai Firefox et je trouve pas l'appli " Contacts" dont tu parles, etc.).

            Autant se choisir un nouveau nom.

            • [^] # Re: B2G OS - l'esprit est encore là :) avec le saint esprit

              Posté par  (site web personnel) . Évalué à 2.

              Bah c'était un bonne idée pour utiliser la renommée de Firefox pour faire connaître le projet. Avec ce nom, on voit de suite à quoi il se rattache.
              En effet il y a quelques confusions, mais comparé à la visibilité marketing… je pense que c'est pas bête.
              Mais de toute façon, problème réglé, Firefox OS est mort.

          • [^] # Re: B2G OS - l'esprit est encore là :) avec le saint esprit

            Posté par  (site web personnel) . Évalué à 5.

            Salut Jehan :)

            Firefox est une marque Mozilla, on n'en a pas le droit d'usage pour ce projet.
            Je pense que c'est assez légitime, ce n'est plus un projet Mozilla. Ils mettraient leur légitimité en jeu dans les mains d'une communauté (encore petite) qui n'a pas les mêmes moyens, et qui est indépendante (mais parlerait "au nom de Mozilla"), c'est quand même prendre un gros risque.
            Surtout vu le bashing régulier contre Mozilla, dans les médias comme chez les libristes, niveau crédibilité ça pourrait leur faire du mal.
            Justement, la presse a tellement parlé de "Firefox OS est mort !" en criant à la catastrophe avant l'heure, puis quand le projet a été arrêté sur smartphone, que c'est presque une mauvaise idée de garder le nom ^
            (alors que pour le coup, leur dernier communiqué cite la reprise communautaire possible - mais difficile - et ça la presse l'a bien relayé. Ça nous prépare le terrain ?)

            B2G, si ça devenait impropre, et ben on changerait le nom, on n'est plus à ça près.

      • [^] # Re: B2G OS - l'esprit est encore là :) avec le saint esprit

        Posté par  (site web personnel) . Évalué à 1.

        Ah j'oubliais: dans le brouillon de manifesto, on y avait écrit que le système devait être développé par les dévs pour les utilisateurs, donc en fonction de leurs besoins/demandes/etc. Et non l'inverse, un outil de geek pour des geeks, avec une UX pas terrible, etc.
        C'était même un argument pour que les utilisateurs choisissent le système: le respect de la vie privée, nécessaire, ne suffit pas à attirer un public relativement large. Faut pas que le téléphone soit pénible à utiliser, au contraire, faut que ça soit plaisant. (un genre de: venez pour son aspect ouvert et respectueux, restez pour son UX )
        Ça me semble pas être l'objectif d'un projet fermé sur le code, d'un délire de développeur.

    • [^] # Re: B2G OS - l'esprit est encore là :)

      Posté par  (site web personnel) . Évalué à 3.

      Merci de cette nouvelle qui montre encore une fois que l'open source reste une bonne idée et sa communauté a de bonnes idées.

      Peux tu me dire où l'on peut avoir des news sur l'avancement de ce projet ? Une ML ? Un blog ? Un forum ?

    • [^] # Re: B2G OS - l'esprit est encore là :)

      Posté par  . Évalué à 5.

      Avoir Dalvik au lieu d'un runtime "personnalisé", ça ne va pas plomber les perfs?
      Parce que vu de ma fenêtre d'ignare:
      Linux-HAL-Dalvik-App native Android
      Linux-HAL-Dalvik-Gecko-App web
      Y'a une couche de plus d'un côté que de l'autre, non?

      Je dirais même: ça changerait quoi si j'avais le Gecko de B2G comme app sur mon téléphone là maintenant tout de suite?

      Je pensais que FFOS semblait mieux adapté aux petites configs que Android. S'il faut mettre Android en-dessous, c'est perdu, non?

      • [^] # Re: B2G OS - l'esprit est encore là :)

        Posté par  . Évalué à 6.

        Je pensais que FFOS semblait mieux adapté aux petites configs que Android.

        Pourquoi ? En quoi gecko/*monkey est plus performant que dalvik ? Je veux dire, qu'est-ce qui te fait dire que gecko est mieux ?

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: B2G OS - l'esprit est encore là :)

          Posté par  . Évalué à 3.

          Très franchement, c'est surtout le fait que FFOS était proposé sur des téls très bas de gamme et les essais semblaient dire que ça tournait pas mal. Je n'ai aucun benchmark et je n'ai jamais eu de tél avec FFOS dans les mains.

          • [^] # Re: B2G OS - l'esprit est encore là :)

            Posté par  (site web personnel) . Évalué à 6.

            Les premiers téléphones avec Android devaient être des veaux par rapport au "bas de gamme" de 2014 sous FxOS.
            Par ailleurs depuis quelques messages ça ressasse la rengaine "haha Java caca pfffrt" mais à part démontrer qu'on a rien compris au sujet ça n'apporte pas grand chose. Ma JavaCard programmable sur laquelle je peux mettre des applet a 80ko de mémoire totale et est alimentée par le contact avec la SIM, du coup je comprends plus, Java c'est léger ou pas ? Le rapport entre Dalvik et JEE, à part la syntaxe…

            • [^] # Re: B2G OS - l'esprit est encore là :)

              Posté par  (site web personnel) . Évalué à 2.

              Les premiers téléphones avec Android devaient être des veaux par rapport au "bas de gamme" de 2014 sous FxOS.

              Et c'était pas le même android/noyau linux/etc qu'aujourd'hui. C'est pas comparable.

              Par ailleurs depuis quelques messages ça ressasse la rengaine "haha Java caca pfffrt" mais à part démontrer qu'on a rien compris au sujet ça n'apporte pas grand chose. Ma JavaCard programmable sur laquelle je peux mettre des applet a 80ko de mémoire totale et est alimentée par le contact avec la SIM, du coup je comprends plus, Java c'est léger ou pas ? Le rapport entre Dalvik et JEE, à part la syntaxe…

              Rajouter une couche ajoute un temps de calcul (+ consommation) supplémentaire. Mais ça n'a pas l'air d'être vraiment impactant sur les perfs (ça reste un peu plus léger qu'avoir un Android "complet").

      • [^] # Re: B2G OS - l'esprit est encore là :)

        Posté par  (site web personnel) . Évalué à 3.

        Oui, ça fait une couche de plus, donc un peu de perfs en moins (interpréteur java puis JS).
        Mais la différence ne semble pas énorme.

        Je dirais même: ça changerait quoi si j'avais le Gecko de B2G comme app sur mon téléphone là maintenant tout de suite?

        Très grosso merdo, c'est comme avoir ton système qui tourne dans ton onglet Firefox (bon y'a plein de trucs en plus qu'on enlèverait, mais tu as l'idée).

        Je pensais que FFOS semblait mieux adapté aux petites configs que Android. S'il faut mettre Android en-dessous, c'est perdu, non?

        C'était une des tactiques initiales. Mais en arrivant un peu tard, on s'est rendu compte qu'android avait réussi à s'adapter à de petites configs bien mieux qu'on ne pensait.
        (dans l'absolu niveau mémoire on pouvait tourner (péniblement) avec 256Mb)
        Ça m'énerve pas mal d'ailleurs, maintenant un téléphone de milieu (voir entrée) de gamme a une config' très décente, digne d'un ultraportable actuel ou de bon pc d'il y a quelques années… Qui tournent parfaitement bien, or sur ces portables android broute.
        Et ils ont montrés qu'ils on peu devenir plus léger au besoin. Pourquoi ça ne serait pas le cas pour tout le monde ?

        "Android" était déjà "dessous", mais pas le Java Runtime.

        • [^] # Re: B2G OS - l'esprit est encore là :)

          Posté par  . Évalué à 4.

          Qui tournent parfaitement bien, or sur ces portables android broute.

          C'est pas du tout le ressenti que j'ai (mon 4*1.2GHz1 avec 1Gio ne bronche pas et c'est une config qu'on aurait pu imaginer sur portable il y a pas mal d'années 2Gio étant la norme depuis longtemps). À coté de ça, Firefox me gêne de plus en plus (alors qu'il y a encore un ans je le vivais bien, avec 4*1.9GHz1 et 16Gio de RAM)… Tu as quelque chose d'autres que du ressenti ? Gecko me pourri la vie et l'avoir sur mon portable ne m'enchante pas le moins du monde. Là où dalvik a évoluer dans la bonne direction avec ART par exemple.


          1. Sachant que l'un c'est de l'ARM et l'autre du Core i5 et qu'à fréquence égale égale Intel devrait pourrir la CPU ARM. 

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: B2G OS - l'esprit est encore là :)

      Posté par  (site web personnel) . Évalué à 2.

      Par contre je me souviens il y a quelques mois d'un billet de la communauté Mozilla francophone qui démontait Fennec à cause de ses performances, en espérant qu'il rattrappe la concurrence (pas retrouvé le lien).
      Du coup, ça fait un peu peur de ce dire que Fennec fera tout tourner..?

  • # Sécurité, CA, certes. Et DANE ?

    Posté par  (site web personnel) . Évalué à 4.

    Je lis « Mozilla cherche à améliorer la sécurité sur le web », je n’en doute pas, c’est presque leur cœur de métier, au moins indirectement.
    Je lis aussi « [WoSign] a joué au plus malin en anti-datant des certificats et leur permettre d'utiliser SHA-1 ». Et ils veulent virer WoSign. C’est une très bonne idée aussi.

    Mais seulement, quand j’entends parler sécurité et CA dans la même dépêche, je ne peux pas m’empêcher de me demander quand est-ce que l’on aura une implémentation native (c’est à dire autrement que par un greffon) de DANE et du DNSSEC dans firefox ? Je pense qu’il est à peu près établi que le problème de x509 sont les CA. Avec DANE on peut s’en passer. On a une RFC pour ça. Qu’est-ce qui empêche de s’y mettre ?

    • [^] # Re: Sécurité, CA, certes. Et DANE ?

      Posté par  . Évalué à 1.

      DNSSEC ne devrait pas plutôt être généré au niveau du service de résolution de l'OS ?

      • [^] # Re: Sécurité, CA, certes. Et DANE ?

        Posté par  (site web personnel) . Évalué à 5.

        La vérification de la validité du DNSSEC est faite par le résolveur (et non par l’OS, la glibc prend ça pour argent comptant), mais c’est bien à firefox de s’occuper du TLSA (ce qu’il y a derrière le DANE).

    • [^] # DANE: on met pas toute sa sécurité dans un seul panier ??

      Posté par  . Évalué à 5.

      DNSSEC est malheureusement peu utilisé, même par des structures où ils ont les moyens d'obtenir des compétences sur ce sujet:
      Domaines Signés avec DANE parmi les sites internet les plus populaires
      source
      Assez surpris qu'autant de DNS aient une péremption de moins d'heure. Dans le cas d'une migration, je veux bien, mais dans le reste du temps, cela me semble générer un trafique inutile.

      Si comme toi, je souhaite qu'il ait une alternative aux Autorités de Certification, je profite de ce commentaire pour poser cette question: Es-ce que déléguer de la sécurité à DNS n'est pas dangereux ?
      Je m'explique: dans ma GULL j'ai débattu sur l'intérêt de DKIM et surtout SPF. Ce dernier permet de déclarer d'où doivent provenir les courriels légitimes. Cette déclaration se fait au sein du DNS. J'ai été assez surpris d'entendre que certains informaticiens ne sont pas chaud pour lier encore plus SMTP à DNS. Sûrement une crainte que DNS ne devienne trop central et aussi la difficulté à gérer la dette historique du mail où la sécurité et l'authenticité des messages ne sont pas des priorités.
      L'attaque contre DYNS peut leur donner raison: on est surpris qu'autant de grands du Web n'avait pas plus de redondance pour leur serveur DNS et que ce dernier n'était que dans un seul AS!

      Après, je pense que Mozilla a des cartes en main pour pousser à l'usage de DANE:

      • avec Let's Encrypt, ils ont une possibilité d'automatiser l'envoi des information nécessaires au sein du DNS. Inconvénient: cela va complexifier/fragiliser l'usage de Let's Encrypt. Mais dès que cela marche une fois, le mécanisme automatique va faciliter bien des choses.
      • avec Firefox, Mozilla peut intégrer nativement DANE dans son navigateur. Mais sauf erreur la gestion du DNS est dévolu à l'OS. Cela obligerait Mozilla à faire un service DNS multiplateforme.

      Et avant l'usage de DANE, il faudrait que l'usage de DNSSEC soit plus répandu et c'est clairement pas le cas. Cela sert à quoi d'avoir DANE nativement dans son navigateur si le DNS de ton FAI n'est pas sécurisé par DNSSEC? (Sauf erreur en France, seul Free le fait).

      Si Mozilla a la possibilité de pousser au niveau des émetteurs et des récepteurs, comment va-ton gérer lorsque les données entre le DNS et l'AC seront contradictoires ? On considère que DNS a toujours raison (alors qu'il est peut-être juste pas à jour)? On averti l'utilisateur? (quand on voit la difficulté pour lui expliquer les certificats auto-signés …).

      Une question pour les Admin Sys, Mozilla utilise t-il DNSSEC pour ses sites web ??

      • [^] # Re: DANE: on met pas toute sa sécurité dans un seul panier ??

        Posté par  (site web personnel) . Évalué à 5.

        Je vais essayer de répondre dans l’ordre.

        Globalement, le DNSSEC est très peu déployé parce que ça ne sert pas à grand chose d’un point de vue business. Par contre, si ça permet d’avoir un petit logo vert dans la barre d’adresse, il y a moyen que ça en fasse bouger certains.
        C’est un peu comme le BCP38 chez les opérateurs…

        D’ailleurs, en parlant de BCP38, s’il était systématiquement déployé, il n’y aura plus de soucis d’attaque par amplification avec le DNS (mais avec des si on met Paris en bouteille…).
        Mettre de la sécurité dans le DNS n’est pas plus dangereux que d’utiliser le DNS tout court. Mais on a l’avantage d’avoir un système certes hiérarchique, mais décentralisé. Là où le système des CA est totalement centralisé.

        Pour SPF et DKIM (tout comme DMARC), ce sont des fioritures développées par les grands silos du mail pour faire chier les petits. Dans les faits, ça ne change presque rien, mais si tu ne l’as pas t’es un spammeur. Là, l’enjeu est tout autre, il s’agît d’arrêter de dépendre d’autres silos. Et avec DANE, c’est possible.

        Si dyndns avait tous ses NS dans un seul AS, bah j’ai envie de dire « mauvis admin, changer admin ». Le problème est le même si on met tous ses MX dans le même AS (et si son cœur de métier est de servir du mail).

        Je te rejoins pour le coup des FAI qui ne font pas de vérification DNSSEC. Là, je n’ai pas de réponse, rien ne les empêche de le faire. Mais après, c’est toujours pareil, on va te dire « Ça coûte combien ? » suivi de « Ça va nous servir à quoi ? ». Si les navigateur poussent cette technologie, il y a des chances pour que ça change.

        Et justement, tu parles de let’s encrypt. Ils ont réussi à pousser x509 à l’époque de netscape, ils poussent maintenant let’s encrypt. Pourquoi pas DANE ?

        Après, pour les questions de quoi faire quand la vérification classique de x509 et DANE se contre-disent, je ne sais pas. Je pense que ce sont des questions qui se réglerons en fonction de l’évolution. Si plus de monde utilise DANE, alors osef des CA. Si ça reste comme ça, on reste comme ça. Après, on peut aussi imaginer que ça soit réglable dans les préférences, comme l’est l’OSCP par exemple.

        Je ne connais pas tous les domaines de mozilla, mais mozilla.org est signé avec DNSSEC.

        J’espère avoir répondu à tes questions, dis moi si ce n’est pas clair.

        • [^] # Re: DANE: on met pas toute sa sécurité dans un seul panier ??

          Posté par  . Évalué à 5.

          Pour SPF et DKIM (tout comme DMARC), ce sont des fioritures développées par les grands silos du mail pour faire chier les petits. Dans les faits, ça ne change presque rien, mais si tu ne l’as pas t’es un spammeur.

          Et on règle comment le problème de l'authenticité des mails? Autrement qu'en utilisant GPG ou regardant les entêtes? Donc en étant lambda compatible ? Je suis bien d'accord que Gmail, Hotmail & Co ont bien trop de poids dans le flux des mails mais je n'arrive pas à comprendre comment je peux aussi facilement usurper un mail, juste en mentant sur le champ FROM.

          Après il est vrai que cela ne te donne pas de la sécurité, tu ne fais qu'offrir de la sécurité pour les autres en évitant que tes domaines ne servent d'émetteur à SPAM.

          Pour les FAI et DNSSEC, je pense que c'est de la responsabilité d'agence comme l'ANSSI de pousser vers ce genre de solution. Comme ils doivent pousser à plus de redondance sur les DNS. Avoir un internet robuste est devenu un enjeux majeur de sécurité de souveraineté dans notre monde actuel.
          Après je comprends que l'ANSSI a fort à faire pour renforcer la sécurité dans les services vitaux et que le DNSSEC des FAI c'est pas une priorité.

          • [^] # Re: DANE: on met pas toute sa sécurité dans un seul panier ??

            Posté par  (site web personnel) . Évalué à 2.

            Et on règle comment le problème de l'authenticité des mails? Autrement qu'en utilisant GPG ou regardant les entêtes? Donc en étant lambda compatible ? Je suis bien d'accord que Gmail, Hotmail & Co ont bien trop de poids dans le flux des mails mais je n'arrive pas à comprendre comment je peux aussi facilement usurper un mail, juste en mentant sur le champ FROM.

            Le problème de l’authenticité des mails est un vaste débat… Le problème majeur est qu’il n’y a aucune corrélation entre les entêtes SMTP et les entêtes du mail en lui-même. Absolument comme ce qui est marqué sur l’enveloppe que voit la poste, et ce qui est marqué dans la lettre qu’elle contient. Exemple :

            12:30 alarig@kaiminus ~ % telnet togepi.gozmail.bzh smtp
            trying 2a00:5884:124::1...
            Connected to togepi.gozmail.bzh.
            Escape character is '^]'.
            220 togepi.gozmail.bzh ESMTP Postfix
            HELO kaiminus.swordarmor.fr
            250 togepi.gozmail.bzh
            MAIL FROM: <alarig@gozmail.net>
            250 2.1.0 Ok
            RCPT TO: <alarig@gozmail.net>
            250 2.1.5 Ok
            DATA
            354 End data with <CR><LF>.<CR><LF>
            From: <alarig@swodarmor.fr>
            To: <alarig@swordarmor.fr>
            Subject: Faux destinataire et emetteur
            
            Coucou.
            .
            250 2.0.0 Ok: queued as 7CD291A0075
            QUIT
            221 2.0.0 Bye
            Connection closed by foreign host.
            zsh: exit 1     telnet togepi.gozmail.bzh smtp
            

            Et si je regarde ma boîte gozmail, j’ai bien un mail en provenance et à destination de mon adresse swordarmor. Tout simplement parce que postfix ne regarde pas du tout ce que l’on met dans la commande DATA, et que c’est là-dedans que l’on met les entêtes affichées par le client mail.

            Après il est vrai que cela ne te donne pas de la sécurité, tu ne fais qu'offrir de la sécurité pour les autres en évitant que tes domaines ne servent d'émetteur à SPAM.

            Même pas, ça empêche son domaine de servir d’émetteur à spam que si le domaine en face vérifie le DKIM et le SPF. Et encore faut-il que le message soit rejeté si ça ne correspond pas aux valeurs annoncées dans le DNS, ce qui en pratique n’est pas fait, car ça casserait pas mal de choses, à commencer par les listes diffusion. On le voit avec DMARC (qui est juste un publication de la politique de traitement à appliquer pour ce genre de cas).
            Et pour revenir au thème principal, sans DNSSEC, un attaquant peut répondre de fausses entrées SPF et DKIM et ainsi le mail passera même si toutes les protections ont été mises en place.

      • [^] # Re: DANE: on met pas toute sa sécurité dans un seul panier ??

        Posté par  (site web personnel) . Évalué à 6.

        comment va-ton gérer lorsque les données entre le DNS et l'AC seront contradictoires ?

        De deux choses l’une :

        a) L’enregistrement TLSA est de type PKIX-TA ou PKIX-EE, ce qui signifie que la chaîne de certification présentée par le serveur doit être validée à la fois par PKIX (c’est-à-dire les autorités de certifications présentes dans le magasin du navigateur) et par DANE. S’il y a discordance entre les deux (PKIX dit que le certificat est valide mais il ne correspond pas à aucun enregistrement TLSA, ou inversement le certificat correspond à un enregistrement TLSA mais n’est pas valide du point de vue de PKIX), alors la chaîne de certification n’est pas valide.

        b) L’enregistrement TLSA est de type DANE-TA ou DANE-EE, ce qui signifie que seules les informations du DNS sont à prendre en compte. Peu importe que le certificat soit, du point de vue de PKIX, invalide (par exemple parce que signée par une CA inconnue du navigateur), s’il correspond à l’enregistrement TLSA, il est valide.

    • [^] # Re: Sécurité, CA, certes. Et DANE ?

      Posté par  . Évalué à 4.

      Bonne nouvelle, Mozilla a donné 25000$ à 1. Et du coup le bug [3] sur Bugzilla a été rouvert le mois dernier :)

      Tu peux contribuer à [1] peut-être ? ;)

      [1] https://www.getdnsapi.net/
      [2] https://blog.mozilla.org/blog/2016/06/22/mozilla-awards-385000-to-open-source-projects-as-part-of-moss-mission-partners-program/
      [3] https://bugzilla.mozilla.org/show_bug.cgi?id=672600

      • [^] # Re: Sécurité, CA, certes. Et DANE ?

        Posté par  (site web personnel) . Évalué à 1.

        Je ne connaissais pas ces projet. Merci :)
        Pour ma part je ne suis pas développeur pour deux sous (je suis admin réseau), donc je vais voir du mal à leur pondre du code, mais je me garde ça sous le coude :)
        (et unbound++, donc ça ne peut être que bien :)

  • # Flexibilité du développement

    Posté par  . Évalué à -9. Dernière modification le 18 novembre 2016 à 09:25.

    L'avancement du projet Electrolysis dépend pour une bonne part du test des extensions

    Du coup, si je comprends bien, ça veut dire que l'introduction d'une nouvelle feature dans Firefox est retardée parce qu'il faut attendre que l'écosystème des extensions se mette à jour.

    Là, comme ça, ça ne fait pas très envie. Ça veut dire que le développement de Firefox est contraint par le développement d'extensions indépendantes qui s'interfacent avec FF. J'ai du mal à voir l'intérêt d'un système d'extensions (au moins en terme de cycle de développement) dans un tel contexte ; si la compatibilité d'un certain nombre d'extensions est cruciale, alors elles devraient être incluses dans le code principal (puisque de toutes manières il faut les attendre pour balancer une release), mais là, je trouve que les rapports de force entre l'équipe de FF et les développeurs d'extensions semble étrangement inversés.

    • [^] # Re: Flexibilité du développement

      Posté par  . Évalué à 10.

      En fait, il y a certes quelques extensions qui sont utilisées par beaucoup de monde, mais celles-ci sont pour la plupart déjà compatibles.

      Le problème concerne plutôt les nombreuses extensions utilisées par juste quelques personnes qui ne peuvent pas vivre sans. C'est pourquoi l'introduction d'e10s est très très progressif pour pouvoir petit à petit réparer les problèmes de ces extensions sans perdre des utilisateurs qui perdraient leurs extensions.

    • [^] # Re: Flexibilité du développement

      Posté par  (site web personnel) . Évalué à 10.

      Ça veut dire que le développement de Firefox est contraint par le développement d'extensions indépendantes qui s'interfacent avec FF

      Tu découvres la dette technique que maintenant?
      C'est depuis le début de l'informatique qu'on a des problème de gestion du passé, tiens on a toujours de la gestion 32-bit dans Linux, les mails qui transportent les pièces jointes en base64 (donc consomment 33% de plus que nécessaire), que plein de sites ne sont pas "aux dernières modes" pour supporter les vieux navigateurs etc…

      Bref, oui, il faut gérer l'éco-système, et ça met du temps de faire bouger tout le monde, c'est la vie, et c'est normal sauf à vouloir virer 1% par ci par la (les gens n'utilisent pas les mêmes extensions vitales…)

      un certain nombre d'extensions est cruciale, alors elles devraient être incluses dans le code principal

      Si quelqu'un a développé, c'est que c'est crucial (pour lui). reste à définir "crucial" pour le logiciel central, et ce n'est pas aussi simple que tu veux le croire.

      J'ai du mal à voir l'intérêt d'un système d'extensions

      Tu peux n'avoir rien à faire d'un éco-système, mais en pratique c'est l'éco-système qui fait que tu es utilisé ou pas. Si tu n'y vois pas d’intérêt, je te conseille de te renseigner sur l'histoire de Mozilla (qui a eu du succès au début avec cette idée des extensions plus que son support des sites webs)

    • [^] # Re: Flexibilité du développement

      Posté par  . Évalué à 10.

      Moi je trouve sain que Mozilla se préoccupe de l'usage qui est fait de son produit. Les extensions sont la raison principale pour laquelle j'utilise FF et je suppose ne pas être le seul dans ce cas.
      IMHO, cela ne veut pas dire qu'il faut aller jusqu'à inclure des extensions dans le cœurs (c'est très mal passé pour la tentative pocket). Car cela augment la taille du logiciel inutilement. L'idée même d'un système d'extension est bien d'avoir un cœur réduit qui soit "étendable".
      Les releases ne sont bloquées que lorsqu'il y a un changement majeur des API voire de l'architecture du logiciel comme pour e10s. Lors des changements mineurs, c'est plutôt les mainteneurs d'extensions qui font les ajustements.

      • [^] # Re: Flexibilité du développement

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        s/étendables/extensibles

      • [^] # Re: Flexibilité du développement

        Posté par  . Évalué à 10.

        IMHO, cela ne veut pas dire qu'il faut aller jusqu'à inclure des extensions dans le cœurs (c'est très mal passé pour la tentative pocket). Car cela augment la taille du logiciel inutilement. L'idée même d'un système d'extension est bien d'avoir un cœur réduit qui soit "étendable".

        Oui mais non c'est pas comme ça que ça se passe et heureusement (pour Firefox comme les autres) :)

        Historiquement, dans le projet mozilla, de nombreuses fonctionnalités ont existé sous forme d'extensions avant d'intégrer le logiciel de base. Pour donner quelques exemples : les onglets (et oui, en 2002 il fallait une extension appelée MultiZilla pour avoir des onglets !), pouvoir réorganiser les onglets à la souris, le bloqueur de popups, le gestionnaire de téléchargement, la synchronisation des marque-pages, la correction automatiques des erreurs courantes de saisie d'une url, annuler la fermeture d'un onglet, "copier et aller" dans le champ d'adresse, zoomer une image, la correction orthographique dans les formulaires, l'autocomplétion des champs de formulaire, zoomer/dézoomer la page ou le texte, le partage de liens, épingler des onglets, le mode plein écran…

        Personne ne voudrait utiliser un navigateur sans ces fonctionnalités parce que tout le monde considère qu'elles font parties des fonctionnalités attendues du logiciel mais ce n'a pas toujours été le cas et je me souviens encore de débats d'il y a une quinzaine d'années qui disaient que les onglets étaient une fonctionnalité uniquement pour les utilisateurs très avertis et que ça ne devrait pas être intégré dans Netscape 6.

  • # bonnes pratiques de programmation

    Posté par  . Évalué à 10.

    J'avoue ne jamais avoir plongé dans le code de FF. Mais quand tu pointes

    protection lors du téléchargement contre un large panel d'exécutables sous GNU/Linux, macOS et Windows ;

    avec un lien vers le fichier source ApplicationReputation.cpp, cela fait un peu peur.

    Cela commence à la ligne 399 : // Extracted from the "File Type Policies" Chrome extension
    Pour finir à la ligne 682. Soit presque 300 lignes pour lister des extensions de fichiers qui auraient pu être mises dans un fichier de configuration ou à la rigueur dans une liste.

    Je suis perplexe.

    D'autre part, ce code n'explique finalement pas en quoi consiste cette "protection".
    Ceci l'explique un peu.

  • # Du certificat racine de Let's Encrypt

    Posté par  (site web personnel) . Évalué à 10.

    Firefox 50 reconnait le certificat Racine de l’Internet Security Research Group: ISRG Root X1. Auparavant c'était Digital Signature Trust Co qui signait les certificats via Let's Encrypt Authority X1 Let's Encrypt Authority X3 pour qu'ils soient reconnus dans tous les navigateurs.

    À noter que cette reconnaissance est un début, mais ne sera utilisable en pratique que quand tous les navigateurs majeurs en auront fait de même. J'explique…

    Le modèle X.509, et en particulier le format de certificats, présente depuis ses débuts une limitation majeure, en ce qu'un certificat ne peut porter qu'une seule signature d'autorité de certification. Soit dit en passant, c'est cette limitation technique qui impose un modèle de confiance pyramidal, par opposition à la toile de confiance de systèmes de OpenPGP, et qui a d'importantes conséquences négatives en matière d'organisation et de sécurité : c'est à cause de cela qu'il y a peu d'autorités de certification, qu'il est difficile d'en créer de nouvelles, et que la défaillance d'une seule compromet à chaque fois la sécurité de tout le réseau.

    Le problème de la création d'une nouvelle autorité s'est posé à Let's Encrypt : n'étant reconnue par aucun navigateur, les certificats qu'ils émettent, signés par leur clef intermédiaire fournie dans un certificat signé par leur clef racine fournie dans un certificat reconnu par personne, auraient été à peu près inutilisables. Pour éviter cela, ils ont émis une version alternative de leur certificat racine, portant la même clef publique, mais qu'ils ont fait signer par une autorité reconnue, IdenTrust. Notons en passant qu'il ne s'agit alors plus vraiment d'un certificat racine, mais d'un certificat intermédiaire, strictement parlant.

    Les administrateurs de serveurs utilisant des certificats émis par Let's Encrypt peuvent donc configurer leur serveur pour exposer leur certificat, suivi du certificat intermédiaire de Let's Encrypt, suivi du certificat « racine » temporaire de Let's Encrypt. Ainsi, pour le client, il s'agit d'un certificat signé par une chaîne qui remonte jusqu'à un certificat d'autorité de certification reconnu.

    Lorsque le certificat racine de Let's Encrypt sera reconnu partout, les administrateurs de serveurs utilisant des certificats émis par Let's Encrypt pourront les configurer pour exposer leur certificat, suivi du certificat intermédiaire de Let's Encrypt et c'est tout. Mais pour le moment, ce n'est pas une option, parce que pour tous les autres navigateurs, il s'agirait d'un certificat sans chaîne de certification remontant à un certificat d'autorité de certification reconnu.

  • # containers

    Posté par  . Évalué à 7.

    Je partage ton espoir concernant les containers.
    Cela serait une solution élégante pour protéger sa vie privée.
    Pour l'instant j'utilise les profiles : un profile poubelle, un profile surf intense, un profile par membre du GAFAM.
    Mais cela consomme pas mal de ressource. Et la gestion des mots de passe est un peu pénible.
    Reste à rendre la fonctionnalité compréhensible et utilisable (un peu comme le mode privé sauf que c'était plus simple).

    • [^] # Re: containers

      Posté par  . Évalué à 3.

      Reste à rendre la fonctionnalité compréhensible et utilisable (un peu comme le mode privé sauf que c'était plus simple).

      Oui c'est le problème principal à résoudre. Car en fait la fonctionnalité était accessible depuis un bout de temps (cf l'add-on priv8 par exemple: https://addons.mozilla.org/en-US/firefox/addon/priv8/) mais l'UX est difficile à définir.

      • [^] # Re: containers

        Posté par  . Évalué à 3.

        cf l'add-on priv8

        Je peux te faire un bisou ? Je jongle avec 3 profils de Firefox + 2 profils de Chromium pour compartimenter mes accès aux différents sites sur lesquels je me connecte (notamment mes comptes GAFAM professionels). Tu viens de me changer la vie. Merci.

        • [^] # Re: containers

          Posté par  (site web personnel) . Évalué à 3.

          Dans la nightly c'est implémenté de base m'a t-on dit ;)
          Click long sur le bouton + (ajouter un onglet)…

        • [^] # Re: containers

          Posté par  . Évalué à 2.

          Ahah il faut surtout remercier le développeur de l'add-on baku :) (mais je lui transmettrai quand je le verrai ;) )

  • # installation pas *user-friendly*

    Posté par  . Évalué à -2.

    J'ai voulu voir comment Firefox distribuait ses exécutables sous Linux. C'est par pure curiosité, parce que je me suis échiné récemment à construire un paquet AppImage et que j'ai lu en partie la doc de FlatPack.

    Je cherche "firefox" dans DuckDuckGo, ce qui m'amène sur le site mozilla avec une grande image d'une rivière qui brille au soleil levant comme à l'ombre, et un bouton "Free Download". Je clique, et j'arrive sur une 504 de CloudFlare. Idem 2 minutes plus tard.

    Quand je finis par télécharger le fichier, je me retrouve avec un tar.gz nu. Aucune instruction à l'écran, pas même un lien vers une doc.

    J'extrais les fichiers, et je me retrouve avec 23 exécutables, dont tous les ".so". Pas de readme ni de documentation dans quelque format que ce soit. Les candidats plus sérieux à l'exécution sont "firefox", "firefox-bin" et "run-mozilla.sh", mais je suis censé deviner lequel lancer ?

    Deux remarques sans rapport :

    1. La configuration de Ctrl-Tab a simplement été ajoutée à l'interface graphique, puisqu'elle existait déjà via about:config.
    2. Quel dommage que about:performance n'existe que pour les développeurs ! Quand mon Firefox pompe 30% d'un CPU, je ne sais pas quel onglet est fautif, à moins que ce soit une extension comme TreeStyleTabs.
    • [^] # Re: installation pas *user-friendly*

      Posté par  (site web personnel) . Évalué à 9.

      Parce que 99% des gens qui utilisent Firefox sous GNU/Linux le récupèrent avec leur gestionnaire de paquet, voire l'ont déjà d'installé comme navigateur par défaut dès le début. Les vraiment barbus eux le compilent. Au final, il n'y a que peu de gens qui sont entre les deux, les dévs web qui testent des versions spécifiques et les curieux qui utilisent la dev edition. Mais je suis d'accord, un README ne ferait pas de mal…

      (PS, passe plutôt par le FTP pour télécharger l'archive : https://ftp.mozilla.org/pub/)

    • [^] # Re: installation pas *user-friendly*

      Posté par  (site web personnel, Mastodon) . Évalué à -2.

      Les candidats plus sérieux à l'exécution sont "firefox", "firefox-bin" et "run-mozilla.sh", mais je suis censé deviner lequel lancer ?

      Tu es vraiment sérieux là ? o_O

    • [^] # Re: installation pas *user-friendly*

      Posté par  (site web personnel) . Évalué à -6. Dernière modification le 18 novembre 2016 à 14:04.

      Après, tu es Linuxien, donc bon ça correspond à l'ambiance voulue de la "communauté" (combien de fois je me suis fais insulter pour vouloir filer des binaires utilisables par les gens? "c'est pas ton rôle, arrête de faire ta pleureuse, les gens prennent la version du repo de la distro").
      Sous Windows ou Mac, clic clic clic, et voila.

      Tu as choisi ta communauté :).

      Note : tu veux faire une AppImage, donc ne pas savoir quoi lancer la n'est pas crédible ;-).

      Plus sérieusement : les distros gèrent bien FF dans les repos, donc seuls les geeks utilisent le tar.gz, pas besoin de doc car ce n'est pas le but que d'utiliser de binaire pour tout le monde. Rien de choquant.

      • [^] # Re: installation pas *user-friendly*

        Posté par  (site web personnel) . Évalué à 3.

        Après l'archive de Firefox contient des binaires tels que firefox.
        Il semble évident que firefox est ce qu'il faut lancer, tout comme sous Windows tu cliques sur le application.exe.

        Et cela fonctionne très bien, j'ai fait ainsi pendant des années.

    • [^] # Re: installation pas *user-friendly*

      Posté par  . Évalué à 10.

      Je suis étonné que tant de gens trouvent ça normal. En tant que barbu linuxien, j'aurais préféré un lien explicite vers le tar.gz (j'aime savoir ce que je télécharge et sourtout pouvoir faire un wget), accompagné de quelques lignes détaillant le contenu de l'archive.

      Pour un non-barbu, c'est moche. Je suis parfois prosélyte en installant Linux chez des amis ou proches, et je peux imaginer certains voulant essayer la dernière version de Firefox que ne leur propose pas leur système de base. Après la page web clinquante, le site les laisse tomber, et ils bloqueraient sûrement à la phase suivante. Même si ça ne concerne qu'une petite part des téléchargements, ce n'est pas pro, et bien des logiciels libres sans finance font mieux.

      A mon avis, ce téléchargement est donc inadapté pour les linuxiens, quelque soit leur profil.

      Sur l'aspect plus anecdotique et plus technique de l'archive, je supposais que des deux principaux exécutables, l'un était un wrapper de l'autre, par exemple pour y greffer les autres exécutables comme "crashreporter" et "updater". Il semble que non, les fichiers "firefox*" sont quasi identiques malgré des tailles différentes. Et "run-mozilla.sh" est apparemment un résidu depuis longtemps obsolète. Même pour un utilisateur averti, des explications seraient utiles pour ne pas avoir à deviner par soi-même.

    • [^] # Re: installation pas *user-friendly*

      Posté par  . Évalué à 5.

      Je suis plutôt d'accord avec toi. J'ai toujours trouvé ça perturbant d'avoir 3 exécutables différents au même endroit. Surtout que souvent exécuter l'un ou l'autre ne changeait pas grand chose… (mais sans doute quelque chose parce que sinon pourquoi en avoir 3? Bref.)

      Plus les .so exécutables, ça fait pas sérieux.

      Il faudrait ouvrir un bug ;) idéalement "firefox" devrait être tout seul dans son répertoire, avec un sous-répertoire "binaries" ou je ne sais quoi où mettre tout le reste.

    • [^] # Re: installation pas *user-friendly*

      Posté par  . Évalué à 1.

      bof,
      j'utilise le gestionnaire de package de ma distrib pour le FF mainstream.
      Et le targz de la nigthly qui ensuite se met à jour tout seule.
      ça me parait pas insurmontable.

  • # WebExtensions

    Posté par  . Évalué à 6.

    Pour information, avec le support du Native Messaging pour les extensions, cette version est la première version officielle pour laquelle mon extension Chrome marche "presque" out of the box sur Firefox.

    La seule vraie modification nécessaire a été l'ajout d'un appel spécifique (cloneInto) avant de pouvoir échanger des customs Events depuis les "content" vers les "pages".

    Sinon, j'ai les mêmes sources pour mes deux projets Chrome et Firefox. your mileage may vary.

    Ce "standard" WebExtensions est formidable, et je ne suis pas prêt (j'espère) de regretter les anciennes façon de faire.

  • # Version 51

    Posté par  (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 18 novembre 2016 à 19:53.

    Le changelog de la version 51 à venir est un peu léger. D'après Phoronix, on devrait voir WebGL 2 activé par défaut, l'enregistrement des mots de passe dans les formulaires ne disposant pas d'un bouton de soumission, une amélioration des performances lors de la lecture de vidéos quand l'accélération matérielle n'est pas activée, l'indicateur de zoom sera affiché dans la barre de menu, le codec audio FLAC sera pris en charge, et la bibliothèque graphique Skia sera désormais utilisée (à la place de Cairo ?) pour le rendu du contenu.

    • [^] # Re: Version 51

      Posté par  . Évalué à 3.

      L’activation de Skia est quand même un gros morceau, c’est un truc qui est en travaux depuis longtemps!!

      Écrit en Bépo selon l’orthographe de 1990

    • [^] # Re: Version 51

      Posté par  . Évalué à 2.

      C'est un peu léger car les mouvements de fond comme Electrolysis ou Quatum prennent du temps.

      Tiens, je pensais que Flac était arrivé dans la version 49. En regardant les notes de version, je vois que non. Un truc de la bêta qui a été retirés de la version finale T_T

  • # Emojis, pas sous Ubuntu :-(

    Posté par  . Évalué à 2.

    Bon, il semble que les Emojis soit retirés de la compilation dans Ubuntu:
    https://forum.ubuntu-fr.org/viewtopic.php?id=2000224 (Ubuntu 16.04 avec Mate).

    Je reproduis avec Ubuntu 12.04.5 x64 et Firefox 50, sur le site http://getemoji.com/ j'ai majoritairement que des carrés.

  • # C'est quant il n'est plus là ..

    Posté par  (site web personnel) . Évalué à 4.

    Depuis 3 ou 4 versions, et via le dépôt F-Droid, Firefox ne fonctionnait plus. En fait il fonctionnait pendant les 10 premières minutes, puis plantait à jamais. Ré-install : pareil. Nettoyage complet : pareil. Ceci sur AOSP sans rien de Google installé.

    Et là, ô bonheur, il fonctionne parfaitement.

    C'est quant Firefox n'est plus là que l'on se rend compte à quel point il manque. Surtout sur Android.

    Merci !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.