As of a couple of days ago, users now have a choice of two ways to log in at Private PAIR and EFS-Web. The two choices are “Java Applet” and “Java Web Start”. How should one choose which login method to use? In this article I give a bit of background, and then I discuss some of the things that might influence your choice.
The first listed choice is the “Java Applet” approach. Anyone who successfully logged in to PAIR or EFS-Web two weeks ago was, whether they knew it or not, using this “Java Applet” approach. Those who successfully logged in two weeks ago are well aware that many newer versions of major browsers do not permit the use of java applets. For example as of two weeks ago it was impossible to log in using Chrome. In my own daily work, I had to use Firefox to log in. The Mozilla folks (who maintain Firefox) have been saying for many months now that eventually Firefox will also discontinue the ability to use java applets.
Why is it that the various providers of web browsers have been cutting off support for java applets? The answer is that java applets present substantial security risks for users. Each provider of a web browser (for example, Mozilla, Google, or Microsoft) these days tries to pay attention to protecting the security of users.
Which brings us to “Java Web Start” (JWS).
JWS has been around since 2001. For some fifteen years now, JWS has been available as an alternative to the java applet approach. For some fifteen years now, system designers that wish to minimize security risks for users have designed their systems to use JWS instead of java applets. For some fifteen years now, system designers who had previously used Java Applets have been migrating to JWS because it is safer for users.
USPTO did not, however, migrate to JWS five years ago or ten years ago or fifteen years ago. The security risks imposed upon users by the use of the java applets did not prompt any such migration by USPTO. What did prompt migration by USPTO was the simple fact that browser makers have one after another simply cut off any ability to use java applets. As of now in October of 2016, there are a few web browsers remaining that still permit USPTO customers to log in to PAIR and EFS-Web. But it is only a matter of time before the few remaining web browsers will also cut off the ability to use java applets. It is this inevitable cutoff that prompted USPTO in October of 2016 to make the JWS approach available for logging in to PAIR and EFS-Web.
Not to put too fine a point on it, but nearly all system designers (other than USPTO) that used to use java applets had migrated to JWS many years ago, out of a desire to minimize security risks for users. For years I had hoped that USPTO would do likewise, and it did not happen. It was only the actions of the browser makers (cutting off java applet support) that forced USPTO into this migration.
It is interesting to read discussion groups of systems designers in which this migration from java applets to JWS has been discussed. As long ago as 2006, there were discussions in which the participants said to each other than as far as they knew, nobody was using java applets any more. Little did they know that the USPTO was still using java applets. It would not surprise me at all if during the past five years, maybe the USPTO was the last remaining organization or company that was still using java applets.
Which brings us to JWS. The second login approach shown in the screen shot above is Authenticate with Java Web Start. To use JWS, the user needs to have installed something called Java Runtime Environment (JRE) into the user’s operating system. This is easy to install (you simply go to java.com). if you were logging in to PAIR and EFS-Web in the past, you already had JRE in your operating system.
The same system designer discussion groups in which people talked five or ten years ago about dumping java applets are discussion groups in which more recently they discuss that JWS is also on the way out. Five years ago system designers were talking about migrating away from JWS to other newer technologies for system designs. These days system designers talk about how nobody uses JWS any more for new system designs.
Nobody, that is, except the USPTO.
The whole point of the java applet which USPTO adopted some ten years ago was to be able to provide “two-factor authentication”. The goal is that the user does not merely use a password to log in but also uses “something else”.
But many readers will be familiar with the ways that other system designers (other than the USPTO) accomplish two-factor authentication. Other system designers have never felt the need to use the awkward and security-risking java applet approach. Other system designers have never felt the need to use the JWS approach. When I log in to Travelex to wire money to the Korean patent office or to wire money to a foreign patent firm, I don’t have to use a yucky java applet to accomplish the “something else”. Likewise I don’t have to use the complicated JWS system to accomplish the “something else”. The way that Travelex does the “something else” is very simple. Travelex simply sends me a text message with a code number. I type the code number in on the Travelex login screen.
Or with our Synology servers I simply use the Google Authenticator. This is an app on my smart phone that calculates and displays a secret number that changes every minute or so. When I am logging in on one of our Synology servers, I type in my password and then I type in the secret number from the Authenticator app. That app provides the “something else” besides a password.
What’s disappointing is that USPTO did not pick one or another of these well established ways of doing “something else” ten years ago or five years ago or a month ago. Right now in October of 2016, USPTO should not have migrated to this awkward JWS approach. USPTO should have migrated to one of these modern-day approaches for two-factor authentication.
So back to the original question. How should a user pick which login approach to use for PAIR and EFS-Web?
Well clearly the best thing is to try out the second choice (the JWS approach). Find out which of your browsers works with JWS. Try it on many different computers and many different operating systems (Linux, Mac, Windows, Chromebook). The reason for doing this is that it is only a matter of time before the last remaining browser maker shuts down the java applets. At that point, the first approach simply won’t work any more.
Meanwhile let’s hope that eventually USPTO will do the right thing and migrate away from the JWS approach to one (or ideally the user’s choice of one or another) of the modern two-factor authentication approaches.
USPTO Motto: “At least we’re not the Copyright Office.”
A bigger issue with the Java Web Start and the unnecessary downloading of a Java Applet is the repercussions for Mac users.
We support a patent law firm that primarily uses Macintosh computers and as with most business networks, the vast majority of users do not have administrative access to their machines. However, since the downloaded Java applet is not signed with Apple (and a new one must be downloaded each time a user logs on), administrative rights are required to allow the application to run every time a user attempts to log in. Furthermore, because the applet is generated at each sign-in, a security exception can’t be made because it’s always a new file.
Disabling the Apple-signed security check is unfortunately not an option as it poses a major security risk and has actually been removed from the current version of the Macintosh operating system (Sierra). It can be safely assumed that future versions of the operating system will follow suit.