Comment répondre

Il n’aura échappé à personne que je développe actuellement une application Web pour lire des articles depuis mon ordiphone. Elle a deux fonctions : stocker des articles pour me permettre de les lire plus tard, et les rendre lisibles sur le minuscule écran de mon téléphone. Pour répondre au premier besoin, enregistrer simplement les pages Web serait suffisant. Mais hélas bien souvent elles ne sont pas adaptées à de petits écrans. Je les passe donc à travers une moulinette, une des nombreuses bibliothèques implémentant un algorithme d’extraction du texte de l’article, et j’enregistre le résultat. De ce fait, je consulte de moins en moins le Web lui-même. Je reçois des liens via divers canaux, en extrait automatiquement le contenu et le lis non plus dans un navigateur, mais dans une application tierce (en l’occurrence une application exécutée à l’intérieur d’un navigateur, mais c’est un hasard).

Je réfléchis également, à la suite de David, à la convivialité (au sens d’Illich) de mes outils. Ou plus exactement j’essaie de déterminer s’ils me rendent plus autonomes ou m’asservissent.

Mon flux de travail me permet de me concentrer sur l’essentiel, le contenu, en gommant l’accessoire, mises en page et décorations qui pourraient me distraire. Mais il me fait perdre un élément fondamental du Web, la possibilité d’interagir. Lorsque je veux répondre à un article, je ne peux pas le faire depuis mon outil, parce que lui-même ne sait pas comment faire. Il me faut ouvrir la page initiale pour essayer de découvrir les possibilité d’interaction : commentaires, liste de discussion par courriel, ping depuis une réponse hébergée ailleurs…

En fait, il me semble que nous n’avons pas encore de moyen simple d’indiquer à des agents automatiques comment réagir à un contenu. Dans le balisage de ce carnet, j’utilise la propriété bug-database du vocabulaire DOAP pour indiquer l’URL du gestionnaire de tickets. À partir de cette info, et en identifiant le gestionnaire cible, un agent automatique pourrait proposer de saisir un ticket. Par exemple un navigateur pourrait proposer un bouton « signaler un problème sur ce site ». J’ai déjà développé ce point.

De manière similaire, il faudrait un vocabulaire décrivant le moyen de répondre à un contenu. Ainsi, un outil comme le mien qui affiche le contenu dans un autre contexte, pourrait proposer un formulaire universel de réponse qui enverrait automatiquement mon commentaire en utilisant le protocole choisi par le contenu initial : requête POST, message électronique, pingtrackback

Bref, il nous faudrait expliciter aux robots comment, non plus seulement lire, mais interagir avec nos contenus.

MDNHub, browse the Web documentation locally

(Version française en dessous).

English version

MDNHub is a HTML application that allows to browse a local copy of the wonderful Web documentation hosted on Mozilla Developer Network. The application consists only in some HTML, JavaScript and CSS, so you only need a browser, no server. Just copy mdnhub.html somewhere on your disk and open it with a Web browser. You can also use the page hosted by GitHub.

It creates a local copy of sections of MDN, either by crawling the site and saving it into a local database, or by importing some hand-made archives.

Bugs and restrictions

  • there is no full-text search (the underlying technology, IndexedDB, doesn’t support full-text search for now. I may later try to add search with a third party library). Articles can only be filtered on their title;
  • some pages from MDN are missing, this is often due to CORS headers missing on some pages;
  • there are some duplicates in the database, this reflects duplicates inside MDN (same content under different URL). Removing this duplicates shouldn’t be to hard;
  • import is slow, it needs improvements;
  • when you have a few thousand documents inside your database, the full export may run your browser out of memory. You can export a subset of the database limited to URLs containing a string by calling exportDatabase(string) into a JavaScript console;

Tips

  • you can import any URL with CORS enabled. Just fill the URL in the option form, and a pattern. It will crawl the page and all linked pages whose URL matches the pattern. If no pattern is given, it should limit the capture to the page itself;
  • every documentation item has its own hash, so you should be able to navigate inside history, and bookmark pages;
  • you could try to import documentation from other sources by scraping it by hand into a well formed JSON file and importing it. Here’s the file format: { “http://www…”: { “title”: “My page”, “content” “Some HTML content” }, … }
  • you can use a portable version of the application, with CSS and JavaScript inline. See mdnhub.html;

Legals

This application is not in any way affiliated with Mozilla. The application is hacked-with-love by Clochix. The source code is available under the AGPL License. It also uses forked version of the asyncStorage library available under an Apache license. The contents are extracted from MDN and available under the following licenses.

French version

MDNHub est une application HTML qui permet de consulter une copie locale de l’excellente documentation Web hébergée sur Mozilla Developer Network. C’est une application utilisant uniquement HTML, JavaScript et CSS, vous n’avez besoin pour l’utiliser que d’un navigateur, il n’y a rien à installer sur un serveur. Il suffit de copier le fichier mdnhub.html quelque part sur votre disque et de l’ouvrir. Vous pouvez également utiliser la version hébergée sur GitHub.

Elle crée une copie locale des sections de MDN, soit en aspirant le site, soit en important des archives pré-aspirées.

Problèmes et limitations

  • pour l’instant, la recherche est limitée aux titres des pages. La technologie utilisée pour stocker les pages localement, IndexedDB, ne permet pas encore de faire de recherche dans le contenu des pages. J’essaierai éventuellement un jour d’ajouter une telle recherche si je trouve une bibliothèque le permettant avec des pré-requis raisonnables ;
  • certaines pages de MDN ne peuvent pas être capturées, car elles ne renvoient pas les entêtes CORS. D’autres sont dupliquées dans la base, lorsqu’elles existent à plusieurs URLs différentes sur le site ;
  • l’import est lent, il y aurait probablement moyen de l’améliorer ;
  • si votre base est grosse, l’export va demander beaucoup de mémoire et risque de faire planter votre navigateur. Vous pouvez limiter l’export aux URL contenant une chaine en tapant par exemple dans une console JavaScript exportDatabase("CSS"); ;

Trucs et astuces

  • vous pouvez importer n’importe quelle URL accessible via CORS. Il suffit de saisir l’URL dans le champs ad hoc des contrôles. Par défaut, seule cette URL devrait être importée. Si vous saisissez également un motif, l’application suivra les liens dans la page contenant ce motif ;
  • chaque page de documentation à une URL propre au sein de l’application, vous devriez donc pouvoir utiliser des signets et l’historique de navigation ;
  • vous pouvez essayer d’importer de la documentation extraite d’autres sites en l’extrayant à la main et l’enregistrant dans un fichier JSON, puis en important ce fichier. Le format de fichier est : { “http://www…”: { “title”: “My page”, “content” “Some HTML content” }, … }
  • vous pouvez utiliser une version portable de cette application, comprise entièrement dans le fichier mdnhub.html ;

Blabah administratif

Cette application n’est en rien affiliée à Mozilla. Elle est bidouillée avec amour par Clochix, et sa recette est disponible sous la licence AGPL. Elle utilise une version modifiées de la bibliothèque asyncStorage, disponible sous la licence Apache. Les contenus extraits de MDN sont disponibles sous ces licences. </section>

Gloubiboulga et serveur

C’était cette après-midi. Je faisais la vaisselle, cherchant une excuse pour retourner devant le clavier. C’est alors que m’est venue cette Révélation, que je me suis empressé d’aller gazouiller : « Je me suis trompé sur le Web. J’aime HTTP, mais ça reste un protocole client-serveur, donc fondamentalement centralisateur. Toute solution impliquant d’installer un serveur est réservée à une élite, donc ne peut être émancipatrice. Il nous faut remettre l’intelligence à la marge, dans les mains des gens, dans leurs ordiphones plutôt que sur des serveurs, fussent-ils Web. » Plusieurs d’entre vous ayant eu la gentillesse de répondre, je vais développer un peu plus le contexte.

Lorsque j’ai reçu il y a quelques mois mon FirefoxPhone, je me suis dit que ça allait enfin être l’occasion de pouvoir lire les Internets pendant les interminables heures que je passe dans les transports. Je me suis donc mis à la recherche d’une application Web libre pour lire sur ordiphone en étant déconnecté. On m’a rapidement conseillé Poche, mais j’ai tout aussi promptement décidé qu’il ne convenait pas à mon besoin. Poche est une application PHP qu’on installe sur un serveur. Je ne veux plus installer d’applications PHP sur mes serveurs. Ni Ruby ou Python d’ailleurs. Parce qu’héberger une telle application demande une vigilance quotidienne. Il suffit d’être déconnecté ou occupé ailleurs quelques jours pour louper l’annonce d’une faille critique dans le logiciel ou la pile sous-jacente, et perdre le contrôle de son serveur et ses données. Sans même parler de faille, des évolutions des plateformes peuvent modifier les réglages par défaut et nécessiter de reconfigurer les applications. Mes priorités actuelles font que je n’ai plus beaucoup de temps à consacrer à ça. Je m’astreins à des apt-get upgrade quotidiens de toutes les machines dont je m’occupe, mais ça ne va pas plus loin. Je ne veux plus installer d’applications ouvertes au monde sur mes serveurs. Et les journaux de mes serveurs Web me confortent dans mon choix, à chaque fois que de nouvelles tentatives par des robots d’accès à certaines URLs m’informent d’une probable nouvelle faille dans phpMyAdmin ou Wordpress.

La sécurité informatique est un domaine trop sérieux pour le confier à des machines, c’est pourquoi je ne crois plus guère qu’apparaitra un jour un jour un serveur d’auto-hébergement grand public, fonctionnant tout seul sans demander d’interventions expertes.

Ce que je veux aujourd’hui, ce sont des applications qui fonctionnent directement sur les périphériques que j’utilise, qui soient faciles à installer, utilisables par quiconque, et relativement sécurisées.

C’est pour cela que je suis en train de créer mon propre lecteur hors-ligne, Àlir (et aussi, je l’avoue, parce que je n’aime rien autant que réinventer la roue et utiliser des versions cuisinées à la maison des logiciels prêts à porter). Il peut fonctionner de manière complètement autonome sur un FirefoxPhone, sans nécessiter le moindre composant sur un serveur. Il suffit de l’installer sur le terminal et de lui envoyer des articles depuis le butineur. Alternativement, on peut également le synchroniser via le génial protocole remoteStorage, ce qui permet de pousser des articles vers l’application depuis n’importe quelle source capable d’envoyer un POST (j’utilise actuellement une extension Firefox et une macro Mutt pour faire le boulot). La synchronisation nécessite dans ce cas de passer par un serveur, on a le choix entre installer son propre serveur remoteStorage, en utiliser un d’un prestataire commercial comme 5apps ou utiliser un compte Dropbox ou Google Drive, avec lesquels remoteStorage est compatible.

Mais je m’éloigne.

Second exemple de ma nouvelle croisade Sans Serveur. Comme je le signalais récemment, je suis un grand utilisateur de DocHub, interface agréable pour consulter de nombreuses documentations informatiques. Malheureusement le projet semble en sommeil, je l’ai donc forké cette semaine pour l’installer. Et rapidement déchanté. Comme pour tout projet Node.js, il faut pour l’installer télécharger la moitié de Github. Puis démarrer un serveur sur un port spécifique, mettre en place éventuellement un proxy inverse… Toutes choses qui m’ont rapidement fait abandonner l’idée d’utiliser ma propre instance de DocHub. Par curiosité, j’ai regardé si La Source de Toute Documentation Web était accessible via CORS. Par chance, elle l’est partiellement. Je me suis donc empressé d’écrire une version de DocHub fonctionnant entièrement dans le navigateur, sans nécessiter d’installer quoi que ce soit sur un serveur. Ainsi naquit MDNHub : votre navigateur aspire le contenu de MDN et le stocke dans une base de données locale où vous pouvez le consulter à loisir. Comme d’habitude, j’ai torché ça rapidement, ça marchote à peine, donc à utiliser avec des pincettes, mais c’est juste pour illustrer l’idée : je ne veux plus qu’on me demande d’installer des trucs sur un serveur là où une appli dans un butineur suffit (éventuellement dans un butineur sous amphétamines comme Firefox OS).

Dans ma secte d’amoureux de drosophiles bâtisseuses de toile, nous organisons de fréquentes séances de lamentation collective sur l’évolution du Web. Ce nouveau média dont nous pensons qu’il a des propriétés émancipatrices est ces jours ci en train d’enfermer nos semblables dans quelques silos. Facebook, Google+, Twitter pour citer les plus communs. Pocket également pour la lecture différée. Et nous ne comprenons pas pourquoi #lesgens se laissent enfermer de la sorte alors que pour gagner en autonomie, il leur suffit d’installer une instance de Diaspora, Poche, Status.net reloaded… Non. Ce « suffire » est déjà de trop. Dire que pour échapper aux silos il « suffit » d’avoir son propre serveur, est aussi irréaliste que de conseiller de faire son potager pour échapper aux grandes chaines agro-alimentaires. Juste sur le papier, très difficile à grande échelle dans la réalité.

HTTP est un protocole merveilleux, mais encore trop lié à une logique client-serveur (intrinsèquement ou par l’usage qu’on en fait, je ne sais pas trop). Au commencement, lorsqu’il n’était utilisé que par des passionnés, le paradigme émancipateur fonctionnait : chacun peut publier librement en installant son serveur. Mais installer un serveur n’est pas une réponse qui résiste à la démocratisation de la technologie. Avec cette démocratisation est venue l’utilisation de serveurs tiers, et, assez logiquement me semble-t-il, des silos actuels. Je ne suis donc plus du tout sûr que, sur ce continent de l’univers Internet qu’on appelle le Web, on puisse désormais connaître autre chose qu’un modèle fortement centralisé.

Heureusement, Internet ne se limite pas au Web, et on a vu il y a quelques années des réseaux très grands publics et fortement décentralisés se mettre en place, à l’époque de la vogue du P2P. Le rêve d’un Internet a-centré n’est donc sans doute pas mort, mais peut-être à chercher ailleurs que sur le Web. À moins que nous soyons capables de repenser, d’inventer, un Web de pairs à pairs.

Accessoirement, peut-être que nombre de nos contemporains n’ont pas envie d’être autonomes mais se sentent parfaitement bien dans les jardins privatifs totalement sécurisés, aseptisés, confortables. Et qu’avec nos histoires de serveurs-à-la-maison nous ne cherchons pas à répondre à un besoin mais à promouvoir notre vision de ce qui serait bon pour l’humanité connectée.

MDN sur Dochub

DocHub est un fort pratique site qui compile de nombreuses documentations utiles pour le développement Web. Il utilise des scripts pour aspirer les sections de MDN consacrées à HTML, CSS et JavaScript, mais aussi la documentation de jQuery et PHP. L’ensemble est ensuite proposé au travers d’une interface unifiée, avec un moteur de recherche. Le site permet de stocker l’ensemble de la documentation dans le navigateur, via appcache. Cela rend la recherche et la consultation de documentation très rapide. J’ai depuis longtemps ce site épinglé dans mon navigateur, et m’en sers tous les jours.

Malheureusement, ni le code source, ni la base de documentation n’ont été mis à jour depuis plus d’un an, et le développeur semble avoir abandonné le projet. Il n’est donc plus très à jour.

MDN a quant à lui récemment reçu un coup de peinture, et la dominante bleue du nouveau thème m’horripile. Ça n’est pas très grave, car je le consulte surtout à travers l’interface de DocHub. Hormis pour toute la documentation liée à Firefox OS et aux APIs Web, qui ne figure pas sur DocHub. Mais qu’à cela ne tienne, puisque le code source est libre, il suffit de dupliquer le projet et de créer un script pour extraire de MDN les pages dont j’ai besoin.

C’est ce que je viens de faire. Je me suis basé sur une version d’Edinei Cavalcanti, qui a ajouté à DocHub la documentation de NodeJS et Python 3. Les scripts de capture de MDN ne fonctionnaient plus, donc je les ai rapidement adaptés et j’en ai créé un pour Web API. J’ai fait ça à la (r)hache et n’ai guère testé, donc je présume que c’est très truffé d’erreur. Le code de DocHub lui-même devrait être améliorable, par exemple en ne chargeant pas toute la documentation en mémoire, mais dynamiquement les extraits nécessaires. Malheureusement, je n’ai pas le temps d’aller plus loin. J’ai une instance locale qui fonctionne à peu près, je m’en contenterai pour l’instant. N’hésitez pas à tester, avoir une version locale de MDN est confortable.

Ceci dit, je trouve l’outil fort pratique. Il allie la pertinence de la documentation de MDN au confort d’utilisation et à la réactivité d’une application locale. Il mériterait de ne pas être laissé en friche. Si des bonnes âmes connaissant un peu Node.js cherchent un projet auquel donner un peu d’affection, celui-ci est un bon candidat. Avis aux volontaires… (évidemment, l’idéal serait de récupérer tout le travail effectué dans les nombreux forks déjà existants sur Github, et de mettre à disposition sur une URL publique l’application mise à jour).

Choisir son exposition

Avertissement : La navigation privée n’a pas pour effet de vous rendre anonyme sur Internet. Votre fournisseur d’accès Internet, votre employeur ou les sites eux-mêmes peuvent toujours pister les pages que vous visitez.

Cet avertissement sur la page de présentation du mode de navigation privée de Firefox illustre combien ce concept de « navigation privée » est ambigu, et l’implémentation choisie par les navigateurs probablement en décalage avec les attentes des utilisateurs.

Lorsque je ne suis pas devant mon clavier, il m’arrive d’avoir des activités publiques. Faire une présentation de Webmakers, distribuer des tracts… Je le fais à visage (relativement) découvert et en assume (vaguement) la publicité. D’autres activités se déroulent dans un cadre fermé dont elles n’ont pas vocation à sortir. Ce sont par exemple mes interactions professionnelles, ou des discussions au bistro (lieu public mais conversations privées qui n’ont pas vocation à être diffusées. Et bien sûr, j’ai avec mes chats des relations intimes, relevant uniquement de ma vie privée (ceci dit, je ne limite pas la sphère privée au périmètre de ma grotte, mais y inclus des activités dans un espace public, comme faire mes courses). Ce sont trois sphères distinctes entre lesquelles nous oscillons en permanence, et qui sont plus ou moins garanties par des conventions sociales et des contrats. On essaie de ne pas écouter les conversations des tables voisines ou les bruits quotidiens de nos voisins. De ne pas rendre publiques des informations relevant de notre activité professionnelle.

En ligne aussi, mon activité oscille entre ces trois sphères. Publique lorsque je m’exprime sur Twitter ou ici. À diffusion restreinte lorsque j’écris à mon cercle d’amis. Et strictement privée lorsque je traine sur YouPron^W VoilàPipole^W ploumploumtralalanarchyvaincra.org. Certains réseaux sociaux en ligne ont d’ailleurs adopté cette distinction, qui permettent pour chacune de nos informations de choisir si nous la partageons avec tous les robots des Internets, juste nos connaissances, ou si on préfèrerait qu’elle reste confidentielle (c’est à dire, dans le cas de Facebook, connue uniquement de leurs employés et partenaires commerciaux, une paille).

En fait, cette distinction me semble si naturelle que je rêve qu’elle soit implémentée au cœur des agents que nous utilisons pour interagir en ligne (c’est à dire de Mozilla/Firefox). Que mon navigateur me permette systématiquement de choisir, pour chaque nouvel onglet, si je souhaite que mon activité en son sein soit publique, privée, ou protégée. Publique, j’autoriserais tous les sites qui le souhaitent à me tracer. Privée, elle ne laisserait aucune trace sur mon ordinateur et me protègerait raisonnablement contre le traçage (connexion via un proxy, blocage de tous les espions, brouillage de l’empreinte digitale du navigateur…). Protégée, j’autoriserais les sites à analyser mon comportement pour me faire des propositions pertinentes, mais pas à partager mon profil avec des tiers (cf le prochain blocage des cookies tiers dans Firefox.

Je jette en vitesse ici cette idée qui me trotte dans la tête depuis quelques jours, n’hésitez pas à me lancer un pavé ICMP si vous avez des remarques.

Fork me on GitHub