Well-known plug-ins such as JAVA will soon stop working in the Google Chrome Browser.

The end of JAVA in Chrome
The browser as we know it is no longer the simple application that only allows us to visit web pages. The browser has become a platform for the use of entire business applications. In the course of time, more and more functionality was added and soon it became possible to extend the browser even further, if the existing functionality was not adequate. This was enabled by adding Application Programmable Interfaces (APIs) to the browser. Much of the functionality that we know nowadays works through these APIs, including the well-known Oracle JAVA environment. With functionality being enabled through these APIs, problems also started to arise. Many of the attacks on browsers are carried out through the components (plug-ins) that are added to the browser through these APIs. In this way, it is often easier to access physical resources such as the hard disk. Obviously, this is a continuous source of annoyance for browser manufacturers, which is why Google for example started with a program to phase out the Netscape Plug-in API (NPAPI) in September 2013 [1]. In November 2014, Google announced the roadmap [2] that will lead to well-known plug-ins such as JAVA to no longer to work in the Google Chrome Browser [4] in September 2015.

Do you still use JAVA applets? Now is the time to look around for solutions that can be implemented by means of other technologies [3].

Where are JAVA applets used?
In the process of defining the product roadmap that would eventually lead to the end of NPAPI, Google has investigated how often users use a particular plug-in [1][2]. They noticed a decline in the use of the JAVA plug-in between September 2013 and October 2014. The number of users that launched the JAVA plug-in decreased from 8,9% to 3,7%.

Now 3,7% of the total user base does not seem much. But who are these 3,7%? If we look at where JAVA applets are used within the browser, then in many cases, this is done to avoid the limitations of the browser and for example, to communicate directly with the hardware components. These are components that often need to be accessed using an Operating System native library. Keeping this in mind, it is not hard to realize that some user groups are more affected than others, as JAVA applets are used for supporting critical processes, crucial to the functioning of our digital (and in some cases, physical) society. An example of the area in which JAVA applets are often used is the digital signing of information by means of a smart card. Functionality that is not available natively in the browser, but is default in JAVA [5].

Google’s advice?
Apart from providing information that explains that the use of plug-ins is getting increasingly difficult in Chrome [2], Google also provides information on how to face this challenge. In short, programmers should use the Javascript APIs that are supported by the Chrome browser. This means that the applications that are currently available as a JAVA applet for instance, need to be rewritten, so that the new Javascript APIs available in the browser can be used.

Oracle’s reaction?
Oracle is aware of what is going to happen and advises users that want to continue to use JAVA applets to switch to a different browser as soon as possible, for the deadline set by Google (end of 2015) is approaching rapidly [4]. But is changing from one browser to another, if possible at all in your environment, really a solution?

What if I use another browser?
Google clearly leads the way with its concrete plans. An example that may be followed by others as well. Statements from Mozilla [6] also seem to suggest that NPAPI has had its day there as well. It is as yet unclear in what direction Microsoft is moving.

Furthermore, it is often not up to the business application Provider to demand that the end-user uses a particular browser. After all, an end-user will want to have access to multiple applications of multiple vendors.

What is AET’s advice?
From the very beginning, AET has developed independent smart card middleware called SafeSign Identity Client (IC). This middleware is used by many of our customers for authentication and the generation of digital signatures within applications and browsers. In the latter case, JAVA API is often used. Obviously, it is possible to write JAVA scripts and continue to use SafeSign IC. However, this is often a large investment and does not have many apparent advantages, such as decreasing the number of helpdesk calls of the end-user. In fact, we often see that in case of such configurations, where our customers cannot influence the environment of the end-user, the number of helpdesk calls is rising. This is further increased by the fact that end-users often do not have the necessary technical expertise themselves.

Although smart card middleware will remain necessary within certain environments for many years to come, we advise to implement a new form of authentication and signing in the browser environment. AET provides this by means of the ConsentID Identity Provider, where the end-user will authenticate himself or digitally sign a document through an App on his mobile device. This App can also support smart cards and can be easily installed from e.g. the Applet store or Google Play store and is easy to use. This method will definitely decrease the number of helpdesk calls. Furthermore, integration of this solution will no longer take place at the front-end (web browser), but at the back-end of the business web application through an interface for authentication and digitally signing documents. This is much easier to maintain than when JAVA scripts are used. Click here for more information about ConsentID Identity Provider.

About Jan Rochat
Mr. Jan Rochat is co-founder of A.E.T. Europe B.V. He was the chief architect of SafeSign Identity Client, the middleware that enables applications to work with PKI smart cards through a PKCS #11 interface (such as Firefox) or a CSP (such as Microsoft Internet Explorer, Chrome). He currently supervises the development of SafeSign Identity Client, BlueX eID Management and ConsentID Identity Provider as CTO. In addition, Mr. Rochat works as an adviser for various security projects that are aimed at the setup and roll-out of PKI-based technology (Secure Web, VPN, secure e-mail) and projects concerning the implementation of eID systems.

More information
For more information, please contact: marketing@aeteurope.nl

References
[1] Saying Goodbye to Our Old Friend NPAPI, Google, September 23, 2013, http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html
[2] The Final Countdown for NPAPI, Google, November 24, 2014, http://blog.chromium.org/2014/11/the-final-countdown-for-npapi.html
[3] NPAPI deprecation: developer guide, https://sites.google.com/a/chromium.org/dev/developers/npapi-deprecation?pli=1
[4] Hoe do I use Java with the Google Chrome Broswer?, Oracle, http://java.com/en/download/faq/chrome.xml
[5] Java PKCS#11 Reference Guide, Oracle, 11 May 2004, http://docs.oracle.com/javase/1.5.0/docs/guide/security/p11guide.html
[6] Plugins, Mozilla, Januari 14 2015, https://developer.mozilla.org/en-US/Add-ons/Plugins