Le web évolue, les annonces pleuvent sur la fin des plug-in Java, les utilisateurs font grise mine !

Abandons en cascade : Google Chrome en septembre 2015, Mozilla Firefox planifié prochainement (voir plus bas), Microsoft Edge…
Chaque éditeur apporte sa pierre sur la tombe du greffon d’applets JAVA, en supprimant l’accès à la technologie NPAPI (voir plus loin dans l'article) inventée par Netscape dans les années 90.

Récapitulons un brin dans cet article : les versions de Java dans la nature, la position d’Oracle/Sun, de Google, Microsoft, Mozilla. Courage, ça va bien se passer.

 

La pagaille des versions Java

Octobre 2015, en cherchant à installer le plugin Java pour navigateur, je tombe sur : « Java 8 update65 » .
Il existe donc déjà 65 versions de Java 8 ??

Pour être tout à fait précis il n’y a pas eu 65 patches (sous-versions) de java 8 publiées, mais seulement 11.
Oracle ne publie qu’une très faible proportion des versions qu’il produit.
La liste exacte (début): Java 8, 8_u5, 8_u11, 8_u20, 8u25, 8u31, 8u40, 8u45, 8u51, 8u60, 8u65, 8u71, 8u73, 8u77, 8u91, 8u101...

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 les utilisateurs à la mise à jour automatique
  • bloquer les versions trop anciennes (avec une sorte de « bombe logique »)

Les navigateurs (Chrome, Firefox) suivent également cette logique de « fuite en avant » sur les versions, tout en refusant de « collaborer » avec un java jugé obsolète. Nous n’y pouvons rien.

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

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

 

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

Google veut éradiquer du Web les applications Java et Silverlight et Flash, au profit de son propre système d’extensions. (le chemin vers Chrome OS).

Cela commence par le nettoyage de NPAPI (voir chapitre suivant sur Firefox).
En effet, pour remplacer NPAPI, il y a bien PPAPI chez Google: la preuve, le greffon 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 puisque Google souhaite que les plugins PPAPI soient migrés vers son propre format (P)NaCL de pseudo-code. Voyez le bazar…

Du côté de la société Oracle, il n’y a pas de plan (à ce que nous en savons) pour répondre à la disparition de NPAPI. Les rares posts sur le sujet racontent en gros:
« rien à f*** de Chrome, on est satisfait de supporter IE + Firefox, et c’est pas grave si Java n’y marche plus ».
Après tout, à l’échelle planétaire la combinaison « Chrome + Java » ne concernerait que 60-70 millions d’utilisateurs actifs…

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 époque on faisait l’inverse (plugin Chrome-frame pour IE, rappelez-vous!). Cela confirme l’inversion des deux acteurs sur la domination du marché.

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

A lire, 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 s’appuient sur NPAPI (Netscape Plugin Application Programming Interface), technologie mise au point au milieu des années 1990.
D’ici à fin 2016, Mozilla mettra 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 ». Et ils gardent le support de Flash avec de telles raisons??

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

En clair, la dernière version de Firefox qui permettra l’usage d’applet Java sera la version 52. En effet, Firefox 53 qui devrait sortir le 18/4/2017 n’aura plus le code applicatif pour NPAPI.

Firefox 52 sort le 7 mars 2017 et, heureusement pour les utilisateurs, c’est un millésime « ESR » (à support étendu). Autrement dit, la véritable "deadline" se situe à l’obsolescence de cette version 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).

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/

Bon OK, la conception de NPAPI n’était vraiment pas assez sécurisée au regard des usages développés depuis, très éloignés de ce qu’imaginaient les ingénieurs de Netscape.
Mais beaucoup (trop?) d’applications métier en entreprise utilisent toujours cette technologie, et n’ont pas d’alternative. Alors?…

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

Devant un tel désaveu, tournons-nous vers Microsoft.
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 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" versions IE8 IE9 IE10, mais aussi le système Windows8 (au profit de Windows8.1, étant considéré comme mise à jour gratuite « obligatoire »).
Évidemment, libre à chacun de laisser les anciennes versions s’exécuter, à leurs risques et périls : 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 disponible avec Windows10 : à noter que « par design » il ne supporte pas NPAPI, donc pas de système de plug-in Java. Il n’est pas possible d’y faire fonctionner des applets Java.

 

Compte à rebours ?

En 2016, que reste-t-il d’utilisable sur mon bureau 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 IE11, les autres sont « hors-support » dès janvier
  • Mozilla Firefox: ce sera fini avec Firefox 52 qui vivra jusqu’en mai 2018

En résumé: il ne resterait plus que IE11 et Firefox, tout en sachant que Firefox a planifié la mort de Java en applet.

 

Comment faire de la signature électronique RGS** sur le Web?

En 2016: utiliser IE11 ou Firefox, et un module de plugin Java™ à jour.

Pour la suite, les éditeurs de logiciels devront être plus réactifs et adapter leurs outils. Différentes solutions alternatives existent, avec leurs avantages et leurs inconvénients. Parmi elles: le développement d'extension native spécifique à chaque navigateur est particulièrement coûteux à mettre en place et à entretenir.

Le cas i-Parapheur

Cas particulier : l'application i-Parapheur utilise l'applet Java LiberSign pour la génération de signatures électroniques. Des développements sont en cours pour qu'une solution opérationnelle soit rendue disponible avant la fin de l'année 2016 suite à une campagne de beta-tests.

Ces développements réalisés par Adullact Projet sont en logiciel libre. Technologiquement, ils s'appuient majoritairement sur la nouvelle API WebExtensions, implémentée notamment dans Google Chrome, Opera, ainsi que Firefox (version 48+). Cette API présente l'avantage d'être largement compatible avec Chrome (puisque interopérable avec Blink), et très probablement avec Microsoft Edge à l'avenir (Microsoft a annoncé son magasin d'extensions en mars 2016, il n'est pas encore mature).
L'architecture de LiberSign subit donc une légère re-ingénierie pour s'adapter à ce nouveau mode d'exécution : l'idée est de réutiliser autant que possible le savoir-faire et le code déjà existant, notamment sur le traitement des certificats et les opérations de chiffrement.

Le résultat: LiberSign2.0 intégré dès i-Parapheur v4.4, et des patches pour les versions supportées v4.3.x de l'application.