The USPTO needs to implement SSL and PFS on all of its public-facing servers. In plain language all of the servers at USPTO need to use “https://” rather than “https://”. Why? Because apparently there are eavesdroppers. See this report from a member of the E-Trademarks listserv:
The company TMFeatures really has figured out how to decipher what we are searching, and I am very concerned. I am working on a very sensitive global launch for a client, and I received an email this afternoon from this company which makes it clear that it knows exactly what I have pulled up on the public USPTO TESS database. How can that happen? If a company is able to compile a list of the marks we have pulled up, it would not be hard to make a very good case of competitive intelligence available for the right price. I assume this would be much worse for single industry in-house trademark counsel than us outside people, but still very concerning.
News events of recent years have provided reminders that (a) it is technically feasible to eavesdrop on any and all unencrypted web traffic (“https://”) and that (b) such eavesdropping has occurred (and is probably still going on) in more that one jurisdiction.
One important step to block such eavesdropping on a web site is to implement SSL on that web site. By this we mean that the URL starts with “https://” rather than “https://”. Years ago this imposed a non-negligible performance hit (pages would take longer to load). Nowadays there are boxes that you can purchase that sit between the web server and the Internet that provide SSL in a very simple and efficient way. Such boxes do not impose any measurable performance hit.
A second important step is to implement a particular type of SSL called PFS (perfect forward secrecy). A web site that has not implemented PFS uses the same encryption key for all sessions of all visitors. An eavesdropper that listens in on, and records, a large number of sessions by various visitors to and from a particular web server, and that manages to crack the encryption key for any one session, can then use the cracked key to go back and decrypt the previous recorded sessions. PFS is a protocol that constructs a new key for each individual web session. So an eavesdropper that cracks the encryption key for a particular session will still not be able to make any sense of previous recordings of other sessions.
The report quoted above provides a vivid reminder that USPTO’s TESS system does not use SSL. This apparently permits the TMFeatures company to eavesdrop on the search sessions.
Spot-checking some of the other USPTO e-commerce systems, I see that many of them do not use SSL. These include TEAS (other than the screen for paying money), EPAS, ETAS, AOTW, PATFT, and TSDR. USPTO should implement SSL on all of its outward-facing servers including these.
As an indication of the importance of SSL in today’s world of eavesdropping, consider that Google, trying to nudge webmasters in the direction of doing the right thing, has announced that it will give an advantage in search engine rankings to web sites that use SSL.
A handful of USPTO systems do use SSL. These include Private PAIR and EFS-Web (and the various screens for payment of money). But none of those systems use PFS.
PFS is trivially easy to implement nowadays. Anyone who is implementing SSL for the first time in 2014 on a server would actually have to go out of their way to prevent PFS from being available. (All commonly used SSL protocol packages nowadays include PFS at no extra charge and with no extra configuration effort.)
Back in January of 2014 I posted to the EFS-Web listserv my strongly expressed suggestion that USPTO implement PFS on all of its SSL web sites. In that posting I also strongly suggested that USPTO implement SSL on the USPTO servers that did not already have SSL. I privately copied that posting to several USPTO decisionmakers. My efforts had no effect; now in August of 2014 USPTO has not implemented SSL on any of its servers that did not previously have SSL. And USPTO has not implemented PFS on any of its servers that do have SSL.
In contrast, EPO and WIPO both have PFS on their servers that have SSL. As I said in January of 2014, USPTO is the laggard here.
Update: TMFeatures denies harvesting IP addresses. TMFeatures says they carry out their targeted mailings based solely on information drawn from post-filing records at the USPTO. Even assuming for arguments’ sake that this is true, it leaves unchanged the need for USPTO to implement SSL and PFS on its public-facing servers, for many other reasons.
Carl, I agree that every website should move to SSL. PFS is certainly a best practice, but its primary purpose is to prevent the government from going back and decrypting an amassed trove of encrypted data in one fell swoop. The PTO *is* the government, so I’m not sure PFS is so important here.
Much more critically, I think you are giving TMFeatures too much credit. SSL or no, TMFeatures would still need to have a privileged network position to watch your web traffic. The entities that can do that: ISPs, the NSA, someone who sets up a malicious WiFi network that you connect to, someone sitting at a coffee shop that has an open WiFi network that you connect to. Unless TMFeatures is doing one of the latter two for you, which would absolutely astound me for a number of reasons, they can’t watch your web traffic.
Hello:
I am from TMFeatures.com. We don’t do any networking snooping. As Michael says above, it’s not technically feasible. In any case we get our information from Google using the URL below:
http://www.google.com/googlebooks/uspto-trademarks-application-images.html
Our TM Features Visual trademark search software, on average really find 20% confusingly similar trademark missed by SERION, USPTO TESS, or any other software search available . We would like to prove it to you for FREE. Give us a call, or send us an e-mail, will run a TMFeatures’ visual trademark search against any other earlier trademark search you’ve done.