The USPTO databases have to be one of the most torturous services to their users in the whole of internet. The UI of both the patent and trademark search is archaic, but not in a HN way but in a really bad way.
In patent search, there is no "search" box. Instead, the "quick search" forces you to specify two (and exactly two) text queries on the database columns with obligatory boolean operation.[1] Even if you happen to find an interesting patent, good luck linking to it (which should be the number one service they provide - GET individual patent documents). The page showing the patent document has a dozen cryptic query parameters in the URL, some of which relate to the search query you used to find the patent! No "make shareable link" button to be seen, either.
And don't get me started on the trademark search, or Trademark Electronic Search System (TESS), as they like to call it.[2] When you navigate to the front page, you get a private session identifier - in your URL of course! And when you search for a trademark ("simple search" is intuitively known as "New User" here) and select a TM to view, you would be excused of thinking that the short URL in your browser address bar is the linkable URL of this entry. But no - it's just your session identifier along with the document's index in the results of your last search query.
When you leave the trademark site or just click "Logout" (since you're a kind person - they after all ask you "logout when you are done to release system resources allocated for you"), that URL is gone in the wind. If you shared a link to that trademark to your friend, they only get this very helpful page:
<H1>This search session has expired. Please start a search session again by clicking on the TRADEMARK icon, if you wish to continue</H1>
So no way to link to individual TM registrations here either.
FWIW, you're often better off not searching, or looking at, patents.
If you end up in a patent case, your liabilities will be much higher if they can sufficiently claim you knowingly infringed. Evidence that you searched for patents can weigh against you / your employer. Even if you weren't associated with the infringing product itself.
The bizarre practice of assigning session keys to visitors and somehow storing the page they're viewing in the server instead of in the URL is pretty common in Brazilian government, which is dominated by Java programmers.
Historically it was fairly common. I wouldn't say it was standard, but it happened often enough to notice. There's a bunch of reasons that come together to cause that.
During the explosion of the web, enterprises moved much of their development into web solutions using an existing workforce that had skills in different technologies - often client-server desktop-to-RDBMS tech. Java was a popular choice for these new projects. Those developers would range in their general aptitude - some were quite good, some weren't - but they all came onto these projects with existing skills and knowledge in patterns and architectures that weren't particularly well aligned with web development. They were expected to adapt and deliver at pace consistent with their previous projects. So they did what they could to get the job done, even though that meant that their solutions were not well suited to the web environment.
That doesn't have a lot to do with Java specifically, except that it was a common language for that situation. It was far more common for enterprises to take VB/PowerBuilder/Delphi/etc Devs and move them into Java than something like PHP.
But Java was more likely to produce this horrible implementation for a couple of reasons.
Firstly, as a general purpose language (that also happened to have decent web capabilities) it was easy to design an application using your traditional patterns and then just shoe-horn the web UI on top. You were far less likely to do that in a web-oriented platform like PHP or ColdFusion (!).
Secondly, the Java servlet spec makes sessions really easy (because it stores standard, stateful, Java objects) and didn't offer a lot for managing complex page state. You could spend several days trying to build something to page through database search results with query parameters, only to find that the back button broke your design. Or you could just throw it all into the session, and call it "done".
That probably peaked about 15 years ago, but inertia is a strong force, particularly in government and large enterprises. Some of those developers are probably still working like that. Some of them trained others. And many others know that it's a bad design, but there's no budget to fix it.
Also, the third likely reason is that there are still a lot of Java web codebases from the mid to late 90s around; the Java runtime can still run the code, so people keep it. Perl and TCL are less likely to be convenient to run today, and more of those codebases will have been dumped.
And Java was disproportionately used for very large complex systems which would be expensive to replace, in any case.
This practice has nothing to do with Java, at all. It is not an approach that was invented by Java, for Java, and it is not in any way unique to Java.
Most web technologies support rendering a view based on a set of values residing in a database, and use the values to populate a template. The template contains placeholders reserved for values expected to originate from a database.
The version of the page that appears in your web browser usually does not exist as a serialized HTML page on a disk connected to a server. It often only exists as a representation of two pieces of information bound to a session in memory on a server: 1. The Template or server-side script, 2. the values you are authorized to retrieve from the database, which may or may not be a SQL database.
What you see in the address bar does not need to correlate to the HTML rendered in the browser window. JavaScript (which is not Java) often employs this technique, termed as a "single page web application."
This is true for PHP, Mcrosoft, Ruby, Python, Perl, server-side JavaScript (such as node.js) and yes Java too.
What's being described above isn't simply template-based rendering (which, yes, essentially everything does), but the practice of building web-software like desktop software and keeping the state of the UI server-side. It ignores that browsers are capable of effectively forking the UI through (today) tabs and (historically) "Open in New Window". Interacting with such software is a profoundly unpleasant experience; thankfully it's not particularly common, especially outside of "enterprise" applications (including government services, public utilities, education management, property management, healthcare, etc.)
It is not Java-specific, but it is common to a few specific Java frameworks as well as at least one of Microsoft's older frameworks (I forget which one).
The vast majority of frameworks (including most modern Java frameworks) do the sane thing and keep application state on the server side (often in a database, as you describe) and UI state on the browser side, which allows links and forms to work the way links are generally supposed to work.
> It is not Java-specific, but it is common to a few specific Java frameworks as well as at least one of Microsoft's older frameworks (I forget which one).
ASP.NET WebForms has a feature where the Session ID, normally stored in a cookie, is stored in the request URL path instead. This was done back in 1999-2001 to support extremely rudimentary HTTP clients which did not support HTTP Cookies - imagine really prototypical mobile-phone web-browsers or hastily-written shell scripts using CURL.
Fortunately it was disabled by default and the documentation describes why it's a bad idea to use it - and I understand the business reasons for including it - however this design does not break things like multiple-tab browsing: that's just what happens when you have any stateful web-application, regardless of framework.
It's now gone in ASP.NET MVC (where you gave full control over rendered URLs), so that horrid chapter has ended.
Which is great, because everybody should downvote anything because of a mild distinction, rather than the wildly off the mark question that prompted a reasonable response. Good job!
Well, the post I responded to included a more or less textbook description of template based rendering. It's a response to a response to this:
> The bizarre practice of assigning session keys to visitors and somehow storing the page they're viewing in the server instead of in the URL is pretty common in Brazilian government, which is dominated by Java programmers.
Having dealt with such a service just today (King County Recorder's Office public records search) that behaves in this manner, I felt pretty familiar with what I was describing.
It is entirely possible I'd misapprehended the situation, but as it's an informal conversation on the internet about bad web development practices, I'm going going to dwell on it too much.
You got what I meant correctly. Thank you for understanding me.
I don't know how could anyone think I was talking about general template rendering (but maybe I expressed myself badly, English is not my first language).
...which is pretty much how hashtag-based single page webapps operate.
Many, if not most, isomorphic react/node.js apps have a single API url, with microservices behind the load-balanced URI, that accepts HTTP POST requests, and looks at a JSON object sent as the request body, in turn responding with a JSON object that informs the client-side app to re-render accordingly.
This isn't bizarre at all. It is very, very common; if not the norm.
Also, once you get your patent search results, clicking on one of the links takes an amount of time that seems to scale with the complexity of the search. So I suspect that they actually re-run the search every time you request a result.
Has anyone built an open index, legal or otherwise? Doesn't seem like it would be too hard to script the downloads and build a real search tool for it.
Question: if it's really this bad, this site is going to have incredibly poor ratelimiting or per-IP analytics/access controls, if it has these things at all.
So, it probably wouldn't be too impossible for someone to build a new site (maybe even an API) that talks to this and prettifies the results, lets you copy URLs (most likely via caching¹), and so forth. (The case in point about my previous paragraph is that the new site would generally hitting the old one, possibly several times a second, from one IP.)
You'd just need a strong mind to handle the inanities of talking to this system. :P
¹ But with the caching thing, you'd absolutely have to have a disclaimer stating that the services don't replace the USPTO website, yada yada (along with some wording buried in a policy document that carefully points out that the data is cached). I mean you'd need that anyway, but yeah.
Probably the only thing keeping this from being abused is that it's the government, it's a low-value target, and they're paying millions upon millions for someone to support this trainwreck with security patches.
Why on Earth could they possibly feel it necessary to do this? The United States Patent Office doesn't have a complex system of sub-domains or even an EV license, if money were the object then they could just go with Let's Encrypt (not to mention the current license continues until 2018 anyway).
The amount of computing power it takes to encrypt with SSL is minimal, especially if you use some of the newer systems like ECDSA and should not be of concern to a company like the Patent Office.
You think they have a free hand, but they don't. People who work are federal agencies are hemmed in by a thicket of rules that prevent them from just entering into an agreement with a private vendor who has not been through a qualification process. Likewise technicians and administrators are enjoined from spending money on their own initiative, eg you can't just see the problem, sign up for a renewable SSL certificate, and then shoot the bill over the accounts payable.
I don't want to speculate about what's going on at the managerial/administrative level, but I notice the current administration is committed to the goal of slashing most government spending by some huge amount while simultaneously cutting taxes. It may be that the head of the USPTO got a phone call telling them not to spend a single damn penny. Now, iirc the USPTO is actually self-financing on patent application fees, but I don't think they're so independent that they can just ignore directives from higher up in the executive branch.
Totally this. I have childhood friends who now work in government IT and I just can't wrap my head around how these people get anything done in those kinds of environments.
It is one of the rare organizations where the people responsible for the budget of the organization have long track records of trying to have them disrupted (or just eliminated).
Congress has often tried to undermine the ability of the EPA, IRS, NIH, NOAA... to do their job which then makes it seem they are ripe for disruption.
The Republicans are essentially government saboteurs, which is fascinating if you can look at it from a distance. Most countries' major conservative party don't do this. Quite frankly, I'd say that having a relatively small government is what saves the US from disaster, as countries with that level of government dysfunction are usually pretty poor.
Maybe they fired or lost the only person left who understood how it works, it broke, and whoever they yanked across the hall to get it going again could only do it this way. I think there's still a govt-wide hiring freeze.
Well if you put on your tinfoil hat - maybe someone wants to track who's viewing which patents, which they can't do when it's encrypted. You're right, it doesn't make any sense to do this, so there must be an ulterior motive.
This will allow ISPs to track who is viewing particular patents and when. That would be very lucrative data to sell in some circumstances. I doubt the USPTO would distribute a list of IP addresses that accessed a patent without some kind of due process.
I think this might be gutted out already though as big companies use proprietary databases which have enhanced data on the patents. Also google patents...
Yeah, I don't think it's actually their reason for the change. It's just one hypothetical consequence that the decision makers probably failed to consider. Still, the decision makers should be investigated for conflicts of interest because they've made a really fishy-smelling decision.
If they shared the data, they could get caught doing so. By simply removing HTTPS someone could intercept the requests on their own without any wrongdoing on the part of USPTO (aside from dropping HTTPS).
> Well if you put on your tinfoil hat - maybe someone wants to track who's viewing which patents, which they can't do when it's encrypted.
No, a third-party attacker can just look at size/timing of packets to figure out which page is being viewed, especially given it's among a limited and static corpus.
Tracking users over HTTPS is a solved problem, so I doubt that'd be it. Something about "never attribute to malice that which can be adequately explained by incompetence"?
What I mean is that if a third party wanted tracking info all they'd have to do is pay for a tracking script to be injected. Let's say the patent office is okay with this. Why wouldn't they just include a <script src="evil.js"> instead of going through the trouble of disabling HTTPS just so a third party can get their eyes on the juicy information? Just as easily, patent office could sell access logs to interested parties. In that not-very-roundabout way, knowing the URL and who wants it is very much a solved problem.
If third party tracking (for malicious intent or otherwise) is the main reason behind the change, why not do it how everyone else does?
It stands to reason they just don't want to deal with SSL termination anymore, for whatever reason. Though, at least in my eyes, that's a solved problem too.
I would assume that they do it because HTTPS does complicate the pipeline on several different levels. If you want to tcpdump the https traffic, for example, you need to do SSL/TLS termination at the load balancer to get something readable. Most web servers don't make it easy to inject on the other side of the decryption; I remember having to enable some very verbose debug logs in nginx to accommodate this. Third-party tooling is necessary to take a dump of encrypted traffic and decrypt it for analysis.
It's also possible that their configuration was causing them performance problems and decreasing overhead by killing HTTPS for "unnecessary" endpoints was seen as a potential solution. Requesting a public record about a patent is not something that, at first glance, seems like it should need to be transferred over a secure protocol.
Of course, none of these are really good reasons to disable HTTPS, but they're some potential explanations.
-----
Separately, I think some people who remember HTTPS being used to secure "true secret" pages kind of resent the "HTTPS must be used anywhere and everywhere" trend that has taken hold. It's not that there aren't good reasons to do that, but it's also silly to pretend there aren't side effects of doing it.
From some perspectives, the need to encrypt all communication can be seen as an external concern for something like a VPN tunnel to handle. End-to-end crypto is good because it, theoretically, precludes reception from anyone who can get in the middle of the server and the VPN, but it needs to be more transparent before everyone is willing to consider that a worthwhile/important tradeoff.
One side effect of HTTPS everywhere is that the site can no longer really designate some portion of traffic as "secret". If every admin in your org needs to be able to decrypt all HTTPS traffic to debug issues, you're giving some access away. Maybe some of them would've been able to get to that data anyway, but probably many of them would not.
Again, this is not to say that that HTTPS shouldn't be used, but just some musings into why someone would not necessarily be enthusiastic about it. Working to integrate HTTPS more transparently to admins and working toward the ability to mark specific information for extra "app-layer secrecy" instead of just relying on transport-layer secrecy seem like they'd be good steps.
You could easily terminate SSL at the LB or even just a proxy in front of the app. Sniffing the line after that is as trivial as turning a mirror port on the switch. In this day and age SSL is trivial and there is honestly no good reason to disable it. In fact protecting users privacy is a good reason they should switch to SSL only.
I know you were only trying to coming up with some kind of reason but, there just isn't a valid one.
The grandparent comment touches upon the reality of working in most large organizations. There tend to be silo'd teams, which in more concrete terms translates into the "application/website" team and the "networking" team. Sometimes, there's a "system administration" team sandwiched in between.
HTTPS everywhere reduces the number of teams that used to, in the old "HTTP-only" world, serendipitously pitch in to help troubleshoot tickets. Now, instead of anybody within the network capable of sniffing HTTP packets, only one or two groups are limited to troubleshoot.
In your example, terminating SSL at the LB, or adding a proxy in front of the app, would either be an annoyance or major project, respectively. Small firms wouldn't think twice and would jump into action; but large organizations have too much internal inertia.
I see your point too, but the USPTO probably: a) is underfunded; and b) exhibits all the average capabilities and organizational "effectiveness" of a large bureaucracy.
Perhaps a better question is whether the USPTO would object to having their site content mirrored by a 3rd party better capable of offering features that users are complaining about (HTTPS & better search). Google has their own version[1].
Having worked doing independent full-stack web design I'd expect an individual could, from scratch, set up a working system with load balancing and failover in perhaps 2-3 weeks ... an experience team should surely be able to do that in their sleep inside a week?
What would be others expectation for such a service? USPTO do have a web team, yes? That site has been the same for over a decade AFAIR, what have they been doing?
The issue here is that even if you could do it, the question when working in a large bureaucracy is whether you're given the latitude to do so when teams are silo'd and responsibilities are split along very sharp fault lines.
So, even though you could setup a working system top to bottom from scratch, depending on which team you're attached to you'd have to design, explain/argue and work with other teams and their overbearing workloads and attendant baggage.
An experienced team with full ownership of load balancers, firewalls, hosts, security and applications could conceivably do this in their sleep inside of a week -- but few large organizations split their responsibilities in this manner.
I don't know anything about USPTO and am only making sweeping generalizations, but my experience with government and large network operators seems to generalize well (so far).
This is why I hope that other 3rd parties can somehow export USPTO data and make them available somehow. Not sure if this is a potential target for the Archive Team[1] or archive.org, although the missions aren't cleanly aligned to this particular need.
They are basically going to be DOSing a huge segment of users who've previously had that header set on their browsers...they're also violating the OMB mandate that requires TLS for all government sites...it is a rather strange move, I can't imagine there is a good reason for it.
EDIT
If it is for portal.uspto.gov then HSTS is a non-issue but still a very bad move.
An excellent question. I tried looking up the current policies, but the "IT Policy Library" [1] is provided in an iframe that doesn't load for me ("The connection to the server was reset while the page was loading.").
>Immediately after the maintenance, users will only be able to access Public PAIR through URLs beginning with HTTP, such as http://portal.uspto.gov/pair/PublicPair. Past URLs using HTTPS to access Public Pair, such as ...
To be pickier, they never said that all URLs beginning with 'HTTP' would be enabled, merely that URLs beginning with something other than HTTP would be disabled, and also that URLs beginning with 'HTTPS' would be disabled. They never stated that HTTPS was part of the "doesn't begin with HTTP" group.
Does F5 do any special secret sauce that can't be replicated with an equally powerful set of hardware and a good HAProxy config? I know one of our network admins is continually complaining about how shitty their UI is...
Does F5 do any special secret sauce that can't be replicated with an equally powerful set of hardware and a good HAProxy config?
Not unless you think "extract a lot of money from clueless execs" is secret sauce. That, and support contracts - you know, throats to choke when it all goes wrong.
BigIP's iRules (Tcl) are pretty nice. (https://devcentral.f5.com/irules). I hear HAproxy has Lua support now, but I don't know how comprehensive it is compared to iRules.
Also, F5 load balancers have real hardware failover capability, and can even synchronize TCP session state across instances. That's a pretty nice feature.
I worked with BigIP for a few years, and I believe that the real value is in the support contracts, and the peace of mind that gives to enterprise execs. failover (local or global) as well as state sync is all do-able with linux or bsd, but that will take time and work. BigIP is more or less plug and play. This is the case for many "enterprisey" products. Personally, I prefer to go the linux/bsd route, since it forces you and your team to have a deeper understanding of what you are building, which is really handy for when things break.
Not an expert, but the last BIG-IP LTM I saw a couple of months ago didn't support TLS acceleration without a dedicated hardware module (and the accompanying license); this would usually mean upgrading to a more expensive model.
Plain old TLS termination isn't license-limited as far as I know.
EDIT: to answer your question, yes, you could probably do it with haproxy, but the added value in these appliances is iRules (TCL hooks for all network events, you could augment request processing etc) and vendor support.
F5 has some secret sauce to it but it's mostly performance related. They have a good chunk of hardware offloading, all the way up to the TLS layer.
I seem to remember even the entry license includes full TLS offloading so I doubt the poster above is correct that it is a cost issue.
As to if HAProxy can do the job, well, that depends. F5s are complex beasts and they can load balance application specific protocols that can be hard to find elsewhere, with the support contract that goes with it.
This would be interesting for patent research; you could legitimately say "I looked for a patent that already covers X but since you cannot guarantee the data was not modified in transit, I cannot be certain that I saw what was actually in the patents I reviewed".
That _might_ help in a criminal case (IMO unlikely unless you can show some requests were actually modified), but any civil case is going to be decided on balance of probabilities. A slight chance of interception probably wouldn't swing that either way.
Even if the courts allowed this to be a valid defense, it could only protect you from willful infringement. Not having knowledge of an existing patent does not stop the other party from claiming damages. If they can prove you knew that your work infringes the patent, they can sue you for treble damages from willful infringement.
They might allow it, but in civil litigation liability hangs upon the balance of probabilities rather than being beyond a reasonable doubt as in criminal trials. So a court might well allow it but that doesn't mean a jury would find it persuasive.
Don't you only need to be 51% confident? As long as fewer than 50% of all HTTP requests are modified by malicious adversaries in transit, you'd still have to pay up.
Anyone looking at creating an IPFS or BitTorrent mirror yet?
Edit: the PDF attachment URL's are very predictable, they're the number of the patent in a weird order + a page number, e.g.: http://pdfpiw.uspto.gov/10/292/096/2.pdf
Back of the envelope calculations say all PDF's should only take 1 - 6 TB's (assuming 100kb to 600kb in PDF's on average). Seriously, why hasn't anyone mirrored this?
This is surprising given that the .gov registrar is requiring HTTPS + HSTS for all new agency websites [1], but they specifically exclude existing domains or _renewals_.
I wonder if 18f can help at all, it seems agencies must contact 18f themselves.
But you listed a completely irrelevant gap. The gap of relevance is the one between automobiles and now, not the one between carriages and automobiles. If automobiles were the transport technology of 1890 and carriages were the technology of 1889, then devolving to carriages puts us back to 1889, regardless of when horses were invented.
I've been involved in writing a few and the result was useless drivel. Combined with the fact that there are penalties for willful infringement, I'm not sure what the benefit to reading patents in your field would be.
The patent system has evolved in a way that has practically inverted its original intents. You're exactly right, practitioners in a given field (ex: engineers in the tech industry) often avoid looking at patents, because no good can come of it. Most are too vague to be useful for licensing, but it opens one up to willful infringement claims later on.
IANAL, but my understanding is no. Also, software patents tend to be so vague and generic that if you were to thoroughly search for anything that you might conceivably be infringing on, you'll spend a preposterous amount of time doing so, probably find not one single thing that directly applies to what you're doing, and will probably find a few thousand that don't apply but are generic enough that some lawyer might still haul you into court in east Texas, who can then claim willful infringement because of your search. I probably couldn't even write /bin/ls without stepping close to infringing on hundreds or thousands of vague, generic IP land mines planted long ago by unscrupulous lawyers who are just waiting with bated breath for someone to stumble across them so they can drag people to east Texas or (more likely) shake them down for settlement money before it goes to court.
They are a public storehouse of technologies. We have a right to read them. Some are well written and have useful information for reproducing them rather than just a lot of BS fluff. I just ran across the TMDS encoding patents (DVI & HDMI signaling) a few weeks ago. My thought was "wow, this is a pretty good patent" and conveniently just expired.
Prime example of a government function that could benefit from the open source community. If all this patent data were dumped today, in whatever format it's stored in, I guarantee we'd be seeing a bunch of cool ShowHNs within days and all of us would be better off for it.
Does seem like I spoke too soon, though the above link is not everything. I downloaded it and it's a CSV file with three fields -- a patent ID (I think), a date, and some other number.
Quite a tricky incident or a tendency ... One day, it will make you look at the problem more creatively. This is an increase in the risks of MITM - when information can be distorted or other manipulations with it are possible. But this is good as a whole. Will help create more sophisticated and safe technologies for viewing information in these networks.
Fortunately, there are quite a few workarounds and opportunities that minimize all the associated risks ...
Drupal is all over government sites. So is Wordpress. Do you expect them to be using closed source CMSs or something? (I get that Drupal is insecure, but no, it's not "illegal" to use Drupal...)
The US Federal Government is essentially the arbiter of all regulations and minimum standards within the United States. It's just surprising to see an opensource framework running on Apache/Coyote expected to run over HTTP.
Of course it is. What's the alternative? Writing all the websites, and the web servers hosting them, along with the operating systems, with hand-written assembly or something like that?
Does anyone have any experience with their support system? On Monday I will be calling them in an attempt to understand why they are exempt from the HTTPS Everywhere federal directive.
I wouldn't use the word "illegal" - it's a directive of OMB (the White House's management and budget office), not a law or a regulation or an executive order. The only true enforcers are OMB themselves.
But to answer your other question, as part of the Department of Commerce, a "CFO Act" agency, USPTO would not be exempt.
Thank you for clearing that up. Are you aware of what kind of consequences might be incurred at the expense of disobeying the OMB as a government entity?
Don't be the person that gets someone fired, arrested, jailed, and in lifetime legal trouble because some asshole thought it would be hilarious to display porn on their computer at work.
(Yes, I'm equating "meatspinning" to malware. Argue if you like about that, but the main point stands: If you meatspin someone, you're taking a chance of ruining their entire life. Don't be That Guy.)
> Don't be the person that gets someone fired, arrested, jailed, and in lifetime legal trouble because some asshole thought it would be hilarious to display porn on their computer at work.
Not to defend "meatspinning" (first time I've heard the term), but don't you think the real problem here is that people can be fired/jailed/etc without due process is the problem here? This was just some drive by malware, imagine what you could do to someone's life if you intentionally targeted someone?
Also worth adding that it was kiddie pr0n that got the guy fired in parent's story. Quite a lot of people tend to overreact to this for either CYA or moral high horse reasons.
If he was fired for meatspin or lemonparty, he would publicly accuse them of homophobia on twitter and things would be different ;)
it seems like most of the pro https arguments are asserting the right to anonymous public patent inspection. it is fundamentally impossible for the uspto to provide this access* (free speech traps ahead). if you don't want data about access patterns tracked the burden is on the consumer not the provider for public resources
In patent search, there is no "search" box. Instead, the "quick search" forces you to specify two (and exactly two) text queries on the database columns with obligatory boolean operation.[1] Even if you happen to find an interesting patent, good luck linking to it (which should be the number one service they provide - GET individual patent documents). The page showing the patent document has a dozen cryptic query parameters in the URL, some of which relate to the search query you used to find the patent! No "make shareable link" button to be seen, either.
And don't get me started on the trademark search, or Trademark Electronic Search System (TESS), as they like to call it.[2] When you navigate to the front page, you get a private session identifier - in your URL of course! And when you search for a trademark ("simple search" is intuitively known as "New User" here) and select a TM to view, you would be excused of thinking that the short URL in your browser address bar is the linkable URL of this entry. But no - it's just your session identifier along with the document's index in the results of your last search query.
When you leave the trademark site or just click "Logout" (since you're a kind person - they after all ask you "logout when you are done to release system resources allocated for you"), that URL is gone in the wind. If you shared a link to that trademark to your friend, they only get this very helpful page:
So no way to link to individual TM registrations here either.1: http://patft.uspto.gov/netahtml/PTO/search-bool.html
2: http://tmsearch.uspto.gov/