Clochix

Revue de Web

Clochix — Mon, 22 Feb 2010 01:03:00 +0100

En attendant pour avoir à nouveau le temps de divaguer sur ce carnet, voire de coder, une prochaine désertion du camp de travail où la nécessité de payer mon loyer m'a renvoyé, voici une rapide revue de quelques trucs aperçus ces dernières semaines. Je préfère définitivement un billet ici avec quelques petits développements à l'exercice trop frustrant du résumé en 140c.

Anastasie et la pomme

L'affaire est vieille de plusieurs semaines, mais comme je me suis aperçu que tout le monde n'en a apparemment pas entendu parler, je poste un lien. Vous savez que ne peuvent tourner sur iPhone (et bientôt iPad) que les applications qui ont été validées par Apple. Cette validation va assez loin puisqu'outre le respect de contraintes techniques, elle vérifie également les contenus diffusés par l'application. Certains programmes ont ainsi été refusés parce qu'ils auraient permis de consulter des textes érotiques. Toujours plus loin, il semble à présent que soient aussi interdites toute référence à des concurrents d'Apple. L'App Store a ainsi demandé à des développeurs de modifier la description de leur application qui mentionnait qu'elle était également disponible sur les téléphones équipés d'Android, développé par Google et concurrent de l'iPhone. Mais à part ça Steve est toujours aussi cool

Un panda dans la poche

A propos d'Android, le développement d'une version de Firefox pour l'OS mobile de Google avance vite et elle pourrait voir le jour avant la fin 2010. Voir par exemple ce billet de Vladimir Vukićević. Ce développement a été rendu possible grâce à l'arrivée sur Android d'un environnement de développement (NDK) permettant l'utilisation de C et C++ alors que jusqu'à présent le SDK était limité à Java. Firefox est déjà disponible sur Maemo, un des OS mobiles de Nokia, sur Windows Mobile (en version alpha) et devrait l'être sur Meego, la fusion de Maemo avec le Moblin d'Intel. L'avancée des différents projets peut être suivi sur le wiki des projets de Mozilla sur mobile. Par contre, toujours rien n'est prévu pour l'iPhone, puisqu'Apple interdit explicitement toute application pouvant concurrencer ses propres produits. Tous les défenseurs du sacro-saint marché fiers d'arborer leur gadget au sein duquel toute concurrence est interdite me font décidément doucement rigoler...

Les progrès de l'électrolyse

S'il est un point sur lequel Firefox a pris du retard sur Chrome et IE 8, c'est dans la gestion du multi-processus. Actuellement, Firefox n'utilise qu'un seul processus, donc toute page Web ou tout plugin qui planterait entraînerait un plantage de tout le navigateur. Cela devrait être résolu d'ici la fin de l'année via le projet Electrolysis : dans Firefox 4 chaque onglet devrait s'exécuter dans un processus séparé. La première étape est disponible depuis quelques semaines dans les compilations nocturnes de Firefox : le projet OOPP (out-of-process plugins) isole les plugins dans un processus séparé. Les plugins ne doivent pas être confondus avec les extensions. Ils sont en général destinés à permettre au navigateur de lire d'autres formats de fichiers : Flash, PDF, Java... Désormais, ils s'exécuteront dans un processus séparé, en clair un plantage de Flash n'enverra plus le navigateur au tapis, et si le même Flash consomme trop de ressources on pourra tranquillement le tuer sans affecter Firefox. De quoi réjouir les utilisateurs du plugin, en attendant le jour que j'espère prochain où HTML 5 enverra Flash rejoindre IE6 dans les poubelles de l'Histoire.

HTML 5 rulez

J'ai déjà eu l'occasion de pester contre la manie d'utiliser Flash pour afficher des présentations sur le Web, manie qui prive de ces présentations les gens qui ne veulent ou ne peuvent pas installer le lecteur propriétaire d'Adobe. Jusqu'à présent je conseillais plutôt l'utilisation de solutions en HTML pur, comme S5 d'Eric Meyer ou Slidy du W3C. Atul Varma, un développeur des MozLabs dont je suis grand fan, propose une solution très jolie utilisant HTML 5. Comme tout est écrit dans un langage ouvert, on peut facilement adapter la présentation à ses besoin, en extraire des informations, rajouter des sous-titres dans une autre langue, etc. Une raison de plus d'aimer le Web Libre. Alors je vous le re-demande : à quand un site utilisant des technologies ouvertes pour héberger des présentations ?

Monde de merde, et encore, je suis gentil

J'écris Web Libre, mais je me demande s'il ne va pas m'arriver des bricoles. En effet, ces jours-ci la censure n'est pas que sur Internet, avec par exemple la LOPPSI dont tout le monde a parlé, mais aussi dans l'autre monde. Ainsi une gamine a été exclue de son école pour avoir porté un maillot appelant à la liberté. On n'est certes pas encore dans la situation hallucinante des école yankees, décrite par @manhack, où l'on rencontre de plus en plus de flics dans les écoles, mais on y vient doucement. Ah le charme des pays symboles de liberté ou de droit de l'homme, des grandes démocraties... On a d'ailleurs chaque jour moins de droit, dans ces "démocraties", puisqu'on peut aussi se faire condamner pour avoir appelé au boycott des criminels de guerre, ou molester pour avoir simplement voulu s'embrasser dans la rue. Et ne parlons même pas du droit de survivre, allègrement bafoué à Bagnolet quand la mairie a profité d'un jour de neige pour évacuer les individus, enfants compris, qui occupaient depuis des années un immeuble abandonné. L'immeuble a été aussitôt détruit, avec toutes les affaires de ses occupants. Le lieu servait parait-il à la prostitution et à la consommation de stupéfiants, c'est du moins les prétextes sortis par les édiles pour justifier leur geste et le harcèlement policier contre les expulsés qui essayaient de camper dans la rue, faute de s'être vus proposer le moindre relogement. Mais après tout, si ce n'étaient que des putes et des toxs, ça ne doit pas être bien grave qu'ils crèvent. Gerbant !

URL, kézako

Autre histoire édifiante, largement commentée mais que je me permet de reprendre, au cas où elle aurait échappé à ta sagacité : I want the old Facebook back !. Il y a quelques semaines, le site à forte audience ReadWriteWeb publiait un article sur la volonté de Facebook de devenir un des principaux fournisseurs d'identité sur le Web. Le but étant que les gens puissent s'identifier sur n'importe quel site avec leur compte Facebook. Le sujet est dans l'air du temps, et l'article, titré Facebook Wants to Be Your One True Login a rapidement été bien indexé dans Google. Or, que font bon nombre d'utilisateurs pour aller sur la page d'accueil de Facebook et se connecter à leur compte ? Il ne tapent pas l'adresse du site dans la barre d'adresse. Ils n'utilisent pas la barre géniale de Firefox. Ils vont sur Google, leur page de démarrage par défaut, et y cherchent Facebook login, puis cliquent sur le premier lien. Or l'article de RWW s'est trouvé être le deuxième résultat de recherche affiché à bon nombre d'utilisateurs qui, sans se poser davantage de questions, ont cliqué sur le lien et ont atterrit sur l'article. Se sont-ils aperçu de leur méprise ? Pas tous apparemment puisque plusieurs centaines d'internautes ont cru être sur la nouvelle page d'accueil de Facebook, et ont laissé des commentaires sous l'article critiquant cette nouvelle page qui ne leur permettait plus de ce connecter, et appelant au retour de la précédente : I want the old Facebook back !. Passé le premier éclat de rire, il y a là de quoi nous interroger sur la différence de pratique et de connaissance de la toile entre les vieux briscards qui codent des sites et l'usage du réseau par bon nombre de gens à qui nous destinons nos sites. Dans les statistiques de ce blog, la principale recherche sur Google qui amène des lecteurs est... mon nom de domaine. Ca donne à réfléchir.

Le retour du doigt

Les informations des otages de Google qui ont un profil public sont à présent disponibles aux formats XRD et FOAF. Par exemple les profils de toto@gmail.com sont accessibles à http://s2.googleusercontent.com/webfinger/?q=toto@gmail.com et http://s2.googleusercontent.com/webfinger/?q=toto@gmail.com&fmt=foaf. Et c'est plutôt cool. FOAF et XRD sont deux technologies utilisées dans le Web sémantique. La première, développée par le W3C, est un vocabulaire dédié à la description de personnes et des liens entre elles. XRD, pour eXtensible Resource Descriptor, initiative de l'OASIS, se veut lui plus générique et vise à décrire toutes les méta-données de n'importe quelle ressource. Google travaille depuis quelque temps déjà à un nouveau protocole, WebFinger, permettant de découvrir le profil public de quelqu'un à partir de son adresse mail. Bref, petit à petit le Web sémantique fait son nid et qu'un acteur de la taille de Google s'y mette de plus en plus est plutôt encourageant. (enfin, ce n'est pas une raison pour créer un compte GMail, le lancement de Buzz a montré une fois de plus et de manière plutôt éclatante le peu de de cas que Grand Frère fait de la confidentialité des données de ses otages).

Prix vacy

Daniel Lyons décrit comment les réseaux sociaux cherchent patiemment à vous faire oublier la valeur de votre vie privée, de vos informations intimes, pour que vous les leur confiez en échange de quelques services pratiques. Tristan a eu la bonne idée de traduire l'essentiel de l'article. Je ne suis que partiellement d'accord. L'important à mes yeux n'est pas tant de dénoncer l'usage que les réseaux sociaux font de nos données que d'être sûr de l'honnêteté du contrat. Or le contrat ne peut être honnête que si les deux parties sont pleinement conscientes de toutes ses implications, des bénéfices mais aussi des dangers, bref si leur consentement est éclairé. Ensuite, chacun et chacune fait ce qu'il veut de son corps, choisit de le monnayer ou pas, et si oui décide de sa valeur. On monnaye bien déjà, pour la plupart d'entre nous, nos vies en fournissant un travail en échange d'une rémunération ^[1], il est tout à fait concevable dans la société marchande actuelle de monnayer également nos intimités, nos relations, etc. Un problème plus pertinent est celui de nos données exploitées à notre insu, sans notre consentement. Ainsi pour ma part je refuse d'utiliser Facebook, Gmail, MSN, etc. C'est mon choix. Mais lorsque je discute avec un correspondant utilisant une adresse de messagerie (courrier ou instantanée, Facebook est en bonne voie pour proposer les deux) chez Facebook, Google ou Microsoft, ces sociétés collectent des données sur moi, sans que j'ai signé le moindre contrat avec elles, parfois même à mon insu lorsque j'écris à une adresse en ignorant qu'elle est redirigée vers un compte Gmail. Il y aurait là je pense matière à creuser et à se battre, contre cette collecte et cette probable utilisation déloyale de mes informations.

Facebook, nouvel AOL ?

Dans la série des traductions, le Framablog a la bonne idée d'en proposer une de l'article de Julianne Pepitone, End of the Web as we know it, thanks to iPad and others, sur la balkanisation en cours du Web, le retour à une situation déjà connue où la toile se fragmente en sous-réseaux ne communiquant pratiquement plus entre eux. En cause, les sites qui emprisonnent les contenus et les nouveaux périphériques qui cherchent à les verrouiller. De plus en plus d'informations qui hier auraient été publiques sont aujourd'hui publiées sur Facebook et accessibles uniquement de celles et ceux qui y ont un compte. On a par exemple beaucoup glosé sur une ministre qui utilise Facebook, y compris pour défendre son action publique, mais comme je n'ai pas de compte je n'ai pas accès à sa prose. L'inscription à FB et autres réseaux privés va-t-elle devenir obligatoire pour suivre et participer à la vie citoyenne ? Du côté des périphériques, les fabriquants poussent les développeurs à privilégier les applications natives à leur gadget plutôt que les applications Web universelles. Ainsi, des informations et des services vont être réservés aux otages d'Apple, d'autres aux utilisateurs d'Android, et dans les deux cas elles seront inaccessibles aux derniers clampins qui n'ont pas de mobiles. Cette nouvelle fragmentation est à mon avis une des menaces qu'il va falloir combattre en priorité ces prochains mois.

La bibi, la bibi, la bidouille

Encore un exemple sympathique de bidouille. Lire du contenu sur le Web n'est pas toujours simple : la fonte choisie peut être peu agréable, sa taille trop petite ou trop grande, les lignes trop longues... Heureusement, le Web, grâce à ses technologies ouvertes comme HTML et CSS, est bidouillable, et vous pouvez relativement facilement modifier la présentation des textes pour les rendre plus lisibles. Pour ma part j'utilise Firebug pour modifier directement les styles de la page, mais je viens de découvrir une petite bookmarklet, Readability qui fait cela bien mieux et plus facilement. Paramétrez sur le site le type de fonte, la taille, les marges, glissez la bookmarklet à l'endroit ad hoc et il vous suffira de l'appeler pour qu'elle re-formate une page. Simple, pratique, possible parce que le Web est libre est ouvert.

JS Rulez !

Si je devais me remettre à coder, c'est assurément vers JavaScript que je me tournerais, tant c'est de ce côté que je vois venir le plus de choses enthousiasmantes (en même temps, ma veille est orientée ) Il ne se passe pratiquement pas une semaine sans recevoir de faire-part annonçant la naissance de bibliothèques qui apportent à JS de nouveaux concepts sympathiques. Tout n'est pas neuf, bien sûr^[2], beaucoup de concepts sont importés d'autres langages, mais qu'importe, ce dynamisme fait plaisir à voir. J'ai notamment vu passer ces dernières semaines deux trucs qui semblent prometteurs, si quelqu'un avec un peu de temps pouvait y jeter un œil et poster sur le sujet, j'en serais ravi. Il s'agit de Promises et de Trait. Promises (promesse) est un concept de programmation pour faciliter la communication entre des traitements synchones et des traitements asynchrones. Bref, une situation courante en JavaScript et qui va le devenir encore davantage avec les WebWorkers HTML5. Le principe consiste à encapsuler le résultat attendu d'un traitement dans un objet, une promesse, contenant l'action à effectuer une fois que le résultat sera disponible. On peut ainsi code sans se soucier de savoir si la méthode appelée renverra un résultat immédiatement ou plus tard. Kris Zyp et Kris Kowal travaillent à la définition d'un standard pour les promises dans le cadre de CommonJS, et deux implémentations sont déjà disponibles, l'une pour NodeJS, l'autre pour Narwhal. De son côté, Trait est un mécanisme permettant d'implémenter un forme d'héritage multiple dans les langages qui n'en proposent pas. Il est similaire aux Mixins. Les Traits sont des ensembles de méthodes qui peuvent être ajoutées dynamiquement à un objet. Un objet pourra utiliser plusieurs traits et disposer ainsi de l'ensemble de leurs méthodes. La bibliothèque traits.js propose une implémentation de ce mécanisme en JavaScript.

Notes

[1] quoique avec l'extension des stages et du travail forcé en prison, entre autres, le curseur soit là aussi en train de bouger vers une dévalorisation de notre sueur;

[2] du côté de l'utilisation de Canvas j'ai l'impression de me retrouver 25 ans en arrière à l'époque du Basic et des ordinateurs 16bits;

L'avenir est encore à Pic de la Mirandole

Clochix — Sun, 20 Dec 2009 23:09:00 +0100

Mon rapide billet de la semaine dernière, pointant certains des dangers de Chrome, a eu certain succès, à l'échelle de ce blog, me rassurant sur le fait que je ne suis pas tout seul à m'inquiéter de l'ombre toujours plus grande de Google. Ca ne l'a évidemment pas empêché de continuer sa marche, par exemple en expérimentant des algorithmes adiabatiques sur un processeur quantique. Aujourd'hui c'est encore de la science-fiction, mais si ces recherches aboutissent l'informatique risque d'entrer dans une nouvelle ère et la perspective de créer une intelligence artificielle se rapprocher fortement. Rien d'étonnant donc que Marissa Mayer, vice-présidente chargée de la recherche et de l'expérience utilisateur, estime que Google pourra bientôt deviner ce que vous allez chercher et vous le présenter avant même que vous ayez formulé la requête.

Mais peut-être qu'une réponse aux légitimes inquiétudes que génère Google a été apportée il y a plus d'un demi-siècle. En 1953, Albert Ducrocq, un des pères de la cybernétique, inventa un "robot poète". André Parinaud, rédacteur en chef de la revue Arts, s'en inquiéta. Boris Vian le rassura d'une lettre titrée Un robot-poète ne nous fait pas peur parue dans le numéro d'avril 1953 de cette revue, et dont j'ai retrouvé cet extrait:

Le monde est au mains d'une théorie de crapules qui veulent faire de nous des travailleurs, et des travailleurs spécialisés, encore: refusons Parinaud. Sachons tout. Sachez ce qu'il y a dans le ventre de ce robot. Soyez un spécialiste de tout. L'avenir est à Pic de la Mirandole. Mirandolez, éclaboussez ce robot poète de vos connaissances en cybernétique, expliquez-lui comment il marche et vous l'aurez tout humble à votre merci. Pour faire tout ce que vous feriez-si l'on vous avait bien élevé- il faudrait qu'il pesât des tonnes, le pauvre. Alors laissez le venir et d'un ton méprisant, avec un regard de haut, lancez-lui : "Va donc, eh GROS robot !"
Pas un être sensible ne résista à ça, et un robot qui veut maigrir est un robot foutu, car il ne s'use pas, comme nous, dans la masse. Il devient faible, s'anémie, mais d'un coup: il se casse; et s'il se répare lui-même, les crabes aussi. Un dernier conseil: ne vous tourmentez pas. Quand le monde sera plein de robots, quoi de plus facile que d'en inventer un doté, par construction, de la haine de son espèce? Alors, tous transformés en Nérons aux mains blanches, nous jouerons de la lyre avec une ficelle et une boîte de conserves en regardant flamber à nos pieds les hangars où les robots se tordront dans les braises comme de présomptueuses fourmis, aux accents majestueux d'une chanson composée par un jongleur prodige de deux ans élevé dans les pattes d'une tigresse à l'abri du monde civilisé.
Votre serviteur dévoué: Boris Vian "

Cet appel me semble d'une brûlante actualité. Hier comme aujourd'hui, l'avenir est à Pic de la Mirandole, c'est à dire à l'honnête homme au sens classique, dont la culture constitue l'une des meilleures défenses.

Mais au delà de la question de l'arrivée des robots poètes et de leur descendant Google, ce texte résonne aussi avec d'autres travers de notre époque. J'ai un peu honte de faire le lien, et j'espère que Bison Ravi me pardonnera de le citer dans la même phrase que les médiocres que nous avons élevés au rang de dirigeants. Mais lorsqu'il parle de la théorie de crapules qui veulent faire de nous des travailleurs spécialisés, je ne peux m'empêcher de faire le lien avec les incessantes attaques contre l'éducation et la culture menées depuis des années par les gouvernements successifs. Attaques qui se traduisent par exemple ces derniers jours par de nouvelles suppressions de postes dans l'éducation et la décision de ne plus enseigner l'histoire dans les classes de terminales scientifiques. Attaques que résume par exemple Zébulonne, une enseignante lectrice du Monde dont je me permet de citer quelques phrases : (...)Que voulons-nous donc : une génération qui n'aura pas de dettes mais pas trop de tête non plus ? Il suffit bien que certains — les chefs — pensent ; ils diront aux autres ce qu'ils doivent faire — telle semble être la philosophie implicite de mon ministère. Les enfants de ceux qui ont un capital économique et/ou culturel pourront toujours aller se former dans des écoles privées où on leur apprendra le maniement de la langue qui permet éventuellement le maniement des autres, ou recevront à la maison les bases nécessaires à leur bon développement et à leur épanouissement personnel. (...) On sent désormais une lutte idéologique s'associer à l'objectif budgétaire pour supprimer ou diminuer l'influence de matières qui pourraient aider les élèves à réfléchir par eux même, c'est à dire contre l'idéologie dominante (...)

A vrai dire, les attaques contre l'apprentissage de l'histoire n'ont rien d'étonnant. L'histoire est la mémoire des vainqueurs, et ces temps-ci les vainqueurs se sentent si sûrs de leur fait qu'ils n'hésitent pas à la malmener et à la ré-écrire entièrement dans leur sens. Dès 2008, une cinquantaine d'écrivains dénonçaient Comment Nicolas Sarkozy écrit l’histoire de France. Deux exemples connus sont le cas de Guy Moquet, fusillé sur proposition de collabos français parce que son père était communiste et honteusement récupéré, et le fameux discours du 12 novembre 2009 à La Chapelle-en-Vercors, où Sarko n'hésite pas à proclamer Depuis deux cents ans, à part l'expérience sanglante de la Terreur, nul totalitarisme n'a menacé nos libertés. C'est que la culture française est irréductible au totalitarisme. Ce petit^[1] homme a décidément un problème avec l'histoire de la France entre 1939 et 1945. Il faut dire qu'il a un conseiller, Patrick Buisson, qui ne semble pas tout à fait avoir renié ses engagements de jeunesse à l'extrême droite et a une position pour le moins iconoclaste sur la période de Vichy. Mais après tout, à trop étudier l'histoire de fRance, si on n'omet pas d'y mentionner quelque rafle du Veldiv, quelques massacres du côté de Sétif, Madagascar, ou Paris, quelques grands succès des exportations d'un des principaux savoir-faire nationaux, la torture, à trop étudier dans son exhaustivité l'histoire de ce confetti sur la mappemonde, il pourrait se trouver moins de gens fiers d'avoir eu le hasard d'y naître — on a les fiertés qu'on peut —, et un peu plus pour établir des parallèles entre certaines politiques contemporaines et celles menées à d'autres époques. Or ces parallèles sont désormais en voie d'interdiction.

Contre les dangers de certaines avancées technologiques comme contre ceux de la réaction triomphante, nous n'avons pas trop le choix : mirandolons, mirandolons ! Ils voudraient faire de nous des consommateurs passifs, des marionnettes décérébrées, aculturées, tout juste bonnes à mettre dans l'isoloir le bulletin que l'on nous aura indiqué. C'est un destin tranquille, qui a l'avantage de ne pas demander trop d'effort. Mais si vous ne le trouvez pas satisfaisant, il va falloir que nous reprenions en main collectivement notre éducation, que nous échangions nos savoir, que nous nous entraînions notre esprit critique, notre dialectique. Que nous créions 1, 2, 3, de nombreuses Wikipédias et les améliorions sans cesse. Que nous en profitions aussi pour réhabiliter certains domaines depuis longtemps relégués aux marges des programmes scolaires. Imagine-t-on être autonome sans savoir réparer soi-même son vélo ou son ordinateur, sans savoir cuisiner ou créer un site Web ? Imagine-t-on être libre en ignorant l'Art ? Pourtant, à l'école de la République, l'Art et la Technique sont des citoyens de seconde zone (à l'image d'ailleurs du mépris de la société pour les artistes et les techniciens). Il est grand temps de permettre à chacun et chacune de découvrir la peinture, la mécanique, la cuisine, l'informatique, la musique... et la bidouille de Web, évidemment, je n'allais pas oublier mon obsession. Allons, tous ensemble, mirandolons, mirandolons !

Bon, allez, partez pas, je vous promet que mon prochain billet sera consacré à des geekeries !

Notes

[1] pas par la taille, même si elle a sans doute un rôle à jouer dans ses complexes je ne me permettrais pas de le moquer sur son physique. Petit comme synonyme de médiocre;

A propos de Google Chrome

Clochix — Sun, 13 Dec 2009 19:18:00 +0100

J'ai gazouillé hier soir être conscient de la dangerosité grandissante de Google et se ruer sur Chrome c'est comme défendre le libre et utiliser des produits Apple. @pscoffoni et @patcito ont engagé la conversation. Après avoir vainement cherché à répondre à mon tour en 140 signes, je me résous à le faire ici. Je re-contextualise pour ceux qui n'ont pas eu le temps de suivre l'actualité de la semaine : Google vient enfin de lancer les versions de Chrome pour GNU/Linux et pour Mac, et la transhumance des geeks commence, accompagnée de critiques dithyrambiques pour le produit de Google et de coup de pieds de l'âne à Firefox. J'ai une vue bien trop partielle pour oser prétendre qu'il s'agit d'une tendance, mais j'espère que ça ne le deviendra pas, et je vais essayer d'expliquer pourquoi.

Réglons ça tout de suite, je ne vais pas parler des qualité ou des défauts de Chrome d'un point de vue technique. Ce n'est pas ce qui m'intéresse aujourd'hui. Je ne l'ai pas encore testé. Je vais probablement l'essayer lorsqu'il sera disponible pour ma distribution, comme j'ai testé GMail, Wave et autres, mais quelles que soient ses qualités, je ne l'utiliserai pas et je déconseillerai son utilisation. Fidèle à mon crédo selon lequel la technique doit rester au service de la politique (en tant que science de la gestion des rapports au sein d'une société), la première des qualités d'un logiciel que je considère est la liberté qu'il procure à ses utilisateurs. Les qualités techniques sont certes importantes, mais de mon point de vue doivent s'effacer devant ce principe premier qu'est la liberté. Cette liberté peut être garantie par une licence comme la GPL, mais je suis depuis longtemps convaincu que placer un logiciel sous licence libre est nécessaire mais pas suffisant pour en faire un logiciel libre et libérateur.

Google et le logiciel libre

Alors oui, Google diffuse bon nombre de ses applications sous des licences libres. Ca peut les rendre sympathiques par rapport aux mastodontes du logiciel privateur que sont Microsoft, Apple, Oracle... Mais Google, à la différence de Microsoft, n'a jamais envisagé de gagner de l'argent en vendant des logiciels. Le cœur de son activité, ce sont les données, les collecter, traiter, organiser, restituer. Google a pour mission d'organiser les informations à l'échelle mondiale dans le but de les rendre accessibles et utiles à tous d'après leur propre présentation. Les logiciels ne sont qu'un moyen pour collecter toujours plus de données. Il faut donc que les logiciels soient distribués le plus largement possible. Et de ce point de vue, ils mettent toutes les chances de leur côté: leurs logiciels sont non seulement gratuits^[1], mais ils sont aussi libre, voire payés, au sens où dans certains cas Google rémunère les utilisateurs de ses produits en leur reversant une petite commission.

Libérer le code les rends sympathiques aux yeux des geeks qui, on l'a vu avec Firefox, sont prescripteurs. Libérer le code permet de désamorcer les accusations de "big-brother-isme" : vous pouvez utiliser votre propre version de Chrome ou d'Androïd, vous pouvez installer votre propre serveur Wave, donc Google ne cherche pas à contrôler vos données, peuvent-ils prétendre. En fait, cette libération est sans danger pour eux: de toute façon, ils contrôlent les évolutions du logiciel, et savent bien que seule un infime minorité d'utilisateurs utilisera les versions alternatives. Ils peuvent sans problème se passer sur la poignée d'irréductibles qui utiliseront Chromium, ChromiumOS, ou installeront leur propre serveur Wave. Leur trésor ce sont les données et accessoirement l'infrastructure, leur nuage. Ils peuvent bien libérer Wave, ou même Gmail et le reste de leurs applications. Tout autant que leur code, ce qui fait la richesse de ces applications c'est l'infrastructure technique sur laquelle elles s'appuient, et de ce point de vue peu de gens peuvent rivaliser avec eux.

Donc oui, Google édite des logiciels libres. Mais pour moi ces logiciels ne sont pas libérateurs en ce qu'ils visent avant tout à renforcer la position dominante de Google dans le monde des données.

#biggooglepartout

Apple et Microsoft sont des monstres dangereux, mais leur pouvoir reste limité à quelques niches (ok, de vastes niches). Aujourd'hui Google est en train d'embrasser l'ensemble du champs des technologies de l'information et de la communication, il va devenir de plus en plus difficile de lui échapper. Il est présent dans le matériel, le logiciel, les réseaux, et il dispose sans doute de la plus formidable base de données jamais conçue. Autant de pouvoir concentré dans les mains d'une seule entité, quelle qu'elle soit, est dangereux.

Google est vraiment partout. Depuis quelque temps, suivre leur actualité est devenu une activité à plein temps, ils font feu de tout bois et investissent l'ensemble du spectre des TIC. A ce rythme, demain on ne parlera plus d'informatique ni d'Internet, mais de Google. Google numérise tous les livres, donc ses cerveaux électronique accumulent peu à peu le matériel pour comprendre toujours mieux le fonctionnement de l'"âme humaine". Google cartographie la planète en tous sens, bientôt avec la montée en puissance des objets communiquants et de la vidéo ses data-center sauront tout en temps réel, aucun frémissement de la planète ne leur échappera. Google va sortir dans quelques jour leur propre smartphone, et je ne doute pas que des Netbooks ou des tablettes sous ChromeOS suivront. Google est fournisseur d'identité (via OpenID) donc demain c'est lui qui centralisera l'identifiant unique avec lequel on se connectera à tous les services, les siens ou ceux des prestataires qu'il n'aura pas encore racheté. Google vient de lancer ses DNS, Google avec SPDY veut remplacer HTTP (et l'arrivée des Web Socket dans Chrome pourrait bien accélérer les expérimentations de SPDY), Google milite pour l'ouverture des ondes radio pour ne plus dépendre des opérateurs de téléphonie, Google, Google... Je pourrais continuer longtemps à énumérer ainsi tous les domaines qu'il a décidé d'embrasser. Pour tout dire, tous les soir avant de me coucher je regarde sous mon lit pour vérifier qu'il n'y est pas encore. Ce qui ne saurait tarder.

Tout exercice du pouvoir corrompt...

(voix chevrotante) J'ai commencé à utiliser Mozilla (l'ancêtre de Firefox) bien avant sa version 1.0. A l'époque, je suis passé d'Opéra, un navigateur stable, puissant, bien fini, à un Mozilla encore bien buggué qui plantait régulièrement. Mais Opéra, malgré toutes ses qualités techniques, avaient deux gros défauts rédhibitoires à mes yeux : il n'était pas libre, et la version gratuite que j'utilisais affichait des publicités, potentiellement liées à ma navigation. Je n'avais pas envie qu'Opéra collecte des informations sur ce que je faisais, et je suis passé à Mozilla, même si c'était plus compliqué, s'il était moins stable et moins joli. Aujourd'hui, peu m'importe que techniquement Chrome soit plus rapide, plus léger ou plus hype que Firefox. Chrome fait partie de la galaxie Google, et je pense qu'il est plus que temps de freiner ce dernier avant qu'il ne devienne vraiment dangereux.

Dangereux Google ? Potentiellement oui. Etre partout n'est pas une fin en soi, ce n'est qu'un moyen pour accumuler toujours plus de données. Et Google enregistre chaque jour davantage d'informations sur chacun de nous, il en sait peut-être même plus sur nous que nous n'en savons nous-même. Qu'est-ce que je faisais à cet instant précis il y a un an ? Je n'en sais rien, mais Google, via l'historique de mes recherches et de mes navigations (grâce à Analytics), mes informations de géo-localisation, mes échanges sur Gmail, Gtalk, etc, etc, etc, Google lui le sait sans doute. Il a la possibilité de savoir à peu près tout ce que j'ai fait et dit publiquement, ces dernières années, les personnes que j'ai fréquentées, mes relations exactes avec elles, etc. Et pas à partir de déclaration publiques, mais par l'analyse de mes conversations privées, bon nombre de mes contacts utilisatant malheureusement GMail. Toutes ces informations lui donnent énormément de pouvoir. Un pouvoir aujourd'hui officiellement au service du bien. Toutes ces informations, il les utilise pour mieux me servir, pour apporter les réponses les plus pertinentes à mes questions, pour me faire des suggestions judicieuses, etc. Mais comment être sûr que demain il ne basculera pas du côté obscur de la force ? Qu'un changement dans son actionnariat ne le mettra pas aux mains d'un Moloch (qui rime avec...) avide d'utiliser ces informations pour asseoir son pouvoir ? Que dans certaines régions des lois ne l'obligeront pas à livrer ces informations à des gouvernements plus ou moins démocratiques pour traquer les déviants ? Une technique d'approche classique de la scientologie est son test de personnalité qui permet de détecter les faiblesses des futures victimes afin de commencer à les manipuler. Imaginez qu'une secte mette un jour la main sur tout ce que Google sait de vous (ne serait-ce qu'à la manière de tous ces simples flics qui consultent illégalement les fichiers de police). Même si je faisais confiance au Google actuel (c'est loin d'être le cas et les dernières déclarations d'Eric Schmidt ne sont pas pour me rassurer), comment être sûr que toutes les informations que je le laisse collecter sur moi ne se retourneront pas un jour contre moi ?

Responsabilité

C'est probablement une vision méprisante, mais je crains que pour beaucoup de geeks la technique soit une fin en soi. La "politique" a été tellement galvaudée (par ceux qui ne veulent pas qu'on s'en mêle afin de continuer à faire leurs petites affaires entre eux, mais c'est un autre débat) que nombre d'entre nous ont préféré l'évacuer, ou au moins la reléguer à la marge, ne pas en faire un élément central de leurs réflexions. De surcroît, la technique est une passion, devant laquelle la raison s'efface. On s'ébahit devant le dernier gadget et on s'empresse de l'adopter. On est certes conscients des problèmes qu'il pose (on n'est pas bête non plus), mais au nom du pragmatisme, d'un principe de réalité, on préfère fermer les yeux. Certes, chacun le fait à des degrés divers, c'est un principe de survie, refuser de fermer les yeux rendrait ce monde invivable. Mais il est certains sujets qui me tiennent à cœur et où cet aveuglement m'énerve au point d'aller déverser ma bile sur mes pauvres followers qui n'en demandaient sans doute pas tant.

En tant que geeks, je pense que nous avons une responsabilité. Comme la technologie est notre passion, nous somme mieux informés des bouleversements en cours, et donc peut-être mieux à même de prendre conscience de leurs enjeux. Comme la technologie est notre passion, nos proches nous font confiance sur ces sujets, écoutent nos conseils. Va-t-on les jeter dans les bras de Google, simplement parce que son navigateur serait le plus performant, et en fermant les yeux sur les dangers sous-jacents, ou va-ton essayer de les informer sur le danger potentiel de Google. Afin qu'ils fassent le choix d'utiliser ou non les services de Google, mais que ce choix soit conscient, raisonné. Donc avant d'inciter votre chat, votre panda ou votre poisson rouge à utiliser Chrome, GMail, Wave et consort, demandez-vous s'il ne risque pas de vous reprocher dans dix ans d'avoir abandonné sa vie privée entre les griffes d'un Grand Frère un peu trop omni-présent.

Suis-je un Nostradamus paranoïaque de comptoir ? Je l'espère, car je préférerais être Nostradamus que Cassandre.

Dernier point : franchement, entre un si mignon petit panda et la résurrection de Simon, comment pouvez-vous hésiter ?

PS: la sortie prochaine du Google Phone commençant déjà à buzzer très fort, il est bien évident que tout ce que je dis ici du navigateur de Sergey et Larry s'applique aussi à leur téléphone. Pas plus que Chrome ou l'iPhone, je n'inciterai mes contacts à utiliser ce terminal.

Notes

[1] certes les entreprises paient pour Google Apps, mais elles ne paient pas vraiment le logiciel, dont elles pourraient utiliser les versions grand public, elles paient quelques services supplémentaires

Commentaire sur l'introduction au De Viris Biduiabilitus

Clochix — Thu, 03 Dec 2009 00:49:00 +0100

Comme vous l'aurez peut-être remarqué, j'ai à nouveau dû reprendre le joug pour nourrir le crohonde en pizzas. Je n'ai donc hélas plus le temps de me tenir informé de l'actualité^[1] et de la partager, encore moins de me répandre ici, et ne parlons même pas de coder Malgré quelques tentatives je n'arrive toujours pas à me plier au diktat des 140c. Il faudrait que je trouve un système de mini-carnet où j'ose laisser de courtes ébauches de brouillons comme celle-ci, mais je n'ai encore rien vu de satisfaisant.

M'enfin, la bidouillabilité est un sujet qui me tient à cœur, et comme Tristan lance une série sur le sujet je vais essayer de jeter ici au fur et à mesure quelques commentaires.

Notes

[1] mensonge, je vis accroché aux tubes de perfusion qui me tournent la tête de gazouillis;

Dispute lexicale

La traduction de Hackability par Bidouillabilité fait débat. Pour ma part je défend mordicus ce choix. D'abord parce que j'ai été un des premiers à proposer cette traduction, dans mon billet sur le Web Libre, et que je suis très fier que le mot ait plu. Mais aussi parce que sur le fond, la bidouille est encore aujourd'hui ce qui décrit le mieux ce que je défend. J'associe la bidouille (ou le bricolage, mais le mot est moins poétique) à l'amateurisme. Mais pas amateurisme au sens péjoratif qu'il prend dans la bouche des professionnels, plutôt l'amateurisme au sens d'appropriation d'une discipline par tout un chacun, sans diplôme mais avec plaisir. Car c'est bien cela que je veux : que la création informatique, la programmation, ne soit plus réservée à une "élite" qui décide pour les autres, mais accessible au plus grand nombre pour que chacun et chacune puisse s'en servir pour faire ce qu'ille veut. Au fond, c'est cela qui m'intéresse : que l'informatique ne devienne pas une technique aliénante mais qu'elle soit au contraire facteur d'émancipation, qu'elle ne serve pas à rendre l'homme esclave de ses machines et de ceux qui les maîtrisent, mais au contraire qu'elle l'aide à davantage prendre en main sa destinée^[1]. Plutôt que de zombis ingurgitant du rata élaboré par des experts professionnels je préfère rêver de foules d'amateurs éclairés bidouillant le Web. Comme une immense maison biscornue où chacun construirait son chez-lui.

Une histoire

Je saute impromptu à un beau billet de Karl paru au printemps, DIY, le Larzac numérique. Billet que j'adore, Pour son titre et sa conclusion. La conclusion se passe de commentaires: Si vous avez une idée, et que j'ai une idée, partageons les, nous serons chacun riche de deux idées. Mais c'est le titre qui m'intéresse ce soir. Car aussi bien DIY que Larzac inscrivent la bidouillabilité dans une longue histoire. L'idée n'est pas sorti avant-hier de la cuisse d'Internet, mais se rattache à une pratique d'avant même l'Epoch. Avec le DIY et le Larzac, elle entre en résonance avec la formidable vague d'espoir des années 60/70. Dans mes moments optimistes, je me dis que le Web^[2] est un lointain descendant des utopies d'alors, s'inscrit dans leur continuité, porte certains de leurs espoirs. Mais l'histoire de la bidouillabilité prend sa source bien avant. Depuis toujours, ceux qui n'ont pas les moyens d'acheter le nécessaire ni le superflu le bricolent avec les moyens du bord. Détournent ou adaptent tout ce qui leur passe sous la main. Bidouillent. Les bidouilleurs de Web d'aujourd'hui sont les dezcendant de tous les bricoleurs qui avec trois bouts de ficelle ont amélioré la vie ou créé des chef-d'œuvre. C'est du moins un héritage que je revendique^[3].

Une question

Et j'ai ici un problème. Je pense que ce qui depuis longtemps motive le bricolage c'est à la fois la nécessité et l'amour de la belle ouvrage. Je laisse de côté le second terme, important mais dont je ne sais que faire pour l'instant. Reste la nécessité. Fabriquer soi-même ce qu'on ne peut acheter, cela tombe sous le sens. Pour survivre ou refuser sa condition. Mais aujourd'hui la donne a changé. Le logiciel est une denrée abondante et gratuite, voire moins que gratuite^[4]. Ce qui manque, c'est le matériel et la connectivité. Alors on bricole pour avoir un ordinateur, on joue du fer à souder pour récupérer des composants, on jongle avec des brics et des brocs de récupération. On bidouille pour se connecter à Internet. On tire des câbles, on installe des antennes, on renifle les ondes. On invente plein d'astuces. Mais sur le front des logiciels et des services, il n'y a à première vue plus de nécessité: ils sont disponibles gratuitement et en abondance. Sans nécessité apparente, le bidouillage peut-il se développer ? Je suis pour ma part bien conscient de la fragilité de ces acquis, des guerres sans merci qui se préparent pour le contrôle du Web, des données et des périphériques d'accès, et de la nécessité de renforcer les logiciels et les services libres et bidouillables. Mais ce besoin nous sommes trop peu nombreux à le ressentir. Voilà le problème sur lequel je bute depuis des mois : comment faire prendre conscience de cette nécessité ? La bidouillabilité que la fondation Mozilla met au cœur de ses produits rend possible^[5] la créativité, l'appropriation, la personnalisation, l'extension ou le détournement des outils. Mais il manque l'aiguillon déclencheur. Aussi, Tristan, ô nôtre Guide, telle est l'angoissante question à laquelle j'espère que tes billets apporteront des éléments de réponse : la bidouillabilité, ok. Ce qu'elle est, pourquoi elle est importante, comment la développer, ok. Mais comment faire pour que les individus qui vivent en dehors de la geekosphère s'en emparent ??? En jouant des percussions, certes, mais encore ?

Fermeture des commentaires le 2010.01.07 pour cause de spam

Notes

[1] toujours les outils conviviaux d'Ilitch, sur lesquels ma réflexion n'a pas progressé d'un iota, il faut dire à ma décharge que peu de gens gazouillent sur le sujet;

[2] et le Logiciel Libre, mais dans ce cas la filiation est évidente;

[3] et une revanche de celui qui n'a jamais été capable IRL de planter un clou sans finir aux urgences;

[4] aparté, si vous ne l'avez pas encore lu je vous conseille ce billet de Bill Gurley sur Google et son modèle économique du "less than free";

[5] Firefox, créateur de possibles, en voilà un joli slogan marketing ;

Bon anniversaire petit panda roux

Clochix — Mon, 09 Nov 2009 00:00:00 +0100

Voici cinq ans que sur les épaules du dinosaure rouge le phœnix est renait de ses cendres, l'oiseau de feu a pris son envol, accouchant d'un mignon petit panda roux qui aujourd'hui symbolise l'espoir d'un Web libre et ouvert. Cinq années qu'il combat Mammon et pourchasse ses séïdes bleus. Cinq ans qu'il a ébréché le mur et qu'il continue brique par brique à briser tous les murs et à poser les fondations d'un monde nouveau. Après tout, les murs ne sont là que pour être détruits et ça se saurait si on aimait le bleu. Bon anniversaire Firefox, merci à toute la communauté Mozilla pour ces cinq dernières années et plus, et j'espère pouvoir te souhaiter ton 10° anniversaire avec le même enthousiasme !

Avec Jetpack, si tu sais cuisiner un site Web, tu peux aussi bidouiller Firefox

Clochix — Sun, 08 Nov 2009 17:03:00 +0100

Si tu sais cuisiner une page Web, tu peux créer une extension pour Firefox. Ainsi pourrait être résumée la philosophie de Jetpack, un projet actuellement développé par les Laboratoires Mozilla et qui devrait devenir d'ici un an la base du nouveau mécanisme d'extensions de Firefox 4. Le but est de permettre à tout développeur Web de pouvoir bidouiller Firefox sans devoir apprendre un nouveau langage. Petit tour d'horizon à l'occasion de l'arrivée de la version 0.6

Simplifier le bricolage de navigateur

Il n'y a à vrai dire pas beaucoup de différences entre Firefox et une application Web riche. Les deux reposent sur quatre technologies:

un langage de description d'interface: HTML dans un cas, XUL dans l'autre, mais les deux sont de proches cousins. XUL est juste un peu plus spécialisé, fournit plus d'éléments d'interface riche que HTML^[1];
des feuilles de styles pour gérer le rendu. Ce sont exactement les mêmes. Un thème Firefox n'est qu'un ensemble de feuilles de style et d'images. Personas, intégré à Firefox 3.6, en est une illustration : on peut modifier le look de son navigateur aussi simplement que celui d'un site Web avec Stylish;
JavaScript, un langage pour rendre le tout dynamique et interagir avec l'utilisateur;
une plate-forme offrant des fonctionnalités de bas niveau et s'occupant de mettre en musique les trois précédents composants. Dans le cadre d'une application Web, cette plate-forme est le navigateur. Dans le cadre de Firefox, c'est son moteur interne, XulRunner. Mais en fait, c'est la même chose, puisqu'au cœur de Firefox, le même moteur s'occupe aussi bien de l'affichage du Web que de l'interface du navigateur.

La principale différence entre une application Web et Firefox, c'est le langage de description d'interface. Mais avec les évolution de HTML et des bibliothèques de composants JavaScript, HTML peut remplacer XUL dans de nombreux cas. Au passage, Flex d'Adobe utilise exactement la même pile : MXML, un cousin de XUL, CSS, ActionScript (grand frère de JavaScript) et le lecteur Flash comme moteur.

Dès lors, étendre Firefox ne devrait pas être beaucoup plus difficile que développer une application Web, et à la portée de quiconque a des notions de HTML, CSS, JavaScript. En étudiant les extensions les plus populaires sur AMO, des membres des MozLabs se sont aperçu que la vaste majorité ne faisait pas d'appels complexes à des composants bas niveau de la plateforme, et n'avaient pas besoin de toute la puissance du mécanisme actuel d'extension, puissance qui se paie par une petite complexité : même si réaliser une extension n'est pas très compliqué, cela nécessite un apprentissage, aussi bien de nouvelles techniques que d'un environnement de développement spécifique. Jetpack est là pour abaisser cette barrière, rendre beaucoup plus facile, accessible, l'ajout de nouvelles fonctionnalités à Firefox. Il proposera une alternative pour bricoler facilement son navigateur. A terme, le but est que la majorité des extensions utilise cette architecture, le système actuel restant bien sûr disponible pour les développeurs ayant besoin de fonctions plus poussées.

Ainsi, Jetpack permettra à n'importe quel développeur Web d'étendre son navigateur en utilisant les outils qu'il connaît : HTML, CSS, JavaScript, JQuery et Firebug. L'environnement est familier, tout se passe dans Firefox, les mises à jour sont instantanées sans relancer le logiciel. Par ailleurs, JetPack devrait également apporter un gain de sécurité: actuellement, toutes les extensions disponible sur AMO sont contrôlées afin de s'assurer qu'elles ne contiennent pas de code malveillant. C'est un travail long et fastidieux. Jetpack devrait simplifier ce travail, et augmenter le nombre d'internautes qui auront les compétences pour lire le code et s'assurer de son innocuité.

Premiers pas

L'architecture est très similaire à celle de GreaseMonkey : des scripts chargés depuis une page Web s'exécutent dans un bac à sable et interagissent avec le navigateur via une API.

Attention, Jetpack est en plein développement, et certaine des informations indiquées ici seront sans doute obsolète dans quelques mois. Même si les versions se succèdent assez vite, Jetpack est encore assez instable. Il peut ne pas fonctionner avec certaines versions de Firefox, avoir des problèmes de compatibilité avec certaines versions de Firebug, et planter avec certains OS. Comme il embarque des binaires, par exemple pour la gestion de l'audio et de la vidéo, vous risquez d'avoir des soucis sous GNU/Linux en 64bits. C'est parfois frustrant, j'ai eu du mal à le faire fonctionner, mais je suis content de m'être acharné. Par ailleurs, Jetpack étant codé en JavaScript, on peut facilement accéder au code pour comprendre comment il fonctionne et le patcher. Les modifications elles-mêmes sont prises en compte instantanément. Les extraites que je donne plus bas ont été testés avec Jetpack 0.6 alpha et Iceweasel 3.5.3 sous Debian GNU/Linux^[2].

Une fois Jetpack installé, vous accédez à sa tour de contrôle en tapant about:jetpack dans la barre d'url. Vous deviez avoir quelque chose comme ça:

Si les onglets ne s'affichent pas, c'est qu'il y a un problème, regardez la console d'erreur, allez faire un tour dans le code ou viendez sur IRC.

Les deux principaux onglets sont le 2° et le 3°:

Develop fournit un éditeur où développer votre code. Attention, contrairement aux apparences ce n'est pas encore Bespin mais une simple textarea^[3];
Intalled Features liste les extensions installées et vous permet de les gérer.

Une fois votre script développé, il ne vous reste plus qu'à l'installer. Pour cela, rien de plus simple, comme pour une commande Ubiquity il vous suffit de créer une page HTML contenant un lien vers le fichier : <link rel="jetpack" href="toto.js">. En visitant cette page, Firefox vous proposera d'installer l'extension.

L'API

Toutes les fonctions de Jetpack sont regroupées dans un seul objet, qui sert d'espace de nom de base. On appelle ensuite les propriétés et les méthodes des modules disponibles. Par exemple, on obtiendra l'onglet courant avec jetpack.tabs.focused, soit la propriété focused du module tabs. Pour l'instant, une dizaine de modules sont déjà disponibles "en standard", qui ne cessent de s'enrichir. Les plus intéressants sont:

jetpack.info permet d'obtenir des informations sur le système;
jetpack.json pour encoder et décoder des données en JSON (euh, pourtant c'est implémenté nativement depuis FF 3.5 ?);
jetpack.notifications.show(message) affiche une notification;
jetpack.tabs permet d'intéragir avec les onglets du navigateur : obtenir l'onglet courant, ouvrir une page dans un nouvel onglet, et attacher des fonctions à des évènements. On pourra par exemple obtenir le document en cours avec jetpack.tabs.focused.contentDocument;
jetpack.statusBar.append(obj) pour ajouter des objets à la barre de status;
jetpack.sessionStorage enregistre des informations dans la session.

Outre jetpack, quelques autres objets sont disponibles dans le bac à sable, les plus utiles étant jQuery et console, un dérivé de la fonction du même nom de Firebug. Jetpack utilisera la console de Firebug s'il la détecte, ou à défaut celle du système.

Extensibilité

Jetpack est prévu pour pouvoir être facilement étendu avec des bibliothèques tierces. L'espace de nom jetpack.lib est réservé pour cet usage. A titre d'exemple, une bibliothèque de communication avec Twitter est déjà fournie. Ces bibliothèques peuvent elle-même communiquer avec des composants binaires externes, via un système de membranes.

Le futur

Jetpack veut être à la fois une plate-forme stable et un lieu d'expérimentation. Comme en Python, on peut donc utiliser des fonctionnalités expérimentales en les important. Elles resteront dans cet espace le temps que leur API se stabilise. La JEP 13 définit une syntaxe très simple:

jetpack.future.import("toto");
var titi = jetpack.toto.tata();

Une vingtaine de modules sont en travaux, n'hésitez pas à participer à leur élaboration ou si vous ne trouvez pas votre bonheur, à proposer une JEP. Voici un petit tour de quelques fonctionnalités en cours d'implémentation:

La slidebar

La slidebar est une réinvention de la sitebar qui existe depuis très longtemps. Pour l'instant on y accède via une petite flèche à gauche du premier onglet. Les slides se présentent comme des onglets verticaux: Elle peut contenir de nombreux slides. Chacun est un simple objet que l'on ajoute à la barre. Par exemple:

jetpack.future.import("slideBar");
jetpack.slideBar.append({
  icon: "", // URL de l'icône
  html: "", // contenu du slide
  url: "",  // pour charger le contenu depuis une URL distante
  width: 300, // largeur du slide
  persist: true, //
  autoReload: true, //
  onClick: function(slide){},
  onSelect: function(slide){},
  onReady: function(slide){}
});

Du multi-média

Le module audio permet d'accéder au micro de l'ordinateur. Le résultat est soit enregistré dans un fichier au format OGG/Vorbis, soit accessible sous forme de flux. Le module vidéo en fera de même pour la vidéo. Quant à Music, il permettra d'accéder aux fichiers multimédias locaux, en fonctions des interfaces de chaque système d'exploitation (par exemple iTunes sur Mac). On pourra par exemple demander à Firefox de jouer l'Hymne avec ces simples lignes:

 jetpack.future.import('music');
 let tracks = jetpack.music.search('Free Software Song');
 jetpack.music.playTrack(tracks0);

Et le stockage local ?

Jetpack implémentera plusieurs moyens pour enregistrer des données. Un premier, live, permet déjà d'enregistrer des données dans la session (mais qui seront perdues au redémarrage):

jetpack.storage.live.myData = {hello: "world"};

Pour enregistrer localement tout type de données, un premier module est en cours de développement. C'est une simple base de clés/valeur :

jetpack.storage.simple.prop1 = "toto";
jetpack.storage.simple.prop2 = {a: 'b', b: 'a'};
jetpack.storage.simple.prop3 = [1, 3, 3, 7];

Jetpack 0.6 offre les débuts du module de gestion des paramètres, défini par la JEP 24. L'implémentation est balbutiante, mais la spécification prometteuse: il suffit de déclarer au début de votre script un manifeste décrivant les paramètres. Jetpack créera automatiquement la boîte de dialogue pour les gérer (accessible depuis la liste des extensions installée):

 var manifest = {
   settings: [
     {id:"autosave",
      type:"range",
      label:"Autosave",
      min: 10,
      max: 600,
      default: 30
     }
   ]
 };
 (...)
 var toto = jetpack.storage.settings.autosave;

Je pense que d'autres modules de stockage devraient rapidement voir le jour, par exemple pour s'interfacer avec des base SQLite ou CouchDB.

Et encore

la JEP 10 définit l'accès au presse-papier via des getter/setter;
on accède à la sélection via le module jetpack.selection décrit par la JEP 12;
pageMods permet d'associer des scripts à des pages, en fonction d'expressions régulières, comme avec GreaseMonkey;
enfin, grosse nouveauté de la 0.6, la gestion de menus qui permet très facilement de rajouter des items dans la barre de menu ou le menu contextuel. Rajouter une action dans le menu contextuel des images est aussi simple que:

jetpack.menu.context.page.on('img').add(function(context)({
  label: "Mon menu",
  command: function(target) {}
}));

Allez voir la vidéo de présentation dans l'annonce de la sortie de la 0.6. Elle est assez bluffante !

A venir

D'autres JEP sont en cours de rédaction. Par exemple pour gérer les barres d'outil. Et bien sûr, chacun est invité, s'il ne trouve pas son bonheur dans l'API existante, à écrire une proposition et une implémentation d'exemple.

Assez causé, du code !!

Quelques bouts de code pour vous donner une idée de sa simplicité. Jetpack permet vraiment de faire beaucoup de choses en quelques lignes. Pour tester différents modules, j'ai commencé à coder une extension stockant des extraits de pages dans la slidebar. Ce sont mes tâtonnements, un travail en cours juste pour apprendre, donc pas très propres ni au point. Pour en voir plus, vous devriez allez jeter un œil aux nombreuses démos disponibles sur le site. Une galerie devrait également voir le jour très prochainement.

On commence par importer tout ce dont on aura besoin. A terme, une fois que l'API de ces modules sera figée, ils seront disponibles par défaut et on pourra se passer de cette phase

 jetpack.future.import("menu");
 jetpack.future.import("selection");
 jetpack.future.import("slideBar");
 jetpack.future.import("storage.settings");
 jetpack.future.import("storage.simple");

Le manifeste décrivant les paramètres de l'extension. Jetpack va créer automatiquement une fenêtre de configuration. En l'état actuel, elle n'est pas encore complètement fonctionnelle. J'utilise ici un range, nouveau type de champ de formulaire défini par HTML5.

 var manifest = {
   settings: [
     {id:"autosave", type:"range", label:"Autosave", min: 10, max: 600, default: 30 }
   ]
 };

On crée d'un slide dans la slidebar. Pour ne pas surcharger le code, le HTML correspondant est dans un fichier à part, qui contient en outre quelques fonctions Javascript pour gérer les extraits. (le code du slide contient un <div id="accordion"></div> à l'intérieur duquel je stocke les extraits). J'utilise ici le stockage local pour initialiser le slide en rechargeant les extraits précédemment enregistrés, et je déclenche une sauvegarde régulière, le délai entre deux enregistrements étant défini dans les paramètres.

 var slider = jetpack.slideBar.append({
   url: "snips.html", // la description est dans un fichier séparé
   width: 500,        // largeur du slide
   persist: true,     // pour qu'il reste ouvert
   autoReload: false, // on ne recharge pas son contenu à chaque fois
   onReady: function(slide){ // fonction appelée à la création du slide
     current = slide;
     var doc = current.contentDocument;
     // on recharge le contenu depuis le stockage local :
     $('#accordion', doc).html(jetpack.storage.simple.content);
     // fonction pour sauvegarder périodiquement le contenu de la diapo
     interval = setInterval(function(){
         jetpack.storage.simple.content = $('#accordion', doc).html();
       }
       , jetpack.storage.settings.autosave);
   }
 });

On ajoute à présent un item dans le menu contextuel pour créer un extrait à partir de la sélection:

 jetpack.menu.context.page.add(function(context)({
   label: "Create snippet",
   command: function(target) {
     // on appelle une méthode pour enregistrer l'élément courant
     // dans une nouvelle diapo
     // la variable current référence notre slide
     // astuce : pour accéder aux objets JS définis dans le code HTML
     // de la diapo, il faut utiliser wrappedJSObject
     current.contentDocument.defaultView.wrappedJSObject.accordionize(jetpack.selection.html, context.document.location.href, null, 'Snippet');
     // on sauvegarde le nouveau contenu du slide
     jetpack.storage.simple.content = $('#accordion', current.contentDocument).html();
   }
 }));

Et c'est tout !

Je me suis amusé à proposer une méthode alternative de sélection de contenus : en cochant une case dans la barre de status, la page passe en édition, c'est à dire qu'on peut créer un extrait à partir de tout élément possédant un identifiant. Voici le code pour ajouter une case à cocher dans la barre de status:

 jetpack.statusBar.append({
   html: 'Snip <input type="checkbox" />',
   onReady: function(widget){
     // lorsqu'un onglet est sélectionné, on décoche la case
     jetpack.tabs.onFocus(function(){
       $("input", widget).attr('checked', false);
     });
     // Gestion du click de la case
     $("input", widget).click(function(){
       // recherche de tous les éléments qui ont un id
       var elmts = $(jetpack.tabs.focused.contentDocument).find('*[id]');
       if( this.checked ){
         elmts.bind('mouseenter', snipable);
       } else {
         elmts.unbind('mouseenter', snipable);
       }
     });
   }
 })

Ca n'a rien à voir avec Jetpack, mais voici juste le code de la fonction utilisée pour sélectionner les éléments:

 function snipable() {
   var elmt = $(this);
   var css = elmt.css('border');
   elmt.css('border', '1px solid red');
   elmt.bind('mouseleave', function(){
     $(this).css('border', css).unbind('mouseleave').unbind('dblclick');
   }).bind('dblclick', function(e){
     e.stopPropagation();
     console.log('click : ' + elmt.attr('id'));
     if (current) {
       current.slide();
       current.contentDocument.defaultView.wrappedJSObject.accordionize(elmt.html(), tabs.focused.url, null, 'Snippet');
     }
     return false;
   });
 }

Et pour installer mon extension, un simple fichier HTML suffit. Si votre extension nécessite d'autres fichiers, référencés dans le script, ils devront être situés au même endroit que le script (pour ce que j'en ai compris, Jetpack cache dans une base SQLite locale les extensions installées. Au moment de l'installation, il vous demande s'il doit se connecter régulièrement au serveur pour récupérer des mises à jour)

 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr">
 <head>
   <title>Snips</title>
   <link rel='jetpack' href='snips.js' />
 </head>
 <body></body>
 </html>

Bon, ça suffit maintenant monsieur

Techniquement, je trouve Jetpack moins révolutionnaire qu'Ubiquity. Ce n'est au final qu'un Greasemonkey complètement intégré à Firefox. Certes très bien intégré, mais le concept n'est pas neuf (le mécanisme d'extensions de Chrome est je crois bâti sur le même modèle). Je ne peux donc m'empêcher de regretter que ce mariage de GreaseMonkey et du Panda n'ait pas eu lieu plus tôt. Car l'idée est excellente et surtout impressionnante de puissance et de simplicité. C'est je crois cette simplicité qui provoque réellement une rupture et mon enthousiasme. Tout développeur Web connaissant JavaScript peut réellement bidouiller le navigateur en quelques minutes. La technique s'efface de plus en plus, pour laisser chacun faire ce qu'il veut de l'outil, pour en démultiplier les possibilités. Et Jetpack est un beau terrain de jeu pour réfléchir et expérimenter de nouvelles pistes pour rendre le bidouillage de Web toujours plus simple, toujours plus accessible à de plus en plus d'internautes. Au final c'est bien ça qui compte. Bon alors, qu'est-ce que vous attendez pour aller essayer ?

Notes

[1] à vrai dire, HTML n'est pas fait pour décrire des interfaces mais des documents. Malheureusement, aucun autre langage spécifique pour les interfaces n'ayant été normalisé, il a été utilisé par défaut et s'est imposé. HTML5 valide cette évolution;

[2] à noter que Jetpack étant prévu pour fonctionner avec toute application basée sur XulRunner, un test est pour l'instant réalisé "en dur" pour différencier Firefox et Thunderbid. Si vous utilisez des variantes portant d'autres nom de ces logiciels, comme par exemple Iceweasel, il vous faudra modifier le fichier modules/xulapp.js situé dans le répertoire de l'extension.

[3] Bespin n'est pour l'instant activé que dans la version Mac OS X, mais j'ai réussi à la faire fonctionner sans trop de problèmes sous Nunux.

Windows 7, dernières nouvelles du minitel

Clochix — Thu, 05 Nov 2009 11:45:00 +0100

Pour moi, la sortie de Windows Seven est un non-évènement. Je m'en fous, et j'ai l'outrecuidance de penser que si la presse n'avait fait un tel battage tout le monde s'en foutrait aussi. Mais bon, Microsoft a parait-il déclenché la campagne de propagande la plus chère de son existence^[1], et la presse a bien besoin de cette manne. Donc on a bouffé du Seven, et encore, je pense avoir eu beaucoup de chance, comme je n'ai pas la télé, surfe protégé par AdBlock et n'ai pas mis le nez dehors depuis longtemps, j'ai dû être relativement protégé de la déferlante.

Notes

[1] je n'arrive plus à retrouver les chiffres, si quelqu'un pouvait me les fournir...

Car au final, qu'apporte Windows 7 ? Des corrections d'erreurs pour faire oublier Vista qui devait corriger les erreurs de XP qui devait faire oublier Windows Millenium (je vous laisse reprendre votre souffle, je sais que ce mot déclenche toujours l'hilarité), et cætera et ad nauseam. Le refrain est connu^[1]. Mais à part ça ? Je veux dire, quelles nouvelles fonctionnalités susceptibles de vraiment améliorer la vie des utilisateurs de PC ? Et plus globalement, que s'est-il passé au niveau des systèmes d'exploitation ces 15 dernières années ? A part des mises à jour esthétiques, je ne vois pas grand chose. L'ergonomie a évolué, mais à part ça... c'est surtout la progression tranquille du matériel qui a permis d'avoir des machines toujours plus puissantes et donc capable de réaliser des traitements toujours plus complexes. Les OS ont suivi, mais sans apporter grand chose. Je caricature, bien sûr, mais pas tant que ça^[2].

En fait, il y a eu deux révolutions ces dernières années: le Web et le mobile. Le mobile en est à ses balbutiements, et je ne connais pas assez le sujet pour l'évoquer. Je remarque juste que Microsoft en est absent. Ils se contentent d'essayer d'adapter leurs vieilles recettes, leur OS du XX° siècle, sans comprendre que quelque chose a changé. Et manifestement ça ne marche pas.

Le Web par contre je peux en parler. Le Web est peu à peu en train de prendre le pas sur les systèmes d'exploitations d'hier. Demain, le Web lui-même sera l'OS. Désormais, le logiciel que j'utilise le plus est mon navigateur. Il remplace peu à peu tous les logiciels de niche installés sur le PC. Pour communiquer j'utilise un webmail, une messagerie instantanée en ligne, des sites de réseaux sociaux. Les logiciels bureautiques en ligne suffisent largement à mes besoin, la retouche photo ou le traitement de vidéos en ligne progressent sans cesse, j'écoute de la musique en ligne, je regarde des vidéos dans mon navigateur, la 3D arrive à présent et même les jeux pourraient bien d'ici quelques années être uniquement en ligne. Certes cette évolution n'est pas sans poser de nombreuses questions, mais c'est un fait : elle est là et je doute qu'elle reflue de sitôt. Aujourd'hui, le navigateur est bien plus important que le système sur lequel il s'exécute. Et une fois de plus, Microsoft est complètement absent de ce nouveau terrain. Ils n'ont jamais cru au Web, ont fait beaucoup pour le saborder, ne s'y sont investis que pour couler un concurrent, Netscape, avant de le déserter. Leurs navigateurs sont des hontes, détestés par la majorité des professionnels du Web. Ils commencent tout doucement à mettre un pied timide dans le nuage, mais à reculons, en copiant ce que tout le monde fait depuis longtemps. Il faut dire qu'investir dans le Web reviendrait à condamner à mort leurs deux vaches à lait, Windows et Office, puisque le Web les rend obsolètes. Du point de vue de l'intérêt de ses actionnaires c'est un choix pertinent. Même sans plus rien investir dans leur développement, Windows et Office vont encore produire des dividendes pendant longtemps. Investir dans le Web reviendrait à assécher le flux qui les engraisse depuis des années. Mais c'est une vision à court terme, puisque le PC ne bureau tel qu'on le connaît n'a pas d'avenir.

L'avenir est en ligne, et très probablement dans la connexion universelle via des périphériques mobiles. Continuer à investir dans un OS pour PC de bureau est un combat d'arrière garde, comme celui d'un fameux opérateur de télécommunications qui a beaucoup misé sur un terminal qui avait fait son succès dans les années 80 sans réaliser que dix ans plus tard la donne avait changé et l'heure d'Internet avait sonné. D'un point de vue technologique, Windows Seven est un Minitel 2.1, ça n'apporte rien, ce n'est qu'une couche de peinture sur un produit qui a fait son temps. Personne n'en a besoin. Ce dont on a besoin aujourd'hui, ce sont d'outils pour libérer toute la puissance du Web et du Mobile. Et heureusement, ces outils d'autres sont en train de les fabriquer. Il y a par exemple un petit navigateur très sympathique à la mascotte trop mignonne et qui fête ces jours-ci son cinquième anniversaire^[3]...

En fait non, je n'ai pas été tout à fait honnête, la sortie de 7 ne me laisse pas si indifférent. Sa technologie m'indiffère, mais pas les méthodes utilisées pour la refiler. Je vieillis mais il me reste encore une petite capacité d'indignation, même si l'actualité quotidienne l'use sans cesse davantage. Et comme beaucoup d'injustice, beaucoup d'escroqueries, ce non-évènement me rend colère et triste à la fois. Colère et triste de voir que tant de mes concitoyens vont encore se faire arnaquer, se faire refourguer contre espèces sonnantes et trébuchantes une daube dont ils n'ont nul besoin. En effet, bien que ça soit illégal, la vaste majorité de la population ne peut pas acheter un nouvel ordinateur sans se voir fourguer une nouvelle version du système d'exploitation. Pas moyen de conserver l'ancien qui suffisait largement à nos besoins : il faut ajouter au prix du matériel quelques centaines d'euros qui iront aider Bill Gates à fourguer des OGM Monsanto aux pays en voie de développement. La majorité des fabricants de matériel et des distributeurs sont complices de cette escroquerie. Essayez donc d'acheter un ordinateur nu parce que vous avez déjà une licence pour un OS à installer dessus. Cette arnaque dure depuis des années, a coûté des fortunes aux gens obligés d'acheter régulièrement des produits pour suivre les mises à jour du système et pallier ses failles. Mais comme l'escroc en chef est un ami du Président, il y a peu de chances que ça s'arrête de sitôt. Heureusement, la traite n'est pas une fatalité, si vous voulez éviter de vous faire avoir, si vous en avez marre de vous faire pomper les mamelles par Billou, renseignez-vous, en cherchant un peu on trouve des matériels parfaitement utilisables et non soumis à la dîme Microsoft. Et arrêtez de perdre votre temps à lire des articles sur Windows Seven !

Notes

[1] au fait, si Seven est essentiellement une correction des erreurs passées, pourquoi n'est-il pas fournis gratuitement aux possesseurs de Vista ? Pourquoi fait-il payer les corrections de défauts de fabrication imputables au constructeur ?

[2] au passage, cela vaut aussi pour l'autre cheval de bataille de Microsoft, la bureautique. Qui utilise vraiment les "nouveautés" introduites dans M$ Office au cours des 15 dernières années ? Est-ce que des fonctions réellement indispensables ont vu le jour depuis M$ Word 6 ? Je n'en ai pas l'impression.

[3] oui, je n'allais quant même pas écrire un billet sans citer Mozilla

Alléger l'interface de Firefox

Clochix — Fri, 30 Oct 2009 17:18:00 +0100

Depuis la sortie de Google Chrome, j'entend des gens vanter la sobriété de son interface et prendre celle-ci pour prétexte abandonner le gentil panda. L'interface par défaut de Firefox prend certes de la place, mais il suffit de réglages très simples pour la réduire au stric nécessaire et gagner de la place pour travailler. Voici par exemple comment en deux minutes, deux extensions et quelques réglages je personnalise mes navigateurs.

Dans la configuration initiale, l'interface du navigateur occupe 118px de haut:

Pour personnaliser tout cela, il vous suffit d'aller faire un tour dans le menu "Affichage / Barres d'outils / Personnaliser". Commencez par cocher la case pour utiliser de petites icônes. Lorsque la fenêtre de personnalisation est ouverte, vous pouvez déplacer le contenu des différentes barres d'outils. Prenez successivement tous les boutons et les zones de saisie de la barre de navigation, et glissez-les dans la barre de menu. Faites de même avec les marques-pages^[1]. Vous pouvez valider, puis désactiver, via le même menu, l'affichage des barres de navigation et de marques-pages. Vous voici avec une interface qui chez moi n'occupe plus que 57px:

Mais elle semble peut-être un peu chargée. Pour y remédier, j'utilise deux extensions:

Personal Menu permet de créer un bouton ouvrant un menu où l'on peut mettre ce que l'on veut. J'y stocke pour ma part tous les autres menus;
Omnibar pour fusionner la barre d'URL et le moteur de recherche.

Et le résultat:

En fouillant un peu sur AMO, vous trouverez sans problème d'autres extensions pour personnaliser à votre guise l'interface. Et si vous ne trouvez pas, soumettez l'idée.

Voilà, pas besoin d'attendre Firefox 4 pour avoir une interface allégée.

Notes

[1] petite astuce : j'ai créé dans la barre de marques-pages un dossier sans nom, et déplacé tous les autres dossiers à l'intérieur de celui-ci. L'ensemble des signets est donc représenté par une seule icône;

Outils pour bidouiller le Web

Clochix — Thu, 29 Oct 2009 16:14:00 +0100

A l'issue de mon envolée lyrique où je prédisais que demain le bidouillage de Web serait à la portée de tout le monde, Eric Mainville me ramenait judicieusement sur terre en me demandant d'être plus concret : Moi qui ne sait qu'écrire et pas du tout coder, comment faire ? Excellente question qui m'oblige à re-descendre de mon nuage et me frotter un peu à l'univers des !geeks^[1]. Voici donc une présentation de quelques extensions Firefox pour commencer à faire vôtre le Web, à jouer avec les pages, à les bidouiller.

Notes

[1] vous avez un terme ni péjoratif ni discriminant ?

Je ne parlerai ici que d'extensions pour Firefox. Parce que c'est l'univers que je connais le mieux. Parce que c'est le plus extensible et donc celui qui ouvre le plus de voies pour bidouiller. Et parce que c'est le seul navigateur libre et "grand public" disponible sous GNU/Linux.

Cette rapide présentation s'adresse à des gens qui n'ont pas ou peu de connaissances des technologies du Web. Malheureusement, un pré-requis pour utiliser la plupart de ces outils est généralement de lire un peu l'anglais technique, très peu de documentation étant disponible dans d'autres langues. Si vous avez des questions, n'hésitez pas à les soumettre en commentaire et je tâcherai de faire un peu de SAV pour ce billet. Enfin, pour vous permettre de télécharger rapidement les outils que je liste ici, je les ai regroupés dans une collection "Bidouille" sur AMO.

Ne dites plus couteaux helvète mais Firebug

Firebug est l'extension indispensable pour quiconque veut bidouiller le Web. Il contient tous les outils possibles pour étudier le Web et commencer à le bricoler. Malheureusement, comme il est très puissant, sa prise en main n'est pas évidente. Il se présente sous la forme d'une série d'onglets, affichés en bas de l'écran ou dans une fenêtre indépendantes. F12 est la touche magique pour le faire apparaître. Les deux premiers panneaux sont sans doute les plus utiles pour débuter.

Le panneau HTML présente dans sa partie gauche le code source de la page, sous la forme d'une arborescence, et dans sa partie droite différentes informations, en particuliers sur les styles de l'élément en cours. On peut sélectionner n'importe quel partie de la page courante pour voir son code source et ses styles. Mieux, les deux sont directement modifiables. On peut ainsi jouer en direct avec la page, expérimenter, voire comment certaines modification du code l'impacteraient, etc. Les modifications ne peuvent pas être enregistrées, et sont perdues lorsqu'on recharge la page. C'est un outil idéal par exemple pour s'initier aux feuilles de style, puisqu'on voit instantanément les effets de chaque modification. Ces modifications peuvent ensuite être rendues permanentes via d'autres outils.

L'autre panneau très utile est la console qui permet dans sa partie de gauche de créer et d'exécuter du code JavaScript, en affichant dans la partie de droite le résultat. Idéal pour mettre au point des scripts.

Extension indispensable, Firebug demande cependant du temps pour être prise en main. Pour débuter, je vous conseille de commencer avec des outils à l'interface plus simple. Mais quel que soit votre niveau, Firebug sera un compagnon utile.

A portée de clic

Commençons donc par une série d'outils ne nécessitant aucune connaissance particulière. Quelques clics suffisent pour supprimer des éléments inutiles ou gênant, ou réarranger une page.

RIP et Aardvark

Remove It Permanently est sans doute la plus simple des extensions pour commencer à personnaliser votre Web. Elle permet tout simplement de masquer définitivement des éléments dans une page. Gêné dans votre lecture par des animations dans une colonne à côté des articles de votre site favori ? Sélectionnez la colonne et demandez à RIP de ne plus l'afficher pour l'ensemble du site. Malheureusement, sélectionner précisément l'élément à supprimer n'est pas toujours évident. RIP offre donc un mode avancé où vous pouvez indiquer les élément à supprimer via leur XPath. XPath est une syntaxe permettant (entre autre) de désigner des fragments d'une page Web. Elle est assez ardue, et si vous souhaitez vous y initier, je vous conseille FireXPath qui vous permet de connaître le XPath d'un élément en le sélectionnant avec Firebug. Mais pour les situations plus complexes, mieux vaut vous tourner vers Aardvark ou Platypus.

Aardvark^[1] est disponible soit comme extension, soit via une simple bookmarklet. Sa principale utilité est d'éditer une page avant de l'imprimer, en supprimer des éléments (ou tous les éléments sauf celui sélectionné), modifier les couleurs... Ces changements ne sont pas enregistrés, hormis si RIP est installé. Comme son interface est plus agréable que celle de RIP, elle en constitue un bon complément. Vous pouvez la tester sans rien installer directement sur sa page de documentation.

Platypus

Platypus (l'Ornithorynque) permet d'aller un peu plus loin. Cette extension offre de nombreuses fonctions permettant d'éditer les pages, et ces modifications peuvent être enregistrées de manière permanente. Il ajoute une barre d'outil pour modifier à votre guise les pages Web. Si vous installez également Greasemonkey, il est capable d'enregistrer vos modifications sous forme de scripts pour Greasemonkey, et de les ré-appliquer à chaque fois que vous revenez sur cette page ou ce site. Platypus offre les fonctions classiques d'Aardvark, pour supprimer ou isoler des éléments, mais également un éditeur de style permettant simplement, pour chaque élément sélectionné, de modifier sa taille, ses couleurs ou les propriétés de la police. Avec un peu d'expérience, vous pouvez aussi injecter du HTML dans la page. Enfin, Platypus offre une option "magique" de réparation, qui essaie de rendre la page plus lisible en supprimant ce qui pourrait déranger la lecture. Bon, les résultats sont assez aléatoires, mais parfois bien vus. Pour une documentation plus complète, c'est par ici.

Customize Your Web

Il y avait longtemps que pas grand chose de neuf n'était apparu pour modifier simplement les pages Web. Apparu il y a à peine quelques mois, Customize Your Web (CYW) permet d'aller plus loin que Platypus, et semble très prometteur^[2].

CYW est une sorte d'éditeur interactif de scripts : vous créez via son interface des scripts, ensemble d'actions à exécuter sur une page, un site, etc. Ces scripts sont enregistrés et exécutés automatiquement à chaque chargement de la page. On peut également les exporter ou importer des scripts écrits pas d'autres, comme avec GreaseMonkey.

Comme avec Aardvark ou Platypus, vous commencez par sélectionner des éléments dans la page, mais la liste d'actions disponibles est ensuite beaucoup plus importante. En cliquant sur un élément, un menu vous offre une liste de commandes. Vous pouvez bien sûr supprimer l'élément, mais aussi éditer ses propriétés. Un mode "expert" vous donne accès à toutes les propriétés CSS disponibles. Vous pouvez déplacer des éléments pour réarranger la page comme vous le voulez. Vous pouvez créer des raccourcis clavier, par exemple pour vous positionner facilement sur un formulaire de recherche. Vous pouvez déclencher le clic sur un bouton, pour lancer une recherche automatiquement en arrivant sur une page, ou vous connecter si Firefox avait mémorisé un login. Vous pouvez également créer des raccourcis pour afficher et masquer à la demande des fragments de la page.

De toutes les extensions précédentes, CYW est pour l'instant celle qui va le plus loin, et surtout elle est en développement actif, quand les autres ont l'air d'être un peu en sommeil. Je vous conseille de garder un œil dessus.

Les mains dans le code

Pour aller plus loin, il est temps de mettre les mains dans le code. Heureusement, ça ne tache pas. Les outils qui manipulent le résultat, c'est à dire la page telle qu'elle est affichée, ne vous donneront jamais autant le contrôle que ceux qui agissent sur le code lui-même. Pour pour vraiment faire ce que vous voulez, il va falloir apprendre un peu de HTML, CSS et JavaScript. Heureusement, autour de chacune des extensions suivantes existent des communautés actives, qui partagent leurs connaissances et surtout leurs scripts. Vous pouvez donc commencer en installant des scripts réalisés par d'autres et en les modifiant pour les adapter peu à peu à vos besoins.

Stylish

Stylish est une extension vous permettant d'appliquer vos propres mises en forme à des pages Web. Vous pouvez soit les créer entièrement vous-même, mais cela demande de connaître CSS, soit utiliser ou vous inspirer des centaines de styles existants et partagés par des utilisateurs sur le site userstyles. Vous pouvez ainsi complètement personnaliser la mise en page des sites que vous utilisez : modifier les fontes utilisées, leur taille, revoir la largeur des colonnes, supprimer certains blocs de contenus, etc. Avec Stylish, vous devenez le maquettiste de vos sites. Si par exemple vous utilisez Scroogle^[3], mais trouvez son interface un peu austère, une simple feuille de style ajoutée à Stylish vous permettra de faire ressembler l'affichage des résultats à celui de Google.

Greasemonkey et Ubiquity

On franchit une étape de plus, car pour utiliser ces deux extensions il vous faudra écrire du code. Greasemonkey et Ubiquity permettent toutes deux d'exécuter des scripts dans une page. La première associe des scripts à des pages et des sites, et les exécute automatiquement au chargement. Par exemple, lorsque vous naviguez sur un site de vidéos, elle peut analyser la page, effectuer si nécessaire des requêtes supplémentaires, et ajouter des liens pour télécharger la vidéo. Des milliers de scripts, mis au point par d'autres utilisateurs, sont partagés sur userscripts.org.

De son côté, Ubiquity vous permet d'exécuter une commande sur n'importe quelle page. Sélectionnez par exemple un texte, appelez la commande translate et Ubiquity fera appel à un service de traduction et remplacera le texte par sa traduction.

L'une comme l'autre proposent une bibliothèque de fonctions facilitant certaines tâches, comme les appels AJAX. Bien que plus récent, celle d'Ubiquity est plus puissante (et s'appuie sur la bibliothèque jQuery qui facilite grandement l'écriture de scripts pour manipuler une page Web). L'extension est développée par les laboratoires Mozilla et sera intégrée directement à une prochaine version de Firefox.

De toutes les extensions précédentes, Greasemonkey et Ubiquity sont les plus puissantes, celles qui vous donnent un contrôle total sur ce que vous affichez, et vous permettent vraiment de le manipuler à votre guise. La contrepartie est qu'elles nécessitent de connaître JavaScript, la manipulation du DOM, AJAX... Bref, elles ne sont pas immédiatement utilisables, mais avec un peu de pratique et l'aide de Firebug, je pense que quiconque avec des rudiments de programmation devrait pouvoir commencer à en profiter.

Et la documentation

Avoir la documentation directement sous la main, c'est pratique. Je n'ai trouvé qu'une extension qui intègre des manuels de référence directement dans Firefox, c'est CodeBurner, liée au site sitepoint. Elle existe en deux versions, soit indépendante, soit intégrée à Firebug. Elle propose une référence des éléments et attributs HTML et des propriétés CSS, avec des exemples et renvois vers le site de sitepoint pour plus d'informations. J'avoue que celui-ci est plutôt bien fait, qui pour chaque propriété propose un espace d'expérimentation. J'utilisais jadis DevBoi mais elle ne semble plus très active.

Hommage

Elle ne fait plus aujourd'hui partie des extensions favorites des développeurs Web ou des bidouilleurs, mais je m'en voudrais de ne pas la citer. Depuis des temps immémoriaux, Mozilla, glorieux ancêtre de Firefox, Thunderbird, SeaMonkey et tant d'autres, incluait un inspecteur DOM, disponible aujourd'hui sous forme d'une extension. Firebug s'en inspire grandement. Associée au debuggeur Venkman, l'inspecteur m'a permis d'apprendre beaucoup. Les deux restent encore fort utiles pour le développement d'extensions, mais sont trop complexes pour les bidouilleurs du dimanche.

Au boulot !

Armés de ces quelques outils, vous devriez pouvoir commencer à vous amuser. J'avoue que les extensions les plus simples d'utilisation se contentent d'agir sur la mise en forme du contenu affiché, pour des manipulations plus complexes, comme l'agrégation de données de plusieurs origine, il faut recourir à du code, il n'existe pas encore d'interface simple. Les bibliothèques fournies avec Greasemonkey et Ubiquity (et demain JetPack) offrent de plus en plus de méthodes de "haut-niveau" qui simplifient les traitements, mais elles nécessitent d'être liées par du JavaScript.

Et toi, lecteur, comment tu initierais ton chat au bidouillage de Web ?

Notes

[1] nom anglo-saxon de l'ocryctérope du Cap, on ne dirait pas mais parfois on apprend des choses sur ce blog;

[2] attention, seule une version 0.1 de l'extension est pour l'instant disponible sur AMO. Vous pouvez télécharger une version plus récente sur le site du développeur, mais à vos risques et péril : le code de toute extension distribuée via AMO est en effet audité pour essayer de s'assurer qu'il ne contient rien de "dangereux" pour votre ordinateur ou vos données. Si vous récupérez une extension ailleurs, elle est susceptible de contenir des virus, espions ou autres. A utiliser en connaissance de cause donc;

[3] c'est un moteur de recherche qui interroge Google mais garantit un meilleur respect de votre vie privée;

It's raining mails, allez Mozilla !

Clochix — Sun, 25 Oct 2009 22:52:00 +0100

Les Laboratoires Mozilla ont annoncé il y a quelques jours un nouveau projet, Raindrop dont le but est d'expérimenter de nouvelles méthodes pour gérer ses conversations électroniques, en utilisant les technologies du Web Libre.

Raindrop est un conteneur qui va vous permettre de centraliser l'ensemble de vos conversations en ligne, et de les visualiser de façon "intelligente". Il agrège des données provenant de multiples sources et permet ensuite d'interagir avec elle. Contrairement à ce qui se dit beaucoup, je ne crois pas que ce soit soit un concurrent de Google Wave. Il se rapproche peut-être plus d'une version personelle de Friendfeed. Et surtout, c'est une expérience qui en est à ses premiers pas, et auxquelles nous sommes tous et toutes conviés à participer.

Architecture

Raindrop se compose de plusieurs composants :

un agrégateur qui récupère des messages de tout type et les stocke en base;
un moteur qui traite chaque nouveau message et en extrait les informations en fonction de règles;
une base de données qui contient une copie de tous ces messages et de leurs informations extraites ou calculées;
une interface pour interagir avec le tout;

L'agrégateur est déjà capable de communiquer avec des comptes mail (via IMAP), Twitter, Skype et des flux RSS. L'ajout du support d'autres protocoles ne devrait pas être compliqué. Une fois les messages récupérés, ils sont insérés en base. Cette insertion déclenche des traitements, définis sous forme d'extensions, qui analysent les messages, en extraient des information, et enrichissent la base de ces nouvelles informations qui seront utilisées pour proposer des vues spécifiques. Ces informations permettent par exemple d'essayer de regrouper les messages en conversations, de séparer les listes de discussion des échanges privés, etc

L'agrégateur est pour l'instant basé sur Twisted, un framework réseau écrit en Python. Cependant, ce choix n'est pas définitif. S'il a permis de développer rapidement un premier prototype, mais n'est peut-être pas le composant le plus adaptés aux besoins de Raindrop. En particuliers, son fonctionnement assez complexe peut être une barrière à la création d'extensions par un maximum de gens. Le wiki du projet contient plus d'informations sur les discussions en cours sur le sujet.

C'est CouchDB qui a été choisie pour stocker les messages. C'est une base de données orientée documents, c'est à dire qu'elle ne stocke pas de données ayant des formats rigides, avec des tables aux schémas figés, mais enregistre tout type de documents, représentés par une simple liste de clés et de valeurs. De ce fait, il n'est pas besoin de créer de nouvelles tables pour enrichir la base d'autres types d'information. Autre caractéristique intéressante de CouchDB, c'est une base distribuée, il est très simple d'avoir plusieurs instances de la base et de les synchroniser. Enfin, elle intègre un serveur Web, qui est son interface naturelle. L'interface actuelle de Raindrop se connecte donc directement à la base et affiche des vues sur les données.

Outre les messages et leurs informations, la base de données stocke également tout le nécessaire pour les afficher, c'est à dire le HTML, CSS et JavaScript utilisés dans l'interface utilisateur. Pour l'instant, tous ces composants sont également disponibles en tant que fichiers dans l'arborescence du projet, et la base est synchronisée avec les fichiers. Au fur et à mesure du développement des interfaces pour modifier Raindrop, les versions en base pourront prendre le pas sur celles du système de fichier.

Une plate-forme

En fait, plus qu'une application, Raindrop est une plate-forme complètement personnable de gestion de conversations. Elle respecte deux éléments essentiels de la philosophie Mozilla : l'utilisateur est central, le Web est bidouillable. Raindrop est donc entièrement configurable, modifiable, extensible, à tous les niveaux. Il permettra à chacun d'être maître de ses données et des usages qu'il en fera.

Côté backend, tous les traitements reposent sur des extensions qui sont appelées quand un nouveau message est ajouté à la base, ou lors de certains événements. Ces extensions analysent les messages et enrichissent la base en créant de nouveaux documents. A titre d'exemple, les extensions disponibles dans la première version permettent :

d'analyser le contenu d'un mail pour détecter les citations du mail répondu;
d'analyser les mails pour essayer de les regrouper en conversations;
d'ajouter tous les identifiants Twitter détectés à vos contacts;
d'extraire les hashtags des gazouillis;
etc

Pour l'instant, toutes les extensions backend sont traitées par le moteur dans un seul processus, et doivent donc être écrites en Python. A terme, elles seront déléguées à des processus externes et pourront donc être écrite dans n'importe quel langage, avec une préférence pour JavaScript, pour unifier les développements entre les modules front et back. Le moteur JavaScript embarqué par CouchDB (SpiderMonkey, le même que Firefox) pourrait être mis à contribution.

Côté frontend, l'utilisateur peut interagir avec les données soit au moyen d'applications Web, soit à travers une API. Une application Web n'est rien d'autre qu'une page HTML, mise en forme avec des CSS, et motorisée par JavaScript. Les applications reposent sur des Widgets qui elles-mêmes utilisent une API JavaScript de bas niveau pour communiquer avec la base de données. Et là encore, on peut adapter Raindrop à ses besoins. Soit en écrivant une application Web complète, soit en créant de nouvelles Widgets pour l'application existante (qui n'est pas l'interface de Raindrop, mais un exemple d'interface), soit via des extensions. Le tout utilise les technologies classiques du Web, HTML, CSS et JavaScript.

Si vous avez installé Raindrop, le lien pour accéder au gestionnaire d'extension est en bas de la page principale. Celui-ci intègre l'éditeur Bespin, pour éditer le code des extensions directement, sans avoir besoin de recourir à un autre logiciel ou d'accéder au système de fichier^[1].

Les extensions déjà disponibles permettent par exemple:

de rajouter en dessous de chaque message la liste des liens HTML qu'il contient (ces liens sont extraits et stockés en base par une extension côté backend, il suffit donc de les afficher);
si un message contient un lien vers une vidéo YouTube, d'afficher la vidéo directement dans le message;
d'afficher la liste des dossiers disponilbes, des mailing-list auxquelles vous êtes abonnés, etc;
et bien d'autres choses. Evidemment, l'activation ou la désactivation d'une extension met à jour l'affichage instantanément;

L'architecture se veut la plus ouverte possible, les communications entre chaque composant passant par des API. Les choix techniques pour chaque module étant loin d'être définitif, cela devrait permettre à tout moment de modifier l'un des composants sans avoir d'impact sur les autres. De plus, cela permet de faire fonctionner les composants sur des machines distinctes. Bien entendu, ces API visent aussi à augmenter la bidouillabilité, à donner aux utilisateurs un maximum de méthodes pour interagir avec les données et l'application. L'API essaiera de se conformer au modèle REST, répondant peut-être enfin au vieux rêve d'accéder à ses mail en mode REST. Et comme tout le reste, elle sera également extensible.

Une pluie rafraîchissante

Attention, Raindrop est un prototype, une expérience à son premier stade. Il est encore loin d'être utilisable, et n'est pas simple à installer. Il nécessite des versions particulières de logiciels (par exemple CouchDB 0.10 alors que seule la 0.9 est disponible dans Sid), a de nombreuses dépendances, etc. Mais c'est le but du prototype : en dévoiler assez pour permettre de se faire une idée des possibilités du concept, et appeler la communauté à la rescousse. Donc voilà. Si vous êtes geek, essayez d'installer la bête, faites remonter vos problèmes, vos idées, bref, profitez-en, on ne vous demande pas de tester pour faire remonter les bugs mais de participer à l'élaboration de ce qui pourrait être une jolie évolution du Web.

Je trouve ce projet excitant, à la fois par ses choix technologiques et par les perspectives qu'il ouvre en terme de nouveux moyens de jouer avec nos données. Cerise sur la chantilly, il reprend, en la menant bien plus loin, mon idée de départ lorsque j'ai codé Couac : avoir une interface unique pour gérer l'ensemble de ses communications.

Mais je l'adore surtout parce qu'après Weave, je vois là une nouvelle brique pour se ré-approprier nos données, pour en reprendre le contrôle. Raindrop est prévu pour fonctionner aussi bien dans le nuage (hébergé sur un serveur donc accessible de partout) qu'installé en local sur le poste de l'utilisateur^[2] Avec Weave et Raindrop, on disposera sous peu de deux conteneurs extensibles où stocker toutes nos données aujourd'hui dispersées un peu partout sur le Web. Les stocker, et les bidouiller à notre guise. Elle est pas belle la vie dans le monde merveilleux du Grand Lézard ?

Notes

[1] pour l'instant, toutes les extensions sont également présentes dans le système de fichier et cette version écrase celle en base au moment du lancement de l'application. A terme, les modifications effectuées en base au moyen de l'éditeur en ligne seront évidemment pérennes

[2] vu le nombre de dépendances, la tâche semble pour l'instant ardue, mais si les équipes du projet arrivent à créer un programme pour facilement installer le serveur Raindrop sur n'importe quelle machine locale, et je ne doute pas qu'elles y arriveront, cela ouvrira bien des perspectives : imaginez, Python et CouchDB largement déployés sur les postes utilisateurs;

Bidouiller pour surfer sur le canal

Clochix — Mon, 19 Oct 2009 19:23:00 +0200

Une des applications pratiques de la bidouillabilité du Web est la libération de contenu, ou plutôt l'accès à des contenus enfermés dans des boîtes privatrices. L'exemple le plus flagrant est la vidéo. Aujourd'hui, l'énorme majorité de la vidéo sur le Web est diffusée via les lecteur Flash, et donc inaccessible aux gens ne disposant pas du lecteur officiel d'Adobe. Heureusement, un peu de bidouille permet souvent de s'en sortir.

C'est pour moi un combat quotidien que de réussir à regarder des vidéos sans avoir ce fameux plugin (un logiciel propriétaire que ma religion m'interdit formellement d'installer). Comme les lecteurs ne servent qu'à afficher un fichier ou un flux, le but est de réussir à trouver l'adresse de ce fichier pour le lire avec le logiciel de mon choix. Parfois l'URL du fichier est disponible directement dans la page, dans les paramètres du lecteur. Parfois il faut accéder à un fichier de configuration sur le serveur pour récupérer cette URL. Et dans les cas extrêmes, découvrir l'URL nécessite de désassembler le lecteur^[1] ou de sniffer les échanges sur le réseau.

Fort heureusement, beaucoup de bricoleurs ont déjà fait ce travail et le partagent. Des sites comme userscripts proposent par exemple de nombreux scripts GreaseMonkey qui ajoutent automatiquement aux pages de YouTube, Vimeo et compagnie des liens vers la source de la vidéo.

Il n'y en a cependant pas pour une chaîne de télé cryptée française, qui met à disposition sur son site de nombreux extraits de ses émissions, hélas embastillés dans du Flash. Jusqu'à il y a peu, les fichiers sources étaient assez simples à trouver, mais le site a changé il y a quelques mois et j'ai dû renoncer à regarder le journal télévisé d'une voisine présipauté.

Heureusement bis, des chtis gars d'Ubuntu-fr ont découvert les nouvelles URL, et j'ai pu écrire un petit script pour à nouveau pouvoir regarder certaines émissions^[2].

Récupérer l'adresse des fichiers

On peut le faire en interrogeant un service web, mais je me suis aperçu d'une méthode encore plus simple : les URLs des flux ressemblent beaucoup à celles des images de leurs vignettes. J'ai donc écrit un petit script déduisant les premières des secondes. Si j'avais été bon, j'aurais créé une commande GM qui ajoute les liens automatiquement au chargement de la page, mais comme je suis mauvais et plus à l'aise avec la syntaxe d'Ubiquity (qui surtout intègre nativement jQuery), j'ai pondu une commande Ubiquity.

 CmdUtils.CreateCommand({
   name: "canal",
   description: "Add download links to C+",
   execute: function() {
     var document = CmdUtils.getDocument();
     jQuery("img[src$='_image_L.jpg']", document).each(function() {
       var file = this.getAttribute('src').split('/').pop().replace('_image_L.jpg', '_video_H.flv');
       var month = /\d{6}/.exec(file);
       if (month) {
         month = month.shift().substr(0,4);
         $(this).after('<a href="rtmp://vod-fms.canalplus.fr/ondemand/videos/'+month+'/'+file+'">rtmp</a>');
       }
     });
   }
 });

Rien de compliqué : je recherche toutes les vignettes (dont le nom finit par _image_L.jpg), je déduis de leur nom celui du flux et j'insère sous l'image un lien vers le flux. Un peu de mise en forme du lien ne ferait probablement pas de mal.

Afficher le flux

Les flux sont diffusés en utilisant RTMP, un protocole de streaming développé par Adobe. C'est un protocole propriétaire. Ses spécifications sont accessibles, mais Adobe a interdit la diffusion de rtmpdump, un utilitaire permettant de lire les flux et incluant certaines fonctionnalités de protection qu'Adobe tient à garder secrètes. Un dérivé de rtmpdump, flvstreamer, est heureusement disponible, dont ont été retiré les fonctionnalités dont Adobe ne souhaite pas la divulgation.

VLC sait normalement lire les flux RTMP, mais s'il n'y arrive pas vous pouvez passer par flvstreamer. Par défaut, celui-ci écrit le flux sur sa sortie standard, on peut donc l'afficher en redirigeant celle-ci vers n'importe quel logiciel capable de lire du flv. J'utilise pour ma part cette simple commande:

$ cat rtmpplay.sh
#!/bin/sh
flvstreamer -r $1 2> /dev/null | vlc -

Reste à expliquer à Firefox que faire des URL rtmp:. Pour cela, rien de plus simple, il suffit de lui demander gentiment de gérer un nouveau protocole. Allez dans la configuration avancée (about:config dans la barre d'adresse) et rajoutez deux clés :

network.protocol-handler.external.rtmp, clé booléenne à true pour lui indiquer que ce protocole est géré par une application externe;
network.protocol-handler.app.rtmp, chaîne de caractère contenant le path de la commande externe à lancer pour traiter l'URL. Si vous omettez cette clé, Firefox vous demandera à la première utilisation de choisir le programme à utiliser;

Vala, le tout ne m'a pas pris longtemps et je peux à présent regarder à ma guise Jules-Edouard. Bien sûr, si le Web était ouvert, ces vidéos auraient été diffusées à un format lui aussi ouvert, via par exemple la balise video, et je n'aurais pas eu à passer par ce petit hack. Mais en attendant, une simple bidouille permet de contourner le problème. J'ai utilisé ici par facilité des fonctions spécifiques à Firefox, via Ubiquity, mais écrire une bookmarklet faisant la même chose et compatible avec tous les navigateurs serait trivial.

Notes

[1] swfdump est là pour ça;

[2] pour ce savoir plus, je vous conseille ce fil ( les messages à partir de juillet-août donnent les nouvelles URL);

Mettre le bidouillage de Web à la portée de tous et toutes

Clochix — Thu, 15 Oct 2009 13:37:00 +0200

Note: ce billet a été écrit au printemps, mais n'a jamais franchi le cap de la relecture car il ne me satisfaisait pas. Comme il a inspiré plusieurs autres divagations, je finis par le mettre en ligne, mais ça reste un brouillon, une maquette en cours, que je continuerai probablement à décliner quelque temps.

Plongée narcissico-temporelle, accrochez vos vaccins

J'ai eu la chance de vivre déjà deux périodes de démocratisation de l'informatique.

La première, au début des années 80, avec l'arrivée de la micro. Pendant quelques années, tous les ordinateurs étaient livrés avec ce qu'il fallait pour apprendre la programmation: un langage et des manuels pour apprendre. Sans doute parce qu'au vu du faible nombre d'applications alors disponibles, il fallait laisser les utilisateurs créer les leurs. Ou peut-être que pour les pionniers de cette époque, il était évident que la première fonction d'un ordinateur était d'être une plate-forme sur laquelle chacun et chacune pouvait créer ce dont on avait besoin/envie. A moins que ce fût pour des raisons marketing: en ce temps là, les adultes n'étaient pas encore des adulescents, pour convaincre de l'utilité d'un ordinateur, apprendre l'informatique était un argument qui marchait mieux que toute la famille pourra jouer à Mario Kart. Mais au final peu importent les raisons, on avait nos drôles de machines, on avait Hebdogiciel et on passait notre temps libre à découvrir, bidouiller, coder...

Puis peu à peu les applications disponibles sont devenues plus nombreuses, les langages de programmation plus complexes, moins accessibles. Pour rester au même niveau que les jeux commerciaux, il fallait se mettre à l'assembleur, pour les applications de bureau au C et découvrir les bibliothèques de composants graphiques. Parallèlement, les langages et environnement de programmation ont disparu des logiciels livrés par défaut avec la machine, sont devenus des trucs payants, et la programmation est redevenue une affaire de spécialistes. Fin pour moi du premier âge d'or.

Au mitan des années 90 est apparu le web, et avec lui un nouvel environnement, relativement accessible et simple à utiliser pour à nouveau créer. HTML est un langage fondamentalement ouvert, pour l'apprendre il suffisait de consulter le code source des pages, auquel tout le monde pouvait accéder. Pour coder, un simple éditeur de texte suffisait. Les différents langages de la pile étant interprétés, les résultats étaient immédiatement visibles, sans nécessiter de passer par une compilation. HTML était très simple à apprendre, ne nécessitait pratiquement aucune culture informatique. Rapidement des hébergeurs ont fourni à faible coût l'architecture permettant à chacun et chacune de créer son site perso, pas forcément de façon très heureuse, mais avec énormément d'enthousiasme. Côté serveur un langage de script simpliste est apparu quelques années plus tard, PHP. Il ne nécessitait lui aussi qu'un investissement minimal. Un éditeur de texte, un client FTP, et on pouvait commencer à rendre dynamiques nos sites. La documentation bien faite ― elle reste encore à ce jour une des principales forces de PHP ― et rapidement traduite dans de nombreuses langues a contribué au succès du langage. Nombre d'internautes sans aucune notion de programmation ont ainsi pu créer des sites en apprenant peu à peu HTML, JavaScript et PHP. C'est ainsi par exemple qu'est né SPIP.

Et à nouveau, au fil des années on a assisté à une professionalisation, on pourrait dire que le Web s'est refermé. Même si les technologies restaient les mêmes, le ticket d'entrée était de plus en plus cher. Qui veut avoir un site aujourd'hui se tourne vers une solution toute faite hébergée plutôt que de développer ou d'installer la sienne. Avec le Web dit "2.0", on crée des contenus, mais on ne maîtrise pas la fabrication des outils servant à les créer, on utilise une plate-forme devenue une boîte noire.

Bidouilleurs, saison 3

J'ai l'impression d'assister aujourd'hui à une troisième vague de démocratisation, via JavaScript et des outils comme Greasemonkey, Firebug, Ubiquity, Bespin, Jetpack. A nouveau, l'atelier est à la disposition de tous, fourni gratuitement en standard avec ce nouvel OS qu'est le navigateur. Une combinaison de touches, et on crée ses propres commandes, on manipule comme on le souhaite le Web, les données... Petit à petit, les outils se mettent en place pour qu'une nouvelle génération s'ouvre à la bidouille informatique. Mais cette fois-ci, l'enjeu me semble encore plus important. Compte tenu de la place qu'est en train de prendre le Web, avoir des rudiments de programmation me semble aujourd'hui une condition indispensable pour permettre aux individus de s'émanciper, de devenir acteurs et non simples consommateurs de leur vie.

Tous et toutes bidouilleurs !

Personne ne niera l'importance de savoir lire et écrire : c'est une condition indispensable pour comprendre le monde dans lequel on vit et pouvoir agir dessus, pour s'émanciper, devenir autonome et libre. Mais lire et écrire doivent être pris dans un sens plus large. Il ne s'agit pas que de caractères, mais de savoir déchiffrer le monde et le modeler. Comprendre et créer. Lire et écrire des livres, mais aussi des machines. Comprendre le fonctionnement d'un moteur et savoir en créer un, ou au minimum être capable de le bricoler, réparer, améliorer. Et c'est valable dans tous les domaines. Il en va également de notre rapport à nos outils et aux machines qui forment notre entourage : pour ne pas en devenir esclave, pour ne pas être aliénés, nous devons apprendre à les comprendre et savoir les bricoler. C'est valable pour une voiture comme pour un ordinateur. Il est essentiel de comprendre comment fonctionne un ordinateur et un logiciel, de savoir lire et comprendre sa recette (dans le cadre d'un logiciel, son code source), d'être au minimum capable de le bricoler, d'en corriger les erreurs, de l'améliorer. Nous pouvons et pourront à l'avenir de moins en moins nous passer de l'informatique et du Web. Il faut donc que chacun et chacune apprenne la programmation. Ou accepte de devenir esclave de la machine et de ceux qui la maîtriseront.

Dans ses présentations sur l'Open Web, Mark Surman dit souvent que tous les usagers doivent devenir des hackers. Il ne faut bien sûr par entendre ici hacker comme expert en informatique, mais plutôt comme bricoleur, bidouilleur. Pour bâtir un Web Libre, il faut non seulement développer et promouvoir des technologies libres et ouvertes, mais il faut aussi éduquer les usagers^[1], les aider à ne pas être de simples consommateurs passifs mais à devenir acteurs de leur vie en ligne, les aider à devenir des bidouilleurs, des bricoleur du dimanche de Web. Heureusement, comme je le disais, les conditions permettant l'appropriation du Web par ses usagers commencent à être réunies, grâce notamment à l'éclosion de nouveaux outils.

Les outils à travers les âges

Les temps immémoriaux

D'après Aaron Boodman, un développeur du navigateur de Google, les trois quarts des extensions des plus populaires de Firefox servent à manipuler les données affichées, et non à ajouter de nouvelles fonctionnalités au navigateur. Ce qui tendrait à prouver que pouvoir manipuler à leur guise les données est un besoin fort des usagers. Or pour cela, nul besoin de créer une extension, ce qui reste complexe. Pour bidouiller des données, bien souvent de petits scripts s'exécutant dans le navigateur suffisent. Des solutions existent depuis longtemps, comme les bookmarklets, les scripts GreaseMonkey, ou Stylish pour la mise en forme. Ce sont des outils simples à prendre en main, un éditeur de texte suffit pour créer des scripts, mais ils manquent un peu de convivialité.

La révolution Firebug

Ensuite est né Firebug, et le Web n'a plus été le même. Firebug est un outil génial pour expérimenter, sans doute l'un des meilleurs. Car il inclut directement dans le navigateur des outils pour afficher la structure des pages, le HTML, les styles, le fonctionnement sous-jacent du réseau, étudier les scripts en en suivant le déroulé pas à pas. C'est l'outil indispensable pour étudier le Web, pour mieux le comprendre. Mieux, Firebug comprend, toujours à l'intérieur du navigateur, tout ce qu'il faut pour expérimenter : un éditeur et une console. On n'a plus besoin d'aucun logiciel externe. On tape des commandes, on commence à rédiger des scripts dans l'éditeur, le résultat est visible immédiatement dans la page, en direct, pas besoin de compiler, redémarrer ou quoi que ça soit, la console affiche des messages d'information ou d'erreur... Oui, cet outil est génial et il est grand temps qu'il ne soit plus réservé aux développeurs, car pour moi Firebug a un formidable pouvoir pédagogique : il permet d'étudier, comprendre, expérimenter. Pour être parfait, il ne lui manque à vrai dire que la possibilité d'enregistrer les scripts que l'on crée, de les transformer en commandes intégrées au navigateur.

Les Mozlabs à la rescousse

Les Laboratoires Mozilla l'ont bien compris, qui ont marié GreaseMonkey et Firebug pour le meilleur et deux superbes enfants, Ubiquity et Jetpack. Avec l'aide du cousin Bespin, qui est en cours d'intégration aux deux précédents, on disposera nativement dans le navigateur de tous les outils pour bidouiller et le Web et la plate-forme, Firefox : un éditeur moderne, avec tous mes mécanismes d'assistance nécessaire (coloration syntaxique, auto-complétion, détection d'erreurs de syntaxe à la frappe, etc); une ligne de commande intuitive qui permettra littéralement de dialoguer avec Firefox, et dans sa langue natale (en terme d'accessibilité au plus grand nombre, c'est indispensable); et des bibliothèques de haut niveau qui permettront d'effectuer des tâches complexes en quelques instructions (allez voir comme Jetpack simplifie le développement).

Envoi

Ce ne sont bien sûr que des outils, mais des outils qui créent des possibles, qui abaissent chaque jour davantage la barrière à franchir pour oser commencer à bidouiller le Web. Bricoler la toile devient chaque jour plus simple, plus accessible. Maintenant que les outils sont là, il faut bien sûr toujours des mécanos pour continuer à les améliorer, mais il faut aussi davantage d'évangélistes, de pédagogues, pour expliquer que la bidouille n'est plus une affaire de spécialiste, qu'elle est à la portée de chaque internaute. C'est aussi comme cela que j'entends le projet Drumbeat : faisons ronfler les Djembés pour faire sortir la bidouille du ghetto geek.

L'enjeu, je le répète, est de permettre à chacun et chacune de s'émanciper, de ne plus être esclave des machines mais de devenir autonome, libre. Le Web Libre et sa bidouillabilité ne sont pas que des débats techniques réservés aux techniciens. Cela a avant tout à voir avec le rapport de l'homme à son environnement. Le Web Libre concerne quiconque s'intéresse à l'émancipation et à la liberté.

Oui je suis follement amoureux de ce navigateur et je vous soûle à chanter ses louanges à longueurs de billets kilométriques, mais franchement il le mérite. Je pousserai le compliment jusqu'à qualifier la MoFo de FSF du Web Libre. A vrai dire, il ne manque à la MoFo qu'un ou une évangéliste aussi sexy que RMS

Réclame : je me suis intéressé à l'aspect plus technique de la bidouillabilité dans plusieurs récents billets, sur l'utilisation de Web Hooks pour bricoler des applications existantes, sur les perspectives ouvertes par le retour d'intérêt pour JavaScript sur le serveur, et dans un questionnement sur le choix d'un langage unique. Ces billets, et peut-être encore un ou deux en gestation, sont des déclinaisons pratiques d'icelui, et offrent peut-être des pistes de réflexion complémentaires.

Ailleurs : je parle beaucoup dans ce billet d'outils, voire de convivialité. Les outils conviviaux sont un élément de la pensée d'Ivan Illich. Certains aspects du présent monologue y font probablement écho. J'aimerais y revenir à l'occasion, mais vous invite à jeter un œil au concept. Vous pouvez pas exemple commencer par Ekopedia (reprise de l'article de Wikipedia sans certaines digressions) et lire Le web, outil convivial à tendance toxique d'Eric Mainville, ou le récent article Vive la bidouillabilité d'Adrien Saumier.

Notes

[1] le Web étant un bien public, j'ai décidé de privilégier désormais usager à utilisateur

Quel langage pour bidouiller le Web ?

Clochix — Thu, 15 Oct 2009 11:17:00 +0200

Une activité dont je souhaite ardemment le développement dans les prochaines années est le bricolage de données, le fameux slogan Hack The Web !. C'est à dire permettre à chacun et chacune de ne plus être simplement consommateur de données, mais de pouvoir les manipuler aisément à sa guise pour en faire ce qu'on veut. Et je réfléchis depuis quelque temps aux meilleurs outils pour bidouiller la toile. Meilleurs pas uniquement d'un point de vue technique, mais aussi de prise en main, d'accessibilité.

J'évoquais dans mon précédent billet l'intérêt d'utiliser le même langage de programmation sur le client et le serveur. Un autre avantage dont je n'ai pas parlé est que cela diminue les pré-requis, les connaissances nécessaires pour commencer à bidouiller le Web. Il est pour moi essentiel que chacun ait des rudiments de programmation. Heureusement, j'y reviendrai, ces jours-ci de nombreux projets tendent à rendre l'apprentissage de la bidouille de Web de plus en plus accessible. Unifier les environnements entre le client et le serveur va également contribuer à rendre l'apprentissage plus aisé. Mais il reste une barrière difficile à franchir, celle du langage de programmation. Car JavaScript est un langage nettement plus complexe que les BASIC, HTML, ou PHP par lesquels nombre d'entre nous ont commencé à bidouiller. Pas sûr que cela soit à la portée des Michus ^[1]. Or la démocratisation du Web impose que cette sympathique petite famille puisse acquérir son autonomie, ne pas dépendre de leur turbulent petit neveu geek, qu'ils puissent eux aussi bidouiller le Web. Mais je me pose la question du choix du langage. Si me semble bonne l'idée d'utiliser le même à tous les niveaux, pages, serveur et navigateur, je ne suis pas sûr que JavaScript soit le meilleur candidat pour devenir ce langage universel du Web. Et pour préciser, je me demande si Python ne serait pas un meilleur choix.

L'idée n'est pas totalement stupide : certes JavaScript est hégémonique sur le Web, côté client du moins. Mais il souffre d'un certain nombre de problèmes qui rendent son apprentissage malaisé:

de grosses différences entre les différentes implémentations. Même si des normes existent, leur implémentation laisse encore parfois à désirer, et un code pourra fonctionner avec un moteur mais pas avec un autre, sans raison particulière. On peut donc difficilement se concentrer sur l'apprentissage du langage en faisant abstraction du contexte;
il n'existe pas de site de référence. La plupart des autres langages ont des sites Web où on trouve l'essentiel de la documentation et des didacticiels. Quelqu'un qui cherche des informations sur JavaScript n'a souvent d'autre alternative que d'utiliser un moteur de recherche. Et, conséquence du point précédent, les documentations sont souvent liées à une implémentation, comme par exemple dans le MDC;
son modèle objet n'est pas facile à appréhender : essayez par exemple de trouver sur le Web une explication simple du concept d'héritage par prototype;
peu de bibliothèques sont disponibles: hormis pour des fonctions nécessaires côté client (manipulation de documents HTML), on dispose de bien peu de bibliothèques : la manipulation de chaînes de caractères, les dates, les expressions régulières... c'est à peu près tout. Rien par exemple pour la communication avec un système de fichier, des bases de données... CommonJS s'est donné pour but de remédier à ce manque, mais le projet n'en est qu'à ses débuts;

De son côté, Python n'est pas totalement absent côté client. Il est notamment un langage de premier choix pour Mozilla: on le retrouve un peu partout sous le capot, et des développeurs comme Atul Varma, qui en sont fan, veillent régulièrement à ce qu'on puisse utiliser Python avec Ubiquity, Jetpack, etc. J'avais déjà évoqué cela il y a quelques mois. Des projets comme jsbridge tissent des ponts entre les deux langages. Et si JavaScript est pour l'instant hégémonique dans les pages Web, Python est lui très populaire dans l'éducation. De nombreuses ressources sont disponibles pour l'utiliser pour apprendre la programmation. Il me semble plus facile d'accès, plus pédagogique.

Bien sûr, il existe des dizaines d'autres environnements pour apprendre à coder. Mais je crois que Python est la seule alternative crédible à JavaScript, car il est très populaire, réellement utilisé aussi bien dans des projets industriels que pédagogiques, et a déjà un pied dans le navigateur.

Je pense qu'on est à un tournant, les mois à venir vont voir la popularisation à la fois d'outils pour bidouiller le Web en utilisant juste son navigateur, et de solutions globales effaçant les barrières entre le client, le serveur et le navigateur. JavaScript semble bien parti pour devenir le langage universel du Web, mais il n'est peut-être pas trop tard pour Python. Je ne connais pas du tout la communauté Python, mais ai peut-être l'honneur de compter un ou deux de ses membres parmi mes lecteurs. Pensez-vous que la communauté pourrait s'investir pour renforcer le support de Python dans le navigateur, dans des outils comme Ubiquity et JetPack ? Afin d'offrir une alternative crédible à JavaScript comme langue universelle du Web. Le choix de cette langue est très important, car il va avoir un impact sur la démocratisation de la bidouillabilité. J'espère de tout cœur que le débat aura lieu et permettra de choisir la meilleure technologie, puissante et accessible à tous et toutes.

Notes

[1] monsieur et madame Michu, utilisateurs types des générations d'avant les Y. En soutien aux camarades de WoMoz je m'engage désormais à ne plus stigmatiser uniquement Madame Michu;

JavaScript : retour sur le serveur

Clochix — Wed, 14 Oct 2009 01:38:00 +0200

Utiliser JavaScript sur le serveur, l'idée est ancienne, mais connaît depuis quelques mois un vif regain d'intérêt. Petit tour d'horizon de cette actualité.

Retour aux sources

On l'oublie souvent, mais au moment de sa conception en 1995 par Brendan Eich pour le compte de Netscape, JavaScript a d'abord été un langage pour le serveur, avant de rapidement intégrer le navigateur. Netscape a longtemps essayé de défendre cette utilisation, avant qu'elle ne disparaisse peu à peu.

Langage maudit du Web 1 (à cause des implémentations incompatibles de Navigator et d'IE qui obligeaient à développer le code en double), JavaScript a peu à peu gagné ses lettres de noblesse avec le Web 2, DHTML et AJAX, et les nombreuses bibliothèques qui ont permis de faire abstraction des spécificités des navigateurs. Depuis environ deux ans, les principaux fondeurs de navigateur se livrent à une compétition forcenée autour de JS, et les performances des moteurs ont explosé (en 10 ans, elles auraient été multipliées par presque 100^[1]). Aujourd'hui, il devient par exemple de plus en plus envisageable d'avoir dans le navigateur, propulsées par JavaScript, des applications demandant de la puissance de calcul, comme par exemple de la 3D. Et l'utilisation de JavaScript sur le serveur revient au goût du jour, les performances du langage commençant à rivaliser avec celles des autres. Signes de ce retour, le grand nombre de bibliothèques "serveur" qui fleurissent depuis quelques mois, et surtout le projet CommonJS.

Mais pour quoi faire ?

L'intérêt de permettre à JavaScript d'enfin s'ébattre sur le serveur me semble évident. Utiliser le même langage sur le client et le serveur présente plusieurs avantages:

actuellement, développer une application Web demande de connaître au moins deux langages, l'un sur le serveur, l'autre dans le navigateur^[2] et des langages assez différents, car JavaScript, ne serait-ce que par son implémentation particulière du modèle objet, a une logique bien spécifique. J'ai toujours trouvé fatigant, dans un projet Web, de devoir passer sans arrêt de JavaScript à PHP/Python/Java/Ruby/..., parce que les philosophies sont différentes, et accessoirement certaines petites différence de syntaxe sont propices aux erreurs. Les fréquents sauts d'un langage à l'autre empêchent de se mettre en mode automatique et fatiguent;
de nombreuses opérations (des validations de données saisies par exemple) doivent être codées deux fois, dans deux langages, avec des implémentations le plus proches possibles. En se limitant à un seul langage, on peut réutiliser davantage de code, avoir la garantie qu'il n'y a pas de différence d'implémentation d'un algorithme entre le client et le serveur (ce qui est toujours la cause de soucis difficilement détectables). On diminue ainsi la charge de travail, et accélère le développement.
la communication entre le client et le serveur s'en trouve facilitée, puisqu'on est sûr que les données sont encodées et décodées de la même façon;

Plusieurs projets relativement pionniers expérimentent déjà ce type d'architecture. Par exemple Jaxer, un projet libre développé depuis plusieurs années par Aptana. Jaxer utilise Gecko sur le serveur, c'est à dire à la fois le moteur JavaScript, SpiderMonkey, et toutes les bibliothèques incluses dans Firefox pour manipuler du XML, le DOM, les accès au système de fichier, etc. Parallèlement Aptana a également créé ActiveJS, un ensemble de bibliothèques utilisables aussi bien dans le navigateur que sur le serveur, et facilitant la mise en œuvre de MVC en JavaScript pur. Parmi les autres précurseurs, on pourra également regarder du côté d'Helma ou de Haxe.

CommonJs

Une des principales raisons pour moi du succès de PHP est la grande richesse de bibliothèques disponibles dans le cœur du projet ou à proximité (c'est à dire dans PEAR ou PECL). Quoi que l'on veuille faire, on trouvera une bibliothèque facile à installer et relativement bien documentée.

JavaScript à l'opposé est un langage que je trouve plus puissant que PHP (il est par exemple réellement objet et offre depuis longtemps des mécanismes qui arrivent timidement dans les dernière versions de l'éléphant bleu), mais pauvre en bibliothèques. Hormis la manipulation du DOM, plus récemment un peu de dessin avec les travaux sur Canvas, on est assez frustré dès que l'on veut l'utiliser pour faire autre chose que que rendre dynamique une page Web. C'est possible, mais encore faut-il trouver les bibliothèques qui vont bien et espérer qu'elles soient compatibles avec le moteur qu'on utilise. Ayant effectué l'essentiel de sa croissance au sein du navigateur, le langage a beaucoup de mal à couper le cordon et s'en émanciper, alors qu'il en aurait le potentiel. C'est pourtant un langage de script moderne qui, du strict point de vue du langage, n'a pas grand chose à envier à PHP, Python, Ruby, etc. Sa faiblesse majeure est dans la pauvreté actuelle de son écosytème, sur le serveur du moins.

Kevin Dangoor, qui travaille sur les outils pour les développeurs chez Mozilla, a remis sur le tapis l'utilisation de JavaScript sur le serveur dans un excellent billet au début de l'année, qui a depuis été suivi de nombreux autres allant dans le même sens. What Server Side JavaScript needs détaille les faiblesses actuelles de JavaScript et l'intérêt d'y remédier pour qu'il prenne enfin son envol sur le serveur. Lancé sous le nom de ServerJS, un groupe de discussion a rapidement eu un gros succès, et a donné naissance au projet CommonJS.

L'objet du projet est de définir un socle d'APIs permettant de répondre aux problématiques les plus courantes, pour que JavaScript dispose enfin des bibliothèques qui lui font tant défaut. La tâche est ardue, car si le cœur de JavaScript est standardisé par l'ECMA, les nombreuses implémentations de la spécification ont parfois pris des libertés avec elle, et surtout ont pallié ses manques en implémentant chacun sa solution. Les problèmes de compatibilité du code sont donc nombreux, et les bibliothèques implémentant CommonJS devront fonctionner de façon transparente avec tous les moteurs disponibles (cf une liste plus bas). Mais elles offriront ainsi un socle sur lequel on pourra s'appuyer pour enfin créer des applications de plus haut niveau, comme jQuery, Prototype et compagnie ont permis de s'abstraire des soucis de compatibilité pour se concentrer sur le développement.

Une version 0.1 de la spécification a déjà vu le jour qui définit l'API de modules inter-opérables, pour pouvoir facilement charger des bibliotèques externes et les faire communiquer entre elles. La version 0.5 en cours de développement crée quatre autres API : pour la manipulation d'objets binaires, l'accès à un système de fichiers, les tests unitaires, et la communication avec les serveurs Web (JavaScript Gateway Interface - JSGI). De nombreuses autres sont en cours de discussion sur le wiki et la liste de discussion. Plusieurs projets ont d'ors et déjà entrepris d'implémenter la spécification, l'un des plus avancés étant sans doute Narwal.

Effervescence

Le regain d'intérêt pour l'utilisation de JavaScript sur le serveur est aussi manifeste par le nombre de projets qui ont éclos ces derniers mois. La liste est longue, en voici quelques uns parmi ceux que je trouve les plus prometteurs:

Narwhal est un ensemble de bibliothèques JS conformes à CommonJS. Le projet aspire à être indépendant du moteur. Narwhal sert entre autre de base à Jack, une couche permettant la communication entre des applications JavaScript s'exécutant sur un serveur, et un serveur Web. Jack implémente la spécification JSGI, développée pour l'occasion, qui définie une API pour ces communications. JSGI s'inspire des spécification WSGI en Python et Rack en Ruby;
Persevere est un serveur permettant entre autre de stocker des objets JavaScript et d'y accéder directement via des services REST. Il est développé par l'équipe de Dojo et en particulier par Kris Zyp dont j'ai déjà parlé dans mes billets sur JSON. Grâce à CommonJS, Narwhal et Persevere peuvent à présent être utilisés de concert, au travers de l'API de modules;
Helma NG (Next Generation) est un framework JavaScript serveur écrit en Java et basé sur Rhino. Sa nouvelle version (NG) vise à le simplifier et à implémenter CommonJS;
Node est un serveur écrit en JavaScript et utilisant le moteur V8. Il propose une implémentation de serveur alternative à celle habituelle basée sur des threads. Il s'inspire par exemple de Twisted en Python. S'il n'implémente pas encore CommonJS, c'est un bel exemple de l'intérêt d'utiliser JS sur le serveur;

Mis à jour j'oubliais que JavaScript est aussi le langage invité de nouvelles bases de données comme CouchDB, où il est utilisé pour faire des requêtes complexes. Il commence donc même à se faire sa place dans le domaine des bases de données.

Quoi d'autre ?

Dernier point, j'ai parlé jusqu'à présent d'unification du langage utilisé dans le client et sur le serveur, mais il y a un troisième acteur à prendre en compte: la plate-forme, en l'occurrence le navigateur. Personne n'ignore que JavaScript est utilisé intensivement dans Firefox, et tout particulièrement dans les extensions. Une position qui va encore gagner en importance avec l'arrivée de JetPack, la nouvelle architecture pour les extensions, dont le slogan est si tu sais créer une appli Web, tu sais aussi créer une extension. Pour ce que j'en ai vu, les extensions Chrome vont elles aussi utiliser JS. CommonJS a donc également une indéniable utilité à ce niveau, en permettant de créer des composants génériques qui seront également utilisables par la plate-forme, le navigateur, et portables d'un navigateur à l'autre. A terme, cela facilitera sans doute encore les interactions entre le navigateur et les contenus.

Ces nouveaux horizons qui s'ouvrent à JavaScript me plaisent beaucoup. Vu la vitesse à laquelle les différents projets avancent, on devrait voir des trucs assez sympas arriver dans les prochains mois.

Annexe : tour d'horizon des moteurs

A ce jour, les moteurs libres les plus répandus et qui peuvent être utilisés sur le serveur, sont

SpiderMonkey : inventé par Brendan Eich en même temps que JavaScript, il est aujourd'hui maintenu par Mozilla. Il évolue aujourd'hui sous le nom de TraceMonkey en intégrant des bouts de Tamarin, un projet commun à Mozilla et Adobe. SpiderMonkey étant codé en C, il offre des mécanismes pour utiliser des routines écrites en C ou C++. C'est ainsi que dans Firefox, composants en C++ et modules en JavaScript travaillent de concert;
Rhino est un moteur en Java développé par Mozilla. Il offre aussi des passerelles avec Java. On peut ainsi appeler des bibliothèques Java depuis le code JavaScript, ou utiliser Rhino dans un projet Java ayant besoin de fonctions de scripting;
v8 de Google, probablement le plus véloce actuellement;
SquirrelFish utilisé dans Safari. mise à jour on me glisse en commentaire que 4D, éditeur d'une fameuse base de données sur Mac, travaille sur le projet Wakanda qui l'utilisera;
je ne parle pas des moteurs utilisés dans Opéra ni IE car je ne sais pas s'ils existent en tant que projets indépendants du navigateur. Ils ne sont de toute façon à ma connaissance pas libres;
pour aller plus loin, Wikipédia propose une liste plus complète de moteurs;

Notes

[1] référence nécessaire, j'ai vu ça dans une graphique sur un site de développeur Google, mais sans source et je ne le retrouve même plus. Si vous avez des infos...

[2] je n'ai pas encore testé les solutions qui génèrent automatiquement le code client depuis le langage serveur, comme Google Web Toolkit par exemple, j'avoue qu'elles m'attirent moins

A quand une plate-forme libre de partage de présentations ?

Clochix — Sat, 10 Oct 2009 23:58:00 +0200

Entre le Mozilla Camp de Prague et ParisWeb, beaucoup de présentations passionnantes ont été données ces derniers jours. Comme je ne me suis rendu ni à l'un ni à l'autre, je guette avec avidité l'apparition en ligne des supports... qui finissent toujours par arriver sur Slideshare, c'est à dire un site utilisant exclusivement Flash^[1]. C'est particulièrement ironique pour les présentations des Moziliens, alors que la Fondation ne cesse de promouvoir le Web Libre. Pour moi, Slideshare n'a rien à voir avec le Web Libre. Portant, depuis longtemps existent des outils permettant d'afficher en ligne des présentation en utilisant uniquement des technologies du Web : HTML, CSS, JavaScript. Par exemple S5 d'Eric Meyer ou Slidy du W3C. Alors a quand l'ouverture d'un site proposant les mêmes fonctionnalités que Slideshare, mais basé sur les technologies du Web Ouvert ? Le site de Mozilla pour les développeurs héberge déjà quelques présentations, cela pourrait être un bon début pour héberger des présentations sur l'Open Web utilisant ses technologies...

Oui, je sais, j'ai qu'à le faire, mais en l'occurrence le problème ne me semble pas tant technique que politique: il faudrait prendre la décision de lancer une telle plate-forme, le reste ne serait qu'un détail.

PS: et comme je suis un utopiste, est-ce que pour les vidéos, il n'y aurait pas moyen d'en avoir au moins une copie sur des sites offrant de l'Ogg Theora, comme Dailymotion, plutôt que de devoir utiliser des scripts GreaseMonkey pour regarder celles hébergées sur YouTube, Vimeo ou autre (et je ne parle pas des vidéos Flickr, je n'ai toujours pas réussi à regarder la cultissime I Love This Community!) ?

Notes

[1] et leur lecteur ne fonctionne ni avec Swfdec, ni avec Gnash, j'en suis réduit à utiliser mon hack pour réussir à les visualiser avec S5

De Mozilla et d'autres

Clochix — Thu, 08 Oct 2009 23:34:00 +0200

Actualités en plus de 140 caractères, où il sera question de Mozilla, d'un peu de 3D et d'un chouïa d'autres choses...

3D

Vladimir Vukicevic est un pionnier de l'utilisation de Canvas pour afficher de la 3D dans le navigateur. Avant de travailler sur l'implémentation de WebGL dans Firefox, il expérimentait depuis longtemps le développement d'une API JavaScript compatible avec OpenGL ES. Celle-ci était disponible via l'extension Canvas 3D (dont le développement a je crois à présent été arrêté). En s'appuyant sur cette extension, Cathy Leung a initié le projet C3DL dont le but est de fournir une bibliothèque JavaScript de haut niveau pour faire de la 3D dans le navigateur. WebGL prenant la suite de l'extension, le projet C3DL est en train de porter la bibliothèque. On pourra donc bientôt l'utiliser pour réaliser relativement facilement des animations en 3D dans tous les navigateurs implémentant WebGL ^[1].

De son côté, David Humphrey, un collègue de Cathy, a décidé d'utiliser C3DL pour ajouter la gestion de la 3D à Processing.js. Processing.js permet d'utiliser le langage Processing dans un navigateur en se basant uniquement sur JavaScript et Canvas. Processing est un langage de programmation orienté vers la création de graphismes fixes ou animés, en 2D et 3D. Il a été initialement développé pour créer des œuvres artistiques, et de nombreux artistes s'en servent. Mais il peut avoir de nombreuses autres usages, pour visualiser des données, ou dans le domaine éducatif, par exemple comme initiation à la programmation (un nouveau Logo). Processing nécessite normalement Java, mais John Resig, le fameux Ninja JavaScript, a commencé il y a quelques temps à écrire un interpréteur en JavaScript pour exécuter des programmes Processing directement dans le navigateur, sans machine virtuelle Java. David Humphrey se propose donc d'enrichir le projet des fonctions 3D de Processing, en utilisant C3DL. Le projet Processing for the Web est porté par la branche Education de la MoFo. Le but est à la fois d'améliorer les performance de JavaScript et de Canvas dans le navigateur, en s'appliquant à faire tourner au mieux les très nombreux programmes Processing existant, améliorer également Bespin, qui sera bien sûr l'IDE de choix pour développer, et de renforcer le Web Libre en élargissant sans cesse l'horizon de ce qu'il est possible de faire directement dans un navigateur avec des technologies libres et ouvertes. J'ai hâte de voir les premiers résultats, car Processing permet réellement de faire de jolies choses. Surtout, avec son résultat visuel, il donne envie d'apprendre à coder. J'espère que le projet pourra amener de nouvelles générations à la programmation.

Vracs de lézard

A Prague

BeFox publie un long compte-rendu du Mozilla Camp Europe 2009 qui a réuni 160 chanceux (donc de rares chanceuses, l'égalité est un long chemin) à Prague le ouikende dernier. La principale annonce à mon sens est la confirmation par Mike Beltzner que Mozilla va essayer d'adopter un cycle de développement plus court, pour sortir de nouvelles versions tous les 6 mois. Sont ainsi prévus Firefox 3.6 et 3.7 en 2010, puis le 4.0 (qui devrait inclure Electrolysis) et le 4.1 en 2011. La feuille de route pour ces versions est déjà relativement définie, avec notamment l'intégration native à Firefox de bon nombre de projets des laboratoires, disponibles actuellement sous forme d'extension;
Jan Odvárko a profité du même Camp pour faire une alléchante présentation des nouveautés de la prochaine version de Firebug (la 1.5). Au menu, la possibilité de ne pas effacer la console lorsqu'on recharge une page, de mettre des points d'arrêt sur les modifications du DOM (par exemple lorsqu'un attribut est modifié) et des propriétés des objets JavaScript, de mettre également des points d'arrêt conditionnels sur les XHR (en fonction de la valeur des arguments par exemple), un meilleur affichage de toutes les données échangées (avec par exemple des explorateurs JSON et XML pour le contenu des XHR)... Mais, surtout, et j'attends cela depuis des années, à la demande des développeurs de Firebug Firefox pourrait bientôt enfin disposer d'une interface pour lister les évènements attachés à un élément (un manque incompréhensible de l'API Events du DOM). Et Firebug proposer dans la foulée un nouveau panel listant tous les évènements définis dans une page. Et là, \o/ !
toujours au même Camp, Matthew Gertner a fait une présentation de Prism. Bien qu'existant depuis de nombreuses années, Prism est encore assez peu connu. C'est une version allégée de Firefox permettant de faire fonctionner une application Web dans son propre navigateur, réduisant ainsi un peu plus la frontière entre applications en ligne et applications "classiques". Avec Prism, vous pouvez par exemple utiliser un Webmail pratiquement comme un client de messagerie "lourd". Cette présentation est une bonne occasion de découvrir Prism si vous n'en aviez pas encore entendu parler;
Mark Surman continue à mener la réflexion autour de Drumbeat. A prague, sept idées de mini-campagnes sont nées, allez donc y jeter un œil pour voir si elles vous inspirent et si vous pouvez les relayer auprès de non-geeks de votre connaissance. On y trouve par exemple des réflexions sur les droits sur les photos partagées en ligne, sur comment expliquer l'OpenWeb à un enfant de 6 ans, ou l'idée de fixer une date pour la mort d'IE 6 (je propose la semaine dernière)...

Ca arrive la nuit

La plupart des brèves suivantes concernent les versions de développement de Firefox.

les balises <video /> permettent à présent d'afficher les films en plein écran, la fonctionnalité est accessible via le menu contextuel. Des travaux sont en cours pour accélérer l'affichage en plein écran en utilisant OpenGL;
deux nouvelles url spéciales sont arrivées, avec des informations utiles pour les développeurs : about:memory renseigne sur la consommation mémoire^[2] et about:support détaille la configuration : version exacte du navigateur, extensions installées, préférences modifiées par l'utilisateur... bref, toutes les informations utiles à joindre à un rapport d'anomalie;
à propos de mémoire, Atul Varma, dont je suis décidément fan, vient de créer une nouvelle version de l'outil d'inspection de la mémoire, sous la forme d'une extension. C'est joli, et nul doute que si vous développez une application Web ça pourra vous aider à détecter des fuites mémoires dans vos pages;
après Flash, Firefox 3.6 essaiera de vérifier que vous avez la dernière version de tous vos plugins. Cela utilisera un service Web, PFS2, installé sur les serveurs de Mozilla, capable de détecter la version de tous les plugins installés. Pour aider à le mettre au point, si vous utilisez des plugins peu communs, n'hésitez pas à visiter cette page^[3] pour vérifier qu'ils sont correctement détectés;
certains se souviennent peut-être que Firefox supporte les profils de couleurs ICC qui peuvent être dans les méta-données des photos. Depuis le 3.5, cette fonctionnalité est activée par défaut. Jeff Muizelaar a annoncé en juin que les prochaines versions utiliseraient pour cela un nouveau mécanisme, QCMS, qui apportera des gains en terme de sécurité et de vitesse. De nouveaux gains de performance viennent encore d'être obtenus, et l'affichage des photos avec un profil ICC pourrait être plus de dix fois plus rapide qu'actuellement. Les amateurs de belles photos apprécieront probablement;
grâce à CSS 3, on peut indiquer dans une feuille de style des URL de fontes à utiliser. Les prochaines versions de Firefox supporteront un nouveau format de fichier de fontes, WOFF, vous pouvez voir une démonstration ici, avec une nightly;
Firefox a franchi dans la nuit de mercredi à jeudi la barre des 300 millions de téléchargements (au passage on voit le gain de succès du navigateur, puisque le nombre total de téléchargements, toutes version confondues, est d'un peu plus d'un milliard);

Ailleurs

Validité - la hshouma, je ne connaissais même pas le projet Unicorn du W3C, alors qu'il a fait ses premiers pas depuis 2006. Unicorn, c'est un validateur universel : vous lui donnez une URL ou un ficher et il effectue en une seule passe tous les tests possibles de conformité aux standards : (X)HTML, CSS... le tout affiché de façon synthétique. Cerise sur la chantilly, le code est libre, vous pouvez donc le déployer sur un serveur de test et l'utiliser par exemple dans le cadre d'un processus d'intégration continue.

Accessibilité - ARIA (Accessible Rich Interactive Applications) est une norme définie par le W3C visant à rendre les applications web accessibles. Cela passe entre autres par l'ajout d'un attribut aux éléments HTML décrivant leur rôle. On pourra ainsi préciser qu'un élément LI sert d'onglet en lui attribuant le rôle tab : <li aria:role="tab">. La spécification définit 59 rôles. Microsoft de son côté a développé sa propre technologie, Microsoft Active Accessibility (MSAA). Elle utilise elle aussi la notion de rôle. 47 rôles ont des correspondances entre ARIA et MSAA. Sous Windows, les navigateurs peuvent ainsi relier certains rôles ARIA à MSAA, rendant les applications Web plus accessibles aux périphériques qui supportent MSAA. Selon le groupe Paciello, qui fait des études sur l'accessibilité, ce sont Firefox 3.6 et IE 8 (pour une fois) qui ont poussé le plus loin l'intégration d'ARIA et de MSAA, puiqu'ils font la correspondance pour 44 et 43 rôles. Les autres navigateurs testé, Opera, Webkit et Chrome, sont loin derrière. Ce qui signifie qu'actuellement sous Windows, les deux navigateurs qui fonctionnent le mieux avec les technologies d'assistance sont FF et IE. Quelqu'un aurait des infos sur l'accessibilité sur Mac ou UNIX-like (je présume que ça dépend du bureau) ?

HTML5 - J'avais loupé ce billet d'Eric Meyer sur HTML 5, où il explique que la texte propremetn dit de la spécification n'est pas destiné aux développeurs Web. En effet, il essaie de définir de la manière la plus précise toutes les caractéristiques "internes" du format, afin que les implémentations soient les plus proches possibles les unes des autres (on sait par exemple que des vides dans CSS 2 ont conduit à des implémentations conformes à la norme mais incompatibles entre elles). Environ la moitié du document est composé de notes décrivant précisément la façon dont la norme doit être implémentée. Eric et ses commentateurs pointent donc vers deux documents plus lisibles : une version de la norme sans les notes d'implémentation (ça reste quant même énorme...) et un extrait reprenant juste le détail des éléments HTML, donc en faisant abstraction de tout le reste, comme le stockage local et les fonctions spécifiques aux applications Web. Si vous êtes intégrateur, je pense que c'est par ce document qu'il vaut mieux commencer votre lecture.

Notes

[1] on me souffle d'ailleurs dans l'oreillette qu'après Safari et Firefox Google Chrome viendrait lui aussi de rejoindre le club. Ne manque plus qu'Opera et tous les navigateurs modernes offriront de la 3D.

[2] ça ne fonctionne pas encore sous GNU/Linux pour des problèmes d'édition de lien, et c'est pour l'instant assez rudimentaire, mais les bases sont là, et ça servira je pense surtout au projet Electrolysis, lorsque Firefox utilisera plusieurs processus

[3] attention, ce n'est pas la page définitive et vous aurez un message d'avertissement à propos du certificat de sécurité

Bidouiller le Web avec des Hooks

Clochix — Sun, 04 Oct 2009 17:49:00 +0200

Les Web Hooks sont une solution pratique pour bidouiller des applications Web côté serveur. Ils jouissent d'une popularité grandissante, et offrent de jolies perspectives. Si vous n'en avez pas encore entendu parler, voici une petite tentative d'introduction.

Nota : ce billet n'a rien d'original puisqu'il se contente de reprendre quelques idées développées par Jeff Lindsay, évangéliste des Web Hooks, sur son blog, dont je vous recommande évidemment la lecture.

Les hooks sont une technique de programmation classique par laquelle un logiciel définit une interface permettant à des composants externes d'étendre ou modifier son comportement. Par exemple, avant et après chaque action, le logiciel regarde si des modules complémentaires ont souhaité être avertis, et si oui il les appelle. Un des exemples les plus connus d'utilisation de hooks est sans doute les logiciels de gestion de source, comme Subversion, qui permettent de définir des actions à exécuter avant ou après chaque commande. Des logiciels comme Drupal, Dotclear, Wordpress... utilisent également ce mécanisme comme base de leur système d'extension. Dans Firefox, les Overlay sont des hooks.

On pourrait sans doute traduire hook par dérivation, comme dans un circuit électrique. Une application utilisant des hooks est dérivable, on peut facilement en modifier le flux standard pour le faire passer par d'autres chemins.

Je pense que c'est une condition de plus de la liberté d'une application: pour être réellement libre, un programme devrait être facilement extensible, dérivable, fournir des points où accrocher des modules additionnels sans devoir toucher à l'application elle-même. Si pour adapter un programme à ses besoins, on est obligé d'intervenir dans son code source, cela oblige à maintenir sa propre version du source, à recompiler l'ensemble à chaque nouvelle révision, etc. Ceux qui ont connu phpBB avant la version 3 se souviennent du cauchemar pour installer un module complémentaire : il fallait appliquer des modifications directement sur le code source, et on n'en finissait plus de devoir lutter avec les problèmes de compatibilité entre modules ou à chaque nouvelle version mineure du logiciel. Les hooks, en facilitant l'extensibilité du code, le rendent plus ouvert.

Cette solution n'est bien sûr pas parfaite. Parmi les problèmes qu'elle pose, j'en relève deux pour mieux appuyer la suite de mon billet:

sauf rare exception, les extensions doivent être écrites dans le même langage que l'application, ce qui implique que vous soyez relativement à l'aise avec ce langage. Certes des ponts existent entre différents langages^[1], mais ce sont souvent des solutions lourdes à mettre en œuvre;
elles nécessitent d'installer le module complémentaire, donc du code, sur le même serveur que l'application. Ce qui est rarement possible si vous utilisez une application hébergée. Par exemple, ce blog est hébergé par la plate-forme de Gandi, ce qui a quelques avantages mais m'empêche d'installer les extensions que je veux;

Une solution à ces deux point commence à poindre son nez : utiliser des Web Hooks pour étendre une application en ligne. Les Web Hooks ne sont rien d'autre que des pages web qui exécutent une action et peuvent éventuellement renvoyer un résultat. On peut les voir comme un sous ensemble des services web REST: on déclenche une action en appelant une URL via une requête GET ou POST, et on peut récupérer le résultat, ou pas.

Les Web Hooks sont une réponse relativement élégante à l'extensibilité des applications hébergées. Il suffit de permettre à l'utilisateur de spécifier des URL à appeler pour chaque hook défini dans l'application, en précisant si celle-ci doit attendre ou non un résultat. Dans le premier cas, le coût est élevé en terme de performances, car il faut compter avec la latence du réseau, gérer les indisponibilités, etc. Mais dans le second, le coût est faible, on se contente d'envoyer une requête sans se soucier du résultat. Les applications sont nombreuses, du simple ping d'un Hub pour annoncer la publication d'un contenu, à des interactions plus complexes entre applications, par exemple pour gérer les droits d'utilisateurs. Même si aucune API n'existe entre deux applications, on pourra aisément les faire communiquer via des hooks, avec un minimum d'intervention au niveau des serveurs qui les hébergent.

Les Web Hooks permettent également d'augmenter la réutilisabilité du code, à la manière de bibliothèques externes. Imaginons par exemple un service qui prenne en entrée un document au format Atom et le publie via le mécanisme PubSub de XMPP. Cet hook pourrait lui-même être appelé par des hooks déclenchés depuis Dotclear, WorPress, Status.Net et qui convertiraient juste les données en Atom. On peut ainsi mettre en place une architecture inspirée des commandes Unix, avec des hooks se contentant de tâches élémentaires et reliés les uns aux autres via des tuyaux.

Si vous voulez tester cette solution, un plugin pour WordPress, HookPress, permet déjà d'appeler des URL en réponse à certains évènements. tcWebHooks en fait de même pour TeamCity, un serveur d'intégration continue. Cette présentation montre l'utilisation de Web Hooks avec PBWiki et Yahoo Pipes. De plus en plus de service permettent d'utiliser cette technique : Google Code, github, Shopify (une boutique en ligne)...

En utilisant des Web Hooks, on peut ainsi étendre une application sans la modifier, et en utilisant le langage de son choix. Les hooks favorisent également les logiques de flux et facilitent les communications entre services.

Pour ce qui est de l'hébergement du hook, la meilleure solution est bien sûr de disposer d'un bout de serveur où installer ses scripts. Mais ce n'est pas une condition indispensable, car des solution en ligne existent et vont probablement se multiplier. Google AppEngine vous propose d'héberger des applications Python ou Java^[2] directement sur les serveurs de Google. L'hébergement propose de plus des bibliothèques offrant des fonctions spécifiques au contexte. Feu AppJet, qui a hélas fermé le 1er juillet 2009, proposait lui d'héberger des applications écrites en JavaScript (je reviendrai très bientôt sur le retour de JavaScript sur le serveur). Techniquement, il utilisait je crois le moteur JavaScript Rhino, développé en Java par Mozilla, en le faisant tourner au dessus d'AppEngine. AppJet offrait de plus un IDE en ligne et des bibliothèques spécifiques. En se basant sur la même architecture, et suite à la fermeture d'Appjet, Jeff Lindsay a lancé Scriptlets, dont le code source est disponible. Il se base lui aussi sur AppEngine et supporte pour l'instant JavaScript, PHP et Python. J'ai également découvert le service hookhup qui héberge des scripts JavaScript. Si vous en connaissez d'autres, n'hésitez pas à les signaler dans les commentaires.

Avec Bespin, qui permettra bientôt de disposer d'un véritable environnement de développement complet en ligne, on dispose de pratiquement toutes les briques pour que les Web Hooks prennent leur envol. Et j'espère que ça sera le cas. Car je vois à ce type de plateforme un intérêt majeur : permettre de bidouiller très facilement le Web côté serveur. Il suffit d'écrire un script dans son langage de prédilection, de le déposer sur un serveur, et d'enregistrer l'URI du hook dans l'application que l'on veut modifier. De même que de nouveaux outils rendent chaque jour plus simple la bidouille en JavaScript dans le navigateur, le Web Hook permettent d'expérimenter sur le serveur. Avec un minimum de connaissances, aidé par un IDE en ligne, on va pouvoir commencer à écrire des petits bouts de code pour modifier et étendre les applications en ligne que l'on utilise. C'est un pas de plus dans la ré-appropriation du Web. Et c'est à ce titre que les Web Hook sont pour moi une des briques de l'Open Web. Pour participer, ll ne vous reste plus qu'à rendre vos applications Web dérivables...

Notes

[1] par exemple jsbridge entre JavaScript et Python, ou PHP/Java Bridge

[2] et par extension dans les langages pour lesquels il existe un interpréteur en Java, comme Ruby via JRuby, JavaScript avec Rhino, etc

Content Security Policy : les prochains Firefox seront mieux protégés contre les XSS

Clochix — Sun, 04 Oct 2009 00:31:00 +0200

Brandon Sterne, qui travaille sur la sécurité de Firefox, vient d'annoncer que des versions de développement de Firefox intégrant la spécification Content Security Policy sont disponibles depuis quelques jours. Cette spécification est une proposition de Mozilla pour renforcer la sécurité des navigateurs contre les attaques de type XSS.

XSS

Les attaques XSS, ou Cross Site Scripting sont parmi les plus courantes sur le réseau. Elles consistent à faire s'exécuter un script, généralement JavaScript, par le navigateur. Imaginons pas exemple un blog qui autoriserait le HTML dans les commentaires sans filtrer les saisies. On pourrait ainsi insérer des scripts dans les commentaires. Ces scripts s'exécuteraient dans le navigateur de toute personne consultant le commentaire comme s'ils étaient des scripts légitimes de l'application. A partir de là, tout est possible, le script peut effectuer toutes les opérations autorisées à l'utilisateur. Si l'administrateur du blog consulte un commentaire piégé, le script pourra par exemple effacer les billets, modifier les droits d'accès au blog, etc. Le jeu pour les auteurs de ce type de script consiste à contourner les protections mises en place au niveau serveur pour réussir à insérer du code qui s'affichera et s'exécutera dans le navigateur des utilisateurs. Par exemple en cachant le code dans l'URL d'une image ou d'un lien. Ces attaques utilisent le fait que le navigateur fait confiance par défaut à tout le contenu en provenance du site Web.

Content Security Policy

Pour y remédier, CSP propose une approche basée sur le principe d'une liste blanche : le site liste explicitement les contenus légitimes. Si un site indique qu'il utilise CSP, le navigateur ne fera donc confiance qu'aux scripts contenus dans cette liste blanche et refusera d'exécuter les autres.

CSP a en fait une double fonction:

il essaie de prévenir l'exécution de code non désiré, et protège donc les utilisateurs;
lorsqu'il détecte une tentative de violation des politiques de sécurité, il en informe le site. Les responsables de celui-ci peuvent donc être rapidement prévenus de toute tentative d'attaque contre leur site, et prendre les mesures pour la bloquer;

Un site indique au navigateur qu'il implémente CSP via l'entête HTTP X-Content-Security-Policy. Celui-ci peut soit contenir la description de la politique, soit l'URI d'un document la décrivant.

Les politiques ne s'appliquent bien sûr qu'aux contenus chargés depuis un site distant, pas aux extensions ou aux scripts locaux de l'utilisateur (type bookmarklets).

Un prototype de CSP a d'abord été implémentée sous forme d'une extension, avant d'intégrer récemment le cœur de Firefox. Les politiques de sécurité seront donc disponibles dans une des prochaines versions du navigateur, la 3.6 ou la 3.7.

Comportement par défaut

CSP implémente un certain nombre de politiques par défaut, qui peuvent être débrayées. Sont donc interdits :

l'exécution de code placé directement dans la page, que ce soit au sein de balises script, dans les liens (<a href="javascript..." />) ou les gestionnaires d'évènements (onclick...)^[1];
l'exécution de code à partir d'une chaîne de caractère, donc par exemple l'utilisation de la fonction eval;
l'utilisation d'URI de type data:...;
les binding XBL, hormis ceux provenant du chrome (je crois que Firefox est le seul navigateur à implémenter XBL, donc si vous ne comprenez pas ce que ça veut dire, ça n'est pas bien grave);

La politique de sécurité permet ensuite de définir, pour chaque type de contenu (script, images, etc), les URI à partir desquelles le navigateur est autorisé à télécharger le contenu.

Syntaxe

Une politique de sécurité se compose de directives, séparées par des point-virgules. Chaque directive comporte un nom et une liste de valeurs, séparées par des espaces. Les directives disponibles sont:

allow définit la politique par défaut. Elle doit toujours être définie;
options permet de définir... des options. Pour l'instant seules deux valeurs sont possibles : eval-script pour autoriser les fonction de type eval, et inline-script, pour permettre la présence de code directement dans la page;
font-src pour la source des fontes chargées via la propriété CSS font-src;
frame-src pour la source des frames et des iframes;
img-src pour la source des images et de la favicon;
media-src pour la source des éléments audio et video;
object-src pour la source des éléments applet, embed et object;
script-src pour la source des scripts
style-src pour la source des feuilles de style externes;
xhr-src pour les requêtes XMLHttpRequest;
frame-ancestors définit les sources autorisées à afficher le contenu à l'intérieur d'une frame. Cela permet donc d'interdire qu'une page soit insérée dans une autre à l'aide d'une iframe (une technique couramment utilisée dans les attaques par clickjacking);
policy-uri : URI d'un fichier contenant la description de la politique;
report-uri : URI où envoyer un rapport en cas de tentative de violation d'une règle

La source peut être soit self, soit none soit une URI. self signifie que ne sont autorisés que les contenus délivré par le même scheme, le même hôte et le même port. Les URI peuvent contenir des méta-caractères, par exemple *.mozilla.org.

Par défaut, les sites ne peuvent pas mélanger de contenu sécurisé et non sécurisé. Pour l'autoriser, il faudra le déclarer explicitement, par exemple:

X-Content-Security-Policy: allow http://*.clochix.net https://*.clochix.net

La description des politiques de sécurité et le comportement à adopter en cas de violation peuvent être décrits dans des documents externes, via policy-uri et report-uri, mais ceux-ci doivent avoir la même origine que le document auquel elles s'appliquent;

Enfin, la spécification précise de plus le comportement à adopter en présence de plusieurs plusieurs politiques.

Les rapports

Si le navigateur détecte qu'une page essaie de violer une des règles définies, il peut envoyer via une requête HTTP POST, un rapport à l'URI définie via report-uri. Ce rapport est un document XML.

Les rapports contiennent la requête avec tous ses entêtes, l'URI du contenu bloqué, la directive à l'origine du blocage, et l'ensemble des directives appliquées. Un rapport pourra ressembler à

<csp-report>
 <request>GET /index.html HTTP/1.1</request>
 <request-headers><![CDATA[
          Host: example.com
          User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9) Gecko/2008061015 Firefox/3.0
          Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
          Accept-Language: en-us,en;q=0.5
          Accept-Encoding: gzip,deflate
          Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
          Keep-Alive: 300
          Connection: keep-alive
 ]]></request-headers>
 <blocked-uri>http://evil.com/some_image.png</blocked-uri>
 <violated-directive>img-src self</violated-directive>
 <original-policy>allow none; img-src *, allow self; img-src self</original-policy>
</csp-report>

Ce qui signifie qu'une page a essayé de charger une image depuis un site externe, alors que seules les images du site d'origine sont autorisées.

Pour faciliter la mise au point des directives, on pourra remplacer X-Content-Security-Policy par X-Content-Security-Policy-Report-Only. Dans ce cas le navigateur se contentera d'envoyer des rapport sans bloquer le contenu qui viole la directive.

Exemples

Autoriser l'exécution de code placé directement dans la page:

X-Content-Security-Policy: allow 'self'; script-src inline;

X-Content-Security-Policy: allow 'self'; options inline-script;

Autoriser l'utilisation des fonctions qui exécutent du code à partir d'une chaîne de caractère:

X-Content-Security-Policy: allow 'self'; script-src eval;

X-Content-Security-Policy: allow 'self'; options eval-script;

Autoriser les images à utiliser le scheme data: :

X-Content-Security-Policy: allow self; img-src data;

Autoriser les images de toute origine, les plugins de certains sites, les sites uniquement depuis le domaine trustedscripts.example.com et le reste du contenu uniquement depuis le serveur d'origine:

X-Content-Security-Policy: allow 'self'; img-src *; \
                           object-src media1.com media2.com *.cdn.com; \
                           script-src trustedscripts.example.com

N'autoriser que le contenu sécurité par SSL:

X-Content-Security-Policy: allow https://*:443

Pour aller plus loin

Outre le Content Security Policy trois autres projets sont en cours pour renforcer la sécurité de Firefox :

Origin vise à prévenir les attaques dites CSRF. Celles-ci consistent à obtenir du navigateur qu'il effectue une requête déclenchant une action. Par exemple si l'utilisateur est connecté à un webmail, on essaiera de lui faire afficher une image dont l'URL correspond à une action du webmail. Le navigateur, pour récupérer l'image, exécutera la requête et déclenchera l'action. Les CSRF ne fonctionnent que pour les actions accessibles via des requêtes HTTP GET$$pour celles nécessitant un HTTP POST, existent des attaques proches, le vol de clic (clickjacking), qui consistent à amener l'utilisateur à cliquer sur un bouton qui déclenchera le POST. Pour lutter contre les CSRF, Brandon Sterne et les équipes de Mozilla proposent que dans certains cas, le navigateur ajoute aux entêtes qu'il envoie au serveur l'origine de la requête (le site d'où elle provient), charge au serveur de déterminer s'il accepte de la traiter ou non. La proposition est en cours de soumission à l'IETF pour devenir un standard et un prototype est attendu pour la fin 2009.

Force-TLS propose aux sites d'ajouter un entête HTTP indiquant qu'ils ne doivent à l'avenir être contactés que via une connexion HTTPS. Un prototype est disponible sous la forme d'une extension.

Le "gros" morceau est bien sûr Electrolysis qui vise à utiliser des processus séparés pour l'affichage du navigateur, des pages et des plugins, afin de circonscrire au maximum les potentiels problèmes (plantages ou attaques).

En conclusion

La mise en œuvre de politiques de sécurité via le Content Security Policy ne sera pas forcément simple, car pour être efficace il faudra appliquer des règles strictes, et bon nombre d'applications existantes devront être modifiées pour en tirer partie. Mais à terme, cela ne peut que s'avérer payant, car cela fournit un garde-fou précieux contre bon-nombre d'attaques.

Il ne reste plus qu'à espérer que la spécification soit reprises par les autres fabriquants de navigateurs et devienne une norme.

Ajout du 07.10 : billet de Chris Blizzard sur HMO

Notes

[1] en terme d'accessibilité, il est cependant recommandé de préférer les onclick aux addEventListener pour exécuter du code, afin qu'un lecteur d'écran par exemple sache que le clic sur un élément déclenche une action. Mais ce n'est qu'un pis-aller. La vrai solution passe par l'utilisation de WAI-ARIA pour indiquer le rôle de l'élément

Vrac du vendredi

Clochix — Sat, 03 Oct 2009 00:02:00 +0200

Devinette : qui a déclaré Nous réalisons également une économie de charges salariales de 62 000 euros par ans, grâce à l'engagement de (...) bénévoles. ? Un quelconque patron voyou ? Presque. C'est en fait une ancienne candidate à l'élection présidentielle, dans un communiqué à propos d'une des meilleures blague de l'année, son nouveau site. Par économie de charges salariales faut-il comprendre licenciements ? En tout cas, elle fait preuve de modernisme, remplacer des emplois payés par des stagiaires ou des bénévoles est dans l'air du temps. Quant à qualifier de charges les salaires, cela ne laisse guère de doute sur le camp dans lequel se situe l'auteure du communiqué : sûrement pas celui des travailleurs.

J'avais déjà lu de nombreuses critiques du livre Comment le peuple juif fut inventé, de l'historien Shlomo Sand. Celle que donne Matthieu Calame au site La vie des idées sous le titre Aux origines du roman national israélien est d'autant plus passionnante qu'elle ne se focalise pas sur la seule question de la nation israélienne, mais fait une large place à l'analyse du concept de nation. J'ai particulièrement apprécié cet extrait de l'analyse [Hans] Kohn considère en effet deux familles de nationalismes aux effets radicalement différents : d’une part, un nationalisme libéral et civique, de cooptation, insistant sur l’adhésion volontaire et consciente de l’individu à la nation (...); d’autre part, un ethnonationalisme, essentialiste, biologisant et « volkiste », pour lequel l’appartenance de l’individu à la nation est prédestinée. Cette conception triomphera en Europe centrale et orientale, dans des États où les élites aristocratiques, sur la défensive au sein de leur « empire », privilégieront un nationalisme sans démocratie. A votre avis, à laquelle ce ces deux visions de la nation se réfèrent des gens capable de créer un ministère pour défendre l'identité nationale ?

Entendu jeudi sur Intox, un bout d'interviou de salariés de France Telecom. Un petit chef qui menace de retirer une journée entière de salaire à ceux qui prennent part à une minute de silence en mémoire d'un de leur collègue suicidé, un autre petit chef qui, à propos d'un travailleur qui s'est jeté d'un pont, plaisante qu'il avait sans doute juste oublié son élastique... Avoir renommé en "manager" les petits chefs et autres caporaux n'y change rien: l'exercice du pouvoir, aussi minuscule soit-il, permet souvent à la connerie de donner sa pleine mesure.

le premier ministre britannique a récemment présenté des excuses pour ce qu'avait subi Alan Turing il y a à peine quelques dizaines d'années. Alan Turing était un mathématicien et l'un des pères de l'informatique moderne. Nos amis électroniques lui doivent beaucoup. Malheureusement, ses travaux ont été brutalement interrompus lorsqu'il s'est suicidé en 1954. Il avait deux ans auparavant été condamné à la castration chimique pour homosexualité. Oui, en ces âges barbares, dans ce pays sous-évolué, l'homosexualité était un crime, passible de prison ou de la castration chimique. Heureusement, nous vivons une époque moderne, dans un pays évolué. Cela ne risque plus d'arriver. Si on doit recourir à la castration chimique, cela ne concernera que les délinquants sexuels les plus dangereux, ceux dont on fiche également l'empreinte génétique. Ah bon, maintenant on peut ficher les empreintes génétiques d'à peu près tout le monde ???

Introduction à Atom et AtomPub

Clochix — Fri, 02 Oct 2009 16:48:00 +0200

Si le format de diffusion Atom est assez connu, comme alternative à RSS, le protocole AtomPub l'est un peu moins. La littérature sur le sujet est abondante, mais comme je n'ai pas trouvé de résumé succinct je vais m'y essayer.

Atom désigne donc deux choses :

un format de document destiné à la diffusion (syndication) de contenus. Ce format est défini par la RFC 4287;
un protocole de gestion de ressources à travers un réseau, décrit dans la RFC 5023;

Le format Atom

C'est un vocabulaire XML. Il définit deux classes d'objets:

des items (entry) représentant des contenus;
des flux (feed) qui sont des listes d'items;

Le vocabulaire permet d'indiquer de nombreuses méta-données sur les items et les flux (titre, auteurs, catégories, liens, etc). L'utilisation d'XML le rend extensible, c'est à dire qu'on peut l'enrichir de données issues d'autres vocabulaires (par exemple en utilisant Dublin Core. Les flux ATOM sont largement utilisés pour représenter les derniers billets de journaux par exemples.

Le protocole Atom alias AtomPub

C'est un protocole de gestion de ressources accessibles en ligne. Il utilise HTTP pour transporter et gérer des données au format Atom. Il exploite de ce fait toutes les caractéristiques des architectures REST.

Ces principales caractéristiques sont:

on appelle ressource n'importe quel objet accessible en ligne et identifiable via une IRI;
AtomPub permet de créer, lister, mettre à jour et supprimer des ressources;
les ressources peuvent être regroupées dans des collections. Une collection est un ensemble de liens vers des ressources. Celles-ci peuvent être des items Atom (on parle d'Entry Resource) ou des "médias" (Media Resource), appellation générique pour les autres formats. A chaque média sera associé un item avec ses méta-données. La représentation d'une collection est un flux Atom;
les collections peuvent elles même être regroupées au sein d'espace de travail (workspace). Ces workspaces sont virtuels, au sens où ils n'ont pas d'IRI, et le protocole ne dit rien de leur administration (ie ne permet pas de créer un wokspace ou une collection). Les workspaces sont eux-même regroupés dans des services;
on peut découvrir la liste des collections disponibles via un type de ressources particulier, les services. Chaque collection peut être rattachée à plusieurs services;
AtomPub permet de définir des critères d'ajout d'une ressource à un collection, en fonction de son type ou de sa catégorie (une collection pourra n'accepter que certains formats de médias ou que des items appartenant à une catégorie). Le protocole permet également de découvrir la liste des catégories existantes;

La spécification, outre le protocole, définit donc également un vocabulaire XML pour lister les catégories disponibles, les services, espaces de travail et collection. Voici, extrait de la spécification, un exemple de document listant les espaces de travail et les collections disponibles pour un service:

 <?xml version="1.0" encoding='utf-8'?>
 <service xmlns="http://www.w3.org/2007/app" xmlns:atom="http://www.w3.org/2005/Atom">
  <workspace>
    <atom:title>Main Site</atom:title>
    <collection href="http://example.org/blog/main" >
      <atom:title>My Blog Entries</atom:title>
      <categories href="http://example.com/cats/forMain.cats" />
    </collection>
    <collection href="http://example.org/blog/pic" >
      <atom:title>Pictures</atom:title>
      <accept>image/png</accept>
      <accept>image/jpeg</accept>
      <accept>image/gif</accept>
    </collection>
  </workspace>
  <workspace>
    <atom:title>Sidebar Blog</atom:title>
    <collection href="http://example.org/sidebar/list" >
      <atom:title>Remaindered Links</atom:title>
      <accept>application/atom+xml;type=entry</accept>
      <categories fixed="yes">
        <atom:category scheme="http://example.org/extra-cats/" term="joke" />
        <atom:category scheme="http://example.org/extra-cats/" term="serious" />
      </categories>
    </collection>
  </workspace>
 </service>

On ne pourra ajouter à la liste des images du blog que des images aux formats PNG, JPEG et GIF; on ne pourra ajouter à la liste des liens du blog que des items Atom des catégories joke et serious.

Exemple de création de contenu avec AtomPub

Un échange classique pourra suivre ce scénario:

envoi d'une requête GET à l'adresse d'un service;
le serveur répond par la liste des collections disponibles, éventuellement regroupées en ''workspaces';
envoi d'une requête GET à l'adresse d'une collection;
le serveur répond avec un flux (feed Atom) listant les éléments de la collection (la liste peut être partielle et paginable. Elle contiendra dans ce cas des liens vers les URI des pages précédente et suivante);
le client crée une nouvelle ressource à l'intérieur d'une collection en POSTant un document à l'adresse de la collection;
le serveur répond avec l'adresse de la ressource créée;
le client peut alors gérer la ressource en envoyant GET, PUT ou DELETE à son adresse;

Création d'une ressource de type "média"

Comme pour un item Atom, il suffit pour créer un média quelconque de le poster à l'adresse de la collection. Le serveur va enregistrer la ressource selon son mécanisme propre (un fichier, dans une base de données, etc), et créer un item Atom contenant un lien vers l'URI de la nouvelle ressource, puis renvoyer cet item au client.

Les liens

Une entrée Atom peut comporter un certain nombre de liens, dont la signification est précisée via leur attribut rel :

alternate pour un lien vers une version alternative de la même ressource;
related pour un sujet lié;
self pour donner l'IRI de la ressource elle-même;
enclosure pour pointer vers des documents "lourds" (par exemple des fichiers);
via désigne la source de l'information;

AtomPub ajoute deux types de liens :

edit contient l'IRI à utiliser pour éditer la resource;
edit-media lorsque l'entrée correspond à un média;

Pour aller plus loin

Deux autres spécifications, moins connues, étendent le format Atom.

La RFC 4685 permet de définir les liens entre des contenus au sein d'un fil de discussion (thread). Elle ajoute au format Atom deux éléments et un type de lien:

les éléments in-reply-to pointent vers les ressources auxquelles le contenu répond;
à l'inverse, les liens de type replies pointent vers les réponse à un contenu. Par exemple, dans le cas d'un billet de blog, vers les commentaires de premier niveau. Un flux ou une entrée peuvent avoir plusieurs liens vers leurs réponses. Ces liens peuvent également avoir deux nouveaux attributs de premier niveau: count indiquant le nombre de réponses dans la ressource, et updated avec la date de la réponse la plus récente;
enfin, un élément total permet d'indiquer le nombre total de réponses connues;

Un flux contenant un billet et un commentaire pourrait ressembler à :

<feed xmlns="http://www.w3.org/2005/Atom" xmlns:thr="http://purl.org/syndication/thread/1.0">
  <id>http://www.example.org/myfeed</id>
  <title>My Example Feed</title>
  <updated>2005-07-28T12:00:00Z</updated>
  <link href="http://www.example.org/myfeed" />
  <author><name>James</name></author>
  <entry>
    <id>tag:example.org,2005:1</id>
    <title>My original entry</title>
    <updated>2006-03-01T12:12:12Z</updated>
    <link type="application/xhtml+xml" href="http://www.example.org/entries/1" />
    <link rel="replies" type="application/atom+xml" href="http://www.example.org/mycommentsfeed.xml" thr:count="1" thr:updated="2005-07-28T12:10:00Z" />
    <thr:total>1</thr:total>
    <summary>This is my original entry</summary>
  </entry>
  <entry>
    <id>tag:example.org,2005:1,1</id>
    <title>A response to the original</title>
    <updated>2006-03-01T12:12:12Z</updated>
    <link href="http://www.example.org/entries/1/1" />
    <thr:in-reply-to ref="tag:example.org,2005:1" type="application/xhtml+xml" href="http://www.example.org/entries/1"/>
    <summary>This is a response to the original entry</summary>
  </entry>
</feed>

La RFC 4946, expérimentale, propose de permettre d'indiquer la licence d'un contenu via l'utilisation d'un nouveau type de liens. Par exemple, pour un contenu sous CC-BY-NC on pourrait avoir <link rel="license" type="application/rdf+xml" href="http://creativecommons.org/licenses/by-nc/2.5/rdf" />;

Bref

Atom et AtomPub fournissent les bases nécessaires pour gérer tout type de contenu accessible en ligne. Leur caractère ouvert permet de plus de les adapter facilement à des contraintes spécifiques. Je ne peux donc que vous encourager à les utiliser chaque fois que vous aurez besoin de manipuler des contenus. A noter toutefois qu'AtomPub est moins mature, et mériterait peut-être quelques ajouts. J'apprécierais par exemple de pouvoir avec les mêmes mécanismes gérer également les services et les collections.