Plugins JAVA, la fin est si proche

dead-endLes annonces pleuvent sur les applets Java, les utilisateurs font grise mine! (billet mis à jour en Fév. 2017)

Google Chrome en septembre 2015, Mozilla Firefox en cours d’abandon, Microsoft Edge….
Chaque éditeur apporte sa pierre sur la tombe du greffon d’applets JAVA, en supprimant l’accès à la technologie NPAPI inventée par Netscape dans les années 90.

Récapitulons dans ce billet:

  • les versions de « plugin Java » dans la nature,
  • la position d’Oracle/Sun, de Google / Microsoft / Mozilla,
  • et tenter de dégager la tendance à venir.

Courage, ça va bien se passer  😉

Java – La pagaille des versions

javaOctobre 2015, en cherchant à installer Java, je tombais sur: « Java 8 update65 ».
Il existe donc 65 versions de Java8 ??

Des patches très nombreux

Pour être tout à fait précis il n’y a pas eu autant de patches (sous-versions) de java 8 publiées, mais seulement 12.
Oracle ne publie qu’une très faible proportion des versions qu’il produit.
La liste exacte: Java8, 8_u5, 8_u11, 8_u20, 8u25, 8u31, 8u40, 8u45, 8u51, 8u60, 8u65, 8u71, 8u73, 8u77, 8u91, 8u101, 8u111, 8u121…
Dans le même esprit, Java7 est aujourd’hui (date de rédaction) en révision 80, alors que n’ont été publiées que: Java7, 7u1 à 7u11, 7u13, 7u15, 7u17, 7u21, 7u25, 7u40, 7u45, 7u51, 7u55, 7u60, 7u65, 7u67, 7u71, 7u72, 7u75, 7u76, 7u79 et 7u80. Une paille…

Question de sécurité applicative

Oracle applique une politique de sécurité telle que:

  • combler les failles de sécurité qui lui sont imputables, par la mise à disposition de mises à jour correctives
  • ne pas laisser les failles ouvertes trop longtemps en incitant (fortement) les utilisateurs à appliquer la mise à jour automatique
  • bloquer l’exécution des versions trop anciennes (avec une « bombe logique »). L’obsolescence est programmée, littéralement.

Les navigateurs (Chrome, Firefox) suivent également cette logique de « fuite en avant » sur les versions:

  • en comblant les trous de sécurité au fur et à mesure,
  • tout en refusant de « collaborer » avec un environnement java jugé obsolète. Nous n’y pouvons rien.

Recommandations

Ainsi il est très raisonnable de considérer les points suivants:

  • Vous appliquez certainement les mises à jour de sécurité pour vos systèmes d’exploitation (Microsoft, etc). De même, il est important de tenir les autres composants du poste de travail à jour (applications, etc.).
  • Il convient par conséquent de suivre aussi les mises à jour publiées par Oracle. Et ce, même si nous ne sommes pas maîtres du calendrier de publication. C’est Oracle qui décide, pas les éditeurs tiers qui développent avec Java, ni les utilisateurs.
  • « Figer » une version de Java sur un environnement d’exploitation n’est pas une bonne idée. C’est même dangereux pour toutes les raisons précédemment évoquées. Cela finira d’ailleurs par bloquer le lancement des applets en navigateur, par exemple l’outil de signature électronique de l’application i-Parapheur.

 

Épisode 1: Google Chrome et les plug-ins JAVA

Année 2015: Google veut éradiquer du Web les « applications riches » écrites en Java ainsi que Silverlight et Flash, au profit de son propre système d’extensions. (c’est le chemin pavé vers Chrome OS).

Cela commence par le nettoyage de NPAPI (voir chapitre suivant sur Firefox), qu’il supportait pourtant jusqu’ici.
Depuis le 15 avril 2015 et la sortie de Chrome 42, cette technologie est « désactivée ». Certes, il était alors possible de réactiver la chose en allant sur l’adresse « chrome://flags/#enable-npapi » et en cliquant sur « Activer » (puis relancer le navigateur). Mesure toute temporaire, puisque Chrome 45 a sonné le glas final.

Naissance d’un géant, support des « standards » Pourquoi ?

Pour la sortie initiale de Chrome, il faut gagner rapidement des adeptes et des parts de marché. Google a fait le choix du support de la technologie NPAPI (Netscape Plug-in API), héritée de Netscape Navigator (ancêtre de Firefox): cela s’est révélé fort pratique car la technologie était déjà maîtrisée par les éditeurs tiers.
Ce système a depuis été affaibli par des attaques sur sa sécurité. En effet, NPAPI n’était pas conçu pour devoir supporter des applications complexes. Google n’a pas cherché à rendre NPAPI plus sûr pour autant.

Émancipation du géant

Face à l’insécurité, Google souhaite donc abandonner NPAPI, qui permet pourtant de fournir Silverlight (et ses nombreuses applications), GoogleEarth, les applets JAVA et Flash sur ses navigateurs. Autre raison, favoriser son propre système proche de ChromeOS…
En effet, pour remplacer NPAPI, il y a bien PPAPI chez Google (créé par ‘feu’ GoogleCode) avec le projet Pepper: la preuve, le greffon Adobe Flash commence à être distribué ainsi pour Chrome.
Et évidemment le mode PPAPI n’est que pour Chrome, les autres navigateurs ne sont pas concernés.
PPAPI n’est pas la solution ultime puisque Google souhaite que les plugins PPAPI soient migrés à leur tout vers son propre format (P)NaCL de pseudo-code (NaCl comme Native Client). Voyez le bazar…

Chez Oracle pas ou peu de réaction sur Java…

Du côté de Oracle, il n’y a pas de plan (à ce que j’en sais) pour répondre à la disparition de NPAPI. Aucun mouvement pour migrer vers PPAPI ou autre. Les rares posts sur le sujet racontent en gros:
« rien à f*** de Chrome, on est satisfait de supporter IE + Firefox, et ce n’est pas grave si Java n’y marche plus ». On a pu lire un officiel déclarer: « nous recommandons vivement aux utilisateurs de Java d’envisager une alternative à l’utilisation de Chrome dès que possible ».
Après tout, à l’échelle planétaire la combinaison « Chrome + Java » ne concernerait que 60-70 millions d’utilisateurs actifs… Et si on ajoute la guerre de brevets entre Oracle et Google à propos de JAVA justement à cette époque: ça n’aide pas.

Inversion de position dominante

Solution en forme de verrue, vue sur le net:
« The best way to use Java (or Silverlight, or other NPAPI-based technologies) going forward is to use IE Tab for Chrome. You can set up Auto URLs to automatically open certain urls using IE Tab, providing a seamless experience, as if Java support never went away. Get it here: »
https://chrome.google.com/webstore/detail/ie-tab/hehijbfgiekmjfkfjpbkbammjbdenadd
En gros, utiliser IE dans Chrome!!
Ironique, car à une autre époque pas si lointaine on faisait l’inverse (plugin Chrome-frame pour IE, rappelez-vous!). Cela confirme l’inversion des deux acteurs sur la domination du marché.

<troll>Dans l’empire du mal, l’acteur en abus de situation dominante n’agit pas pour les utilisateurs.</troll> En la matière Google a remplacé Microsoft.

A lire, aucun rapport mais c’est rigolo:
http://blog.seboss666.info/2015/02/pourquoi-vous-devriez-arreter-dutiliser-chrome/

 

Épisode 2: disparition des plugins NPAPI pour Firefox

Qu’est-ce qu’un plugin au juste ? Un plugin (« greffon » en français) est un « composant logiciel d’extension ». Autrement dit c’est une sorte de programme complémentaire venant se greffer à un logiciel afin de lui ajouter des fonctionnalités qui ne sont pas proposées nativement.

Chez Mozilla Firefox, ces modules exploitent le système NPAPI (Netscape Plugin Application Programming Interface), technologie mise au point au milieu des années 1990.

20 ans d’âge

Après ces années de service, Mozilla souhaite mettre un terme au support des plugins Java, Silverlight et consorts au sein de son navigateur, sauf Flash. #ohWait
Raisons évoquées: « des problèmes de performance, des plantages et des incidents de sécurité pour les internautes »(sic). Et ils gardent le support de Flash avec de telles raisons?? o_O
(oui,… mais  tu peux pas comprendre… le web c’est tellement les animations de chatons en Flash…)

Cependant, Mozilla annonce en 2015 « continuer à travailler avec le Java Platform Group d’Oracle afin d’assurer une douce transition aux sites qui s’appuient sur Java ».

Plan de sortie

En clair, la dernière version de Firefox qui permettra l’usage d’applet Java sera la version 52 ESR. La version « normale » non-ESR abandonne cette technologie (vraisemblablement dès v52), ensuite Firefox 53 qui sortira autour du 18/4/2017 n’aura plus le code pour NPAPI.

Firefox 52 ESR sort le 7 mars 2017. Ce millésime « ESR » signifie « à support étendu ». Autrement dit, la véritable deadline se situe à l’obsolescence de cette release qui nous mène jusqu’en mai 2018. A suivre…
Notons également qu’elle sera dotée d’un « switch » pour activer manuellement cette technologie (on comprend qu’elle sera désactivée par défaut).

Donc: à ceux qui ne peuvent se passer d’applets JAVA, basculez en canal de distribution « ESR » pour Firefox, pour durer le plus longtemps, jusque mai 2018.

Sources

http://www.nextinpact.com/news/96833-firefox-se-debarrassera-plugins-npapi-dici-fin-2016.htm
https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
http://www.ghacks.net/2016/07/19/firefox-roadmap-2016-2017/
https://www.fxsitecompat.com/en-CA/docs/2016/plug-in-support-has-been-dropped-other-than-flash/

Une dette technique qui reste

Bon OK, la conception de NPAPI n’était vraiment pas assez sécurisée au regard de tous les usages développés depuis. Ceux-ci sont très éloignés de ce qu’imaginaient les ingénieurs de Netscape à l’époque. On peut troller aussi sur la sécurité des extensions XUL/XPCOM dont la dépréciation a été amorcée du reste…
Mais beaucoup (trop?) d’applications métier en entreprise utilisent toujours cette technologie Java, et n’ont pas d’alternative. Alors?…

 

Épisode 3: arrêt programmé du support Microsoft pour les vieux « Internet Explorer »

Devant un tel désaveu industriel, il reste Microsoft, l’espace d’un fugace instant teinté d’espoir.
Pas plus rassurant en définitive, puisqu’il faut se rappeler l’annonce du 7 août 2014, passée inaperçue: la simplification de la politique de support produit de la part de Microsoft, qui décide grosso-modo de ne supporter que la version la plus récente du navigateur.

Cette nouvelle politique entre en vigueur le 12 janvier 2016: donc à cette date, exit les versions IE8 IE9 IE10, mais aussi le système d’exploitation Windows8 (Windows8.1 étant considéré comme mise à jour gratuite « obligatoire »). J’oublie volontairement le IE pour Vista, mais plus personne n’a Vista, si?
Évidemment, libre à chacun de laisser les anciennes versions s’exécuter, mais elles ne recevront plus de corrections sur les futures découvertes de failles de sécurité.

Source:
https://support.microsoft.com/fr-fr/gp/microsoft-internet-explorer

Quant au tout neuf Microsoft Edge: à noter que « par design » il ne supporte pas NPAPI, donc il n’est pas possible d’y faire fonctionner des applets Java packagées en plug-in.

 

Résumé: Compte à rebours pour les applets ?

compte-reboursEn 2016, que reste-t-il d’utilisable sur mon bureau de PC MS-Windows, compatible « applet Java »?

  • Google Chrome: c’est fini depuis septembre 2015
  • Microsoft Edge: aucun support n’est prévu pour ce navigateur.
  • Microsoft Internet Explorer: il convient de n’utiliser que IE 11, puisque les autres sont « hors-support » depuis le 12 janvier 2016
  • Mozilla Firefox: ce sera fini avec Firefox 52 ESR qui vivra jusqu’en mai 2018

En résumé: il ne reste plus que IE-11 et Firefox-52 (canal ESR).

 

Épisode 4: Oracle met un terme aux applets avec Java 9

minitel-1980Boum. La bombe est lâchée. Dans un article daté du 8 octobre 2015, un blogger d’Oracle nous refait l’histoire de la techno acquise lors du rachat de Sun, rejetant la faute vers les usages mobiles. Il propose de migrer vers « Java Web Start », tout en précisant ne pas prévoir de fournir de plug-in nouveau à l’avenir. Là déjà, ça sent le sapin.

Et ensuite donc d’annoncer tranquillement le 2 février 2016 la « dépréciation » de leur technologie de plug-in de navigateur dans le tout prochain Java JDK9. Ainsi, c’est une techno morte et bientôt enterrée, qui va aller rejoindre la carte perforée et le Minitel au cimetière de l’informatique. RIP…

 

2016, comment faire de la signature électronique sur le Web?

icon_inprogressEn 2016: utiliser IE11 ou Firefox, et un module de plugin Oracle/Java actif et à jour.

Pour la suite, aux éditeurs d’être réactifs et adapter ou redévelopper leurs outils.
Par exemple: Firefox, comme Java, supporte PKCS#11 (interface standard utilisée pour le dialogue avec les cartes à puce et autres certificats de type HSM), sous réserve de pilote hardware développé spécifiquement. C’est d’ailleurs le système utilisé par http://eid.belgium.be/fr .
Il serait peut-être intéressant de se pencher sur le développement d’extension spécifique au navigateur, MAIS sous contraintes de procédure d’installation pénible de driver de token pour Firefox.

Ou alors, suivre Oracle qui propose la technologie Java Web Start. Économiquement avantageux en terme de ré-ingénierie, mais est-ce bien raisonnable, est-ce bien pérenne?

Une piste

Un logiciel Windows qui tournerait en permanence en liaison avec le token hardware (exemple RGS**). Celui-ci écoutant sur un port TCP donné, puis communiquer avec ce service via du JavaScript en utilisant https://developer.mozilla.org/fr/docs/Web/API/TCP_Socket_API .
En rejetant brutalement les potentiels soucis de sécurité posés par Java, les éditeurs de navigateur ont déporté clairement le problème globalement sur le poste de travail. Avec les risques de MitM (man-in-the-middle), cela constitue une source beaucoup plus importante de failles de sécurité potentielles, mais cela n’est plus le souci du navigateur. Charge aux éditeurs tiers d’implémenter « correctement » la sécurité de la liaison réseau locale entre le navigateur et le service de signature… Mais pourquoi diable réinventer la roue?

 

Et après, futurologie et raisonnable pari sur l’avenir

Il existe une autre piste (beaucoup) plus intéressante pour les adeptes de Mozilla Firefox. Il s’agit d’exploiter la prometteuse spécification d’API « WebExtensions » promue par Mozilla depuis le mois d’août 2015.

Nouvelle API WebExtensions

Elle est implémentée dans Firefox à compter de sa version 42 (nightly builds). Une nouvelle interface donc, compatible avec Blink .
Cela offre la promesse d’une bonne portabilité cross-navigateurs avec Chrome et Opéra, puis Edge (qui s’y intéresse de près).
Autre atout, cela ouvre la voie pour communiquer avec une application Java lancée « Ad-hoc ». Cela minimisera les efforts de ré-ingénierie.

Autre avantage d’une API normalisée (telle que WebExtensions), c’est d’avoir par design des gardes-fous au niveau sécurité justement, grâce notamment à la nécessaire signature du code par l’éditeur.

Un standard quasi-supporté

Ainsi, utilisateurs et éditeurs sont dans une situation moins anxiogène, ce nouvel écosystème Blink / WebExtensions est :

  • Déjà implémenté dans Google Chrome, ainsi que dans Opera: nous pouvons déjà jouer avec la techno!
  • Prête pour Firefox : la version dite stable de l’API a été rendue publique avec la sortie de Firefox 48 (12 juillet 2016).
    • Firefox 44 (26 janvier 2016): les développeurs ont accès à une batterie d’outils pour faciliter leur travail de migration
    • Firefox 45 (8 Mars’16): une partie de l’API est supportée complètement (alarms, browserAction, contextMenus, pageAction), et d’autres éléments partiellement (bookmarks, cookies, extension, i18n, notifications, runtime, storage, tabs, webNavigation, webRequest et windows)
    • Et ensuite : commands, Devtools (mostly panels), downloads, history, idle, omnibox, permissions, Native messaging (runtime.connectNative)
  • à venir sur Microsoft Edge : certains éléments du moteur JavaScript passent Open-Source, les choses bougent beaucoup. Un peu de retard à l’allumage tout de même pour les extensions sur début 2016, le cycle de mises à jour suivra celui de Windows10.
    • Mars 2016: Microsoft annonce travailler sur un outil de portage des extensions Google Chrome.
      La version « développeur » de Edge (dans Windows Preview du printemps 2016) a permis de se faire la main, avec 3 extensions disponibles. Microsoft l’a diffusée dans la mise à jour de l’été 2016.
    • Microsoft entend ne pas trop se laisser distancer sur les extensions de navigateur, tant mieux. Le développement est en cours…

Ressources et sources, voir:

 

Au boulot !

Un feedback/avis en message privé ? Contactez-moi via ce formulaire :

 

Et bravo d’avoir lu jusqu’ici 🙂

  1. oui, restons positifs 🙂
    Et depuis l’écriture du billet en 2015, et ses ajustements de février’17, les choses ont bougé encore! Côté Flash, et côté firefox. Les informaticiens n’ont pas fini de bosser

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.