Attention : Cet article est un peu technique et certaines notions risquent de vous échapper si vous n’avez pas quelques connaissances de base en développement web.

Depuis l’introduction d’un bouton Pocket dans Firefox il ne se passe pas une seule semaine (j’aurais pratiquement même tendance à dire « un seul jour » au point où on en est) sans que Mozilla se prenne un nouveau FUD dans la face.

Petite définition de FUD :

FUD est un acronyme signifiant « Fear, uncertainty and doubt » ou, en français : « Peur, incertitude, doute »

C’est généralement une stratégie marketing organisée par une entreprise pour dénigrer un concurrent en semant la peur, l’incertitude et le doute dans l’esprit des clients.

Il s’agit de manipuler une information pour la parsemer d’hypothèses et de conditionnel afin de la rendre angoissante. La répétition de cette manipulation ancre le FUD dans l’inconscient collectif et le rend plus efficace.

Les derniers FUD auquel Mozilla a du faire face :

Firefox Social API, ou Facebook dans mon Firefox

Celui là est assez vieux et il a fini par être oublié. En 2012, Mozilla active la Social API dans Firefox Beta et lance un appel à testeures pour essayer leur intégration de Facebook Messenger.

Cette API est très simple et se configure à l’aide d’une bête chaine en JSON passée au navigateur à l’aide d’un évènement Javascript. En gros, on indique un nom, quelques urls et l’emplacement de boutons et de cadres.

Ensuite Firefox demande confirmation aux utilisateurices pour l’activation du module et le navigateur se charge d’afficher le contenus des pages référencées dans les cadres définis.

Si vous voulez voir un exemple d’implémentation, j’ai participé en mai à l’ajout du module Social API sur Shaarli. Comme on peut le voir c’est très simple et très innocent.

Pourtant, dès cette annonce on a pu voir des inquiets s’agiter et répéter à tort et à travers que Facebook s’infiltrait dans un module propriétaire de Firefox, que c’était la fin de la protection de la vie privée par Mozilla, une pluie de pierre et de feu, sacrifices humains, copulation entre chiens et chats, etc.

En dépit du fait que Mozilla avait accompagné un article expliquant que les modules Social n’avaient accès à aucune information (à l’exception de l’URL et de la description de la page quand l’utilisateure cliquait sur « Partager » évidemment) : Being social with privacy in mind

This new functionality doesn’t give your social network access to any additional information from your browser. Again: it’s a lot like having a tab open to your social network.

Trois ans plus tard la Social API est largement tombée dans l’oubli, Facebook a supprimé la page d’activation du module et les gens ont heureusement oublié que « Facebook est intégré par défaut dans Firefox »

Firefox Hello

Un peu sur le même modèle mais beaucoup plus récent, fin 2014, Mozilla annonce l’arrivée de Firefox Hello. Un bouton permettant la discussion instantanée directement dans Firefox en utilisant le protocole WebRTC.

Pour l’occasion ils ont fait un partenariat avec TokBoxi (propriétée de Telefonica), spécialiste dans les communications WebRTC, pour utiliser leur plateforme.

Rebelote, Mozilla a vendu la vie privée de ses utilisateuricess avec une extension privatrice rendue obligatoire qui ralenti incroyablement Firefox et qui espionne leurs moindres faits et gestes.

Alors que le bouton ne fait strictement rien tant qu’on ne clique pas dessus, de même que son affichage ne ralenti par Firefox puisque les boutons de barre d’outils sont chargés de manière asynchrone.

Firefox Pocket integration

C’est cette fois en Juin 2015 que Mozilla annonce l’intégration d’un bouton Pocket dans Firefox. Pocket est un service de marque-page dont le principal intérêt est sa capacité à reformater le contenu des pages qu’on y enregistre pour qu’elles soient plus lisibles.

Ici encore, sacrifice de la vie privée, espionnage des utilisateurs, ralentissements du navigateur.

Je vais quand même faire une mention spéciale à Numérama pour le titre le plus imbécilement racoleur et mensonger qu’il m’ait été donné de voir parmis tous les articles alarmistes sur le sujet : « L’add-on Pocket imposé par Mozilla sur Firefox avait une faille »

Notez l’élément de langage : « imposé » quand le simple fait de masquer le bouton en deux clic désactive effectivement l’add-on en question. Et notez également que la faille dont il est question ici n’a absolument rien à voir avec cet addon mais plutôt avec l’infrastructure de Pocket. Pour preuve, on peut lire l’article expliquant les détails de la faille et on peut également utiliser son cerveau et réaliser que Mozilla n’a publié aucun correctif en rapport avec Pocket au moment où la faille a été corrigée.

Comme avec Firefox Hello, le bouton ne fait toujours rien tant qu’on ne clique pas dessus, son affichage ne ralenti toujours pas Firefox et le simple fait de l’enlever de la barre d’outil désactive l’exécution du code d’affichage du bouton (logique).

La signature obligatoire des add-ons

En février 2015, Mozilla annonce que Firefox refusera de lancer les add-ons qui n’ont pas été signés sur addons.mozilla.org (Aussi appelé AMO). Cette décision est motivée par la sécurité des utilisateurs et vise à analyser le code de toutes les extension Firefox afin d’interdire celles qui tenteraient des choses curieuses comme envoyer le contenu de vos fichiers ou la liste de vos mots de passe sur un serveur distant. (Oui, les add-ons peuvent faire ça.)

L’initiative vise aussi à diminuer le nombre de barres d’outils et de malware publicitaires installés par des programmes comme… Flash Player.

Si les utilisateurices de Firefox peuvent se satisfaire d’un add-on installé de base qu’il est possible de désactiver, avec la signature obligatoire on touche là au cœur même de la liberté des gens puisque la première plainte émise a été de ne plus pouvoir télécharger ses add-ons ailleurs que sur AMO, d’ouvrir la porte à la voie de la censure et de transformer Mozilla en dictature de la pensée unique (rien que ça).

Pourtant, rien de tout ça n’est fondé.

Les extensions qui sont déjà sur AMO sont déjà soumise à une procédure de vérification. Elle est manuelle, effectuée par des bénévoles, la vérification peut prendre plusieurs jours. Et ça fait bien longtemps que personne ne s’en est plain. Ces add-ons seront signés automatiquement.

Les extensions qui ne sont pas sur AMO, et là est la nouveautée, seront soumises à une vérification automatique puis signées. Si la vérification automatique échoue c’est une vérification manuelle qui aura lieu, la même que celle pour les add-ons de l’AMO. Après signature, le/la développeureuse récupère le fichier xpi de l’extension et est libre de le distribuer où bon lui semble.

Avant signature et pendant le développement de l’add-on il faudra utiliser Firefox Aurora ou Firefox Developper Edition pour lancer des add-ons non signés.

Le point faible de tout ça reste la procédure de review manuelle. À titre d’exemple ça fait 9 mois que HTTPS Everywhere est en review sur l’AMO, étant un add-on soutenu par l’EFF ils ont pu obtenir une signature rapide en demandant directement à Mozilla mais tout le monde n’est pas l’EFF.

Mozilla est bien conscient de ça et prévoit d’améliorer le processus de vérification automatique ainsi que d’augmenter la taille des équipes salariées et bénévoles pour la vérification manuelle.

La fin des add-ons XUL et SDK

Hier, le 21 Août 2015, Mozilla annonce l’obsolescence des add-ons classiques qui utilisent XUL, des add-ons jetpack et des add-ons SDK pour introduire une nouvelle API d’add-on qui sera majoritairement compatible avec celle utilisée par Chrome et Opera mais qui sera étendue pour maintenir l’existence d’add-ons populaires existants.

La raison avancée est que les add-ons dépendant d’interface bas niveau empêchent les évolutions du navigateur. Electrolysis qui doit apporter le support du multi-process et le sandboxing des onglets a largement été retarder à cause d’incompatibilité avec des extensions très utilisées. Il est impossible de remplacer le Gecko vieillissant par Servo pour les mêmes raisons.

Mettre en place une API limitera, certes, les possibilités de développement d’add-ons mais permettra en même temps de faire des changement profonds dans le fonctionnement de Firefox sans trop s’inquiéter de voir tous les add-ons crasher dans tous les sens.

Les réactions FUDesques ne sont sont pas fait attendre et le développeur de DownThemAll! a été le premier à s’enflammer en déclarant la mort de DownThemAll, NoScript ou Greasemonkey.

Bref, c’est la fin de la personnalisation dans Firefox qui achève une transformation en clone de Chrome, transformation entamée avec l’arrivée de l’interface Australis apparue dans les nightlies fin 2013.

Dans les journaux LinuxFR c’est la panique également puisqu’on apprend ceci :

L’impossibilité d’accéder au coeur de Firefox et de son interface mènera à la disparition d’extensions extrêmement appréciées et utilisées telles que, outre DownThemAll, TreeStyleTab, NoScript, FireGestures, Drag2Go, Greasemonkey, TabMixPlus, FireFTP, FoxyProxy, AllInOne Sidebar et beaucoup d’autres.

Comprenons-nous bien : on ne parle pas ici d’un classique cassage d’API qui requiert la réécriture de certaines parties de ces extensions pour les rendre compatibles. Non, on parle d’un changement qui rendra ces extensions impossibles à implémenter en tout ou en partie.

Ou encore que l’API n’est pas officiellement publiée alors qu’il reste 18 mois à vivre aux extensions old-school.

Là encore, rien n’est fondé puisque dans l’article même de cette annonce, Mozilla donne le lien vers la documentation actuelle : WebExtensions sur laquelle figure des liens vers les modules et fonctions supportées, les fonctions qui ne sont pas encore implémentées, une mention indiquant qu’elles le seront prochainement ainsi qu’une liste de fonctions non supportées par Chrome qui seront conservées dans Firefox pour garder des extensions en vie :

We plan to add our own APIs based on the needs of existing Firefox add-ons :

• NoScript-type functionality. This would come in the form of extensions to webRequest and possibly contentSettings.
• Sidebars. Opera already supports sidebar functionality; Chrome may soon. We would like to be able to implement Tree Style Tabs or Vertical Tabs by hiding the tab strip and showing a tab sidebar.
• Toolbars. Firefox has a lot of existing toolbar add-ons.
• Better keyboard shortcut support. We’d like to support Vimperator-type functionality.
• Ability to add tabs to about:addons.
• Ability to modify the tab strip (Tab Mix Plus).
• Ability to take images of frames/tabs (like canvas.drawWindow)

On voit bien que contrairement à ce qui est colporté, Mozilla est conscient de la nécessité de préserver l’existence de nombreuses extensions et qu’ils ne se priveront pas d’aller plus loins que l’API de Chrome pour le faire.

En bref, les extensions Chrome seront facilement portables sur Firefox, les extensions simple de Firefox seront facilement portable sur Chrome et les extensions plus lourdes conserveront leurs fonctionnalités avancées.

Conclusion

Je suis prêt à admettre qu’une certaine inquiétude puisse se faire sentir devant tous les changements opérés par Mozilla cette année mais il me semble qu’une fois contextualisés ces changements deviennent soit compréhensibles même si pas idéaux, soit justifiés.

Hello et Pocket résultent de partenariats commerciaux. On le sait et elle était extrêmement critiquée pour ça, Mozilla dépendait grandement du financement de Google (85% en 2011) pourtant et pour s’en détacher, c’est Yahoo qui devient le nouveau moteur par défaut en Novembre 2014 et on imagine bien qu’ils n’ont pas la puissance financière d’un Google.

Mozilla se trouve donc obligée de diversifier ses partenariat et jusqu’à présent en parvenant avec succès à protéger la vie privée de ses utilisateurices.

Du côté des add-ons, il s’agit de choix techniques qui visent à diminuer le nombre de malwares infectant le navigateur et à permettre plus facilement la réduction de dette technique présente dans Gecko.

J’ai, en revanche du mal à saisir ce qui pousse des gens qui ont tout à perdre de la défection de Firefox à propager des articles alarmistes et infondés pour manifester leur inquiétude.

Le seul effet que ces critiques ont est de ternir l’image d’un Firefox qui n’en a pas besoin et d’affaiblir le seul navigateur Libre et indépendant, poussant les gens à… utiliser Chrome.

À suivre : Les requêtes HTTP et HTTPS envoyées par un Firefox tout neuf.

Attention : Cet article est un peu technique et certaines notions risquent de vous échapper si vous n’avez pas quelques connaissances de base en développement web.

Depuis l’introduction d’un bouton Pocket dans Firefox il ne se passe pas une seule semaine (j’aurais pratiquement même tendance à dire « un seul jour » au point où on en est) sans que Mozilla se prenne un nouveau FUD dans la face.

Petite définition de FUD :

FUD est un acronyme signifiant « Fear, uncertainty and doubt » ou, en français : « Peur, incertitude, doute »

C’est généralement une stratégie marketing organisée par une entreprise pour dénigrer un concurrent en semant la peur, l’incertitude et le doute dans l’esprit des clients.

Il s’agit de manipuler une information pour la parsemer d’hypothèses et de conditionnel afin de la rendre angoissante. La répétition de cette manipulation ancre le FUD dans l’inconscient collectif et le rend plus efficace.

Les derniers FUD auquel Mozilla a du faire face :

Firefox Social API, ou Facebook dans mon Firefox

Celui là est assez vieux et il a fini par être oublié. En 2012, Mozilla active la Social API dans Firefox Beta et lance un appel à testeures pour essayer leur intégration de Facebook Messenger.

Cette API est très simple et se configure à l’aide d’une bête chaine en JSON passée au navigateur à l’aide d’un évènement Javascript. En gros, on indique un nom, quelques urls et l’emplacement de boutons et de cadres.

Ensuite Firefox demande confirmation aux utilisateurices pour l’activation du module et le navigateur se charge d’afficher le contenus des pages référencées dans les cadres définis.

Si vous voulez voir un exemple d’implémentation, j’ai participé en mai à l’ajout du module Social API sur Shaarli. Comme on peut le voir c’est très simple et très innocent.

Pourtant, dès cette annonce on a pu voir des inquiets s’agiter et répéter à tort et à travers que Facebook s’infiltrait dans un module propriétaire de Firefox, que c’était la fin de la protection de la vie privée par Mozilla, une pluie de pierre et de feu, sacrifices humains, copulation entre chiens et chats, etc.

En dépit du fait que Mozilla avait accompagné un article expliquant que les modules Social n’avaient accès à aucune information (à l’exception de l’URL et de la description de la page quand l’utilisateure cliquait sur « Partager » évidemment) : Being social with privacy in mind

This new functionality doesn’t give your social network access to any additional information from your browser. Again: it’s a lot like having a tab open to your social network.

Trois ans plus tard la Social API est largement tombée dans l’oubli, Facebook a supprimé la page d’activation du module et les gens ont heureusement oublié que « Facebook est intégré par défaut dans Firefox »

Firefox Hello

Un peu sur le même modèle mais beaucoup plus récent, fin 2014, Mozilla annonce l’arrivée de Firefox Hello. Un bouton permettant la discussion instantanée directement dans Firefox en utilisant le protocole WebRTC.

Pour l’occasion ils ont fait un partenariat avec TokBoxi (propriétée de Telefonica), spécialiste dans les communications WebRTC, pour utiliser leur plateforme.

Rebelote, Mozilla a vendu la vie privée de ses utilisateuricess avec une extension privatrice rendue obligatoire qui ralenti incroyablement Firefox et qui espionne leurs moindres faits et gestes.

Alors que le bouton ne fait strictement rien tant qu’on ne clique pas dessus, de même que son affichage ne ralenti par Firefox puisque les boutons de barre d’outils sont chargés de manière asynchrone.

Firefox Pocket integration

C’est cette fois en Juin 2015 que Mozilla annonce l’intégration d’un bouton Pocket dans Firefox. Pocket est un service de marque-page dont le principal intérêt est sa capacité à reformater le contenu des pages qu’on y enregistre pour qu’elles soient plus lisibles.

Ici encore, sacrifice de la vie privée, espionnage des utilisateurs, ralentissements du navigateur.

Je vais quand même faire une mention spéciale à Numérama pour le titre le plus imbécilement racoleur et mensonger qu’il m’ait été donné de voir parmis tous les articles alarmistes sur le sujet : « L’add-on Pocket imposé par Mozilla sur Firefox avait une faille »

Notez l’élément de langage : « imposé » quand le simple fait de masquer le bouton en deux clic désactive effectivement l’add-on en question. Et notez également que la faille dont il est question ici n’a absolument rien à voir avec cet addon mais plutôt avec l’infrastructure de Pocket. Pour preuve, on peut lire l’article expliquant les détails de la faille et on peut également utiliser son cerveau et réaliser que Mozilla n’a publié aucun correctif en rapport avec Pocket au moment où la faille a été corrigée.

Comme avec Firefox Hello, le bouton ne fait toujours rien tant qu’on ne clique pas dessus, son affichage ne ralenti toujours pas Firefox et le simple fait de l’enlever de la barre d’outil désactive l’exécution du code d’affichage du bouton (logique).

La signature obligatoire des add-ons

En février 2015, Mozilla annonce que Firefox refusera de lancer les add-ons qui n’ont pas été signés sur addons.mozilla.org (Aussi appelé AMO). Cette décision est motivée par la sécurité des utilisateurs et vise à analyser le code de toutes les extension Firefox afin d’interdire celles qui tenteraient des choses curieuses comme envoyer le contenu de vos fichiers ou la liste de vos mots de passe sur un serveur distant. (Oui, les add-ons peuvent faire ça.)

L’initiative vise aussi à diminuer le nombre de barres d’outils et de malware publicitaires installés par des programmes comme… Flash Player.

Si les utilisateurices de Firefox peuvent se satisfaire d’un add-on installé de base qu’il est possible de désactiver, avec la signature obligatoire on touche là au cœur même de la liberté des gens puisque la première plainte émise a été de ne plus pouvoir télécharger ses add-ons ailleurs que sur AMO, d’ouvrir la porte à la voie de la censure et de transformer Mozilla en dictature de la pensée unique (rien que ça).

Pourtant, rien de tout ça n’est fondé.

Les extensions qui sont déjà sur AMO sont déjà soumise à une procédure de vérification. Elle est manuelle, effectuée par des bénévoles, la vérification peut prendre plusieurs jours. Et ça fait bien longtemps que personne ne s’en est plain. Ces add-ons seront signés automatiquement.

Les extensions qui ne sont pas sur AMO, et là est la nouveautée, seront soumises à une vérification automatique puis signées. Si la vérification automatique échoue c’est une vérification manuelle qui aura lieu, la même que celle pour les add-ons de l’AMO. Après signature, le/la développeureuse récupère le fichier xpi de l’extension et est libre de le distribuer où bon lui semble.

Avant signature et pendant le développement de l’add-on il faudra utiliser Firefox Aurora ou Firefox Developper Edition pour lancer des add-ons non signés.

Le point faible de tout ça reste la procédure de review manuelle. À titre d’exemple ça fait 9 mois que HTTPS Everywhere est en review sur l’AMO, étant un add-on soutenu par l’EFF ils ont pu obtenir une signature rapide en demandant directement à Mozilla mais tout le monde n’est pas l’EFF.

Mozilla est bien conscient de ça et prévoit d’améliorer le processus de vérification automatique ainsi que d’augmenter la taille des équipes salariées et bénévoles pour la vérification manuelle.

La fin des add-ons XUL et SDK

Hier, le 21 Août 2015, Mozilla annonce l’obsolescence des add-ons classiques qui utilisent XUL, des add-ons jetpack et des add-ons SDK pour introduire une nouvelle API d’add-on qui sera majoritairement compatible avec celle utilisée par Chrome et Opera mais qui sera étendue pour maintenir l’existence d’add-ons populaires existants.

La raison avancée est que les add-ons dépendant d’interface bas niveau empêchent les évolutions du navigateur. Electrolysis qui doit apporter le support du multi-process et le sandboxing des onglets a largement été retarder à cause d’incompatibilité avec des extensions très utilisées. Il est impossible de remplacer le Gecko vieillissant par Servo pour les mêmes raisons.

Mettre en place une API limitera, certes, les possibilités de développement d’add-ons mais permettra en même temps de faire des changement profonds dans le fonctionnement de Firefox sans trop s’inquiéter de voir tous les add-ons crasher dans tous les sens.

Les réactions FUDesques ne sont sont pas fait attendre et le développeur de DownThemAll! a été le premier à s’enflammer en déclarant la mort de DownThemAll, NoScript ou Greasemonkey.

Bref, c’est la fin de la personnalisation dans Firefox qui achève une transformation en clone de Chrome, transformation entamée avec l’arrivée de l’interface Australis apparue dans les nightlies fin 2013.

Dans les journaux LinuxFR c’est la panique également puisqu’on apprend ceci :

L'impossibilité d'accéder au coeur de Firefox et de son interface mènera à la disparition d'extensions extrêmement appréciées et utilisées telles que, outre DownThemAll, TreeStyleTab, NoScript, FireGestures, Drag2Go, Greasemonkey, TabMixPlus, FireFTP, FoxyProxy, AllInOne Sidebar et beaucoup d'autres. Comprenons-nous bien : on ne parle pas ici d'un classique cassage d'API qui requiert la réécriture de certaines parties de ces extensions pour les rendre compatibles. Non, on parle d'un changement qui rendra ces extensions impossibles à implémenter en tout ou en partie.

Ou encore que l’API n’est pas officiellement publiée alors qu’il reste 18 mois à vivre aux extensions old-school.

Là encore, rien n’est fondé puisque dans l’article même de cette annonce, Mozilla donne le lien vers la documentation actuelle : WebExtensions sur laquelle figure des liens vers les modules et fonctions supportées, les fonctions qui ne sont pas encore implémentées, une mention indiquant qu’elles le seront prochainement ainsi qu’une liste de fonctions non supportées par Chrome qui seront conservées dans Firefox pour garder des extensions en vie :

We plan to add our own APIs based on the needs of existing Firefox add-ons :

• NoScript-type functionality. This would come in the form of extensions to webRequest and possibly contentSettings.
• Sidebars. Opera already supports sidebar functionality; Chrome may soon. We would like to be able to implement Tree Style Tabs or Vertical Tabs by hiding the tab strip and showing a tab sidebar.
• Toolbars. Firefox has a lot of existing toolbar add-ons.
• Better keyboard shortcut support. We'd like to support Vimperator-type functionality.
• Ability to add tabs to about:addons.
• Ability to modify the tab strip (Tab Mix Plus).
• Ability to take images of frames/tabs (like canvas.drawWindow)

On voit bien que contrairement à ce qui est colporté, Mozilla est conscient de la nécessité de préserver l’existence de nombreuses extensions et qu’ils ne se priveront pas d’aller plus loins que l’API de Chrome pour le faire.

En bref, les extensions Chrome seront facilement portables sur Firefox, les extensions simple de Firefox seront facilement portable sur Chrome et les extensions plus lourdes conserveront leurs fonctionnalités avancées.

Conclusion

Je suis prêt à admettre qu’une certaine inquiétude puisse se faire sentir devant tous les changements opérés par Mozilla cette année mais il me semble qu’une fois contextualisés ces changements deviennent soit compréhensibles même si pas idéaux, soit justifiés.

Hello et Pocket résultent de partenariats commerciaux. On le sait et elle était extrêmement critiquée pour ça, Mozilla dépendait grandement du financement de Google (85% en 2011) pourtant et pour s’en détacher, c’est Yahoo qui devient le nouveau moteur par défaut en Novembre 2014 et on imagine bien qu’ils n’ont pas la puissance financière d’un Google.

Mozilla se trouve donc obligée de diversifier ses partenariat et jusqu’à présent en parvenant avec succès à protéger la vie privée de ses utilisateurices.

Du côté des add-ons, il s’agit de choix techniques qui visent à diminuer le nombre de malwares infectant le navigateur et à permettre plus facilement la réduction de dette technique présente dans Gecko.

J’ai, en revanche du mal à saisir ce qui pousse des gens qui ont tout à perdre de la défection de Firefox à propager des articles alarmistes et infondés pour manifester leur inquiétude.

Le seul effet que ces critiques ont est de ternir l’image d’un Firefox qui n’en a pas besoin et d’affaiblir le seul navigateur Libre et indépendant, poussant les gens à… utiliser Chrome.

À suivre : Les requêtes envoyées par un Firefox tout neuf.

Attention : Cet article est un peu technique et certaines notions risquent de vous échapper si vous n’avez pas quelques connaissances de base en développement web.

Depuis l’introduction d’un bouton Pocket dans Firefox il ne se passe pas une seule semaine (j’aurais pratiquement même tendance à dire « un seul jour » au point où on en est) sans que Mozilla se prenne un nouveau FUD dans la face.

Petite définition de FUD :

FUD est un acronyme signifiant « Fear, uncertainty and doubt » ou, en français : « Peur, incertitude, doute »

C’est généralement une stratégie marketing organisée par une entreprise pour dénigrer un concurrent en semant la peur, l’incertitude et le doute dans l’esprit des clients.

Il s’agit de manipuler une information pour la parsemer d’hypothèses et de conditionnel afin de la rendre angoissante. La répétition de cette manipulation ancre le FUD dans l’inconscient collectif et le rend plus efficace.

Les derniers FUD auquel Mozilla a du faire face :

Firefox Social API, ou Facebook dans mon Firefox

Celui là est assez vieux et il a fini par être oublié. En 2012, Mozilla active la Social API dans Firefox Beta et lance un appel à testeures pour essayer leur intégration de Facebook Messenger.

Cette API est très simple et se configure à l’aide d’une bête chaine en JSON passée au navigateur à l’aide d’un évènement Javascript. En gros, on indique un nom, quelques urls et l’emplacement de boutons et de cadres.

Ensuite Firefox demande confirmation aux utilisateurices pour l’activation du module et le navigateur se charge d’afficher le contenus des pages référencées dans les cadres définis.

Si vous voulez voir un exemple d’implémentation, j’ai participé en mai à l’ajout du module Social API sur Shaarli. Comme on peut le voir c’est très simple et très innocent.

Pourtant, dès cette annonce on a pu voir des inquiets s’agiter et répéter à tort et à travers que Facebook s’infiltrait dans un module propriétaire de Firefox, que c’était la fin de la protection de la vie privée par Mozilla, une pluie de pierre et de feu, sacrifices humains, copulation entre chiens et chats, etc.

En dépit du fait que Mozilla avait accompagné un article expliquant que les modules Social n’avaient accès à aucune information (à l’exception de l’URL et de la description de la page quand l’utilisateure cliquait sur « Partager » évidemment) : Being social with privacy in mind

This new functionality doesn’t give your social network access to any additional information from your browser. Again: it’s a lot like having a tab open to your social network.

Trois ans plus tard la Social API est largement tombée dans l’oubli, Facebook a supprimé la page d’activation du module et les gens ont heureusement oublié que « Facebook est intégré par défaut dans Firefox »

Firefox Hello

Un peu sur le même modèle mais beaucoup plus récent, fin 2014, Mozilla annonce l’arrivée de Firefox Hello. Un bouton permettant la discussion instantanée directement dans Firefox en utilisant le protocole WebRTC.

Pour l’occasion ils ont fait un partenariat avec TokBoxi (propriétée de Telefonica), spécialiste dans les communications WebRTC, pour utiliser leur plateforme.

Rebelote, Mozilla a vendu la vie privée de ses utilisateuricess avec une extension privatrice rendue obligatoire qui ralenti incroyablement Firefox et qui espionne leurs moindres faits et gestes.

Alors que le bouton ne fait strictement rien tant qu’on ne clique pas dessus, de même que son affichage ne ralenti par Firefox puisque les boutons de barre d’outils sont chargés de manière asynchrone.

Firefox Pocket integration

C’est cette fois en Juin 2015 que Mozilla annonce l’intégration d’un bouton Pocket dans Firefox. Pocket est un service de marque-page dont le principal intérêt est sa capacité à reformater le contenu des pages qu’on y enregistre pour qu’elles soient plus lisibles.

Ici encore, sacrifice de la vie privée, espionnage des utilisateurs, ralentissements du navigateur.

Je vais quand même faire une mention spéciale à Numérama pour le titre le plus imbécilement racoleur et mensonger qu’il m’ait été donné de voir parmis tous les articles alarmistes sur le sujet : « L’add-on Pocket imposé par Mozilla sur Firefox avait une faille »

Notez l’élément de langage : « imposé » quand le simple fait de masquer le bouton en deux clic désactive effectivement l’add-on en question. Et notez également que la faille dont il est question ici n’a absolument rien à voir avec cet addon mais plutôt avec l’infrastructure de Pocket. Pour preuve, on peut lire l’article expliquant les détails de la faille et on peut également utiliser son cerveau et réaliser que Mozilla n’a publié aucun correctif en rapport avec Pocket au moment où la faille a été corrigée.

Comme avec Firefox Hello, le bouton ne fait toujours rien tant qu’on ne clique pas dessus, son affichage ne ralenti toujours pas Firefox et le simple fait de l’enlever de la barre d’outil désactive l’exécution du code d’affichage du bouton (logique).

La signature obligatoire des add-ons

En février 2015, Mozilla annonce que Firefox refusera de lancer les add-ons qui n’ont pas été signés sur addons.mozilla.org (Aussi appelé AMO). Cette décision est motivée par la sécurité des utilisateurs et vise à analyser le code de toutes les extension Firefox afin d’interdire celles qui tenteraient des choses curieuses comme envoyer le contenu de vos fichiers ou la liste de vos mots de passe sur un serveur distant. (Oui, les add-ons peuvent faire ça.)

L’initiative vise aussi à diminuer le nombre de barres d’outils et de malware publicitaires installés par des programmes comme… Flash Player.

Si les utilisateurices de Firefox peuvent se satisfaire d’un add-on installé de base qu’il est possible de désactiver, avec la signature obligatoire on touche là au cœur même de la liberté des gens puisque la première plainte émise a été de ne plus pouvoir télécharger ses add-ons ailleurs que sur AMO, d’ouvrir la porte à la voie de la censure et de transformer Mozilla en dictature de la pensée unique (rien que ça).

Pourtant, rien de tout ça n’est fondé.

Les extensions qui sont déjà sur AMO sont déjà soumise à une procédure de vérification. Elle est manuelle, effectuée par des bénévoles, la vérification peut prendre plusieurs jours. Et ça fait bien longtemps que personne ne s’en est plain. Ces add-ons seront signés automatiquement.

Les extensions qui ne sont pas sur AMO, et là est la nouveautée, seront soumises à une vérification automatique puis signées. Si la vérification automatique échoue c’est une vérification manuelle qui aura lieu, la même que celle pour les add-ons de l’AMO. Après signature, le/la développeureuse récupère le fichier xpi de l’extension et est libre de le distribuer où bon lui semble.

Avant signature et pendant le développement de l’add-on il faudra utiliser Firefox Aurora ou Firefox Developper Edition pour lancer des add-ons non signés.

Le point faible de tout ça reste la procédure de review manuelle. À titre d’exemple ça fait 9 mois que HTTPS Everywhere est en review sur l’AMO, étant un add-on soutenu par l’EFF ils ont pu obtenir une signature rapide en demandant directement à Mozilla mais tout le monde n’est pas l’EFF.

Mozilla est bien conscient de ça et prévoit d’améliorer le processus de vérification automatique ainsi que d’augmenter la taille des équipes salariées et bénévoles pour la vérification manuelle.

La fin des add-ons XUL et SDK

Hier, le 21 Août 2015, Mozilla annonce l’obsolescence des add-ons classiques qui utilisent XUL, des add-ons jetpack et des add-ons SDK pour introduire une nouvelle API d’add-on qui sera majoritairement compatible avec celle utilisée par Chrome et Opera mais qui sera étendue pour maintenir l’existence d’add-ons populaires existants.

La raison avancée est que les add-ons dépendant d’interface bas niveau empêchent les évolutions du navigateur. Electrolysis qui doit apporter le support du multi-process et le sandboxing des onglets a largement été retarder à cause d’incompatibilité avec des extensions très utilisées. Il est impossible de remplacer le Gecko vieillissant par Servo pour les mêmes raisons.

Mettre en place une API limitera, certes, les possibilités de développement d’add-ons mais permettra en même temps de faire des changement profonds dans le fonctionnement de Firefox sans trop s’inquiéter de voir tous les add-ons crasher dans tous les sens.

Les réactions FUDesques ne sont sont pas fait attendre et le développeur de DownThemAll! a été le premier à s’enflammer en déclarant la mort de DownThemAll, NoScript ou Greasemonkey.

Bref, c’est la fin de la personnalisation dans Firefox qui achève une transformation en clone de Chrome, transformation entamée avec l’arrivée de l’interface Australis apparue dans les nightlies fin 2013.

Dans les journaux LinuxFR c’est la panique également puisqu’on apprend ceci :

L'impossibilité d'accéder au coeur de Firefox et de son interface mènera à la disparition d'extensions extrêmement appréciées et utilisées telles que, outre DownThemAll, TreeStyleTab, NoScript, FireGestures, Drag2Go, Greasemonkey, TabMixPlus, FireFTP, FoxyProxy, AllInOne Sidebar et beaucoup d'autres. Comprenons-nous bien : on ne parle pas ici d'un classique cassage d'API qui requiert la réécriture de certaines parties de ces extensions pour les rendre compatibles. Non, on parle d'un changement qui rendra ces extensions impossibles à implémenter en tout ou en partie.

Ou encore que l’API n’est pas officiellement publiée alors qu’il reste 18 mois à vivre aux extensions old-school.

Là encore, rien n’est fondé puisque dans l’article même de cette annonce, Mozilla donne le lien vers la documentation actuelle : WebExtensions sur laquelle figure des liens vers les modules et fonctions supportées, les fonctions qui ne sont pas encore implémentées, une mention indiquant qu’elles le seront prochainement ainsi qu’une liste de fonctions non supportées par Chrome qui seront conservées dans Firefox pour garder des extensions en vie :

We plan to add our own APIs based on the needs of existing Firefox add-ons :

• NoScript-type functionality. This would come in the form of extensions to webRequest and possibly contentSettings.
• Sidebars. Opera already supports sidebar functionality; Chrome may soon. We would like to be able to implement Tree Style Tabs or Vertical Tabs by hiding the tab strip and showing a tab sidebar.
• Toolbars. Firefox has a lot of existing toolbar add-ons.
• Better keyboard shortcut support. We'd like to support Vimperator-type functionality.
• Ability to add tabs to about:addons.
• Ability to modify the tab strip (Tab Mix Plus).
• Ability to take images of frames/tabs (like canvas.drawWindow)

On voit bien que contrairement à ce qui est colporté, Mozilla est conscient de la nécessité de préserver l’existence de nombreuses extensions et qu’ils ne se priveront pas d’aller plus loins que l’API de Chrome pour le faire.

En bref, les extensions Chrome seront facilement portables sur Firefox, les extensions simple de Firefox seront facilement portable sur Chrome et les extensions plus lourdes conserveront leurs fonctionnalités avancées.

Conclusion

Je suis prêt à admettre qu’une certaine inquiétude puisse se faire sentir devant tous les changements opérés par Mozilla cette année mais il me semble qu’une fois contextualisés ces changements deviennent soit compréhensibles même si pas idéaux, soit justifiés.

Hello et Pocket résultent de partenariats commerciaux. On le sait et elle était extrêmement critiquée pour ça, Mozilla dépendait grandement du financement de Google (85% en 2011) pourtant et pour s’en détacher, c’est Yahoo qui devient le nouveau moteur par défaut en Novembre 2014 et on imagine bien qu’ils n’ont pas la puissance financière d’un Google.

Mozilla se trouve donc obligée de diversifier ses partenariat et jusqu’à présent en parvenant avec succès à protéger la vie privée de ses utilisateurices.

Du côté des add-ons, il s’agit de choix techniques qui visent à diminuer le nombre de malwares infectant le navigateur et à permettre plus facilement la réduction de dette technique présente dans Gecko.

J’ai, en revanche du mal à saisir ce qui pousse des gens qui ont tout à perdre de la défection de Firefox à propager des articles alarmistes et infondés pour manifester leur inquiétude.

Le seul effet que ces critiques ont est de ternir l’image d’un Firefox qui n’en a pas besoin et d’affaiblir le seul navigateur Libre et indépendant, poussant les gens à… utiliser Chrome.

À suivre : Les requêtes envoyées par un Firefox tout neuf.

Il y a un peu plus d’un an, j’ai parlé de moyens pour sécuriser nos communications sur nos téléphones mobiles. J’avais parlé de TextSecure, Redphone et Telegram.

Avec le vote de la loi sur le renseignement qui autorise maintenant le gouvernement à surveiller tout un chacun sans passer par le moindre juge, il me semble pertinent de refaire un point sur ce qui a changé ou non et sur les nouveaux moyens disponibles.

Si vous n’y connaissez rien en chiffrement, ce n’est pas grave, vous pouvez continuer à lire. Je ne présenterai que des outils qui fonctionnent immédiatement après s’être installés parce que je fais parti de celleux qui pensent qu’une bonne sécurité doit être accessible à toutes et à tous, même si on ne sait pas ce qu’est le chiffrement à courbes elliptiques (et aussi parce que les arcanes de la sécurité ont tendance à me filer mal au crane.)

Comme d’habitude, la sécurité n’est possible que lorsqu’il est possible d’examiner le code source des applications qui la mettent en place afin de pouvoir contrôler que le logiciel ne dissimule rien. Exit donc Whatsapp, Skype, Facebook, Bleep, etc. Même si ils prétendent fournir de la sécurité, on est sensé les croire sur parole sans vérification possible. Et vous avez vraiment envie de croire sur parole une entreprise capitaliste vous ?

Les logiciels dont je vais parler sont Libres, donc open-source et gratuits. Le chiffrement n’est actif qu’avec les contacts qui utilisent le même logiciel que vous.

Les messages mobiles

Cette section concerne les SMS et équivalents et se compose de trois logiciels très proches : TextSecure, SMSSecure et Signals.

Textsecure

Celui là c’est un peu mon préféré. Il était déjà opérationnel l’an dernier et je l’utilise quotidiennement depuis ce moment là.

C’est une application pour Android qui peut remplacer (sans obligation) l’application SMS standard. Si vous décidez de conserver votre application SMS, vous recevrez les messages TextSecure dans TextSecure et les SMS dans l’application SMS.

Elle permet également d’envoyer des MMS qui seront, eux aussi, chiffrés.

Au premier lancement elle demande de saisir votre numéro de téléphone et quelques secondes plus tard vous recevez un SMS spécial qu’elle utilise automatiquement pour s’activer.

Vous pourrez dès lors envoyer des messages chiffrés aux contacts qui l’utilisent, sans même y faire attention. Le chiffrement est simplement indiqué par un petit cadenas au bas de chaque message envoyé ou reçu.

Les SMS reçus sont en vert et les messages TextSecure sont en bleu.

Concernant le mode de transport il y a plusieurs choses à savoir :

• Les messages transitent par internet, il vous faut donc un forfait compatible (mais de nos jours pratiquement tous les forfaits incluent au moins 20Mo de données par mois et TextSecure en consomme environ 600Ko)
• Ils transitent par les serveurs de Google puis par les serveurs d’OpenWhisper (les gens qui développement TextSecure).
  Comme les communications sont chiffrées, Google pourra uniquement voir que vous utilisez l’application (mais comme vous l’avez installée, ils se savent déjà) et de son côté OpenWhisper ne verra que l’identifiant de la personne à qui vous envoyez un message (pour lui délivrer un message, il est logique que le transporteur en connaisse l’adresse)

Néanmoins, pour ne pas passer par Google et OpenWhisper ou pour ne pas être obligé⋅e d’utiliser internet, il y a une alternative : SMSSecure.

SMSSecure

SMSSecure est très proche de TextSecure puisqu’il partage une grande partie de son code source et donc la même méthode de chiffrement.

Cette application est apparue quand les développeurs et développeuses de TextSecure ont décidé⋅es d’arrêter le support du chiffrement pour les SMS en raison d’un trop grand nombre de correctifs nécessaire qui les empêchaient de se concentrer sur l’ajout de nouvelles fonctions.

D’autres personnes ont donc copié le code source et ont supprimé tout rapport avec Google et OpenWhisper pour ne développer que la partie SMS.

L’interface est donc très proche/identique à celle de TextSecure et pour recevoir des SMS chiffrés elle doit obligatoirement remplacer votre application SMS standard. (Vous pouvez toujours utiliser TextSecure à côté.)

Elle permet également d’envoyer des MMS qui seront, eux aussi, chiffrés.

Une fois installée, il n’y a qu’à sélectionner un contact qui vous a prévenu qu’ille l’utilise et cliquer sur le petit cadenas en haut à droite. Elle va alors lui envoyer un SMS de préparation auquel son téléphone répondra automatiquement et la suite de la conversation se déroulera de manière sécurisée.

Concernant le mode de transport il y a là aussi des choses à savoir :

• Elle utilise les SMS ; comme un message chiffré prend plus de place qu’un message classique il est possible qu’un message de moins de 140 caractères soit automatiquement coupé en plusieurs parties et que votre forfait soit décompté de plusieurs SMS. Attention donc si vous n’avez pas de SMS illimités.
• Contrairement à TextSecure où Google peut savoir que vous l’utilisez et où OpenWhisper peut savoir à qui vous écrivez, ici c’est votre opérateur mobile et toute personne qui écoute le réseau téléphonique qui peut savoir à qui vous écrivez. À vous de choisir à qui vous préférez exposer votre liste d’interlocuteur⋅ices.

Signal

Il y a un an, aucune solution libre n’existait pour les personnes possédant un iPhone. Mais maintenant il y a Signal.

Signal est l’exact équivalent de TextSecure pour Android et comme il est développée par les mêmes personnes, les gens utilisant Signal peuvent discuter en toute transparence avec les gens utilisant TextSecure.

L’application utilise la même procédure d’activation que TextSecure : Au premier lancement on saisit son numéro, on reçoit un SMS d’activation et c’est prêt.

La seule différence est qu’Apple n’autorise pas les applications tierces à accéder aux SMS, vous ne pourrez donc pas récupérer tous vos messages dans une seule application et le seul mode de transport disponible sera le même que TextSecure, avec les mêmes points à retenir que ceux cités plus haut.

Les appels mobiles

Pour ce point, il y a une solution pour Android : RedPhone, et une solution pour iPhone : Signal (oui, la même)

RedPhone

Développée par OpenWhisper (les mêmes qui font TextSecure et Signal, décidément), RedPhone permet de passer des appels chiffrés via Internet. Ce ne sera donc pas décompté de votre forfait voix, mais de votre quota de données (sauf si vous êtes en Wifi, ce qui permet de s’affranchir du même coup d’une mauvaise couverture.)

L’activation se déroule comme avec TextSecure et l’usage est ensuite transparent. La réception d’appel se fait sans manipulation particulière et au moment de passer un appel, si RedPhone détecte que votre correspondant⋅e est dans son annuaire, il vous offrira le choix de sécuriser l’appel ou non.

Comme pour TextSecure, les données transitent par Google et OpenWhisper, donc Google sait que vous utilisez RedPhone et OpenWhisper sait qui vous appelez. Encore une fois, sans RedPhone c’est votre opérateur mobile qui sait qui vous appelez mais il sait également ce que vous racontez.

Signal

Pour iPhone, OpenWhisper a choisi d’unifier les usages et Signal permet également de recevoir ou d’émettre des appels vers d’autres personnes utilisant Signal ou RedPhone.

L’activation se fait en même temps que l’activation des messages et pour appeler quelqu’un il suffit de se rendre dans l’historique des messages et de cliquer sur appeler.

La messagerie instantanée et les conférences audio/vidéo

Maintenant on s’éloigne un peu du mobile pour s’attaquer à un gros morceau de la communication en ligne : Les conférences audio / vidéo et la messagerie instantanée.

On connait tous Skype, le leader sur le marché. Il appartient à Microsoft, propose des fonctions payantes et, en dépit de la sécurisation qu’il annonce, s’avère être aussi sécurisé qu’une passoire (lien en anglais).

Pour le remplacer, il n’y a pas grand monde. Mais l’alternative la plus aboutie est Tox.

Tox

Tox est un logiciel encore incomplet mais néanmoins déjà utilisable au quotidien.

Il permet de communiquer de plusieurs manières :

• Message texte avec une ou plusieurs personnes.
• Conversation audio avec une ou plusieurs personnes.
• Conversation vidéo avec une personne. (Les conférences vidéos à plusieurs sont prévues mais les développeurs galèrent un peu sur la meilleure interface possible pour ce cas.)

Après installation, Tox génère un identifiant : le ToxId. Il n’y a qu’à le communiquer à votre contact et après avoir accepté sa requête vous voila prêt⋅es à communiquer.

La communication s’effectue sans passer par aucun serveur et sans moyen de lire ou d’altérer le message pendant qu’il transite.

Cependant, comme il n’est pas tout à fait terminé il y a quelques points noirs qui seront prochainement résolus (d’ici la fin de l’année) :
* Pour accepter une requête de contact il faut être connecté⋅e. Si vous êtes déconnecté⋅e au moment où votre contact l’envoie, il devra la réémettre.
* Il est impossible d’envoyer des messages à quelqu’un qui est hors ligne car ils disparaîtront dans l’oubli.
* Il est impossible de rejoindre spontanément une conversation groupée, le seul moyen est d’y être invité⋅e.

Pour le reste tout y est : Smileys, audio, video, transfert de fichiers,…

Il est disponible sur Windows (lien de téléchargement), sur MacOS (lien de téléchargement) et sur GNU/Linux.

Vous avez maintenant toutes les clés en main pour mettre des bâtons dans les roues de quiconque voudrait surveiller vos communications instantanées.

Ce n’est qu’en proposant à vos contacts de les utiliser que vos communications seront protégées puisqu’il n’y a qu’avec les contacts qui utilisent le même logiciel que vous que le chiffrement fonctionne. TextSecure et RedPhone sont compatibles avec Signal mais Tox ne fonctionne qu’avec les utilisateur et les utilisatrices de Tox et SMSSecure ne fonctionne qu’avec les personnes utilisant SMSSecure.

Alors n’hésitez pas, motivez vos contacts et sortez couvert⋅es !

---

Crédits : Lockpicking with the hackers. par Sally Crossthwaite

Il y a un peu plus d’un an, j’ai parlé de moyens pour sécuriser nos communications sur nos téléphones mobiles. J’avais parlé de TextSecure, Redphone et Telegram. Avec le vote de la loi sur le renseignement qui autorise maintenant le gouvernement à surveiller tout un chacun sans passer par le moindre juge, il me semble pertinent de refaire un point sur ce qui a changé ou non et sur les nouveaux moyens disponibles.