Nous avons tous pesté contre Macromedia Adobe Flash qui nous pompent sauvagement les ressources sur certains sites web. Nous avons tous pesté contre le plugin Skype qui s'invite dans vos pages webs et modifie à la volée tout ce qui ressemble à des numéros de téléphone, même si ce sont des numéros de bordereaux de commandes. Nous avons tous râlé devant un plugin bizzaroïde qui s'installe sans aucune raison, et qui se révèle être “indispensable” pour un site de jeu où vous n'êtes allés que par hasard. Nous avons tous hurlé quand nous nous sommes rendus compte qu'Adobe (tiens, l'usual suspect) Acrobat Reader plugin présentait une défaillante hallucinante qui permettait à un script dans un PDF malicieux de voir vos pages.

Halléluïa ! C'est FINI !
Nous ne pardonnerons plus jamais à Flash !

Le péché originel

Avec la Mozilla Foundation, Google retire définitivement le connecteur NPAPI de Chrome. C'est donc la fin d'une des plus vieilles API du web, des plus mal maintenues, des jamais standardisées et des plus instables.

Pour le lancement de la version 2.0 de son Navigator, Netscape voulait frapper un grand coup, celui d'amener des aminations dynamiques à une époque où les interactions DOM étaient impossibles en Javascript. Netscape avait créé l'interface NPAPI qui permettait à des logiciels tiers de s'insérer dans des pages web. Selon Wikipédia, c'était une demande d'Adobe pour intégrer des PDF, en attendant que le design ne se fasse plus en tables (et encore…). L'une des applications des plus populaires reste Flash, mais avant ça, ce fut Real Player, Windows Media et Quicktime, tous pour lire du son ou des vidéos.

source Jean-Lou Dupont's WEBlog

L'API en question était exclusivement gérée par Netscape. Évidemment, le grand rival Microsoft construit sa propre API d'intégration, ActiveX. Évidemment ça donne un code mauche et bloated au possible qui n'aide pas aux plugins de gagner en réputation. En ces temps obscurs, tout le monde trouvait tout à fait normal cette stupide guerre. Et quand Netscape coula, cette API ne bougea plus !

Depuis, c'est la foire d'empoignade entre <object />, <embed />, avec ou sans classid=""

It works, don't fix it est le mantra le plus stupide qui soit sur internet : Le navigateur est la principale porte d'attaque utilisée par les virus, les logiciels malveillants car dehors, le Grand Web n'est pas un monde de bisounours, même quand un opérateur tente de le minitéliser.

Les Prémices : <object> is <abject>

Java, qui “bénéficiait” de sa propre API au navigateur (et son propre tag, <applet>, ce qui fait partir en sucette mon jeu de mots), en a fait en premier les frais. Le plugin était troué, a mauvaise réputation, n'a jamais offert une sécurité raisonnable, et seul un Oracle aurait pu croire qu'il deviendrait un jour stable, et les bulletins d'alertes ne font même plus sourire. Le pire épisode fut quand Java devint la méthode d'“authentifikof koftion” utilisé pour… payer les impôts en ligne ! Sauf que, et on apprécie l'ironique sécurité, il fallait une version obsolète et dangereuse du plugin Java afin d'être “authentifié”.
Encore une merveille servie par une de nos Glorieuses Nationales SSII, qui auraient fait mieux de rester à leurs barebones Thomson CSF.

Si Java qui fut un temps très utilisé, a complètement disparu de nos navigateurs, vous pensez bien que les constructeurs qui font ces derniers se moquent complètement de sauvegarder le legacy. Je vous fais même le pari qu'ils y songent avec un sourire carnassier.

La Fin Est Proche

Avec le SVG, les balises audio/video, canvas et WebGL, bien des possibilités se sont ouvertes d'un coup, sans plugins, et interopérables.
Pour encore accélérer le développement du web “HTML5” natif, les constructeurs de navigateurs avaient deux défis : Passer à l'embarqué et l'interactivité (API tactile, direct TCP, WebRTC, licences MPEG…) et définitivement supprimer ces verrues que sont les plugins.

Le dernier usage restant “légitime” concerne la lecture de produits de divertissement sous DRM, et encore ! Et là, l'intégration de DRM dans les définitions HTML fait l'objet d'un combat homérique.

Apple avec son iPhone a été le précurseur de ce mouvement : Le premier téléphone était assez puissant pour accueillir une version mobile du player Flash, mais devant sa consommation proverbiale, ce fut un niet avec un accent Cuppertinien. Ensuite, Adobe a creusé la tombe, puisqu'il est maintenant plus rentable de vendre des outils d'authoring HTML5 qu'en Flash. Ils commencent par abandonner Flash pour Android, puis pour Linux. Par mesures de “rétortions”, des développeurs de Mozilla poussent pour retirer au plus vite le support plugin dans Firefox.

Ce qui motive aussi les développeurs de navigateurs, c'est une question d'image : Les plugins représentent toujours actuellement la plus grosse source de plantages et d'insécurité d'un navigateur. C'est un code tiers, fermé, inauditable. On peut certes le contenir dans un bac à sable, mais leur présence est de moins en moins tolérée car NPAPI ou ActiveX, c'est un sacré monceau de code mort et mal maintenu.

Remplacement

Google Chrome compte utiliser des solutions embarquées, du code tiers incorporé par ses soins. C'est le cas pour Flash et un lecteur PDF. Mozilla foundation préfère le code externe : Il existe déjà PDF.js qui est un lecteur de PDF en javascript, et normalement est censé avancer Shumway, un player Flash en javascript lui aussi. Clairement, le constructeur de Firefox souhaite une interopérabilité avec les autres navigateurs.

Concernant les plugins créés par Google ces dernières années, les versions HTML5 attendaient juste une stabilisation des API standards sur lesquelles elles reposent pour être lancées. Google Hangout par exemple, repose sur les API Media Capture et WebRTC. Devinez qui a été stabilisé en Août ?

Agonie

Dès Décembre, à la prochaine release de Firefox, il faudra cliquer pour activer un plugin. Cela ne vous rappelle rien ?

Eh oui, le procès Eolas !

À partir de Janvier, Google Chrome n'acceptera plus aucun plugin extérieur au navigateur, avant de définitivement les retirer à moyen terme. Les seules exceptions seront Flash et l'exécuteur de code NaCl. Il y aura une période de transition, mais elle ne sera pas longue.

En fait, un mouvement de développeurs au sein de la Mozilla Foundation propose le retrait total des plugins au plus vite, en représailles à Adobe qui ne maintient plus à jour son plugin Flash sous Linux et Mac.

Et si la position d'Apple reste inconnue, Microsoft avait failli débrancher tous les plugins dès la sortie de Windows 8. Oui, même Silverlight et Flash ; Et il faut saluer la boîte à fromage de Redmond qui a totalement transformé ses principaux sites pour qu'ils ne reposent que sur du HTML pur et propre. Bravo (sincère) Microsoft !

Mort

La mort des verrues purulentes du web que sont les plugins, c'est l'arrivée définitive du web sémantique, de l'accessibilité, de l'interopérabilité.
Vœu pieux, mais désormais, rien n'empêchera d'être propre.
Finies, les petites roues…

Le problème, ce sont les 5% de plugins (en proportion d'installation relevées par Google) utilisés dans des cadres industriels, du type insertion d'Excel, de Lotus Notes ou de scanner. Et là, on aura pas le choix : Soit on commet l'irresponsabilité d'interdire à nos clients de se mettre à jour, soit il faut tout reprendre à zéro. Finie cet âge stupide où l'on pariait sur la longue traîne des mises-à-jour. Les navigateurs font ça comme des grands, 90% du parc en moins de deux semaines, c'est plus simple en terme de sécu utilisateurs.

Il reste néanmoins les solutions LTS. Qui ne dureront pas plus de deux ans.
C'est acceptable dans les administrations ou les très grandes entreprises (certaines banques ne sont toujours pas prêtes à abandonner MSIE 6 en interne), c'est-à-dire des structures capable de crâmer des millions en DSI fan de Lotus Notes et en pare-feu Cisco Office.
Mais c'est idiot pour les PME/TPE, les particuliers et les associations.

In memoriam

✝
Plugins (1995 — 2014)
Requiescat in pace