A reminder that USPTO needs to scrap the Entrust java applet for PAIR and EFS-Web

Regular users of USPTO’s Private PAIR and EFS-Web systems are reminded several times a day that the only way that they make use of the systems is by permitting a computer program called the Entrust java applet to run on their computer.

But the Java system will block the Entrust applet in a future Java security update.  (See warning at right.)

Here is what USPTO should do …

USPTO should scrap the Entrust java applet.

The whole point of the applet, when USPTO chose some years ago to start licensing it from the Entrust company, was to provide “two-factor authentication”.  To log in you had to have “something you have” and “something you know”.  The “something you know” was your super-secret password.  You know, the password that you have no choice but to share with everyone in your office so that the non-practitioners in your office can log in to Private PAIR and EFS-Web.  The “something you have” is your super-secret USPTO cryptographic certificate (that file that has a file name that ends in EPF).  You know, the certificate that you have no choice but to share with everyone in your office.

This is the certificate that expires without warning on a date that USPTO claims it cannot tell you in advance.  This is the certificate that USPTO will renew in a surreptitious manner (notified only in a transitory pop-up window that you will not see because it will pop up on the screen of one of the non-practitioners in your office because the renewal will happen when they log in, not when you log in).

The thing is that there are lots of ways nowadays to do “two-factor authentication” for logging in at a secure site.  If you review a dozen or so of your favorite sites, or if you review a hundred, you won’t find any other organization or company that uses technology from the Entrust company.  Not one.  Only the USPTO somehow thought that this was the right way to do two-factor authentication.

For example.  Logging in with ePCT (WIPO’s counterpart to Private PAIR and EFS-Web).  To log in with ePCT you need “something you know” which is your WIPO password.  And “something you have” which is your WIPO cryptographic certificate.  But all you need is an ordinary web browser like Firefox.  You don’t need this odd security-risk Java applet.  The ordinary web browser knows how to pass along the crypto cert and the password to the ePCT server which is then able to authenticate you and log you in.

Not only that but WIPO is sophisticated enough to know how to interface with a RADIUS authentication server, for example the RADIUS server at EPO.  So if you already have login credentials at the EPO, they will work with the ePCT system seamlessly.  Same thing for people who have login credentials at the Korean patent office or the Japanese patent office.

The main point being that for access to WIPO’s ePCT system, you just need a modern web browser and that’s it.  No pesky security-risk Java applet.

Let’s look at some other web sites that use two-factor authentication.  For example Western Union Globalpay, the company that we use to initiate wire transfers to non-US patent and trademark firms.  With Globalpay the two factors are again a cryptographic certificate and a password, and again the only software needed at the user end is an ordinary modern web browser.

Or GoDaddy, which our firm uses for some domain name registrations.  To log in at GoDaddy we need a password and a secret code number.  The way we get the secret code number is it is texted to my cell phone.  The secret code number is good for twenty minutes and is different every time I log in.

Or some of our firm’s in-house servers.  To log in, we need a password and a secret code number.  The way we get the secret code number is by looking at an app on my Android phone.  The app, from Google, is called “authenticator”.  It displays a secret code number that changes every thirty seconds.  (There are a lot of advantages to using an Android phone not the least of which is that I can carry a spare charged battery with me and swap it in if the battery in the phone runs down.  iPhone users of course can’t do this because there is only one battery and it is glued in.  This makes me feel sorry for iPhone users.  But anyway, there is a corresponding authenticator app for iPhones too.)

The two-factor authentication approach that USPTO selected years ago — the Entrust Java applet approach — is very bad because it presents the now-well-known security problems that Java imposes on your computer.  But it is also bad for other reasons.  For example it makes it impossible for Mac or Linux users to get into EFS-Web or Private PAIR.   In contrast, the ePCT system is supported for any operating system that has Firefox or Microsoft Internet Exploder installed.  Which permits Mac and Linux users to use ePCT.

Another reason that the Entrust Java app approach is very bad is that it gets in the way of users who need an API (programming interface).  Any normal well designed e-commerce system will be friendly to users who want to write their own programs to interface with the e-commerce system.  But the Entrust Java applet approach is actively hostile to any user writing his or her own program to get into PAIR or EFS-Web.  It basically forces the user to hand-key any inquiry.  If you want to check the status of your pending USPTO patent files daily, you have to log in and manually check that status daily.  There is no way to automate it.

Anyway I have been saying for years that USPTO needs to scrap the Entrust Java applet system.  Not that this has led to USPTO scrapping the system.  But anyway now we have a warning from Oracle (the publishers of Java) that in a future Java security update, the Java system will block the Entrust applet.  So what users can hope for is that USPTO will take this poke from Oracle as a reason to do the right thing, even if all of the previous reasons were not enough to make USPTO do the right thing.