Pas de confinement pour Firefox 74

34
20
mar.
2020
Mozilla

La version 74 de Firefox desktop a été publiée le 10 mars 2020.

On peut la qualifier de relativement mineure tout en appréciant tout de même que l’installation des extensions soit placée sous le contrôle exclusif de l’utilisateur ou que, pour les utilisateurs de macOS, des gains de performance et d’autonomie (avec WebRender activé) soient au programme. Mais ne boudez pas trop vite : par comparaison, la prochaine version promet son lot d’améliorations sur GNU/Linux. ;)

Nous vous détaillons tout cela et bien plus ci‑après.

Sommaire

Nouveautés pour le bureau

Voici les principales nouveautés de la version 74 pour le bureau :

  • vous avez désormais la main pour supprimer, via le gestionnaire d’extensions, les extensions qui ont pu être installées par le passé par des programmes tiers, et, pour l’avenir, les programmes n’ont plus la possibilité d’installer leur extension dans le navigateur (enfin !) ;
  • sous macOS, l’utilisation du compositeur système lorsque WebRender est activé (à ce stade, WebRender reste désactivé par défaut) ;
  • côté vie privée, la prise en charge du protocole mDNS ICE permet de masquer votre adresse IP en la remplaçant par une adresse aléatoire dans certains scénarios WebRTC ;
  • on peut désactiver la possibilité de déplacer un onglet vers une nouvelle fenêtre en tirant dessus grâce une nouvelle préférence, pour éviter les fausses manip’ : browser.tabs.allowTabDetach ;
  • révision de la façon dont sont présentées les demandes de permission à l’utilisateur (de la caméra, du micro, etc.) lorsqu’elles proviennent d’une page embarquée (iframe) : le navigateur présente la demande comme venant de la page parente et, si la page parente obtient la permission, celle-ci est partagée avec la page embarquée ; si la page parente n’obtient pas la permission, la permission est automatiquement refusée à la page embarquée sans que l’utilisateur ne soit sollicité à nouveau — auparavant, l’utilisateur pouvait recevoir une demande de permission d’un domaine sans rapport avec l’adresse affichée dans le navigateur, ce qui pouvait être source de confusion ; il s’agit aussi d’éviter de demander à l’utilisateur une double permission ;
  • TLS 1.0 et 1.1 ne sont plus pris en charge ;
  • une nouvelle variable d’environnement MOZ_DBUS_REMOTE (à configurer) homogénéise la communication entre les versions X11 et Wayland de Firefox ;
  • et d’autres nouveautés, notamment concernant la gestion des contextes par les conteneurs avec les extensions Firefox Multi‑Account Containers ou Facebook Container !

Par ailleurs, aux États‑Unis, le DNS via HTTPS (avec les serveurs de Cloudflare comme résolveur DNS par défaut, et possibilité d’en changer dans les préférences pour NextDNS ou tout autre à configurer manuellement) va progressivement être déployé auprès des utilisateurs.

Nouveautés pour Android

Rien que le minimum, l’actuel Firefox pour Android étant entré en mode maintenance en attendant la sortie du nouveau Firefox pour Android (qui est actuellement développé sous le nom de Firefox Preview).

Actualités afférentes

À venir dans Firefox pour le bureau

Version 75

Voici ce que devrait arriver dans la prochaine version de Firefox pour le bureau :

État de WebRender

Une prochaine étape importante est l’implémentation d’un back‑end permettant un rendu logiciel de WebRender, qui permettrait d’avoir un même code pour toutes les situations (rendu WebRender matériel pour les processeurs graphiques récents, logiciel pour les anciens). Différentes solutions sont actuellement testées.

État de la version Flatpak de Firefox

On touche au but !

L’oxydation continue

Ce que Mozilla appelle en interne « oxydation » est le processus d’intégration/remplacement au sein de Firefox de composants en Rust (il y a un jeu de mots là‑dedans).

Sont actuellement travaillés :

  • l’intégration du service de mise à jour en arrière‑plan pour Windows écrit en Rust (GNU/Linux n’est pas concerné) ;
  • l’intégration de Mozilla Sync Storage écrit en Rust (projet Durable Sync).

Et, parce que c’est vous : la feuille de route d’oxydation de Firefox, mais chut !

État du futur Firefox pour Android

Une version majeure de Fenix est attendue pour bientôt (actuellement en « feature Freeze »), avec :

Identifiants, Sites les plus visités, prise en charge de UBlock Origin comme première extension, de meilleures pages d’erreur, Protection renforcée contre le pistage paramétrable, sélecteur de langue, améliorations de l’interface et de la stabilité…

dav1d 0.6 AV1 Video Decoder

Une nouvelle version du décodeur implique de meilleures performances ! dav1d est inclus dans Firefox et ces améliorations y atterriront tôt ou tard.

Firefox Send n’est pas plus bêta qu’un autre

Ce mardi, Mozilla a annoncé que son service de transfert de gros fichiers sécurisé Firefox Send sortait de bêta.

Contribuer aux dépêches sur Firefox

Pour contribuer à la prochaine dépêche sur Firefox 75, c’est par ici !

Aller plus loin

  • # VA-API et génération de CPU

    Posté par  (site web personnel) . Évalué à 4. Dernière modification le 20 mars 2020 à 11:25.

    Je suis en train de réfléchir au fait que mon processeur Intel Ivy Bridge (GPU Gen7) décode matériellement le H264 mais pas le VP9 donc j'utiliserai sûrement à terme l'extension donnée dans le paragraphe qui force YouTube à servir du H264

    https://wiki.libav.org/Hardware/vaapi

    PS : il n'y aurait pas un réglage au niveau du navigateur directement, valable pour tous sites et évitant une extension ?

    • [^] # Re: VA-API et génération de CPU

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

      Tiens je vois que media.mediasource.enabled est bien sur true, mais que media.mediasource.webm.enabled est sur false chez moi…
      Du coup est-ce que ça décide YouTube à me servir du H264 plutôt que du VP9 sans extension ?
      https://lafibre.info/navigateurs/vp9-youtube/?PHPSESSID=5ihg87tn8dgcd32knk5q7366r7

      Comment on peut savoir ce que YouTube nous sert (H264/VP9) ?

      • [^] # Re: VA-API et génération de CPU

        Posté par  (site web personnel) . Évalué à 5. Dernière modification le 20 mars 2020 à 19:47.

        Comment on peut savoir ce que YouTube nous sert (H264/VP9) ?

        Clic droit sur une vidéo, puis en bas Stats for nerds, et ligne du milieu Codecs
        YouTube me sert VP9 et Opus actuellement, malgré mon réglage

      • [^] # Re: VA-API et génération de CPU

        Posté par  (site web personnel) . Évalué à 3. Dernière modification le 21 mars 2020 à 11:07.

        Bon :
        1°) J'ai comparé avec l'ESR vierge présente sur mon ordinateur : media.mediasource.webm.enabled devrait être sur true, j'ai fait la modif.
        2°) puis j'ai regardé les préférences incluant la chaîne « webm » et j'ai passé media.mediasource.webm.enabled sur false : du coup YouTube me sert du H264 sans extension particulière (ex avec la chanson du confinement : https://www.youtube.com/watch?v=m1P6Xtb3dU4). Ça l'air de le faire. Dans la mesure où mon système n'accélère pas VP8/9 mais accélère H264, voyez-vous un inconvénient technique auquel je n'aurais pas pensé à cette opération qui a un effet général dans le navigateur (pas que sur YouTube) ?
        Vos avis ?

        • [^] # Re: VA-API et génération de CPU

          Posté par  . Évalué à 3.

          Je pense que si un site ne sert que du webm, tu n'auras pas de vidéo du tout.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: VA-API et génération de CPU

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

      Je n'ai aucune idée de la manière dont Firefox gère les GPUs, mais comme j'ai un peu bossé dessus, quelques pistes:

      Intel a libéré le code HD de ses GPU en 2017/2018, dans l'ordre d'encapsulation:

      1. libVA ;
      2. le media driver pour VA-API: Il génère le pilote nommé iHD_drv_video.so que vous devez trouver dans ${usr_lib}/dri/ ;
      3. le media SDK, qui va généré la bibliothèque libmfx.

      Gstreamer va plutôt utiliser le media-driver alors que ffmpeg va préférer le media-sdk.

      Le media driver peut vous apporter VP9 et HEVC(H265) selon les cartes. Consultez le tableau sur le site.

      • Gstreamer: plugin vaapi, de mémoire ça ne fonctionne vraiment qu'à partir de gst-1.12.4 (mais en tout cas, pas la 1.12.0) ;
      • ffmpeg: plugin libmfx ;
      • Il existe un plugin Gstreamer pour le media-sdk, mais je n'ai jamais réussi à le faire fonctionner correctement .

      il me semble que Firefox est plutôt basé sur gstreamer ?

      Dans tous les cas, installer les vautils pour débugger et configurer les variables d’environnement pour rediriger le vaapi vers iHd, plutôt que i965.

      export LIBVA_DRIVERS_PATH=${usr_lib}/dri/iHD_drv_video.so
      export LIBVA_DRIVER_NAME=iHD
  • # FFx 75

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

    je trouve completement con de masquer une partie de l'url …. C'est habitué les utilisateurs à ne pas tout connaitre… et au final, ça crée des soucis quand on les aide…
    Désolé, je suis un réac mais http://toto.com n'est pas http://www.toto.com

    • [^] # Re: FFx 75

      Posté par  (site web personnel) . Évalué à 3. Dernière modification le 20 mars 2020 à 12:24.

      C'est juste dans les suggestions sous la barre d'url ;)

    • [^] # Re: FFx 75

      Posté par  . Évalué à 6.

      et avec la fin du support du ftp et l’avènement du protocole unique on pourra réduire à toto.com :) Maintenant que les jeunes n'ont même plus besoin de recompiler leur kernel pour faire fonctionner leur raie alcatel, on leur ôte les derniers vestiges du web pre-4.0.

    • [^] # Re: FFx 75

      Posté par  . Évalué à 1.

      Si si, j'ai testé on arrive bien sur le même site :'-D

      Sérieusement, plutôt d'accord avec toi, mais avec un bémol.

      Dans le système des DNS, le TLD n'était pas censé fournir un service. Donc toto.com ne devrait pas/jamais être utilisé. Les navigateurs font donc le choix d’officialiser un "alias" entre le TLD et www (chose qui est finalement faite de facto sur 99% des domaines).

      Qui irait mettre sur son domaine deux services différents sur les DNS toto.com et www.toto.com ? Personne. Le seul cas que l'on voit sont les domaines ou le TLD est juste inutilisé, donc l'aliasser visuellement dans le navigateur n'a pas d'impact.

      • [^] # Re: FFx 75

        Posté par  (site web personnel) . Évalué à 10. Dernière modification le 20 mars 2020 à 14:15.

        Dans le système des DNS, le TLD n'était pas censé fournir un service.

        Déjà, ça sort de nulle part, cette affirmation. Ensuite, toto.example, ce n'est pas un TLD, le TLD correspondant, c'est example. Le mot que tu cherches, c'est l'apex d'une zone : le nom de domaine toto.example est l'apex de la zone du même nom, son sommet si tu veux.

        Et pour en revenir à ton affirmation, elle est fausse, et il est très courant d'avoir un service de courrier électronique à l'apex d'une zone. Certains peuvent choisir de créer et de dédier un nom de domaine inférieur à leur courrier électronique, et d'utiliser par conséquent des adresses du style moi@email.toto.example, mais c'est parfaitement inutile grâce aux enregistrements MX, assez moche, et donc très rare.

        La spécificité d'HTTP, c'est de s'être largement fossilisé sur les couches basses, et de n'avoir pas su évoluer alors que le courrier électronique s'est adapté aux services multiples avec les enregistrements MX, et plein d'autres protocoles avec des enregistrements SRV. Les gens ont pallié ce défaut avec ces fameux www.

        • [^] # Re: FFx 75

          Posté par  . Évalué à 4.

          La spécificité d'HTTP, c'est de s'être largement fossilisé sur les couches basses, et de n'avoir pas su évoluer alors que le courrier électronique s'est adapté aux services multiples avec les enregistrements MX, et plein d'autres protocoles avec des enregistrements SRV.

          D'ailleurs je jetais un œil régulièrement au bug proposant l'amélioration de Firefox en lui ajoutant le support des SRV, et il a été fermé l'année dernière (WONTFIX), après vingt ans d'existence ! https://bugzilla.mozilla.org/show_bug.cgi?id=14328
          La justification, après avoir eu moult débats et propositions de patchs jamais intégrés ? « Il n'y a pas de use-case utilisateur en vue, en particulier au vu de la migration vers les web-extension » : bref, le passage à la guillotine des web-extension pour justifier n'importe quoi. Le web vraiment décentralisé n'aura pas lieu.

      • [^] # Re: FFx 75

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

        Si si, j'ai testé on arrive bien sur le même site :'-D

        Euhhh…

        tth@lubitel:~$ host toto.com
        toto.com has address 54.249.74.177
        toto.com has address 52.197.8.181
        tth@lubitel:~$ host www.toto.com
        www.toto.com has address 202.232.69.147
        tth@lubitel:~$
        
        • [^] # Re: FFx 75

          Posté par  . Évalué à 4.

          Ça amène bien au même site:

          $ curl -L -D -  toto.com -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:74.0) Gecko/20100101 Firefox/74.0'
          HTTP/1.1 302 Found
          Date: Mon, 23 Mar 2020 20:38:04 GMT
          Content-Type: text/html; charset=iso-8859-1
          Content-Length: 216
          Connection: keep-alive
          Server: Apache
          Location: http://www.toto.com/en/index.htm
          
          HTTP/1.1 301 Moved Permanently
          Date: Mon, 23 Mar 2020 20:38:05 GMT
          Server: Apache
          Location: https://www.toto.com/en/index.htm
          Content-Length: 241
          Connection: close
          Content-Type: text/html; charset=iso-8859-1
          
          

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Commande en ligne, dur dur

    Posté par  . Évalué à 4.

    Récemment j'essayais de scripter le téléchargement, l'installation de Firefox-stable avec l'ajout de quelques extensions, notamment uBlock-origin. Et je m'aperçois que c'est de + en + galère.

    Auparavant, il y avait en ligne de commande l'option install-global-extension

    firefox -install-global-extension any.xpi

    Désormais, elle n'existe plus.
    Et pas d'autres moyens d'installer des extensions sans passer par l'interface graphique.

    Avez-vous une piste ?

    • [^] # Re: Commande en ligne, dur dur

      Posté par  . Évalué à 5. Dernière modification le 21 mars 2020 à 09:34.

      Ta distribution propose peut-être ces extensions dans des paquets ?

      Par exemple webext-ublock-origin pour installer uBlock Origin sur Debian.

      Sinon il n'est d'ailleurs peut-être pas trop compliqué de construire automatiquement des paquets à partir des extensions téléchargées depuis Mozilla Add-ons ?

    • [^] # Re: Commande en ligne, dur dur

      Posté par  . Évalué à 4.

      Tu peux regarder du côté des options récentes que propose Firefox pour les administrateur de parcs informatique.

  • # DoH

    Posté par  . Évalué à 4.

    Par ailleurs, aux États‑Unis, le DNS via HTTPS (avec les serveurs de Cloudflare comme résolveur DNS par défaut, et possibilité d’en changer dans les préférences pour NextDNS ou tout autre à configurer manuellement) va progressivement être déployé auprès des utilisateurs.

    Le fait que ça soit complètement débile mis à part, je n’ai pas trouvé d’information sur comment Mozilla déterminait quels utilisateurs sont États-Uniens (ou aux États-Unis on sait pas trop).

    Si je fais un voyage aux US est-ce que ça va s’activer tout seul ? Si oui, ça se désactive quand je reviens dans un pays civilisé ?

    • [^] # Re: DoH

      Posté par  . Évalué à 3.

      Il me semble que c'est quand tu télécharge le binaire (via le site ou mise à jour).

      Après, ça ne semble pas forcément débile. C'est un paramètre qui fonctionne en fonction de la configuration des FAI. Donc si ça été mieux testé aux USA, ça ne me semble pas débile de l'appliquer là.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Retour en arrière sur TLS 1.0 et 1.1

    Posté par  . Évalué à 6.

    Apparemment ils retournent en arrière sur TLS 1.0 et 1.1.

    Mozilla is going to temporarily re-enable the TLS 1.0/1.1 support in Firefox 74 and 75 Beta. […] This is because many people are currently forced to work at home and relying on online tools amid the novel coronavirus (COVID-19) outbreak, but some of critical government sites still don’t support TLS 1.2 yet.

    C’est complètement dingue qu’en 2020 il y ait toujours des sites qui ne supportent pas IPv6 TLS 1.2 et 1.3.

Suivre le flux des commentaires

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