Firefox : Rumeurs et news sur le développement

[teoli2003]

Les standards du web sont en train d'évoluer vers plus de restriction dans le mélange de données de sources cryptées/authentifiées et de sources non-cryptées. En effet, c'est un vieux problème: la page est https:// mais certains contenu sont http:// et même parfois l'URL de soumission du formulaire de données confidentielle est en http://. C'est le problème du mixed content ou contenu mélangé.

Les navigateurs n'ont pas encore unifié leur manière de faire (pas facile, parce que ce genre de restrictions ont tendance à casser des sites, il faut donc y aller par étapes, selon le principe du Don't break the web).

Néanmoins, pour les nouveaux trucs, il vaut mieux ne pas introduire ce genre de problèmes! Or justement il existe deux types de websockets: les non-sécurisés (protocole ws:) et les non-sécurisés (protocole wss:).

Donc désormais on ne pourra pas créer de websocket non sécurisé depuis une page https:// !

Déjà dans vos Nightly.

Bug 662692 — Do not allow mixed-content WebSockets

[teoli2003]

Ces dernières années, avec l'arrivée entre autres des smartphones, les favicônes se sont répandues un peu partout sur vos appareils: outre l'icône associée à un marque-page, à une page dans l'historique ou à un onglet, on utilise de plus en plus cette icône comme l'icône d'un programme sur un bureau. Les webapps sont bien là.

Seulement voilà, la petite icône rikiki, c'est pas terrible sur le bureau. Mais HTML5, chevalier des temps modernes, est passé par là et il a ajouté l'attribut sizes à l'élément <link> qui permet de définir plusieurs icônes de taille différents.

Si iOS ne l'utilise pas (mais un mécanisme bâtard à peine différent: des valeurs apple-touch-icon et apple-startup-icon comme type dans <link>... Le truc super quand 200 vendeurs feront de même: samsung-touch-icon, htc-touch-icon, nokia-touch-icon, ... Je sais pas ce qui leur est passé par la tête-là), les vrais navigateurs, eux, le font. Et dès la prochaine Nightly, Fennec pourra rouler des mécaniques aussi! (Firefox 8 pour Mobile).

Webdevs! Utilisez donc désormais sizes! Ça coûte presque rien (quelques icônes à différentes tailles) et vos webapps ou marque-pages n'en seront que plus jolies sur smartphone (et je parie que des utilisations sur le bureau apparaîtront aussi).

Bug 596650 — Use the "sizes" attribute to select the best web app icon

[teoli2003]

Dès la prochaine Nightly, Firefox (mais pas une page web!) pourra lire le type de connexion réseau que vous utilisez. Il pourra obtenir l'une des valeurs suivantes:

• unknown
• wifi, pour le IEEE 802.11 (que ce soit du a/b/g/n ou autre);
• wimax, pour le IEEE 802.16;
• 2g, pour le GSM, GPRS ou EDGE;
• 3g ,pour l'UTMS et le CDMA;
• 4g, pour le LTE ou l'UMB;
• ethernet, pour le IEEE 802.3 (toutes variations)
• ou usb, ben pour une clé USB.

Cela permettra au navigateur de ne pas faire certaines demandes avec certaines connexion (télécharger une mise à jour, envoyer les données de télémétries, checker les mise à jour des modules, etc.).

Cela a deux conséquences pour les utilisateurs de Firefox sur Androïd:

1. Une nouvelle permission sera demandée à l'installation de l'application (Read phone state and identity')
2. et, conséquence de ce point 1., il ne pourra y avoir de mise-à-jour automatique entre Firefox for Android 7 et Firefox for Android 8.

Bug 667980 — Expose network connection type to chrome

[teoli2003]

Toujours dans le cadre de l'implémentation/nettoyage de l'API HTML5 File API, voici la méthode getFile sur l'objet BlobBuilder. L'objet BlobBuilder doit toujours être préfixé par moz pour l'instant. Bien que dans la spécification, il s'agit encore d'un WorkingDraft.

getFile prend deux arguments: le nom du fichier, et, en option, le type de celui-ci.

À noter que cette méthode n'a pas encore été ajoutée à la spec.

Dans votre prochaine Nightly, et, si tout va bien dans Firefox (version release) le 8 novembre 2011.

Bug 669437 —Implement BlobBuilder.getFile

[teoli2003]

L'affichage des données de télémétrie, dans la page about:telemetry, a été fortement améliorée. Outre de nombreuses nouvelles métriques, les histogrammes sont désormais affichées avec une abscisse horizontale les rendant bien plus lisible.

Ayant loupé le bug concernant ce changement, je ne peux vous dire de quand il date. Mais c'est au moins dans votre Nightly!

[teoli2003]

Jusqu'à présent chaque élément HTML de type media (soit <audio> et <video>) utilisait 3 fils (4 sous Linux).

Ce n'est pas optimal car:

1. Chaque fil possède sa propre pile. Elle fait 1 Mo par défaut et même 10 Mo sous Linux. (Soit 30 Mo par tag!!!)
2. Si il y a 100 éléments media, il y a 300 fils créés. Ce qui est inutile sur des processeurs 1 - 12 coeurs. Pire, l'OS peut empêcher la création d'un gros nombre de fils/processus et parfois les performances globales peuvent s'écrouler (c'est assez rare)

L'idéal c'est d'avoir besoin 1 seul fil par élément media et de gérer ceux-ci en pool, ce qui permet un contrôle optimal du nombre global de fils et minimise la mémoire.

La première étape est arrivée il y a quelques jours (sur Nightly). Désormais il y a un fil de moins par élément. De plus lorsque l'élément n'est pas en train de "jouer" (car pas encore inactif, pas démarré ou en pause), les fils restant sont détruits.

La consommation mémoire est donc plus basse et les pages "extrêmes" ont plus de chance de marcher à peu correctement.

Bug 592833 — Reduce thread usage of media elements

Ce n'est qu'une première étape, mais probablement la plus notable. L'étape suivante sera de supprimer le second fil (Bug 623444 — Replace libsydneyaudio with a callback based audio library). Par la suite d'autres amélioration (comme un pool de fils) pourront être faites, mais cela n'aura d'intérêt que lorsqu'il y a beaucoup de media éléments fonctionnant en même temps et mélangeant leur audio, comportement cacophonique de toutes manières peu agréable à l'utilisateur et donc très très rare).

[teoli2003]

Un identifiant de fragment est ce qui apparaît après le '#' dans une URI. Souvent appelé juste fragment, il identifie une partie d'un document. Il est également appelé parfois, surtout par les anglophones, hash reference car dièze se dit hash en anglais.

Il y avait un soucis avec les identifiants de fragments et le protocole file:. En effet, celui-ci était parfois simplement "effacé" de l'URI lorsque file était suivi d'exactement deux slash.

C'est corrigé dans vos Nightly.

Pas très important, mais c'est le genre de bugs que l'on peut voir passer sur le forum (« Mais euh, mon file il marche sous IE et pas sous Firefox ! »). Pas très courant, mais…

Bug 656853 — The URI "file://" doesn't handle hash references correctly

[teoli2003]

Une petite amélioration vient de rendre le cache de démarrage plus efficace.

Firefox possède un cache de démarrage. En effet, au démarrage de Firefox de très nombreux scripts sont chargés: ceux de Firefox, ceux d'extensions classiques ou de jetpacks...

Cela fait de nombreuses opérations, qui d'un démarrage à l'autre ne changent pas, ou rarement. Pour éviter de refaire à chaque fois certaines opérations, et démarrer ainsi le navigateur plus rapidement, Firefox a un cache de démarrage (startup cache).

Mais jusqu'à présent, les scripts chargé à partir de l'interface XPCOM mozIJSSubScriptLoader et son unique méthode loadSubScript().

Cela devrait accélérer très légèrement le démarrage de Firefox, surtout en présence de nombreuses extensions utilisant l'Add-on API.

C'est dans vos Nightly, et prévu dans Firefox le 8 novembre 2011.

Bug 648125 — Allow caching JS loaded with loadSubScript

[teoli2003]

Accrochez-vous! J'ai essayé de vous simplifier une nouveauté depuis quelques jours dans vos nocturnes: l'attribut HTML5 crossorigin, son utilité et comment l'utiliser. Ben c'est pas évident à dé-techniciser le plus possible.

Depuis longtemps, des sites malhonnêtes utilisent (euh, essaient d'utiliser) une technique subtile pour retirer des informations sur vous. S'ils arrivent à deviner l'adresse de l'image d'une page à laquelle vous seule avez accès (un truc de votre banque à tout hasard), ils peuvent charger cette image dans la page malhonnête qu'ils vous servent et, à l'aide de script, se l'envoyer, ou ses données; le serveur de la page croira que c'est vous (puisque vous avez la même IP).

C'est un problème, aussi depuis longtemps, il y a un règle fondamentale de la sécurité sur le Web (et donc dans les navigateurs) : Ne jamais permettre à un script d'accéder aux images d'un autre site au niveau du pixel. Ils peuvent les afficher, mais comme une boîte noire, sans en avoir le contenu. On appelle ce genre d'images des cross-domain images et on évite donc de donner de l'information sur leur contenu au site tiers.

C'est assez efficace, et ne limite pas l'usage de cross-domain images dans 99% (et les cross-domain usages sont une pratique très courantes et nécessaires). Avec les évolutions modernes du web, ce problème redevient une préoccupation majeure. Ainsi l'élément HTML <canvas> pourrait permettre de contourner la sécurité: en y ajoutant une image externe, on pourrait manipuler ainsi l'image au niveau du pixel via des scripts. (via la méthode drawImage()). C'est pourquoi, un mécanisme de modification de l'image a été mis en place dans ce cas-là. Un peu comme lorsque l'on vole un bancomat, les billets sont automatiquement recouverts de peinture indélébile. Le terme anglais est tainted (images) mais, attention, c'est un faux ami, il ne signifie pas teintée mais contaminée.

Avec l'arrivée de WebGL, le même traitement a été imposée aux textures. Mais une technique pour contourner la limitation a été trouvée (avec les shaders et le temps qu'ils prennent à s'exécuter)! Je vous fais grâce des détails, qui ne sont pas triviaux.

On pouvait utiliser ces textures pour obtenir des informations sur des images de tiers. Firefox, et d'autres, a désactivé en urgence (dans Firefox 5) l'utilisation de textures "cross-domain" avec WebGL.

Seulement voilà, il existe des cas où l'on veut malgré tout pouvoir utiliser cette faculté. Par exemple dans une webapps où l'on veut retravailler une image, ou dans le site même puisque souvent un site utilise désormais deux domaines (soit parce qu'il utilise un CDN, soit pour une protection accrue contre le XSS).

Or le web a développé depuis quelques années un nouveau système d'autorisation: CORS, Cross-Origin Resource Sharing, le partage de ressources d'origines différentes.

Initialement développé pour contrôler les XMLHttpRequest, CORS permet au serveur de demander au serveur si la ressource peut être utilisée sur des sites tiers, et si oui, on relaxe les limitations. Cela a été naturellement été adapté pour les textures WebGL et pour cela il a fallu ajouter un attribut crossorigin à <img>, <video> et <audio>.

• Si l'attribut crossorigin n'est pas mis, c'est comme dans Firefox 5: la ressource ne peut être utilisée comme texture que si elle est de la même origine. Quand à son accès par des scripts, il n'est également possible qu'avec la version "tainted", sauf si elle est de la même origine.
• Si l'attribut crossorigin est mis à anonymous: le navigateur fait la requête en ajoutant un en-tête HTTP Origin:. Le navigateur va contrôler l'en-tête Access-Control-Allow-Origin: et s'il ne matche pas (soit * soit une valeur correspondant à l'Origin:, sans tenir compte de la casse). Si cela joue il affiche la ressource sinon pas.
• Si l'attribut crossorigin est mis à use-credentials: le navigateur fait la requête non seulement avec l'en-tête Origin: mais également avec les qualifications de l'utilisateur (cookies, HTTP authentification et/ou certificat client). [Note: ces informations ne sont pas envoyés dans le cas anonymous].

En résumé, les requêtes cross-domain pour <img> <audio> <video> renvoient des valeurs contaminées par défaut (et interdites comme textures), mais cette limitation peut être relaxée par le serveur les envoyant sur demande (relayée par le navigateur) du site voulant les utiliser.

Il n'empêche pas une utilisation simple de ces données (affichage de l'image).

Voilà, j'espère avoir été clair, ce n'est pas évident.

Le retour des textures inter-domaine webGL: Bug 662599 — Allow cross-domain textures with CORS approval
Les nouveaux attributs HTML5: Bug 664299 — Add crossorigin attribute
La suppression des textures inter-domaine webGL dans Firefox 5:Bug 656277 — Prevent loading WebGL textures from cross-domain images
La spec HTML5 sur les attributs crossorigin: http://www.whatwg.org/specs/web-apps/cu ... -attribute
La spec sur l'extension de l'HTTP pour le support du Cross-origin resource sharing (CORS): http://dev.w3.org/2006/waf/access-control/
CORS dans le MDN: https://developer.mozilla.org/en/HTTP_access_control
La spec WebGL mise à jour: http://www.khronos.org/registry/webgl/specs/latest/#4.2
Le blog de Chromium sur le même sujet: http://blog.chromium.org/2011/07/using- ... l-and.html (avec un exemple d'utilisation de crossorigin)
L'excellent article de Benoît Jacob sur l'interdiction des textures webGL dans Firefox 5, source d'une grande partie des infos données ici, mais en mieux: http://hacks.mozilla.org/2011/06/cross- ... firefox-5/

Note: si vous n'avez pas compris les explications, n'hésitez pas à poser des questions. C'est un sujet crucial et il est important que l'on soit capable de vulgariser ceci pour que n'importe qui connaissant un tantinet HTML/HTTP puisse comprendre.

[vulcain]

Depuis longtemps, des sites malhonnêtes utilisent (euh, essaient d'utiliser) une technique subtile pour retirer des informations sur vous. S'ils arrivent à deviner l'adresse de l'image d'une page à laquelle vous seule avez accès (un truc de votre banque à tout hasard), ils peuvent charger cette image dans la page malhonnête qu'ils vous servent et, à l'aide de script, se l'envoyer, ou ses données; le serveur de la page croira que c'est vous (puisque vous avez la même IP).

Gné ??
J'ai une image sur un site en https, par je ne sais quel moyens des méchants pas beaux en devinent l'adresse exacte (https://mozilla.com/.img/superphoto.png) mais ne peuvent la voir (accès sécurisé avec login & mdp).
Mais ensuite je n'ai pas compris il m'envoie cet image lors d'une tentative de pishing, pour avoir mon ip ? C'est une attaque man in the middle ?
Ils utiliseraient alors mon ip pour se faire passer pour moi auprès du serveur mozilla quand je suis connecté (sinon je vois pas l’intérêt de l'ip ) Mais je ne vois pas comment le serveur peut penser que les méchants et moi sont les mêmes puisent que l'on a une ip différentes et je doute qu'ils puissent m'utiliser comme proxy (ou sinon j'ai du nettoyage à faire).

[Thomas]

Tu es client de MaBanque. Sur leur site web digne des années 90 (ça semble si peu crédible ?) ils affichent toutes les données confidentielles de ton compte sous forme d'image (https://mabanque.fr/mon-compte/details.png). Heureusement, il faut se logguer pour y accéder.

Maintenant tu va sur sitemalhonnete.fr. Ils incluent dans leur site, https://mabanque.fr/mon-compte/details.png. L'image se charge donc car tu as encore les cookies et l'IP qui vont bien. Libre à eux de l'afficher ou pas (plutôt non, via des CSS) mais du coup ils peuvent l'analyser en JavaScript. Avec la balise canvas notamment, ils pourraient appliquer un algorithme de reconnaissance optique (mais heureusement, canvas ne charge pas des images sur une autre domaine).

[teoli2003]

Il y a un travail qui a repris: donner à l'utilisateur le contrôle des extensions dans son Firefox. Entre désactivations, volontaire ou pas (car incompatibilité), installation par des tiers, mises à jour plus fréquente. C'est un peu le bordel.

Une interface utilisateur est à l'étude. Voici un essai:


Et pour ceux qui veulent suivre c'est le bug 596343 — Users should have exclusive control over selecting their add-ons

[teoli2003]

<math> a été modifié pour prendre tous les paramètres de <mstyle> (conformément à la spec). Mais l'un d'entre eux, displaystyle avait été oublié. C'est réparé, on peut désormais écrire:

Code : Tout sélectionner

<math displaystyle="true">
  ...
</math>

au lieu de:

Code : Tout sélectionner

<math>
  <mstyle displaystyle="true">
    ...
  </mstyle>
</math>

Dans votre Nightly et live si tout va bien le 8 novembre 2011.

Bug 669719 — the <math/> element does not support the displaystyle attribute

[teoli2003]

L'amélioration du about:memory continue (et c'est pas fini!):

• Désormais les caches de Necko (le composant accédant au réseau) y sont affichés: Bug 669117 — Necko memory cache needs an about:memory reporter
• Mais aussi la mémoire nécessaire au collecteur de cycle (CC): Bug 665995 — Memory reporter for cycle collector

Et ce n'est qu'un début...

[teoli2003]

Il y a beaucoup d'activité sur le front des devs tools, mais il y a encore pas mal de boulot (Highlighter, meilleure console, Scratchpad, Style Inspector).

Mais voici un prototype de Tilt, visualiseur 3D de l'imbrication des <div>, <article> et autres <sections> d'une page: http://hacks.mozilla.org/2011/07/tilt-v ... age-in-3d/

Il y a une superbe vidéo dans l'article pour ceux qui ne veulent/peuvent tester.

Faudra encore du temps avant que ce soit intégrer au menu DevTools de Firefox.