Notre responsabilité

Vinton Cerf1 a publié dans le New-York Times une tribune, « Internet Access Is Not a Human Right » où il explique que selon lui, Internet n’est pas un droit humain2. Son argument est que les technologies sont des moyens d’accéder à des droits, non des droits eux-mêmes. J’avoue que la question ne me passionne guère. Lorsqu’on voit le peu de cas fait de droits universellement reconnus comme des droits humains, je trouve que ce n’est pas un combat prioritaire[^priorité]. Les dernières lignes de sa tribune m’intéressent davantage, et je vais de ce pas en proposer une traduction :

Cependant, tous ces arguments philosophiques négligent un problème plus fondamental : la responsabilité des créateurs de technologies eux-même de défendre les droits humains et civils. L’Internet a créé une plate-forme extrêmement accessible et égalitaire pour créer, partager et obtenir de l’information à une échelle globale. De ce fait, nous avons de nouveaux moyens pour permettre aux gens d’exercer leurs droits humains et civils.

Dans ce contexte, les développeurs ont non seulement une obligation très forte de donner plus de possibilités aux utilisateurs, mais aussi une obligation d’assurer leur sécurité en ligne. Cela signifie, par exemple, les protéger contre des maux spécifiques, comme les virus et les vers qui envahissent silencieusement leurs ordinateurs. Les techniciens devraient travailler à ça.

Ce sont les ingénieurs — et nos associations professionnelles et nos organismes de standardisation comme l’IEEE — qui créent et maintiennent ces nouvelles capacités. À mesure que nous cherchons à faire progresser l’état de l’art de la technologie et son utilisation dans la société, nous devons être conscients de nos responsabilités civiles en plus de notre expertise technique.

[Internet access is not a human right](http://www.nytimes.com/2012/01/05/opinion/internet-access-is-not-a-human-right.html) par Vinton Cerf

On ne le répètera jamais assez. Sur Internet, le code est la loi. Les règles sont fixées par celles et ceux qui conçoivent les normes et développent les logiciels implémentant ces normes. L’écriture des normes et leur validation par le code allant d’ailleurs généralement de paire. Lorsque nous participons au développement de normes et de logiciels qui les mettent en œuvre, nous ne devons pas seulement chercher à obtenir le meilleur résultat technique. Nous devons aussi réfléchir en législateurs, être conscients que nous fixons les limites des possibles et des usages du réseau. Que notre responsabilité est donc beaucoup plus importante que de juste produire un code qui fonctionne. Selon la façon dont nous les concevons, les outils qui sortent de nos mains peuvent libérer les utilisateurs, ou les aliéner.

L’actualité des derniers mois a fourni bien des illustrations de cette responsabilité. Le réseau a participé à de nombreuses mobilisations citoyennes, de la Tunisie à Wall Street en passant par l’Égypte ou la Syrie. On a pu voir les tentatives de contrôle des gouvernements et les contre-mesures de groupes de hackers comme Telecomix. Heureusement, Internet a vaincu le minitel dans les années 90. Si Telecomix réussit à mettre en échec la censure, c’est grâce à la résilience de l’Internet. C’est parce que le caractère décentralisé, incontrôlable du réseau a été inscrit dans son ADN par ses créateurs, RFC après RFC. Au contraire, les sites centralisés comme Facebook ou GMail ont constitué autant de talons d’Achille du réseau, des cibles faciles pour la censure ou l’espionnage. Si le minitel l’avait emporté, imaginez comme il aurait été simple pour un pouvoir de contrôler l’essentiel des communications des citoyens, et bien plus compliqué le contournement de cette censure.

Lorsque nous concevons des systèmes d’information, il faudrait garder ces exemples en tête, nous souvenir qu’il nous appartient de choisir si nous fournissons à nos utilisateur un minitel qui permettra de les contrôler ou un réseau qui augmentera leurs libertés.

Bien sûr, tout cela, ce sont de beaux discours. Ils rejoignent les multiples tentatives depuis des années de créer des chartes déontologique et autres codes de bonne conduite pour cadrer nos métiers. Souvent des vœux pieux. Dans le cadre professionnel, on peut parfois avoir un rôle de conseil et influer sur les valeurs que portent le produit final. Mais bien souvent, le but recherché étant le profit, le retour sur investissement du logiciel pour les investisseurs prime sur son utilité pour les utilisateurs. Et d’un point de vue purement financier, mieux vaut un utilisateur captif, contrôlé par le logiciel, qu’un internaute libre et adulte.

D’où l’importance de s’investir, hors des projets professionnels qui heureusement ne sont bien souvent que des châteaux de vent, dans des projets qui auront de l’importance pour le Web. Pour aider ces projets à être non seulement les meilleurs possibles d’un point de vue technique, mais aussi les meilleurs humainement parlant. Participer aux discussions du W3C, à la mise au point de nouvelles fonctionnalités, c’est jouer un rôle dans la rédaction des prochaines lois communes. Une oligarchie verrouille le monde actuel, fixe ses règles, ne laisse personne qui ne soit du sérail y mettre le nez. À côté, un autre monde est en train de se bâtir, qui pour l’instant est encore relativement ouvert aux contributions de chacun, malléable. Dans ce monde, nous pouvons encore exercer notre citoyenneté, participer jour après jour à l’élaboration de la cité, et pas juste en faisant mine de donner notre avis par un vote une fois de temps en temps. Nous aurions tord de nous en priver.

Euh, oulah, voilà que je prêche. Désolé. Bref, mettez un pense-bête dans un coin de votre écran pour ne pas oublier, en codant, de réfléchir à l’impact de votre code sur la société.

  1. qui, en tant que co-inventeur de TCP/IP est souvent considéré comme l’un des « pères d’Internet »

  2. le débat court depuis quelques années et a par exemple été évoqué dans un rapport du conseil des droits de l’homme de l’ONU ou une décision du conseil constitutionnel sur Hadopi;

Mozilla : pistes pour des services respectueux de nos données

Résumé des épisodes précédents : Mozilla a sauvé le mondeWeb une première fois en relançant la compétition dans le domaine des navigateurs grâce à Firefox. Mais les super-méchants ne se sont pas découragés et de nouvelles menaces planent sur le mondeWeb :des systèmes d’exploitation pour téléphones qui empêchent les utilisateurs de faire ce qu’ils veulent, des services en ligne qui phagocytent toutes les données et acquièrent une emprise croissante sur leurs internautes, une inculture qui empêche les gens de comprendre ce qu’est le Web et donc de se l’approprier, de l’utiliser pour créer et non juste pour consommer, et cœtera. Heureusement les Forces du Bien ne restent pas inactives et ont décidé d’aller en 2012 défendre leurs valeurs partout où la liberté du Web est menacée. Cela va passer entre autres par la création de services en ligne plus respectueux de leurs utilisateurs (création directe par Mozilla ou soutien à des projets qui vont dans ce sens, via les incubateurs Drumbeat1 et WebFWD2). Mais qu’est-ce qu’un service Web respectueux de ses utilisateurs ? Ben Adida a fourni un premier élément de réponse dans un article où il annonce la création au sein de Mozilla d’un groupe de travail pour réfléchir à offrir la meilleure protection possible aux données que Mozilla hébergera. Il suggère également quelques lignes directrices en la matière que devront suivre tous les projets de Mozilla.

Une des choses que j’aime de Mozilla, c’est sa relative ouverture et transparence. La réflexion sur le sujet est ouverte, tous les avis sont les bienvenus. Dans l’espoir d’aider au débat, j’ai très rapidement traduit l’article de Ben et son introduction par Mitchell. Je pousserai cette traduction sur Github, donc n’hésitez pas si cela vous intéresse à l’améliorer et la reprendre (ping Frenchmoz).

Toutes les notes de bas de page sont de mon fait, et ne figurent pas dans les articles originaux.

Outre la traduction, ces articles appellent des réactions, mais j’ai trop peu de temps libre ce ouikende pour disserter. Voici déjà les deux articles, bonne lecture.

[User Sovereignty for our Data](http://blog.lizardwrangler.com/2012/01/13/user-sovereignty-for-our-data/) par [Mitchell Baker](http://blog.lizardwrangler.com/)

Être maîtres de nos données

Nos expériences en ligne s’accompagnent de plus en plus de données sur nous. Nous en créons certaines. Parfois ce sont nos amis et nos connaissances qui les créent, et parfois les services que nous utilisons créent des données sur nous. D’un côté, cela rend possible toutes sortes de nouvelles applications excitantes. De l’autre, l’explosion des données personnelles a quelques aspects très troublants. La capacité des fournisseurs de service de cloud computing et de traitement des big data de surveiller, journaliser, stocker, utiliser, corréler et vendre des informations sur ce que nous sommes et ce que nous faisons a des implications importantes tant pour la société que pour les individus.

À l’heure actuelle, il n’existe pas de moyen me permettant de partager de l’information sur moi et de garder le contrôle de cette information. Je partage l’information à mon sujet en la plaçant quelque part où quelqu’un d’autre décide de toutes les règles. Ce « quelqu’un d’autre » est l’application. La plupart des gens pensent à Facebook ou Google, mais le problème dépasse largement l’un ou l’autre. C’est aujourd’hui un problème de l’architecture des données des utilisateurs, et il concerne l’ensemble du réseau. Pensez aux gros sites où les utilisateurs donnent leur avis sur des produits, ou à n’importe quelle application où vous passez beaucoup de temps. Pensez à n’importe quel réseau social auquel vous êtes connecté. Le seul moyen pratique d’avoir un endroit à soi sur ces sites est de leur apporter nos données et de n’avoir d’autre contrôle que celui que les développeurs de l’application ont décidé de nous donner.

Ces problèmes ont des implications importantes pour Mozilla.

D’abord, cela signifie que nous devrions inventer de nouvelles choses dans le domaine des données utilisateur. Pour réellement aider les gens à gérer et partager leurs données, Mozilla devra également leur offrir le choix de stocker leurs données dans le nuage de façon à ce que d’autres services puissent y accéder avec leur accord. Cela implique de nouveaux défis. C’est important que nous les relevions et y répondions bien. Si nous développons et offrons de quoi gérer correctement les données des utilisateurs dans le nuage, nous aiderons à garantir le choix et la souveraineté de l’utilisateur dans de nouveaux pans de la vie en ligne. Chacun d’entre nous devrait pourvoir choisir en connaissance de cause où et comment nos données sont stockées et gérées. Aucune autre organisation n’a à la fois la capacité de réaliser quelque chose de complètement centré sur la souveraineté des utilisateurs plutôt que sur le profit financier, et la capacité d’avoir un vaste impact. La présence de Mozilla dans le cloud nous permettra de remplir notre mission dans de nouvelles dimensions importantes de la vie en ligne.

Ensuite, cela signifie que notre approche de la gestion des données utilisateur doit être différente de la norme actuelle dans l’industrie Web. Elle doit vous placer au centre, disposer vos données tout autour de vous, et vous laisser partager ces données avec les applications que vous choisissez, selon les termes que vous choisissez. Notre approche ne devrait enregistrer les données de l’utilisateur que si cela a un bénéfice mesurable pour lui, plutôt que de tout collecter dans l’espoir que des applications de data mining extraient de la valeur utile à quelqu’un d’autre. Elle devrait permettre aux gens de déterminer si leurs données sont accessibles à d’autres. Le principe de la souveraineté de l’utilisateur3 influencera la façon dont nous concevons chaque aspect de nos offres. Les offres de Mozilla doivent incarner les valeurs du Manifeste de Mozilla, et nos principes de respect de la vie privée.

Mon collègue Ben Adida (responsable technique du domaine de l’identité et de données utilisateur, et un de nos experts en cryptographie) a écrit un article décrivant nos réflexions sur la création de tels produits.

[User Sovereignty for our Data](http://blog.lizardwrangler.com/2012/01/13/user-sovereignty-for-our-data/) par [Mitchell Baker](http://blog.lizardwrangler.com/)

Et voici donc l’article de Ben :

[Mozilla to Offer New User-Centric Services in 2012](http://blog.mozilla.com/privacy/2012/01/13/mozilla-to-offer-new-user-centric-services-in-2012/) par [Ben Adida](http://ben.adida.net/#me)

Mozilla va créer de nouveaux services centrés sur l’utilisateur en 2012

Chez Mozilla, nous nous concentrons depuis longtemps sur le développement de logiciels qui donnent aux utilisateurs la maîtrise de leurs vies en ligne. Cela signifie les concevoir de manière à fournir aux gens une meilleure connaissance de comment fonctionne le Web, des fonctionnalités logicielles uniques pour personnaliser leur expérience en ligne et le contrôle sur leurs données personnelles. Ces derniers temps, nous avons réfléchi à comment la souveraineté de l’utilisateur s’est étendue pour ne plus dépendre seulement du navigateur. De nombreux sites Web stockent pour l’utilisateur l’ensemble de ses données et de ses actions. Même si le navigateur est complètement contrôlé par l’utilisateur, beaucoup de services que l’utilisateur apprécie ne le sont pas. Parfois, ces services Web gèrent les données d’une manière dont la valeur est questionnable pour l’utilisateur, et parfois même à son détriment.

Il est clair que Mozilla a besoin de franchir une étape et de fournir, en plus du navigateur Firefox, certains services pour augmenter le contrôle de l’utilisateur sur son expérience en ligne et ses données personnelles. La présidente de Mozilla, Mitchell Baker, l’a expliqué ainsi 3:

Je crois qu’il est impératif que nous développions d’autres produits. Nous avons besoin, à plusieurs niveau de notre vie sur Internet, de plateformes ouvertes, au code source libre, interopérables, au service du public et basées sur des standards. Nous choisissons d’emmener nos valeurs là où sont les gens.

Les services que nous imaginons et sur lesquels nous travaillons dur, afin de les lancer dans les prochaines semaines et les prochains mois, incluent : une approche innovante de l’identité, un système d’exploitation pour les terminaux mobiles basé sur le Web, et une boutique d’applications. Pour offrir ces services, nous aurons besoin de stocker des données des utilisateurs sur les serveurs de Mozilla à bien plus grande échelle que nous le faisons actuellement. Cela nécessite beaucoup de soin et de réflexion. Nous avons commencé à chercher comment le faire et avons essayé quelques prototypes. Je voudrais vous dire ce à quoi nous pensons et solliciter votre avis et vos idées.

Notre approche actuelle — Firefox Sync

Mozilla stocke déjà des données chiffrées dans le cadre de Firefox Sync, qui permet à des millions d’utilisateurs de Firefox de synchroniser entre de multiples installations de Firefox — dont Firefox Mobile — leurs marque-pages, leur historique de navigation et leurs mots de passe. Nous sécurisons ces données en utilisant un chiffrement plus avancé que celui utilisé par les institutions financières. Typiquement, les banques chiffrent les données transférées (SSL) : vous données sont chiffrées entre votre navigateur et les serveurs de la banque. Une fois sur le serveur de la banque, elles sont naturellement déchiffrées. En comparaison, Firefox Sync utilise un chiffrement au niveau de l’application : vos données sont chiffrés par Firefox avant d’être envoyées sur le réseau, et elles restent chiffrées une fois arrivées sur nos serveurs, et lorsqu’elles sont stockées sur nos disques. Seul votre Firefox peut les déchiffrer. Mozilla n’a pas la clé qui permet de les déchiffrer.

Cela signifie que nous ne voyons jamais vos données. Si un de nos serveurs était piraté, ou si quelqu’un réussissait à subtiliser quelques disques dans un de nos datacenters, vos données resteraient malgré tout à l’abri des yeux indiscrets. Peu d’autres société en font autant pour assurer la sécurité de vos données.

Les nouveaux services auxquels nous pensons vont, lorsque cela sera possible, continuer à utiliser ce niveau de sécurité des données.

Les limites du chiffrement au niveau de l’application

Si nous ne pouvons pas voir vos données, alors vous êtes incroyablement à l’abri, mais nous ne pouvons pas non plus faire grand chose pour vous. Le chiffrement au niveau de l’application est comme le coffre-fort que vous cachez dans votre placard : vous pouvez y mettre des objets de valeur et vous pouvez les récupérer si vous êtes là en personne, mais vous ne pouvez pas facilement demander au téléphone à l’un de vos colocataires de vous dire combien de liquide est stocké dans le coffre. En comparaison, c’est facile d’appeler un colocataire et de lui demander de vous lire un numéro de téléphone que vous avez laissé sur la table de la cuisine. Certaines données ont tellement de valeur que vous devez les stocker dans un coffre-fort. D’autres données peuvent ne pas être aussi sensibles, et être un peu plus utiles si vous pouvez obtenir de l’aide pour les gérer, les retrouver et les traiter. Quelque chose d’aussi simple que de vous envoyer des rappels pour les anniversaires de vos amis nécessite que le service puisse accéder à ces données lorsque vous n’êtes pas connecté.

J’ai écrit plus tôt sur les limitations du chiffrement pour mettre à l’abri les données4. Le chiffrement n’est pas de la magie. Il n’est pas approprié pour toutes les applications. Si nous voulons pouvoir fournir des services alternatifs réalistes, qui montrent ce que peut signifier la souveraineté de l’utilisateur, cela va nécessiter de stocker des données des utilisateurs sur nos serveurs, même sans chiffrement au niveau de l’application.

Principes de conception

Nous proposons quelques principe de conception de départ :

  • un bénéfice clair pour l’utilisateur : les données que nous collectons devraient toujours offrir à l’utilisateur un bénéfice clair et direct. Le stockage agressif de données « juste au cas où on en aurait besoin plus tard » n’est pas acceptable;
  • un inventaire des données : nous devrions toujours savoir quelles données nous collectons, où et comment elles sont stockées et pourquoi le stockage de chacune est crucial pour la fonctionnalité pour l’utilisateur final. Nous devrions nous assurer que les utilisateurs puissent facilement accéder à cet inventaire, le comprendre, le mettre à jour ou le supprimer;
  • minimiser les données que le serveur peut consulter : si nous pouvons implémenter une fonctionnalité donnée sans jamais envoyer de données au serveur, ou en utilisant un chiffrement au niveau de l’application, alors nous le ferons;
  • minimiser la conservation des données : nous devrions stocker les données pour une durée aussi courte que possible. En particulier, si nous avons besoin de serveurs uniquement pour fournir un point de transit pour des données, alors ces données devraient uniquement transiter par les serveurs, et ne jamais y être stockées;
  • agréger à chaque fois que c’est possible : nous étudierons si nous pouvons implémenter la fonctionnalité en utilisant des données agrégées à partir d’un nombre significatif d’utilisateurs, plutôt qu’en conservant des données individuelles. (Étant donné la richesse de ces jeux de données, nous ne pouvons pas prétendre que les rendre anonymes est particulièrement utile pour protéger les utilisateurs individuels);

Nous voulons passer en revue chaque fonctionnalité que nous envisageons en utilisant sur les procédures existantes que le projet Mozilla connait déjà bien : Bugzilla. Les questions seront suivies dans Bugzilla, rattachées à un ticket principal que nous appelerons probablement « Sûreté des données ».

Personnes impliquées

Les personnes suivantes se sont rassemblées pour créer une Équipe de Sécurité des Données, afin de développer ces idées et de les inclure dans tous nos produits :

  • Jay Sullivan, en charge de la définition des produits Mozilla qui incarneront nos valeurs;
  • Sid Stamm, qui gère l’ingénierie de la gestion de la vie privée dans Firefox et sur la plate-forme Web;
  • Jonathan Nightingale, chargé du développement de Firefox;
  • Alex Fowler, qui s’occupe de gestion de la vie privée et des politiques de confidentialité, en se concentrant sur l’amélioration de la gestion des informations;
  • Brendan Eich, responsable depuis le premier jour de la direction technique du Projet Mozilla;
  • Michael Coates, qui s’occupe de la securité des infrastructures et supervise les applications, les serveurs et les réseaux;
  • Chris Beard, chargé des programmes de marketing et d’engagement;
  • David Ascher, qui mène la réflexion au sein de Mozilla sur comment les utilisateurs découvrent le Web et y partagent;
  • Ben Adida, c’est moi, je suis responsable des travaux sur l’identité;

Nous savons que cette équipe devrait grossir pour inclure des individus avec des parcours plus divers, des gens de Mozilla et d’ailleurs, et des gens du monde entier. Nous aurons également besoin de nous soucier des différentes législations et usages locaux5 pour concevoir et héberger nos services.

Au delà de la simple conformité

La sûreté des données nécessite d’être attentif à la conformité avec les lois et les bonnes pratiques, mais notre but est d’aller au delà. Nous allons impliquer nos architectes logiciels et nos experts en sécurité les plus expérimentés pour déterminer comment créer une meilleur protection de la vie privée. Ces discutions et ces itérations, comme toutes celles concernant le sécurité et la vie privée, seront par défaut publiques, afin qu’elles puissent être auditées, tout comme l’est notre code source (à l’exception naturellement de lorsque ces révélations donneraient à des attaquants une longueur d’avance, auquel cas nous conserverons ces informations temporairement secrètes). De plus, comme tous les projets Mozilla, nous impliquerons nos utilisateurs dans le processus de définition de l’architecture qui permettra de leur donner davantage de maîtrise. Il est crucial qu’ils comprennent les solutions que nous proposons, les bénéfices qu’elles apportent, et comment leurs données sont utilisées pour arriver à ces bénéfices.

Coller à nos principes

La souveraineté de l’utilisateur requiert un excellent navigateur et un certain nombre de services centrés sur l’utilisateur. Nous aimerions créer certains de ces services, et nous avons l’intention de le faire avec autant de dévouement que toujours envers nos principes de respect de la vie privée : pas de surprise, de vrais choix, des réglages sensés, des données limitées et le contrôle par l’utilisateur. Nous ne vendrons ni ne donnerons vos données. Nous expliquerons toujours quelles données nous stockons et pourquoi nous les stockons. Nous vous laisserons toujours partir et emmener vos données avec vous, et nous vous expliquerons toujours quel bénéfice vous obtiendrez de la collecte de ces données.

Vos réactions sont les bienvenues, via des articles, des messages sur la liste dev.planning ou sur Twitter en utilisant le hashtag #mozdatasafety.

[Mozilla to Offer New User-Centric Services in 2012](http://blog.mozilla.com/privacy/2012/01/13/mozilla-to-offer-new-user-centric-services-in-2012/) par [Ben Adida](http://ben.adida.net/#me)
  1. Drumbeat se consacrant désormais à la mission d’éduquer à la culture Web, je ne suis pas sûr qu’il continue à soutenir beaucoup d’autres projets, comme il le faisait à ses débuts;

  2. ainsi par exemple d’Open Photo, une alternative libre à Flickr ou de Verese qui gère des micro-paiements au sein d’une communauté;

  3. version française sur le blog de FrenchMozila 2

  4. Version française sur le blog de FrenchMozilla

  5. pour le coup, utiliser la « règle de proximité » et accorder avec le nom le plus proche me semble beaucoup plus joli que d’écrire « les différents législations »;

Au revoir les zombies

Firefox a souvent été qualifié d’ogre à mémoire (bloatware), et pas toujours à tort. En Mars 2011, Mozilla a donc lancé le projet MemShrink pour s’attaquer au problème. Nicholas Nethercote, un des responsables, publie chaque semaine un état d’avancement. Que l’on pourrait décrire comme des chroniques de la chasse aux (compartiments) zombies. J’avoue que c’était jusqu’à présent pour moi un rituel aussi mystérieux que la chasse au Dahu. Je viens juste de tomber sur un article, depuis synthétisé sous forme d’une documentation dans MDN où il explique le concept. Je vais tenter de résumer ce que j’en ai compris, merci de me signaler mes erreurs.

À chaque origine son compartiment

La mémoire utilisée par le moteur JavaScript de Firefox est divisée en compartiments. Tous les objets créés par une origine1 sont stockés dans un compartiment. Pour d’évidentes raisons de sécurité, les objets d’un compartiment ne peuvent accéder qu’à des objets du même compartiment.

Vous pouvez voir la liste de tous les compartiments à l’URL about:memory?verbose. Sous Explicit Allocations vous verrez le détail de l’ensemble des compartiments, tant ceux liés à une origine que ceux utilisés par Firefox lui-même. En sus des compartiments, cette vue affiche également la pile, la mémoire utilisée par le DOM de chaque onglet ouvert, par l’interface du navigateur et différentes autres informations. On peut ainsi facilement visualiser la mémoire utilisée par les scripts de chaque page (mais pas par chaque page, il faudrait additionner les scripts, le DOM, les images…)

Il est important de faire la différence entre une origine et une page Web :

  • si vous avez plusieurs onglets ouverts sur des pages d’un même site, leurs scripts auront la même URL, donc seront dans le même compartiment;
  • il est fréquent qu’une page charge des scripts de diverses origines. Par exemple un ou plusieurs scripts de pistage des utilisateurs, des scripts de partage sur des réseaux « sociaux », etc… Cette page créera donc de nombreux compartiments. L’expérience est facile à faire : créez un profil temporaire, ouvrez-y par exemple un site d’actualité puis avec about:memory?verbose allez compter le nombre de compartiments créés. Facebook, Google, Twitter seront probablement du voyage2;

Les compartiments ne sont pas supprimés dès la fermeture du dernier onglet utilisant un script d’une origine. La libération de la mémoire se fait de manière classique au moyen d’un ramasse-miette appelé à intervalles réguliers. Les compartiments survivent donc quelques secondes aux scripts qui les ont créés.

Les zombies attaquent

Parfois, certains compartiments ne sont pas supprimés après la fermeture des onglets qui les utilisaient. Ils continuent donc à occuper inutilement de la mémoire, et la mémoire globale utilisée par le navigateur croit à mesure que se multiplient ces zombies. Une bonne partie du travail de Memshrink est donc d’identifier les causes entraînant la création de tels zombies.

Chasser les zombies

Le meilleur moyen de participer à la chasse est de regarder régulièrement l’état de la mémoire. Si vous voyez un compartiment associé à une URL qui ne semble plus utilisée par aucun onglet ouvert, ça pourrait être un zombie. Pour en avoir le cœur net, redémarrez Firefox en n’ouvrant que la page que vous pensez à l’origine de ce compartiment, ouvrez le gestionnaire de mémoire pour vérifier que le compartiment est présent. Fermez alors la page et forcez l’appel du ramasse-miette au moyen du bouton minimize memory usage de about:memory. Si après avoir appuyé plusieurs fois sur le bouton et attendu quelques minutes, le compartiment est toujours là, vous êtes probablement en présence d’un zombie. Il faut alors créer un ticket détaillant le problème (je vous renvoie à l’article sur MDN pour les détails de la création du ticket).

Beaucoup de progrès ont été faits ces derniers mois pour éradiquer les zombies. Memshrink s’attaque à présent à un nouveau gros chantier : les zombies enfantés par des extensions. Pour les aider, nous pouvez, lorsque vous détectez un zombie, essayer de voir s’il est lié à une de vos extensions en répétant les manœuvres ci-dessus en désactivant les unes après les autres chacune de vos extensions.

Bonus

Quelques nouvelles extraites du dernier point d’avancement de Memshrink :

  • Jared Wein a corrigé une fuite qui survenait en regardant une vidéo HTML5 tout en ayant installé une extension utilisant certaines fonctionnalités du navigateur. Parmi les extensions impactées : Adblock Plus, GreaseMonkey et NoScript. Soit un paquet d’utilisateurs;
  • Arantius a corrigé des fuites liées à GreaseMonkey;
  • l’équipe travaillant sur JetPack a réduit significativement l’utilisation mémoire des extensions crées avec le SDK;
  • Krzysztof Kotlenga a corrigé un bug qui permettait à WebGL de consommer plus d’1Go de mémoire sur GNU/Linux avec l’accélération matérielle activée;

La consommation mémoire de Firefox s’améliore semaine après semaine. Si vous aviez délaissé le petit panda parce que vous le trouviez trop gourmand, n’hésitez pas à tester de temps en temps les nightlies pour voir les progrès réalisés.

Références

  • la page de documentation sur les compartiments zombies;
  • Andreas Gal a écrit un article très détaillé sur la gestion de la mémoire par le moteur JavaScript de Firefox (article un peu vieux, je ne sais pas s’il est encore entièrement exact);

Moralité

Je viens enfin de comprendre le sens de la fameuse chanson « what’s in your heap ? Zombies… »

  1. deux pages ont la même origine si leurs URLs ont le même protocole, le même port et le même hôte. Cf cette explication sur MDN.

  2. à noter un petit bug qui n’aide pas à s’y retrouver : le nom du compartiment est l’URL de la première page ouverte sur une origine, non cette origine. Vous aurez donc parfois des compartiments nommés par l’URL d’une page que vous avez fermée. Ce n’est pas forcément une erreur, mais signifie que d’autres scripts de la même origine sont encore actifs;

Des réunions constructives selon Google

Je déteste les réunions, du moins au boulot. Alors pour une fois que Google donne quelques conseils qui devraient permettre d’en subir moins et de rendre plus intéressantes celles auxquelles on ne coupera pas, je relaie avec plaisir leur prose1. Vu l’aura de la bête chez les wannabe, n’hésitez pas à relayer la parole auprès de votre taulier.

Des réunions constructives

Une de nos premières observations a été que beaucoup de réunions ne fonctionnaient pas aussi bien qu’elles auraient dû. Une réunion rondement menée est une bonne chose; elle donne les moyens aux gens de prendre des décisions, permet de résoudre des problèmes et de partager de l’information. Mais les réunions mal menées sont une perte de temps démoralisante. Nous ne voulions pas que nos employés perdent leur temps ou leur énergie, donc nous avons collecté les avis et fait quelques recommandations pour rendre les réunion plus efficaces.

Pour commencer, nous avons noté qu’il devrait y avoir à chaque réunion destinée à prendre une décision une personne clairement définie qui prendra la décision. Si ça n’est pas le cas, la réunion ne devrait pas avoir lieu. Ces réunions ne devraient idéalement pas réunir plus de dix personnes, et chaque participant devrait apporter une contribution. Si quelqu’un n’a pas de contribution à faire, alors peut-être que sa place n’est pas là. Ce n’est pas grave — participer à des réunions ne rapporte pas de médaille d’honneur. Les participants doivent également être à l’heure. Plus important, les décisions ne devraient jamais être différées en attendant une réunion. Si une réunion est absolument nécessaire pour prendre une décision, alors cette réunion doit se faire immédiatement.

Source: Think Quarterly, une lettre d’information de Google.

Ces conseils font partie d’une réflexion plus large où Google réalise qu’à force de grossir la société est en train de s’enliser, et essaie de réagir en renouant avec l’état d’esprit de startup de ses débuts. Je n’ai pas lu la suite, n’ayant guère d’appétence pour ce genre de discours, mais peut-être mes camarades Mozilliens, confrontés à une très forte croissance, y trouveront-ils matière à réflexion.

  1. j’ai cru comprendre que c’était extrait d’un mémo interne envoyé par Larry Page lorsqu’il a repris les rênes de la boîte en 2011.

Entre deux chaises

Une récente traduction sur le Framablog, traitant de la « Révolution Libre » en cours m’a rappelé que j’avais noté il y a un mois une autre citation à propos de révolution. Un brouillon de note qui n’allait nulle part et que, contrairement au principe de ce carnet, je n’avais pas publié. La voici.

(…) à un premier capitalisme centré sur la production (celui de l’école de Ferry), privilégiant l’ingénieur, la propriété intellectuelle, la captation de la force physique des ouvriers, a succédé un second capitalisme articulé autour de la production de masse, la communication de masse et la consommation de masse, privilégiant le marketing et tentant de capter le désir des consommateurs. Nous sortons aujourd’hui péniblement de cette ère pour entrer dans un monde hyper-instruit, hyper-connecté et hyper-outillé, essayant de capter la créativité des consommateurs, et privilégiant donc le design des systèmes et des interfaces —

[Henri Verdier][verdier] in [Eduquer après la Révolution numérique][eduquer]

Je n’ai pas la prétention de comprendre Stiegler ou Moulier Boutang, autres théoriciens de la mutation vers un capitalisme cognitif, et n’ai donc retenu que l’idée des trois phases, chacune symbolisée par leur cheville ouvrière : l’ouvrier, le commercial, le designer. Et en ai déduit que j’ai deux révolutions de retard : étant moi-même ouvrier1, je continue à analyser le monde comme si nous étions encore dans la première révolution industrielle. Celle de la production (de logiciels dans mon cas). Je ne m’intéresse qu’à la production et à ses conditions. Je cherche à manufacturer des objets logiciels en me concentrant sur leur conception et leurs fonctionnalités. À produire de beaux objets utiles.

Je n’aime pas les commerciaux. Je m’en méfie. Les assimile à des voleurs, des escrocs, prêts à tout pour vendre aux gens des produits dont ils n’ont pas besoin, mentant sur le produit, imposant une diminution de la qualité pour réduire les coûts, etc. Je refuse de devenir commercial, d’entrer dans ce jeu pour diffuser auprès du plus grand nombre mes productions.

Je me méfie des designers. Parce que je n’ai ni talent ni sensibilité pour le design, et ne comprend donc pas grand chose à leur métier. Parce que j’ai l’impression que le design est souvent synonyme de primauté de la forme sur le fond. Et que pour moi le fond doit primer. La beauté du code sur celle de l’interface. La richesse fonctionnelle. Le reste n’est que futilités.

Je pense que parmi les gens gravitant dans le monde du logiciel libre, nous sommes nombreux à être restés bloqués au stade de la production, à refuser d’essayer de devenir des commerciaux et des designers. À préférer peaufiner méticuleusement un objet pour le rendre le plus utile possible, en estimant que son utilité seule suffira à le faire adopter par le plus grand nombre. À refuser de nous abaisser à faire du marketing pour « vendre » nos logiciels. À nous méfier des designers qui voudraient nous faire renoncer à certaines fonctionnalités au profit d’une interface prétendument plus ergonomique pour le commun des mortels. Je pense que ces deux trains de retard sont en partie responsables du manque de popularité de nos logiciels comparés à leurs équivalents privateurs. (oui, ce n’est pas un constat nouveau).

Et pour reprendre une fois de plus un exemple qui me tient à cœur, celui de Mozilla, ces trois stades offrent peut-être une grille d’analyse permettant de comprendre certaines tensions. Entre une première génération, soucieuse uniquement de la qualité technique et des fonctionnalités des logiciels. Une deuxième génération, qui a aidé à diffuser le produit auprès du grand public en utilisant les techniques du marketing — souvent au grand dam des premiers, OMG, on utilise Facebook ! — et la génération « Jobs », celle des designers, celle qui cherche à privilégier la créativité des utilisateurs en effaçant l’outil. Cet outil qui fait la fierté des ouvriers lesquels, du fond de leurs ateliers sombres, se sentent dépossédés une deuxième fois.

Les délocalisations et la désindustrialisation consécutive ont effacé les ouvriers de notre imaginaire. Ils représentent pourtant encore près du quart de la population active, mais nous les avons oubliés, oubliées les petites mains qui fabriquent tous les objets de notre quotidien. Oubliées et dévalorisées. Au niveau des études comme de la position sociales, les voies les plus valorisées sont désormais celles qui forment des commerciaux, non des ingénieurs. Et le véritable culte autour de Jobs est sans doute précurseur de l’arrivée des designers en haut de la pyramide sociale. D’où le malaise de tous ceux qui produisent les richesses, agriculteurs et ouvriers de l’industrie mécanique, chimique ou logicielle.

Finalement, les développeurs informatiques ont un peu le cul entre deux chaises. À la fois au cœur de la « Révolution numérique » en cours, et effacés au profit de ceux qui la vendent et en conçoivent l’emballage. Pas très confortable.

  1. je considère les développeurs logiciels comme des ouvriers ou, s’ils sont à leur compte, des artisans. Le sens premier du mot est « travailleur, travailleuse qui exécute pour le compte d’autrui, moyennant salaire, un travail manuel » (source). Mon métier est de manipuler une machine pour créer un objet. L’aspect « intellectuel » de la chose étant équivalent à la réflexion nécessaire à tout ouvrier qualifié ou artisan pour réaliser sa tâche;

Fork me on GitHub