La 51e version de Firefox est sortie le 24 janvier 2017.
Avec cette version, Firefox intègre des technologies aux noms venus d’ailleurs tels que FLAC, WebGL 2, Skia (dorénavant activé pour GNU/Linux), electrolysis (qui poursuit son déploiement), etc., sans oublier différentes améliorations, dont le détail figure dans la suite de la dépêche.
Sommaire
- Les nouveautés de la version 51
- Installer Firefox
- Prochaines versions
- État des chantiers
- Autour de Firefox
Les nouveautés de la version 51
Version bureau
- prise en charge du codec audio FLAC avec les types de MIME suivant (demande 1195723) :
-
audio/flacetaudio/x-flac, -
audio/ogg; codecs=flacetvideo/ogg; codecs=flac, - FLAC sera aussi utilisable au sein de MP4 (à la fois avec ou sans MSE) via l’analyseur MP4 en Rust correspondant à la demande 1303888,
- Chrome rejoindra Firefox sur ce point la semaine suivante (bogue 93887) ;
-
- mise à jour de WebGL, Firefox est le premier navigateur Web à prendre en charge WebGL 2 (qui est basé sur OpenGL ES 3, là où WebGL 1 était basé sur OpenGL ES 2) et permet ainsi l’utilisation de techniques d’accélération graphique plus modernes (cf. ce billet de blogue sur hacks.mozilla.org et ces démonstrations utilisant WebGL 2) ; WebGL 2 n’est pas encore finalisé, le dernier brouillon date du 14 janvier 2017 ;
- enregistrement des mots de passe dans les formulaires ne disposant pas d’un bouton de soumission ;
- amélioration des performances quand l’accélération matérielle de la lecture de vidéos n’est pas active (ce qui est le cas sous GNU/Linux : cf. bogue 563206 et bogue 1210726) ;
- ajout de l’indicateur de zoom directement dans la barre d’adresse : jusqu’à présent l’accès au niveau de zoom était caché derrière le bouton menu et aucun témoin n’était directement visible pour signaler à l’utilisateur que le niveau de zoom avait été changé ; dorénavant, le niveau de zoom apparaît dans la barre d’adresse lorsque celui‐ci n’était pas à sa valeur par défaut et il suffit alors d’un clic pour réinitialiser le niveau de zoom, à la façon de Chrome (bogue 565718) ;
- un témoin (un cadenas barré de rouge) est là pour avertir l’utilisateur qui est sur le point de rentrer ses identifiants sur un site non sécurisé (cf. ce billet de blogue sur blog.mozilla.org) ;
- synchronisation plus fine des marque‐pages : lors de la synchronisation d’un dossier de marque‐pages, celui‐ci est bloqué tant que la synchronisation n’est pas terminée ;
- le basculement entre les onglets utilise Electrolysis, et c’est plus rapide !
Version Android
Rien de particulier pour Android dans cette version.
Changements communs à la version de bureau et mobile
Qu’est‐ce skia ?
La version GNU/Linux de Firefox pour le bureau est en retard dans les domaines impliquant la pile graphique de GNU/Linux (par exemple, l’accélération par le processeur graphique du rendu des pages d’une part et des vidéos d’autre part — lire la dépêche sur la version 49 — se fait encore attendre, de même que le fonctionnement natif sous Wayland — lire ce rapport de bogue).
Toutefois, le récent passage à la boîte à outils graphique GTK+ 3 (activé dans Firefox 46 pour ce qui concerne Mozilla, mais généralement plus tard dans les distributions compte tenu des bogues résiduels : version 49.0-5 pour Debian, par exemple) ouvre la voie au portage vers Wayland et permet également de changer de bibliothèque d’affichage sans pénalité de performance. En effet, historiquement, la version GNU/Linux utilise Cairo, mais Skia — déjà utilisé par Firefox sur d’autres plates‐formes — est une alternative censée offrir de meilleures performances pour le rendu de pages Web.
Cette version utilise dorénavant la bibliothèque d’affichage Skia par défaut, sous GNU/Linux comme sous Android.
Pour les développeurs
- beaucoup de retraits, sûrement causés par l’abandon de Firefox OS : Alarms PI (bug 1300884), Page Visibility API (bogue 812701), mais aussi remplacement de Simple Push API par W3C Push API (bogue 1296579) ;
- les WebExtensions permettent d’interagir avec le presse‐papiers et commencent à intégrer Native messaging (vous pouvez relire la dépêche précédente sur ce point) ;
- WEBRTC utilise maintenant VP9 par défaut, mais si le processeur n’est pas adapté, Firefox repassera en VP8 (moins exigeant en calculs) ;
- un script du serveur commençant par
image/*,video/*,audio/*outext/csvsera bloqué, non téléchargé et non exécuté (bogue 1288361) ; - retrait d’une large partie des Social API que Mozilla avait créées (voir le wiki) ;
- le superviseur réseau affiche maintenant un état « bloqué » sur les requêtes réseau.
Failles de sécurité corrigées
Dans la version 50
La version 50 a connu trois failles critiques (CVE-2016-9894, CVE-2016-9078 et CVE-2016-9079), dont une sur le SVG qui affecte aussi Thunderbird et Firefox ESR (CVE-2016-9079: Use‐after‐free in SVG Animation).
Cela a été assez problématique pour que Mozilla marque le coup en changeant la numérotation de version : Firefox 50.1 et Firefox ESR 45.6 !
Dans la version 51
Vingt‐cinq failles ont été corrigées dans Firefox 51 : six failles critiques (CVE-2017-5375, CVE-2017-5376, CVE-2017-5377, CVE-2017-5374 et CVE-2017-5373), six failles élevées, dix modérées (dont deux qui ne concernent que Firefox mobile pour Android et une autre concernant addons.mozilla.org CDN) et trois basses, dont une qui ne concerne que Firefox mobile pour Android.
On dénombre neuf failles corrigées pour Firefox ESR 45.7 : trois critiques (CVE-2017-5373, CVE-2016-5290 et CVE-2016-5296), quatre élevées et deux modérées.
Installer Firefox
Les utilisateurs de versions Windows 32 bits (XP SP2 minimum), Windows 64 bits (Windows 7 minimum), macOS 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) sur x86 ou ARM (ARM v7 minimum) [page de téléchargement].
Une version spécifique (n’utilisant pas le moteur de rendu développé par Mozilla) existe également pour iOS (version 8.2 minimum) [source].
Par ailleurs, il existe dorénavant un paquet Flatpak de la version développeur de Firefox.
Prochaines versions
Version 52 ESR
Windows XP et Vista
Mozilla est le dernier éditeur à proposer un navigateur récent sous Windows XP (déjà mort depuis avril 2014), mais l’échéance est proche et les utilisateurs sous XP ne basculeront pas vers Firefox 53 : cf. bogue 1317780 et bogue 1305453, mais resteront sous Firefox 52 ESR au vu du bogue 1315083. Les utilisateurs de Windows XP et de Vista auront droit à un message bogue 1315153 (comme les utilisateurs de Chrome l’ont eu en avril 2016).
Mozilla a affiné l’agenda de la fin de Windows XP et Windows Vista pour Firefox et la disparition se fera mi‐2017, soit avant la fin de Firefox 52.
Collaboration avec le projet TOR
Firefox 52 envisage de mieux protéger les utilisateurs contre le fingerprinting de polices système en se servant d’un mécanisme de liste blanche : cf. l’article sur developpez.com et le bogue 1121643. Cette configuration vient du projet Tor Uplift, qui cherche à utiliser certains paramètres de Tor Browser (un dérivé de Firefox) pour obtenir un navigateur plus efficace dans le respect de la vie privée. Un article sur le blogue du projet Tor revient sur ces avancées et celles en cours. Ainsi, la fonctionnalité First Party Isolation apparaîtra dans la version 52 de Firefox, bien que désactivée par défaut.
Version 53
Il est prévu de refondre l’interface des contrôles audio‐vidéo avec intégration plus poussée de la balise track (affichage de l’audio description, choix des sous‐titres, etc.), voir bogue 1271765.
Prévu aussi pour cette version 53, l’ajout de display: flow-root, une façon moderne d’indiquer que les éléments flottants d’un bloc ne puissent pas en dépasser (aussi appelé clearfix) (bogue 1322191).
On devrait aussi voir l’arrivée d’une interface pour <input type="date"/>, voir le bogue 1286182.
Mozilla refusera sur AMO toute nouvelle extension de Firefox pour le bureau qui ne sera pas faite à l’aide de WebExtensions. Les extensions de Firefox sur Android, de Thunderbird et de Seamonkey ne sont pas concernées. Les extensions actuelles utilisant SDK, XUL ou XPCOM pourront continuer à être mises à jour [source].
La prise en charge de la gestion des droits numériques (DRM)Adobe Primetime sera retirée de cette version de Firefox. A priori, parce qu’elle ne fonctionne que dans les versions de Firefox compilées par Mozilla [source]. Si l’on en croit cette page, seule la version de Firefox pour Windows proposait la gestion des droits numériques d’Adobe, alors que Google Widevine est disponible sur Windows, macOS et GNU/Linux (en attendant Android).
Version 57
On apprend dans une publication officielle que :
À La fin de l’année 2017, et avec la sortie de Firefox 57, nous basculerons sur l’utilisation exclusive des WebExtensions et nous arrêterons de charger tout autre type d’extension sur la version bureau. Pour s’assurer que toute nouvelle extension fonctionnera après 2017, AMO arrêtera d’accepter de signer toutes les nouvelles extensions qui ne seront pas basées sur WebExtensions dès Firefox 53.
Les extensions autorisées dans cette version seront :
- les WebExtensions signées ;
- les extensions « bootstrapped » signées ;
- les packs de langues ;
- les dictionnaires ;
- les greffons pour le moteur de recherche ;
- les thèmes d’apparence légers.
Nightly
MozillaZine nous donne un petit aperçu des nouveautés dont les utilisateurs de Nigthly profitent déjà quotidiennement depuis quelques semaines.
Également, Homputer Security détaille le nouveau processus exclusif pour les fichiers locaux.
Enfin, Async/Await arrive dans Firefox.
État des chantiers
Projet Electrolysis
Electrolysis a été progressivement activé pour la majorité des utilisateurs ne disposant pas d’extensions (Firefox 49), puis pour ceux disposant d’extensions explicitement marquées compatibles avec Electrolysis (Firefox 50). Tous les retours ont été positifs, c’est pourquoi avec Firefox 51, Electrolysis sera activé, sauf si présence d’une extension marquée explicitement incompatible.
De plus, l’architecture d’Electrolysis évolue : le canal nightly est utilisé pour tester l’utilisation d’un second processus de contenu (qui gère des pages Web, par opposition à celui qui gère l’interface graphique), corriger les bogues et trouver le nombre optimal de processus à utiliser.
Enfin, des travaux sont en cours pour utiliser des processus fils comme bacs à sable, d’abord sous Windows. Ça doit encore être renforcé et étendu à macOS et GNU/Linux. Cf., en anglais, cet article sur le blog de Mozilla et le dernier compte‐rendu de l’avancement du projet.
Projet Quantum
Où en est le projet Quantum récemment annoncé ?
Fin novembre, l’équipe derrière Servo se félicitait de l’arrivée dans Nightly de l’analyseur d’adresses URL de Servo en ces termes :
Manish and Valentin Gosu have been working on this for a long time, and with some work from Ted and Nathan, it’s now available behind a flag. It will probably be some time before it reaches full compatibility with all of the specialized and internal things that Firefox does with URLs and can be used by default, but this is a huge first step and the largest integration of Rust code into Firefox to date.
Par ailleurs, la feuille de route de Servo continue d’être mise à jour et l’on voit bien que le prochain gros morceau du projet Quantum qui devrait se concrétiser est Stylo, ou Quantum CSS.
Animations dans Firefox
« Petite » rétrospective, en anglais, des avancées survenues en 2016 en la matière.
Autour de Firefox
B2G OS
Pour ceux qui n’ont pas lu les commentaires éclairants placés par lapineige sous la précédente dépêche, nous en retranscrivons ici la teneur.
L’équipe communautaire qui avait repris le développement de Firefox OS après son arrêt par Mozilla, a dû envisager une nouvelle solution après que Mozilla a décidé dans un deuxième temps de supprimer le code de Firefox OS du tronc commun de développement.
Ces courageux et motivés bénévoles s’attellent désormais à proposer une nouvelle alternative consistant à faire perdurer les points forts de Firefox OS (en gros : tout est Web, pas d’application « native » propre au système d’exploitation, comme sur les autres plates‐formes) en utilisant une base technique libre (aux pilotes près), activement développée par ailleurs, permettant de ne pas disperser leurs modestes ressources.
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 environnement Java minimal (oui, je sais, Java, bref :D) qui lancerait 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 géré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 il y a quelques couches en moins.
Autrement dit :
En gros, tu prends un android/CM classique, tu vires toute la partie système et interface (systemUI), en gardant l’environnement Java qui interface avec le noyau & co (mais réduit au minimum syndical) et tu lances 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).
Et de conclure :
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. :)
Les liens pour suivre le projet et/ou contribuer sont donnés ici.
Tor Browser
Tor Browser 6.5 est paru le même jour que Firefox 51, vous trouverez le détail des nouveautés ici.
Firefox Focus pour iOS
Après Focus by Firefox (un bloqueur de publicités pour Safari Mobile), voici Firefox Focus, un ersatz de Safari iOS proposé par Mozilla pour permettre de se concentrer (une page à la fois) sur une navigation sans traces (source en anglais et article en français).
Flash
Mozilla avait déclaré la fin des greffons fin 2016, mais Flash resterait une exception, un mal nécessaire à activer si besoin (cf. le chapitre de la dépêche sur le sujet Flash d’Adobe à l’agonie).
Edge et Chrome avaient une position similaire mais il viennent de donner un calendrier un peu plus précis et plus agressif (Chrome, Edge), d’autant que ces deux navigateurs incorporent Flash en leur sein.
Dans tous les cas, on sent que les navigateurs essayent de mettre la pression sur les webmestres pour faire abandonner Flash sans pénaliser l’utilisateur final.
Contribuer à LinuxFr.org
Vous pouvez participer aux dépêches relatives aux sorties des prochaines versions : par exemple, ça se passe ici pour la prochaine !
- Plus d’information sur l’image en tête de dépêche ici.
- L’image I Want To Believe est tirée de la série X-Files : Aux frontières du réel, produite par la Fox.
Aller plus loin
- Firefox 51 Site Compatibility (382 clics)
- Mozilla Developper Network — Firefox 51 for developers (223 clics)
- Notes de la version bureau de Firefox 51 (308 clics)
- Notes de la version Android de Firefox 51 (176 clics)
- Nouveautés WebRTC de cette version (220 clics)
- Nouveautés WebExtensions de cette version (178 clics)
- Failles de sécurité corrigées dans Firefox 51 (171 clics)
- Précédente dépêche, pour la version 50 (193 clics)
# Flac, WebGL2, HTTP-nonS: Chrome ce suiveur
Posté par cbri . Évalué à 7.
Le titre est volontairement trollesque ;-)
Chrome 56 disponible : WebGL 2.0, FLAC et alertes pour les identifications non sécurisées
Je ne suis pas de près le développement de Google Chrome, mais il me semble que sur le coup Google a suivi Mozilla. Ou du moins il y a eu une synchronisation entre eux pour que ces fonctionnalités sortent au même moment.
Mozilla travaillait depuis cet été sur Flac, le bug était ouvert depuis plus longtemps chez Google mais annoncé résolu qu'en décembre.
Pour WebGL 2, un employé de Mozilla est l'un des auteurs de la dépêche (le deuxième travaille chez Apple). Mais je ne doute pas que Google suit ce dossier d’où la sortie conjointe entre les 2.
Même raisonnement pour les alertes sur HTTP, Mozilla et Google ont clairement mal pris les révélations de Snowden et déclaré vouloir passer au tout HTTPS. D'ailleurs, HTTP/2 a été intégré dans Firefox et Google Chrome avec le chiffrement obligatoire!
[^] # Re: Flac, WebGL2, HTTP-nonS: Chrome ce suiveur
Posté par Benoit Jacob (site web personnel) . Évalué à 3.
Effectivement, on dirait bien que Mozilla a un peu joué les Lucky Luke en sortant WebGL 2 avant que la spec soit officiellement ratifiée. Ceci dit, ça fait très longtemps que WebGL 2 est au stade expérimental (un excellent stagiaire avait écrit un bon bout d'implémentation et fait tourner une belle démo à l'été 2013) donc finalement il faut bien sortir tout ça un jour. J'espère juste que ça ne va pas créer de précédent ou de mauvaise volonté.
[^] # Re: Flac, WebGL2, HTTP-nonS: Chrome ce suiveur
Posté par StyMaar . Évalué à 1.
Malheureusement c'est toujours comme ça que ça se passe sur le web, les trucs sont implémentés avant que la spec ne soit finalisée …
Pour webCrypto par exemple, quand j'avais eu à m'en servir (fin 2014) Firefox et Chrome implémentaient la même dernière version du brouillon mais IE 11 supportait une ancienne version (basée sur des
callbacket non despromise).Pour webRTC ça donne une espèce de situation bizarre ou Chrome et Firefox supportent chacun une version différente de la spec' (elles sont inter-opérable mais l'API est légèrement différente) et aucun des deux n'implémente la dernière version en date du brouillon de spec' (et personne ne sait d'ailleurs quelle version exacte de la spec' est implémentée par chacun des navigateurs).
Évidemment, les navigateurs ne se privent pas pour rattraper la spécification de temps en temps quitte à abandonner la compatibilité avec l'existant. Pour Firefox c'est assez bien documenté et on sait à peu près à quoi s'attendre grâce aux canaux de distributions (nightly, devEdition et Beta) mais avec Chrome c'est le gros bordel: ce genre de changement n'est pas souvent documenté et il peut surgir d'un coup en version stable sans être passé par la beta …
Bref c'est à se demander à quoi servent les spécifications du W3C et ça donne envie de continuer à bosser dans le web …
# Avant...
Posté par GG (site web personnel) . Évalué à 7.
Avant, il y avait une option pour interdire l'interdiction du clic-droit.
Cela fait un bout de temps que l'on ne peut plus désactiver l'interdiction du clic-droit, et c'est bien dommage.
Dans certains cas on pouvait se retrouver avec le menu du clic-droit ainsi que celui de l'application web dessous, et ça laissait le choix à l'utilisateur averti (puisque cette option était désactivée par défaut).
De temps en temps, au fur et à mesure des évolutions de Firefox et Thunderbird, je découvre des redressions importantes au niveau de la liberté des utilisateurs. C'est encore pire sur Smartphone, où l'on ne peut pas ouvrir un lien dans une page de navigation privée parce que c'est toujours le profil par défaut qui est proposé (je parle de la fonction : ouvrir dans un navigateur). etc.
Sinon, c'est bien. (y en a toujours pour râler)
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Avant...
Posté par pascalc . Évalué à 10.
Si tu appuies sur la touche MAJ de ton clavier en cliquant, c'est le menu contextuel de Firefox qui s'affichera, pas celui imposé par la page.
[^] # Re: Avant...
Posté par Stéphane P. . Évalué à 10. Dernière modification le 26 janvier 2017 à 13:41.
Venge toi en faisant du Shift + Clic droit, la nouvelle version du clic droit ininterdisable :)
(oups, répondu sans rafraîchir la page, trop tard, désolé)
[^] # Re: Avant...
Posté par StyMaar . Évalué à 2.
Heureusement qu'il y a des gens comme toi qui râlent, parce qu'après des gens leur répondent et du coup on est plein à avoir appris un truc aujourd'hui :D
# Erreur dans la dépêche
Posté par Renault (site web personnel) . Évalué à 10.
Ce n'est pas vrai. C'est l'inverse. Cela ne s'active que si toutes les extensions possédées sont déclarées comme compatibles. La différence est que beaucoup d'extensions n'ont pas de status à ce sujet, cela sera donc considéré comme incompatible même si ce n'est pas vrai.
J'en profite pour dire que Mozilla ne peut deviner seules les extensions qui sont compatibles ou non. Cela repose donc sur les développeurs et utilisateurs des extensions de le signaler.
Si vous souhaitez accélérer le déploiement par défaut de Electrolysis dans Firefox vous pouvez consulter la page listant les extensions et leurs status.
Vérifiez que toutes vos extensions soient marquées comme compatibles. Si non, installez l'extension recommandée sur cette page. Forcez Electrolysis sur votre configuration et testez. Faites ensuite un rapport d'activité via l'extension après un usage raisonnable de l'extension et du navigateur (donc quelques jours probablement). Et si ce n'est pas compatible, n'hésitez pas à contacter les développeurs des extensions concernées.
Plus il y aura de retours, plus vite la situation évoluera pour un déploiement total et sans casse.
Le Logiciel Libre, c'est aussi s'impliquer pour que cela avance. ;-)
[^] # Re: Erreur dans la dépêche
Posté par Benoît Laurent (site web personnel) . Évalué à 4.
Bonne idée, justement j'ai une extension "It's all text !" qui est marqué incompatible.
J'ai installé l'addon Add-on Compatibility Reporter qui me dit "Multiprocess is not enabled."
Donc j'active dans
about:config, en faisant Toggle surbrowser.tabs.remote.autostartcomme indiqué dans wiki.mozilla.org - ElectrolysisEt maintenant ? J'utilise quelque temps l'extension et si pas de problème je soumet, c'est ça ?
J'ai quand même un doute, dans
about:supportj'ai toujours " Multiprocess Windows 0/1 (Disabled by add-ons)"[^] # Re: Erreur dans la dépêche
Posté par Renault (site web personnel) . Évalué à 2.
Tu as redémarré Firefox après ta manipulation ?
[^] # Re: Erreur dans la dépêche
Posté par Benoît Laurent (site web personnel) . Évalué à 1.
Et oui et redémarré à nouveau pour être sûr.
[^] # Re: Erreur dans la dépêche
Posté par Renault (site web personnel) . Évalué à 4.
Ah oui, je n'avais pas fait attention, je n'ai pas suivi cette procédure et chez moi cela marche.
J'ai crée la clé browser.tabs.remote.force-enable que j'ai mis à True puis j’ai relancé. Tu devrais essayer.
[^] # Re: Erreur dans la dépêche
Posté par Benoît Laurent (site web personnel) . Évalué à 2.
Ah oui en ajoutant cette clé ça marche et il semble que l'extension aussi.
Merci.
[^] # Re: Erreur dans la dépêche
Posté par ff9097 . Évalué à 2.
Je viens de mettre à jour Firefox en version 51 sur Fedora. Je n'ai qu'une extension installée : ublock origin, marqué compatible (https://arewee10syet.com/#15) et pourtant dans about:support j'ai "Fenêtres multi-processus 0/1 (Désactivé)". Du coup je ne comprends pas.
[^] # Re: Erreur dans la dépêche
Posté par Renault (site web personnel) . Évalué à 3.
C'est probablement Fedora qui a décidé de couper par défaut pour tout le monde ce mode, le temps de vérifier son bon fonctionnement.
[^] # Re: Erreur dans la dépêche
Posté par barmic . Évalué à 2.
Wow… Si Fedora n'ose pas le mettre c'est que ça doit vraiment être pas frais… :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Erreur dans la dépêche
Posté par Renault (site web personnel) . Évalué à 3.
Il faut dire que Mozilla et les distributions sont rarement en phases pour ce genre de changements importants. Chaque OS a plus ou moins son propre calendrier. On l'a vu pour GTK+3 où Linux (et Fedora en tête) ont été en avance par rapport à Windows, mais Linux a été en retard sur la question de l'accélération matérielle et pour les bibliothèques multimédias, etc.
Fedora est certes une vitrine technologique mais avec un minimum de QA derrière. Je suppose qu'étant donnée l'importance de Firefox (navigateur principal et par défaut) et les potentiels soucis qui peuvent apparaître le mainteneur a dû être frileux. On verra bien. :)
[^] # Re: Erreur dans la dépêche
Posté par barmic . Évalué à 3.
Ils ont poussé des trucs comme PulseAudio à une époque où c'était Rock'n'Roll pourtant et je pense qu'il y a plus de gens qui savent changer de navigateur que de gens qui savent bypasser PA.
Mais bon c'était une boutade, ils font bien ce qu'ils veulent. Ça m'a surpris parce que je trouve Mozilla assez méticuleux sur le sujet et que c'est une fonctionnalité assez attendue.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Erreur dans la dépêche
Posté par Renault (site web personnel) . Évalué à 3.
Fedora a changé depuis cette époque, la QA a pris énormément d'importance depuis. Cela se voit avec Wayland qui a été maintes fois repoussé et avec conservation de la roue de secours quand cela a été envoyé.
Mozilla fait attention, c'est vrai, mais comme indiqué, le calendrier de Mozilla est rarement identique pour tous les systèmes d'une part (Windows a quand même bien plus de testeurs) et les distributions ont leur propre politique (n'oublions pas que c'est cela le but d'une distribution aussi, potentiellement différer sur la source pour avoir un tout cohérent).
# Contribuer à mozilla en utilisant Nightly
Posté par pascalc . Évalué à 10.
Bonjour,
Le petit paragraphe sur Nightly date de novembre et la plupart des fonctionnalités présentées à l'époque sont sorties dans la version grand public :)
Je profite donc de ce billet de sortie pour rappeler qu'un premier pas pour aider Mozilla à développer Firefox mieux et plus rapidement est d'utiliser la version Nightly ! Si vous laissez la télémétrie activée et que vous renvoyez vos rapports de plantage, sa simple utilisation est une aide précieuse pour les développeurs. Si vous rapportez en plus des bugs dans notre bugzilla (https://bugzilla.mozilla.org) c'est évidemment encore mieux mais déjà l'utiliser nous aide à détecter des tas de problèmes et régressions au plus tôt et on préfère faire un retour arrière en 10mn sur un patch intégré il y a 2 jours que passer des heures ou des jours sur le même problème une fois la régression livrée au grand public (voire être forcés de faire une nouvelle version pour un problème qu'on aurait pu découvrir plus tôt).
Si vous voulez en savoir plus sur l'actualité de Nightly en anglais, vous pouvez suivre le blog (https://blog.nightly.mozilla.org/) et le compte Twitter (https://twitter.com/FirefoxNightly/). Et la page de téléchargement est https://nightly.mozilla.org
Tous les développements lourds liés à Quantum arriveront à un moment sur Nigthly, e10s était sur Nightly 1 an avant la version grand public, toutes les nouvelles fonctionnalités sont aussi sur Nightly longtemps avant la version finale.
Évidemment Nightly n'est pas pour tout le monde, ça n'est pas dans les dépôts de votre distro, ça se met à jour (automatiquement) quotidiennement, ça n'a pas le "polish" d'une version finale… mais je pense que si vous lisez LinuxFR c'est que vous avez un certain bagage technique et qu'utiliser une version en plein développement et mettre de temps en temps les mains dans le cambouis ne vous fera pas peur.
Quelques fonctionnalités actuellement activées uniquement sur Nightly 54 pour vous donner une idée :
- Les onglets d'identité contextuels https://tech.mozfr.org/post/2016/09/10/Les-onglets-contextuels-dans-Firefox-Nightly
- De nouveaux thèmes clairs/sombres par défaut proches de ceux de la Dev Edition https://twitter.com/FirefoxNightly/status/820954456829423616
- Electrolysis-multi, on commence cette semaine à augmenter le nombre de processus pour le contenu web
- Un bouton directement dans l'interface pour nous signaler un site incompatible avec Firefox (https://miketaylr.com/posts/2017/01/report-site-issue-button-in-firefox-nightly.html)
- Une plus grande sécurité avec du sandboxing sous Linux (https://groups.google.com/forum/#!searchin/mozilla.dev.platform/linux$20sandbox%7Csort:relevance/mozilla.dev.platform/V-5G9dWJEXo/S9qxkg9EAgAJ)
- De manière générale des performances accrues
- De nombreux petits changements d'interface et de fonctionnement (par exemple un champ de recherche pour les balises <select> de plus de 40 options, un affichage des titres des onglets légèrement différent, un nouveau look pour de nombreux dialogues, widgets et le lecteur vidéo…)
Merci de votre aide !
Pascal Chevrel
(employé Mozilla)
[^] # Re: Contribuer à mozilla en utilisant Nightly
Posté par cbri . Évalué à 1.
On essaye de compiler les différentes nouveautés dans les dépêches, une partie de celles que tu as évoqués ont été cités dans la dépêche sur Firefox 50.
Une autre partie est dans cette dépêche rubrique" prochaines versions"
On aurait pu mettre fusionner la rubrique Nightly et prochaines versions. À voir.
[^] # Re: Contribuer à mozilla en utilisant Nightly
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Une petite question concernant le fingerprint de navigateur, c'est un moyen d'identifier une personne a son insu mais si l'utilisateur veut être identifié, il n'y a que les cookies pour faire ça ?
Est-ce qu'il existe un moyen vaguement automatique de mettre une clef public/privé dans le navigateur pour faire des échanges sécurisées avec lui, et en même temps, que le vol de ces donnés ne puissent pas servir à un autre navigateur sur une autre machine ? Je parle au-delà d'une simple connection TLS.
Il me semble que les impôts faisaient cela à une époque, mais il y avait des modifications manuels à faire pour installer le certificat qu'il ne fallait pas perdre.
Je recherchais une solution qui permettrait d'avoir la sécurité du certificat mais l'installation aussi simple qu'une double authentification.
"La première sécurité est la liberté"
[^] # Re: Contribuer à mozilla en utilisant Nightly
Posté par Julien Wajsberg . Évalué à 2.
Je ne comprends pas exactement ce que tu veux dire. Tu peux déjà regarder du côté de https://developer.mozilla.org/en-US/docs/Web/API/Crypto, et stocker des trucs dans localStorage.
[^] # Re: Contribuer à mozilla en utilisant Nightly
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Une autre question concernant les proxy https menteurs d'entreprise. Est-ce Mozilla a des mesures pour démasquer ce genre de technologies ? Par exemple, avec des certificats racines "en dure" pour les sites les plus sensibles, comme les moteurs de recherche, entre autre.
Ce n'est pas encore arrivé, mais il y a un risque massif de fuite de données personnels si ce genre de technologies a des logs bavards (vol de mot de passe, de numero de carte de crédit, etc…)
"La première sécurité est la liberté"
[^] # Re: Contribuer à mozilla en utilisant Nightly
Posté par Julien Wajsberg . Évalué à 3.
La plupart des navigateurs supportent les 2 mécanismes suivants:
* HSTS Preloading (https://hstspreload.org/) permet de forcer l'usage de HTTPS sur un site, même à la première visite
* HPKP: HTTPS Public key pinning, permet de forcer une certaine clé publique, voir https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning. D'après l'article Wikipedia, on dirait que Chromium ne l'utilise pas dans l'usage que tu dis cependant, je ne sais pour Firefox..
[^] # Re: Contribuer à mozilla en utilisant Nightly
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Le HSTS ne sert pas dans le cas dont je parle (MiM HTTPS). Concernant le HPKP j'avais lu des trucs déplaisant : un administrateur de réseau pouvait contourner cette protection, un peu comme si, les entreprises passaient devant les utilisateurs. Je voulais connaître la situation actuelle.
"La première sécurité est la liberté"
[^] # Re: Contribuer à mozilla en utilisant Nightly
Posté par ckyl . Évalué à 3.
De toute façon la plupart des navigateurs laissent faire du MITM sur un certificat a été déployé manuellement dans le private trust store:
C'est une fonctionnalité voulue et assumée.
Après HPKP présente forcément le problème que c'est du trust on first use. Si un méchant te répond à la première utilisation, c'est mort. Or par définition, si je contrôle ton réseau j'ai accès à ton premier appel sur un domaine.
Si tu veux pas que quelqu'un face du MITM, passe par une app ;)
[^] # Re: Contribuer à mozilla en utilisant Nightly
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Typiquement, les certificats de google sont en dure dans chrome et ne peuvent être changé.
A part faire de l'espionnage, il n'y a aucune raison de toucher aux certificats des sites des moteurs recherches, des réseaux sociaux, etc…
"La première sécurité est la liberté"
[^] # Re: Contribuer à mozilla en utilisant Nightly
Posté par ckyl . Évalué à 4.
Absolument. Ils le sont aussi dans Firefox.
Les deux navigateurs publient la liste des domaines en question. Ça reste une solution pour un tout petit club, les autres n'ayant mieux que TOFU pour solution.
Maintenant certificat en dur dans le browser, pardon téléchargé depuis un site de confiance, ou TOFU, la décision d'appliquer le certificate pinning est la décision du navigateur. Et il se trouve que dans certains cas, ils décident de ne pas l'appliquer.
C'est ton point de vu, et il se défend.
D'autres ont un avis différent et pensent que si tu as accès au private trust store du navigateur, alors tu as la main sur la machine, que tu sois admin ou que tu l'ai déjà compromis, et qu'il n'y a pas de raison de ne pas te laisser faire du MITM si le certificat racine qui est utilisé est celui que tu as inséré. Les cas d'usages vont de la politique d'entreprise de tout inspecter, à l'espionnage en passant par des trucs bizarres comme la mesure d'audience où les gens sont volontaires pour se faire ouvrir leurs connexions.
Pour le moment les navigateurs ont choisi cet autre point de vu et implémentent ce comportement. Si ton admin insère un certificat dans ton private trust store, alors il peut faire du MITM.
De l'autre côté n'importe qui maitrisant ton réseau peut faire du MITM sur tout ce qui repose sur une stratégie TOFU.
[^] # Re: Contribuer à mozilla en utilisant Nightly
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Tu te répètes :)
Au minimum, Firefox devrait informer ses utilisateurs que les certificats ne sont pas les bons (avec un cadenas écrasé ?).
"La première sécurité est la liberté"
[^] # Re: Contribuer à mozilla en utilisant Nightly
Posté par ckyl . Évalué à 4. Dernière modification le 30 janvier 2017 à 18:01.
Puisque tu veux la version courte. Ta question originelle était:
Non. Le fonctionnement actuel est un choix assumé et documenté.
Si tu penses que c'est une erreur, direction le bug tracker.
Tu posais aussi une autre vague question
Bin tu as aussi la réponse…
Entre temps je te donne les liens, l'explication de pourquoi c'est comme ça et t'indique clairement que la désactivation du pinning est orthogonale au reste. Tu en fais ce que tu veux.
Maintenant si tu lis attentivement la troisième alternative de ma réponse, tu trouves un cas intéressant philosophiquement et techniquement. Tu peux aussi te poser la question avec les app de savoir si je devrais pouvoir faire du MITM sur les connections SSL sortant des app de mon téléphone, ou si l'éditeur de l'application peut / devrait m'en empêcher. Dans ce cas je ne pourrais plus savoir ce qu'il transmet à ses serveurs ou faire du reverse engineering via le réseau, mais devrait intercepté ça au niveau de l'OS.
[^] # Re: Contribuer à mozilla en utilisant Nightly
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Pour ton 3ième cas, tu parles d'une application où tu n'as pas confiance. Pour mozilla, c'est censé être l'inverse. J'ai plus confiance en Mozilla Firefox concernant mes données, que de Androïd ou d'un réseau wifi "smartphone" avec DPI.
Je suis d'accord qu'il ne faut pas faire n'importe quoi avec les modules. Mais bon, l'utilisateur de Firefox est rarement le propriétaire du réseau par lequel il passe.
Tu ne réponds pas sur le fait de signaler ou non à l'utilisateur que les certificats ne sont pas les bons.
"La première sécurité est la liberté"
[^] # Re: Contribuer à mozilla en utilisant Nightly
Posté par Parleur . Évalué à 1.
Ya une extension comme Certificate Patrol qui fait un peu ce genre de truc, je crois.
[^] # Re: Contribuer à mozilla en utilisant Nightly
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Oui, je l'utilise. Mais il passe son temps à te signaler les changements de certificats, sans préciser, si la chaine est de confiance ou pas. Bref, c'est bas niveau, et il faut être expert pour comprendre les alertes.
"La première sécurité est la liberté"
[^] # Re: Contribuer à mozilla en utilisant Nightly
Posté par Moonz . Évalué à 3.
Ou le reverse engineering.
[^] # Re: Contribuer à mozilla en utilisant Nightly
Posté par Julien Wajsberg . Évalué à 2.
Ou bien mets la pref security.cert_pinning.enforcement_level à 2.
https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning#How_to_use_pinning
[^] # Re: Contribuer à mozilla en utilisant Nightly
Posté par Julien Wajsberg . Évalué à 2.
À noter qu'il y a un bug bugzilla avec une discussion similaire à celle-ci: https://bugzilla.mozilla.org/show_bug.cgi?id=1059392
Pour l'instant ça aboutit pas sur grand chose.
[^] # Re: Contribuer à mozilla en utilisant Nightly
Posté par GG (site web personnel) . Évalué à 0.
Sur Windows il y a souvent les anti-virus (sic) qui sous prétexte de scanner tout ce qui entre font du MITM.
Le problème arrive quand on veut visiter un site en https, le certificat ne coincide plus avec celui renvoyé par Avast.
C'est une plaie, parce que les utilisateurs se croient protégés, ou bien ils ne comprennent pas ce qui se passent ni le fait que leur soit disant logiciel anti-virus compromet la sécurité en étant placé en MITM…
Bon, c'est sous Windows, alors… OSEF?
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Contribuer à mozilla en utilisant Nightly
Posté par StyMaar . Évalué à 1.
Bien plus longtemps que ça ! e10s est arrivé sur Nightly en début d'année 2014 ;)
Il faut dire que ça a été un chantier super long ce truc, j'espère que Quantum prendra moins de 8 ans à voir le jour !
# Vimperator cassé
Posté par refreketu . Évalué à 3. Dernière modification le 26 janvier 2017 à 13:55.
Pour info : cette version a cassé Vimperator. Si cette extension est importante pour vous, je vous déconseille la mise à jour pour l'instant.
[^] # Re: Vimperator cassé
Posté par cbri . Évalué à -1.
Cela fait depuis novembre que le développer c'est qu'il va y avoir un souci.
Vu les failles corrigés dans Firefox 51, j'éviterais de déconseiller la mise à jour.
[^] # Re: Vimperator cassé
Posté par refreketu . Évalué à 4.
J'ai pas déconseillé la mise à jour, j'ai déconseillé la mise à jour SI vimperator est plus important pour toi que ce que tu gagnerais à la faire, correctifs de sécurité compris. Après chacun est juge. Moi par exemple j'ai la chance de ne rien y connaître du tout en memory corruption attacks et tout ça, et donc de m'en foutre comme de ma première chaussette. Par contre perdre 50% de ma productivité à devoir reprendre la souris alors que je suis habitué à tout faire au clavier, ça je m'en fous pas. Mais j'imagine effectivement que quand on est conscient des risques on voit les choses autrement.
[^] # Re: Vimperator cassé
Posté par cbri . Évalué à 5.
J'y connais rien non plus à la corruption mémoire.
Mais un navigateur web est un logiciel extrêmement exposé et je ne souhaite pas que quelqu'un rentre dans mon ordi! Si je dois me mettre à jour (juste des patch de sécurité), je le fais, point barre! Si cela m'empêche d'utiliser une extension qui m'est fortement nécessaire, je basculerais plutôt sur Firefox ESR que de traîner avec une veille version trouée comme une chaussette.
Mozilla te permet de placer le curseur où tu le souhaite, le temps que ton extension redevienne compatible.
[^] # Re: Vimperator cassé
Posté par reynum (site web personnel) . Évalué à 2.
Zut j'ai lu le message après avoir mis mon système à jour et remarqué que le Bô Firefox Pastis était arrivé mais que le mode vimpérator était devenu inutilisable :-(.
kentoc'h mervel eget bezan saotred
[^] # Re: Vimperator cassé
Posté par Sclarckone . Évalué à 5.
En moins "extrême" que Vimperator (car il ne modifie pas l'apparence de Firefox) il existe aussi VimFx, qui n'est pas cassé dans la version 51.
[^] # Re: Vimperator cassé
Posté par reynum (site web personnel) . Évalué à 2.
pas mal du tout je suis en train de tester, ça me change pas mal après plus de 6 ans de vimperator mais j'aime bien le principe d'utiliser la barre d'adresse au lieu de la barre spéciale en bas.
Mais l'historique des commandes me manque un peu quand même.
kentoc'h mervel eget bezan saotred
# Enregistrement des mots de passe
Posté par Sytoka Modon (site web personnel) . Évalué à 7.
Je ne comprends pas que le trousseau de mot de passe ne soit pas protéger OBLIGATOIREMENT par une phrase de passe. Je trouve anormal qu'un tel logiciel puisse enregistrer des mots de passe sans chiffrer derrière le trousseau.
A une époque, j'avais lu que le chiffrement utilisé dans Firefox pour chiffrer le trousseau était faible. Qu'en est-il aujourd'hui ?
En parlant de mot de passe, lorsqu'on s'identifie sur une site en mode HTTP BASIC ou DIGEST (donc sans formulaire car en utilisant la norme intégré dans HTTP), une popup s'ouvre dans laquelle on donne son login/mot de passe. Il serait bien alors de rajouter dans l'onglet un bouton pour se déconnecter car cela est actuellement (et depuis toujours) impossible sans avoir à fermer son navigateur. C'est hyper pénalisant. A noter que personnellement, je préfère ce type d'authentification dans les sites web car celle-ci peut se réaliser par le serveur web AVANT exécution de tout code PHP, Python, Ruby…
Bref, l'authentification pourrait être bien plus intégré dans le navigateur qu'actuellement et pourtant, c'est un point fondamental.
[^] # Re: Enregistrement des mots de passe
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à -2.
L'authentification HTTP ne conserve pas d'état. Si tu restes connecté après être passé par une authentification HTTP, c'est probablement parce que la page sur laquelle tu t'es authentifié t'as donné un cookie. Mais les pages suivantes vont utiliser seulement ce cookie, et pas re-demander l'authentification à chaque fois.
Donc, on ne peut pas se "déconnecter" automatiquement, à moins d'identifier le cookie en question et de le supprimer. Ce qui n'est pas simple s'il est noyé au milieu de douzaines d'autres.
[^] # Re: Enregistrement des mots de passe
Posté par jyes . Évalué à 6.
Mais Firefox, si. Il ne redemande pas le mot de passe chaque fois que l’on change de page et garde les informations en mémoire tant qu’il n’est pas quitté. C’est ce comportement que Sytoka Modon souhaiterait voir évoluer.
[^] # Re: Enregistrement des mots de passe
Posté par Wawet76 . Évalué à 4.
Je viens de vérifier, et ça ne marche pas comme tu l'indique.
Firefox conserve bien l'état "connecté" : Il renvoie le mot de passe (entête Authorization) dans toutes les requêtes après une authentification HTTP.
Ça n'empêche pas une application de conserver l'état via un cookie, mais je pense que très très souvent l'authentification HTTP est mis en place au niveau de la configuration du serveur (ex: un .htaccess sur du mutualisé) et donc avant tout contrôle en PHP ou autre.
[^] # Re: Enregistrement des mots de passe
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Exact. Cela marche depuis l'origine (plus de 20 ans) et pas besoin de cookies ou de PHP. Cela a lieu avant ce qui est intéressant car on est dans les premières couches du navigateur donc on espère qu'on peut le faire confiance coté sécurité.
[^] # Re: Enregistrement des mots de passe
Posté par Babelouest (site web personnel) . Évalué à 6.
Effectivement, ce qui ce passe ici c'est la méthode HTTP Basic Auth. Le serveur lors d'une connexion invalide renvoie une erreur 401 et un realm (une sorte de nom de contexte qui permet d'utiliser des user/mot de passe différents sur le même site), l'utilisateur doit recommencer la connexion avec un couple login/mot de passe encodé en base64 et transmis au serveur http via le header Authorization.
Ensuite, les implémentations de navigateur gardent le login/mot de passe en cache quelque part et le redonnent à chaque connexion au même serveur s'il réclame le même realm, pour éviter d'avoir à se cogner le mot de passe à chaque changement de page.
On peut aussi spécifier le login/mdp HTTP Basic Auth dans l'url de cette manière:
Donc, une astuce pour se "déconnecter" est de modifier l'url en
http://error:error@domaine.tld/reste_de_l_url/, ce qui forcera la connexion avec le usererroret interdira la connexion, et normalement aura pour effet de vider le mot de passe du cache de ton navigateur.Cela dit, j'ai jamais compris moi non plus pourquoi les navigateurs n'avaient pas un bouton ou une fonctionnalité "se déconnecter" accessible pour ce genre de site.
C'est une méthode d'authentification assez facile à implémenter et à utiliser, et elle permet effectivement dans certains cas de faire l'authentification avant même d'exécuter le moindre code métier coté serveur, genre directive Auth dans apache, super pratique quand on veut faire de l'authentification sans avoir nécessairement besoin d'identification.
Mais il reste que le HTTP Basic Auth est une méthode d'authentification figée, peu souple, et peu sécurisée par rapport à ce qu'on est capable de faire de nos jours (oauth, hawk, soap, certificats, etc.), elle impose l'utilisation d'un couple user/mot de passe, et permet dans n'importe quel navigateur d'avoir accès au mot de passe en clair, vu qu'au pire, t'as juste à décoder le header en base64.
Donc je restreindrais l'utilisation du HTTP Basic Auth à des sites pour lesquels tu n'as pas besoin de te déconnecter.
[^] # Re: Enregistrement des mots de passe
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Personnellement, je l'ai mis en place sur le reverse proxy en tête d'un paquet de serveur web. Le RP est un serveur Apache n'ayant aucune extension. Pas de PHP, pas de Python… Évidement, c'est tout en https quand même.
Coté sécurité, c'est peut être pas top mais vu le peu de ligne de code et de langage exposé, c'est peut être pas forcément pire qu'autre chose ? Associé à un petit fail2ban, on limite quand même les problèmes. Personnellement, l'authentification étant un élément central dans le web, c'est quand même mieux si le navigateur et le serveur web peuvent gérer tout cela sans que le développeur n'ait besoin de faire la moindre ligne coté serveur (PHP, Python…) ou client (Javascript).
Bref, peut être que Mozilla et Apache pourrait travailler sur cette problématique de l'authentification afin d'intégrer en dur un truc bien robuste et régulièrement évaluer par des experts en sécurité.
[^] # Re: Enregistrement des mots de passe
Posté par Sufflope (site web personnel) . Évalué à 0.
Et comment tu gères l'inscription d'utilisateurs ? Comment ils changent leur mot de passe ? Comment ils gèrent leurs options de double authentification, etc ? Ah oui, avec une appli web. Du coup autant mutualiser avec celle qui utilise déjà une modélisation de tes utilisateurs, dont les développeurs connaissent le code et les technos, qui est testée…
Il y a une raison pour laquelle tu es la première personne à trouver Auth cool depuis 20 ans et pourquoi c'est complètement abandonné.
[^] # Re: Enregistrement des mots de passe
Posté par claudex . Évalué à 6.
Je ne crois pas que c'est le premier depuis 20 ans. Il y a du monde qui trouve cela intéressant. Même s'il y a des défauts. Le plus gros pour moi étant le problème du 2FA (oui, il y a des contournement, comme ajouter l'OTP au mot de passe, mais c'est source d'erreur et d'incompréhension des utilisateurs).
Quand tu as des utilisateurs dans un domaine1, c'est le même mot de passe que leur login, du coup, ça se gère très bien sans interface web. Avoir une interface distincte pour la consultation en BDD que celle pour écrire dedans n'est pas forcément un problème. Et avoir une interface de login unifiée (toujours la même fenêtre) pour tous les sites internes est, pour moi, un avantage.
en plus, avec du Windows, tu peux faire de l'auth NTLM et tu as du SSO. ↩
« 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: Enregistrement des mots de passe
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
C'est tout comme tu dis. Dans mon milieu professionnel, il n'y a pas d'inscription utilisateur. 100% de ceux-ci sont dans le LDAP et rentrer via un autre moyen que les appli web utilisateur. Idem pour le changement de mot de passe, il a lieu dans le LDAP et non dans les 36 appli web et c'est tant mieux.
Du coup, oui, AUTH BASIC a des défauts mais il fait son boulot AVANT que la première ligne de Python ne s’exécute. Je préférerais comme beaucoup d'autre avoir une évolution de AUTH BASIC afin de profiter de technologie nouvelle car je pense que c'est souvent mieux que cela soit gérer en amont de l'appli web.
Sinon, vu nos budgets dans la recherche publique, je n'ai pas les moyens de faire (ou pas trouvé encore comment faire) une authentification à double facteur pas chère. Il faut que cela marche sur tous les OS, avec nos collaborateurs à l'étranger…
[^] # Re: Enregistrement des mots de passe
Posté par claudex . Évalué à 3.
Il existe des serveurs OTP libre, (LinOTP par exemple, mais je n'ai pas testé). Et pas mal de logiciel permettent d'extraire les
premiers ou derniers caractères du mot de passe pour questionner le serveur OTP avec.
Ces serveurs fonctionnent avec des applications pour smartphone, des serveurs SMS, via mail ou même des listes papier, ce qui couvre pas mal de cas d'utilisation.
« 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: Enregistrement des mots de passe
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Je me vois pas faire un serveur SSH avec OTP via courriel. Pour ce qui est du smartphone, c'est mort. Tout le monde n'en a pas et il n'y a pas de smartphone professionnel. Donc ce n'est pas possible de baser une solution la dessus. A suivre donc ;-)
[^] # Re: Enregistrement des mots de passe
Posté par Pierre-Alain TORET (Mastodon) . Évalué à 8.
Tu peux facilement te déconnecter en utilisant http(s)://logout@tonurl/
[^] # Re: Enregistrement des mots de passe
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Génial. Je ne connaissais pas et ça marche ! Je ne connais personne qui savait cela. Comment as tu découvert cette astuce ?
Cela ne doit pas être bien difficile de faire une extension avec un bouton qui gère cela ;-)
[^] # Re: Enregistrement des mots de passe
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
En fait, la partie avant l'URL est l'identifiant de l'utilisateur. Mettre "logout" (ou "chaussette") efface tout simplement les infos d'authentification précédentes. Je ne sais pas si Firefox a un traitement spécial pour "logout" ou s'il continue d'envoyer un en-tête d'authentification avec un login qui ne marche pas?
[^] # Re: Enregistrement des mots de passe
Posté par Moonz . Évalué à 4. Dernière modification le 27 janvier 2017 à 18:37.
La dernière fois que j’avais testé, Firefox arrêtait d’envoyer les infos d’authentification dès qu’il reçoit un 401 du serveur.
[^] # Re: Enregistrement des mots de passe
Posté par barmic . Évalué à 4.
Utilise la navigation privée. Je pense que les contextes par onglets qui arrivent vont aussi te simplifier la vie :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Enregistrement des mots de passe
Posté par SamG . Évalué à 2.
Tu peux supprimer toutes les connexions basé sûr l'authentification HTTP via : Menu Historique -> Supprimer l'historique récent -> Connexions actives
[^] # Re: Enregistrement des mots de passe
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
J'aimerais pouvoir me déconnecter d'un site et non de tous… Firefox (et les autres navigateurs) demande un login/password en mode AUTH Basic pour chaque AuthName différent. C'est quand même fou que le navigateur puisse authentifier les personnes dans la requête HTTP normalisé (BASIC ou DIGEST avec AuthName) mais que rien n'est jamais été prévu dans les clients pour se déconnecter. On a l'impression que seul la moitié du protocole a été implémenté ;-)
Quand à la navigation privée proposée ci-dessus, c'est faisable mais c'est quand même incroyable de devoir sortir l'artillerie lourde pour contourner une fonctionnalité qui manque depuis tant d'année.
# WebAssembly ?
Posté par damien.polizzi . Évalué à 2.
Bonjour
J'aimerais savoir si firefox a avancé dans le support de web assembly.
Du côté moteur et outils pour développeurs.
Merci
[^] # Re: WebAssembly ?
Posté par cbri . Évalué à 2.
https://hacks.mozilla.org/2016/10/webassembly-browser-preview/
[^] # Re: WebAssembly ?
Posté par damien.polizzi . Évalué à 1.
Ok merci
# Dernière version avant grid !
Posté par rdhlnn . Évalué à 10.
On va entrer dans une nouvelle ère du web design d'ici peu !
Grid va enfin changer la manière dont on peut construire une page web, notamment dans l'utilisation des espaces vides.
Si vous souhaitez avoir un exemple de ce changement, allez voir le labo de Jen Simmons. Et ensuite, retournez-y après avoir activé dans
about:configlayout.css.grid.enabled!il y a cette présentation de Jen Simmons où elle explique un peu certaines possibilités offertes par grid. Il y a aussi le travail de Rachel Andrew sur cette nouvelle option.
# Electrolysis et NVidia
Posté par Antoine . Évalué à 2.
Avec la mise à jour Ubuntu vers Firefox 51, je viens d'essayer Electrolysis en désactivant mes modules Firefox. Verdict : ça marche très mal, l'affichage n'est pas rafraîchi correctement quand je passe d'un onglet à l'autre. Le tout sur une carte GeForce GT 730 utilisant, bien sûr, les pilotes proprios. Est-ce que quelqu'un a eu la même expérience que moi ?
[^] # Re: Electrolysis et AppArmor
Posté par Antoine . Évalué à 5.
Après une courte investigation, le responsable n'est pas NVidia mais le profil AppArmor d'Ubuntu pour Firefox :
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1660051
(pour ceux qui rencontrent le même problème, une solution est donnée dans le rapport de bug ci-dessus)
[^] # Re: Electrolysis et AppArmor
Posté par StyMaar . Évalué à 1.
Ça me rassure un peu, j'avais du mal le lien entre e10s et la carte graphique. Par contre le passage à skia au lieu de Cairo pourrait poser ce genre de problèmes …
# WebGL 2 : Firefox et Chrome, même combat
Posté par ComputingFroggy (site web personnel) . Évalué à 1.
Salut,
J'ai voulu tester WebGL 2 sur Firefox : je vais sur le site des démos et sur celui du blog de Mozilla ou j'accède à la démo qu'ils présentent. Même résultat : WebGL n'est pas activé. Je suis les instructions données par le wiki : ça ne fonctionne toujours pas.
Je me dis pas grave : j'ai vu que Chrome fonctionnait aussi avec WebGL 2. J'essaye Chrome et cela ne fonctionne pas non plus (même après avoir activé le flag qui va bien).
Quelqu'un a-t'il plus de réussite que moi et saurait me dire pourquoi cela ne fonctionne pas chez moi ?
(je tourne sous Xubuntu 16.04)
[^] # Re: WebGL 2 : Firefox et Chrome, même combat
Posté par Antoine . Évalué à 3.
Ça marche ici (Xubuntu 16.04, carte NVidia). En allant sur
about:supporttu auras des infos sur l'accélération graphique.[^] # Re: WebGL 2 : Firefox et Chrome, même combat
Posté par ComputingFroggy (site web personnel) . Évalué à 1.
Effectivement, cela vient de ma config graphique :
Rendu WebGL Intel Open Source Technology Center—Mesa DRI Intel(R) Sandybridge Desktop
Rendu WebGL2 WebGL creation failed: * WebGL 2 requires support for the following features: transform_feedback2 * Exhausted GL driver options.
…
HW_COMPOSITING blocked by default: Acceleration blocked by platform
OPENGL_COMPOSITING unavailable by default: Hardware compositing is disabled
Je regarderai à l'occasion comment activer ça … et si c'est activable : je n'ai pas de carte graphique spécifique mais j'utilise le chip graphique de mon CPU.
ID du périphérique Mesa DRI Intel(R) Sandybridge Desktop
Merci pour les réponses.
[^] # Re: WebGL 2 : Firefox et Chrome, même combat
Posté par Nibel . Évalué à 2. Dernière modification le 29 janvier 2017 à 23:16.
Tape chrome://gpu/ dans ta barre Chromium et vérifie que WebGL et WebGL2 soient bien en accélération matérielle.
Si ce n'est pas le cas, tape chrome://flags/ et active WebGL2.0.
Fonctionne chez moi sous Arch. Et c'est d'ailleurs relativement impressionnant, 50 FPS en Ultra en plein écran (1080p) avec une GTX 970m et les drivers proprios.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
# panorama : fini fini
Posté par sifu . Évalué à 4.
Il semble que ces modifications dans les extensions sonnent la fin du successeur de panorama https://addons.mozilla.org/fr/firefox/addon/tab-groups-panorama/.
Le développeur annonce qu'il ne pourra pas faire avec le nouveau système http://fasezero.com/lastnotice.html :/
[^] # Re: panorama : fini fini
Posté par StyMaar . Évalué à 1.
Cette nouvelle m'a vraiment attristé.
Par contre je n'ai pas bien compris la position de Quicksaver dans cette histoire: lorsqu'il a repris le projet panorama abandonné par mozilla pour en faire une extension, les webExtension avaient déjà été annoncées, or il n'avait jamais parlé en public du problème que ça poserait à terme pour cet addon. Naïvement je pensais que qu'il avait prévu le coup et qu'il était tranquillement en train de faire le portage …
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.