On sait que Mozilla prépare activement l’arrivée de Firefox 4. Il s’agit pour l’éditeur de ne pas se tromper, car jamais avant une version de son produit n’a autant revêtu d’importance. Tandis que croît en effet l’importance de Chrome, Microsoft a de grandes ambitions pour son Internet Explorer 9. Nouvelle interface, performances, sécurité, synchronisation : Firefox 4 revoit à peu près tout. Une nouvelle page consacrée aux développeurs dévoile un peu plus certaines nouveautés très importantes.
Première modification de taille : l’utilisation du parseur HTML5. Cela signifie d’emblée plusieurs changements et nouveautés :
Pour la partie graphique, les améliorations sont assez nombreuses :
Mais c’est probablement du côté de la sécurité que les choses vont le plus bouger chez Mozilla. Firefox 4 introduira la CSP (Content Security Policy), qui est une proposition de l’éditeur pour aider les développeurs à définir comment les contenus de leurs sites interagissent. Le but est d’identifier clairement qui fait quoi afin d’empêcher un maximum d’attaques de type cross-site scripting ou injections de code.
L’un dans l’autre, il s’agit ni plus ni moins de donner de nouvelles habitudes aux développeurs. Les restrictions se feront au niveau du client et empêcheront par exemple le code JavaScript de générer lui-même du nouveau code, ou d’exécuter un autre code sans que ce dernier ait d’abord été signé. La CSP devrait être également suffisante pour empêcher les attaques de type clickjacking, une méthode malveillante, bien qu’ancienne, qui permet de récupérer à l’insu de l’utilisateur ses identifiants et mots de passe.
Pour rester dans le chapitre de la sécurité, Mozilla mettra également en place des « allocations de mémoire infaillibles ». Les développeurs qui connaissent les appels « malloc » pourront s’ils le souhaitent utiliser à la place « moz-xmalloc ()» dans le cadre d’un code JavaScript. Conséquence : aucune valeur nulle ne pourra être envoyée à une variable qui y fait appel. L’allocation de mémoire elle-même utilisera d’ailleurs un algorithme plus agressif. Dans le cas d’un code JavaScript, il ne pourra pas y avoir d’échec. En-dehors, la possibilité existe, mais Firefox fera alors planter toute l’application web plutôt que de laisser la porte ouverte à une exploitation malveillante.
Les développeurs qui sont intéressés par une liste plus complète des nouveautés pourront se rendre sur cette page de Mozilla qui leur est consacrée. À noter que celle-ci sera mise à jour au fur et à mesure de l’avancée des travaux.
Première modification de taille : l’utilisation du parseur HTML5. Cela signifie d’emblée plusieurs changements et nouveautés :
- La possibilité d’inclure du contenu SVG et MathML directement dans le code HTML
- La possibilité d’utiliser l’API WebSockets pour des communications en temps réel entre une application web et le serveur
- Des améliorations dans la prise en charge des web forms dans HTML5
Pour la partie graphique, les améliorations sont assez nombreuses :
- Le support de WebGL
- De meilleures performances graphiques
- Le support du format vidéo WebM, ce qui n’étonnera personne puisque Mozilla faisait partie des éditeurs à avoir annoncé leur support au projet de Google
- Une API pour le plein écran (les détails seront donnés plus tard)
- Le support des animations SMIL du SVG
Mais c’est probablement du côté de la sécurité que les choses vont le plus bouger chez Mozilla. Firefox 4 introduira la CSP (Content Security Policy), qui est une proposition de l’éditeur pour aider les développeurs à définir comment les contenus de leurs sites interagissent. Le but est d’identifier clairement qui fait quoi afin d’empêcher un maximum d’attaques de type cross-site scripting ou injections de code.
L’un dans l’autre, il s’agit ni plus ni moins de donner de nouvelles habitudes aux développeurs. Les restrictions se feront au niveau du client et empêcheront par exemple le code JavaScript de générer lui-même du nouveau code, ou d’exécuter un autre code sans que ce dernier ait d’abord été signé. La CSP devrait être également suffisante pour empêcher les attaques de type clickjacking, une méthode malveillante, bien qu’ancienne, qui permet de récupérer à l’insu de l’utilisateur ses identifiants et mots de passe.
Pour rester dans le chapitre de la sécurité, Mozilla mettra également en place des « allocations de mémoire infaillibles ». Les développeurs qui connaissent les appels « malloc » pourront s’ils le souhaitent utiliser à la place « moz-xmalloc ()» dans le cadre d’un code JavaScript. Conséquence : aucune valeur nulle ne pourra être envoyée à une variable qui y fait appel. L’allocation de mémoire elle-même utilisera d’ailleurs un algorithme plus agressif. Dans le cas d’un code JavaScript, il ne pourra pas y avoir d’échec. En-dehors, la possibilité existe, mais Firefox fera alors planter toute l’application web plutôt que de laisser la porte ouverte à une exploitation malveillante.
Les développeurs qui sont intéressés par une liste plus complète des nouveautés pourront se rendre sur cette page de Mozilla qui leur est consacrée. À noter que celle-ci sera mise à jour au fur et à mesure de l’avancée des travaux.
Source :
Mozilla
Vincent Hermann
Rédacteur/journaliste spécialisé dans le logiciel et en particulier les systèmes d'exploitation. Ne se déplace jamais sans son épée.
Le 31 mai 2010 à 12:17
(22 768
lectures)
Il y a 110 commentaires
Du SVG comme fond de site ? Pourquoi pas
Ah, une information sur la future interface de pci
Les développeurs qui connaissent les appels « malloc » pourront s'ils le souhaitent utiliser à la place « moz-xmalloc ()» dans le cadre d'un code JavaScript. Conséquence : aucune valeur nulle ne pourra être envoyée à une variable qui y fait appel. L'allocation de mémoire elle-même utilisera d'ailleurs un algorithme plus agressif. Dans le cas d'un code JavaScript, il ne pourra pas y avoir d'échec. En-dehors, la possibilité existe, mais Firefox fera alors planter toute l'application web plutôt que de laisser la porte ouverte à une exploitation malveillante.
la derniere phrase sous entend qu'une allocation échouée peut entrainer une faille de sécurité / exploitation malveillante
ce n'est heureusement pas le cas!
au pire, c'est juste le script qui ne va pas fonctionner correctement et etre interrompu car à l'instruction suivante on risque par exemple de tenter d'acceder à une propriété d'une référence qui est nulle... ça ne pose nullement un probleme de sécurité, mais c'est juste génant si le développeur n'a pas prévu cette situation car l'utilisateur ne verra pas d'erreur mais le site risque de ne plus fonctionner correctement (génant pour un webmail en ajax par exemple)
là de ce que je comprend, la nouveauté est que firefox signale à l'utilisateur que le site a rencontré un probleme, au lieu de laisser l'utilisateur s'en servir dans un état inconsistant
pas contre le coup de la fonction javascript spécifique à mozilla
quand c'est IE on se plaint que c'est pas standard, mais ça ne dérange pas mozilla de faire la même chose...
Sur la capture je trouve bête de faire un gros bouton "firefox" sur une barre séparée.
Ils peuvent facilement gagner de la place en mettant le logo firefox à gauche des onglets comme sur Opera 10.
Ils peuvent facilement gagner de la place en mettant le logo firefox à gauche des onglets comme sur Opera 10.
la derniere phrase sous entend qu'une allocation échouée peut entrainer une faille de sécurité / exploitation malveillante
ce n'est heureusement pas le cas!
au pire, c'est juste le script qui ne va pas fonctionner correctement et etre interrompu car à l'instruction suivante on risque par exemple de tenter d'acceder à une propriété d'une référence qui est nulle... ça ne pose nullement un probleme de sécurité, mais c'est juste génant si le développeur n'a pas prévu cette situation car l'utilisateur ne verra pas d'erreur mais le site risque de ne plus fonctionner correctement (génant pour un webmail en ajax par exemple)
là de ce que je comprend, la nouveauté est que firefox signale à l'utilisateur que le site a rencontré un probleme, au lieu de laisser l'utilisateur s'en servir dans un état inconsistant
pas contre le coup de la fonction javascript spécifique à mozilla
quand c'est IE on se plaint que c'est pas standard, mais ça ne dérange pas mozilla de faire la même chose...
Minute papillon
... La fonction moz-xmalloc n'est que pour les développeurs du navigateur lui-même (c'est du C / C++ quoi, pas du JavaScript), et enfin, son utilité est peut-être liée à l'une des failles les plus intéressantes que l'on a pu décrouvrir (une faille par pointeur NULL, balaise).
Edité par Amy T. le lundi 31 mai 2010 à 12:45
Les développeurs qui connaissent les appels « malloc » pourront s’ils le souhaitent utiliser à la place « moz-xmalloc ()» dans le cadre d’un code JavaScript.
Le JavaScript c'est un langage bas niveau maintenant ?
Il n'est plus possible de commenter cette actualité
Vous devez être connecté ou vous inscrire en haut pour pouvoir participer aux commentaires.














