Firefox 129 améliore nettement son mode lecteur et déploie Address Autofill en France

Firefox était l’un des premiers navigateurs à avoir intégré un mode lecteur, avant que la fonction devienne courante. Pour rappel, le lecteur reprend le texte de la page en cours et l’affiche sous une forme simple, débarrassée de toute distraction.

La nouvelle version 129 apporte plusieurs nouvelles options à ce mode. Dans les réglages, on trouve ainsi des paramètres pour l’espacement entre les lettres, l’espacement entre les mots et l’alignement du texte. Le panneau des thèmes s’enrichit de nouveaux venus et autorise surtout la pleine personnalisation.

Plusieurs autres améliorations significatives sont présentes. Par exemple, les onglets en arrière-plan peuvent maintenant afficher un aperçu du site quand on y passe la souris (la fonction est en cours de déploiement). Le remplissage automatique des adresses est enfin disponible en France (et en Allemagne).

Tout aussi important, HTTPS est désormais le protocole par défaut pour la barre d’adresses. Si un site n’est pas disponible en HTTPS, Firefox basculera automatiquement en HTTP. En outre, les enregistrements DNS HTTPS peuvent maintenant être gérés par le résolveur DNS du système (Windows 11, Linux, Android 10 +) et ne nécessitent plus DoH (DNS over HTTPS).

Outre la prise en charge de plusieurs nouvelles langues sur Mac via VoiceOver, Firefox 129 corrige aussi 14 failles de sécurité, dont 11 de sévérité élevée.

Commentaires (17)


Ha cool pour l'Autofill sur les adresses, le nombre de fois que j'ai pesté que ça ne soit pas disponible...

Sinon pour le mode lecture, je trouve qu'il manque une option "masquer les images" personnellement, mais c'est pas mal quand même d'avoir plus de paramètres.
Pendant ce temps un concurrent fanfaronne sur une option où on peut se débarasser manuellement des districtions.
L'un suit les recommandations de la sémantique du web, l'autre vend entrainer une IA pour le faire.
Dans les réglages, on trouve ainsi des paramètres pour l’espacement entre les lettres, l’espacement entre les mots et l’alignement du texte.


Euh ça fait des années qu'on peut définir ces espacements.
Les thèmes par contre, c'est nouveau.
Pareil ici, ça fait un moment que ces paramètres existent.

Par contre, ce qu'il manque, c'est d'avoir un peu plus de choix de police; c'est quand même dommage, pour un mode lecture, de ne pas pouvoir choisir facilement* Literata, Bookerly ou OpenDyslexic - même si le pré-requis est qu'elles soient installées sur le système !!

*C'est faisable en activant un truc legacy dans about:config et avec un userContent.css, mais je ne considère pas ça "facile" - surtout qu'avec FF 129, ça a changé. D'ailleurs, la question sur superuser.com qui a presque 9 ans a une nouvelle réponse datée ... d'hier, intitulée «Firefox 129 and onwards» :fumer:
Il me semblait que l'utilisation de https par défaut se faisait déjà mais cela était chiant quand ff remplaçait http par https quand l'url était complète. En gros, quand j'écris http sans s, c'est que j'ai une bonne raison de le faire.

La bascule automatique sur http évitera donc pas mal de soucis avec les appareils locaux comme les freebox. Pour le wan, j'imagine que cela est devenu rare.

Sur mes serveurs, le port 80 est à l'écoute uniquement pour la validation letsencrypt ou la redirection vers https.

Peut être que je vais remplacer la redirection par une erreur 444 un jour car plus personne ne vas avoir de bonne raison d'essayer en http par défaut.
Je n'ai pas bien compris la partie sur la nécessité ou pas de DOH si http ou https.

Je peux déjà le bloquer dans les paramètres et c'est une obligation chez moi pour que mon pihole soit opérationnel.

Il existe en outre déjà plusieurs modes intermédiaires qui activent ou non DOH en fonction du contexte. Peut être que ce sont les règles de choix automatique qui ont évolué.



Le DoH permet de garantir que l'IP retournée par le serveur DNS n'a pas été falsifiée pendant le transport. (DNS menteur, man-in-the-middle, ...).

En https, ce n'est pas nécessaire d'avoir cette protection puisque si une réponse DNS te donne une mauvaise IP pour te rediriger vers un faux serveur. Le faux serveur sur lequel tu vas te connecter ne pourra pas avoir de certificat valide, et le navigateur t'empêchera d'accéder à la page web au bout du compte.


J'ai deux choses à ajouter la dessus:
- Repasser en DNS classique permet au fai, ou n'importe qui sur le passage entre toi et le serveur DNS de voir les requêtes en clair et en déduire les sites que tu visites.

- Je ne sais pas si DoH, DoT, DoQ, ... sont implémentés coté Windows, mais re-passer par le resolver de Windows permet juste de mettre le niveau de sécurité de Firefox au niveau de sécurité de l'OS à ce niveau là. Ce que je trouve bien plus propre, plutôt que chaque appli implémente son resolver. Surtout pour ceux qui utilisent des solutions comme PiHole, Adguard, etc...

ForceRouge

Le DoH permet de garantir que l'IP retournée par le serveur DNS n'a pas été falsifiée pendant le transport. (DNS menteur, man-in-the-middle, ...).

En https, ce n'est pas nécessaire d'avoir cette protection puisque si une réponse DNS te donne une mauvaise IP pour te rediriger vers un faux serveur. Le faux serveur sur lequel tu vas te connecter ne pourra pas avoir de certificat valide, et le navigateur t'empêchera d'accéder à la page web au bout du compte.


J'ai deux choses à ajouter la dessus:
- Repasser en DNS classique permet au fai, ou n'importe qui sur le passage entre toi et le serveur DNS de voir les requêtes en clair et en déduire les sites que tu visites.

- Je ne sais pas si DoH, DoT, DoQ, ... sont implémentés coté Windows, mais re-passer par le resolver de Windows permet juste de mettre le niveau de sécurité de Firefox au niveau de sécurité de l'OS à ce niveau là. Ce que je trouve bien plus propre, plutôt que chaque appli implémente son resolver. Surtout pour ceux qui utilisent des solutions comme PiHole, Adguard, etc...
Effectivement, dit comme cela, c'est limpide.

Je partage ton point de vue concernant le fait que la résolution est l'affaire de l'OS.

Je peux comprendre que ff s'en charge pour les vieux OS plus mis à jour mais pas pour les autres.

wanou

Effectivement, dit comme cela, c'est limpide.

Je partage ton point de vue concernant le fait que la résolution est l'affaire de l'OS.

Je peux comprendre que ff s'en charge pour les vieux OS plus mis à jour mais pas pour les autres.
je crois que rien ne protège des résolveurs dns menteurs, à part ne pas les utiliser.

brupala

je crois que rien ne protège des résolveurs dns menteurs, à part ne pas les utiliser.
Dans le cas où c'est la machine cliente qui résout lui même (donc dans passer par un resolver intermédiaire), toutes les améliorations de DNS évites justement les DNS menteurs.

DoH, DoT, DoQ, DNSSEC, ...

La question, c'est toujours "A qui tu fais confiances?"

C'est valable dans le cas du resolver DNS que t'utilises, mais aussi pour ceux qui utilisent des "VPN" (je parles des CyberGhost et autre trucs relayés par les youtubeurs), etc...

wanou

Effectivement, dit comme cela, c'est limpide.

Je partage ton point de vue concernant le fait que la résolution est l'affaire de l'OS.

Je peux comprendre que ff s'en charge pour les vieux OS plus mis à jour mais pas pour les autres.
A part ne gérer qu'un seul cache pour tout le monde, je ne vois bien l'intérêt à demander à l'OS de faire les résolutions.
En même temps, ça va un peu à l'inverse de ce qui est expliqué au #.5.3 là sur les enregistrements de type https.
Modifié le 08/08/2024 à 14h21

Historique des modifications :

Posté le 08/08/2024 à 13h44


A part ne gérer qu'un seul cache pour tout le monde, je ne vois bien l'intérêt à demander à l'OS de faire les résolutions.

Posté le 08/08/2024 à 14h18


A part ne gérer qu'un seul cache pour tout le monde, je ne vois bien l'intérêt à demander à l'OS de faire les résolutions.
En même temps, ça va un peu à l'inverse de ce qui est expliqué au #.5.3 là sur les enregistrements de type https.

brupala

A part ne gérer qu'un seul cache pour tout le monde, je ne vois bien l'intérêt à demander à l'OS de faire les résolutions.
En même temps, ça va un peu à l'inverse de ce qui est expliqué au #.5.3 là sur les enregistrements de type https.
En fait, l'os ne fait pas de résolution lui-même mais il donne l'adresse des DNS et potentiellement l'ordre de priorité entre le fichier host (qui existe aussi dans windows), et les autres moyens.

Après, il peut y avoir un résolveur cache local mais ce n'est pas obligatoire.

Avec DOH, le navigateur ignore tout simplement les informations du système et demande directement à google ou autre, y compris pour les noms de machines locales : pas de domaine racine ou un domaine racine comme .loc ou .home

C'est donc un comportement plutôt dêsirable sur un téléphone mobile ou en wifi non sécurisé pour l'accès à des ressources globales, mais cela pose des problèmes en entreprise ou sur un réseau local.

ForceRouge

Le DoH permet de garantir que l'IP retournée par le serveur DNS n'a pas été falsifiée pendant le transport. (DNS menteur, man-in-the-middle, ...).

En https, ce n'est pas nécessaire d'avoir cette protection puisque si une réponse DNS te donne une mauvaise IP pour te rediriger vers un faux serveur. Le faux serveur sur lequel tu vas te connecter ne pourra pas avoir de certificat valide, et le navigateur t'empêchera d'accéder à la page web au bout du compte.


J'ai deux choses à ajouter la dessus:
- Repasser en DNS classique permet au fai, ou n'importe qui sur le passage entre toi et le serveur DNS de voir les requêtes en clair et en déduire les sites que tu visites.

- Je ne sais pas si DoH, DoT, DoQ, ... sont implémentés coté Windows, mais re-passer par le resolver de Windows permet juste de mettre le niveau de sécurité de Firefox au niveau de sécurité de l'OS à ce niveau là. Ce que je trouve bien plus propre, plutôt que chaque appli implémente son resolver. Surtout pour ceux qui utilisent des solutions comme PiHole, Adguard, etc...
l'adresse ip V4+V6) du serveur est dans le certificat ? je pensais qu'il n'y avait que le domaine .
L'autorité fait une résolution inverse comme pour le mail pour vérifier ?
Sinon windows 11 fait du DOH/DOT, ça se configure sur l'interface (2 fois v4 et V6).
Modifié le 08/08/2024 à 13h41

Historique des modifications :

Posté le 08/08/2024 à 13h30


l'adresse ip du serveur est dans le certificat ? je pensais qu'il n'y avait que le domaine .
L'autorité fait une résolution inverse comme pour le mail ?

Posté le 08/08/2024 à 13h36


l'adresse ip V4+V6) du serveur est dans le certificat ? je pensais qu'il n'y avait que le domaine .
L'autorité fait une résolution inverse comme pour le mail pour vérifier ?
Sinon windows 11 fait du DOH, ça se configure sur l'interface (2 fois v4 et V6).

brupala

l'adresse ip V4+V6) du serveur est dans le certificat ? je pensais qu'il n'y avait que le domaine .
L'autorité fait une résolution inverse comme pour le mail pour vérifier ?
Sinon windows 11 fait du DOH/DOT, ça se configure sur l'interface (2 fois v4 et V6).
Un certificat peut inclure une IP dans le champ alternate name mais ce n'est pas le cas courant et cela ne sert pas à associer une adresse avec un FQDN.

Un faux serveur n'est simplement pas en mesure de produire un certificat valide sauf en cas d'attaque de l'homme du milieu institutionnelle comme le DPI en entreprise mais cela implique d'installer des certificats racine dans les OS des machines clientes pour signer les certificats de complaisance.

Les seuls certificats qui ne sont pas du tout vérifiables sont les certificats autosignés que l'on ne trouve quasiment plus qu'en local.

Avec les attaques de l'intérieur qui peuvent se produire via une caméra IP par exemple, ce genre de certificats devient dangereux.

C'est pour cela qu'il faudrait selon moi mettre en place la gestion des certificats racines locaux. Ces certificats pourraient être générés et gérés par les box ou les routeurs et seraient réservés à des domaines locaux: .home ou .loc et ne pouraient correspondre qu'à des adresses non globales.

Avec une telle chose, il serait possible de rendre accessible à tout le monde un moyen de sécuriser son réseau local sans grandes connaissances. La box pourrait ainsi générer les certificats pour le nas, la caméra ip, l'imprimante bref, tous les serveurs d'un lan relativement lamba.

brupala

l'adresse ip V4+V6) du serveur est dans le certificat ? je pensais qu'il n'y avait que le domaine .
L'autorité fait une résolution inverse comme pour le mail pour vérifier ?
Sinon windows 11 fait du DOH/DOT, ça se configure sur l'interface (2 fois v4 et V6).
Pour répondre à tes questions:

Q1:

L'adresse IP n'est pas dans le certificat. Mais avec https, ce n'est pas important.

Pour imager ce que je dis, imaginons qu'il y a un site www.toto.com qui résoud en 1.2.3.4.

Imaginons qu'un DNS malintentionné te réponds que www.toto.com est à 5.6.7.8 et que ton navigateur s'y connecte. Alors 2 cas possible:

- en http: ton navigateur va s'y connecter, et il si le site est correctement imité, tu ne seras pas capable de dire si tu est sur le vrai www.toto.com ou une copie destiné à récupérer tes identifiants par exemple.

- en https: Au moment de la vérification du certificat, le serveur qui prétend être www.toto.com ne sera pas en mesure de fournir un certificat valide qui certifie qu'il est www.toto.com.

Dans ce second cas, le certificat qui va t'être présenté aura au moins l'un des caractéristiques suivantes:
- reconnu par une CA publique, mais pas émis pour le domaine www.toto.com
- émis pour le domaine www.toto.com, mais pas reconnu par une CA publique


=======================
Q2:

Pour des certificats EV, c'est un process manuel au départ où tu dois envoyer un Kbis de ta société. C'est un cas particulier qui représente très peu de site web. Ca permet de mettre le nom de la société dans le certificat.

Aujourd'hui, 99% des sites web sont signés avec Let's Encrypt de façon automatique. Ca ne prouve pas que abc.com appartient à la société ABC, mais juste que le site abc.com appartient bien à celui qui possède le nom de domaine abc.com.

Le process le plus utilisé est le suivant (mais il y en a d'autre moins utilisé):
- Le client (serveur à protéger) se connecte à Let's Encrypt ("LE") en demandant un certificat "bidule.com"
- "LE" t'envoi un challenge pour lequel tu dois mettre la réponse dans un path bien spécifique (.acme/xxx)
- "LE" se connecte à http://bidule.com/.acme/xxx pour vérifier que tu es bien le propriétaire de bidule.com en s'assurant que le challenge est réussi
- "LE" génère un certificat signé par la RootCA Let's Encrypt et l'envoi au client.

Ce qui signifie que si tu n'es pas le propriétaire de bidule.com, tu ne pourras pas créer un champs A ou CNAME pour envoyer bidule.com vers l'IP de ton serveur, et donc "LE" ne pourras pas vérifier le challenge.


PS:
Avec "LE", tu peux aussi faire un système de challenge via DNS, mais c'est moins utilisé.
Certaine grosses boites font carrément leur propre certificate authority et s'auto signe ensuite (Google par exemple). Tu peux regarder dans le magasin de certificat de Firefox, y'en a des centaines.
En fait, la page décrivant la version de Firefox parle de HTTPS DNS records qui est un type d'enregistrement DNS défini dans la RFC 9460.

Une explication de ce que permet ces enregistrements. Ça permet en gros d'être plus rapide.

J'ai signalé l'erreur pour proposer une amélioration du texte de la brève.
Modifié le 08/08/2024 à 12h07

Historique des modifications :

Posté le 08/08/2024 à 12h04


En fait, la page décrivant la version de Firefox parle de HTTPS DNS records qui est un type d'enregistrement DNS défini dans la RFC 9460.

J'ai signalé l'erreur pour proposer une amélioration du texte de la brève.

Mais la 129 pose un problème de DRM sur MyCanal qui n'est plus fonctionnel sur ce navigateur, un ticket est ouvert sur le sujet.
Fermer