Live data from Hacker News

“Users will only be able to view patents via HTTP. HTTPS will no longer work”

uspto.gov

121–130 of 172 posts

Re: “Users will only be able to view patents via HTTP. HTTPS will no longer work”

#121

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…

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.

Re: “Users will only be able to view patents via HTTP. HTTPS will no longer work”

#122
post #79
post #71

Earlier quoted context omitted.

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.

A Java app of my university does this too. Is this a practice shared by most Java programmers? How come?

It's called a "Single Page Application" or SPA, and it's made with JavaScript.

https://en.wikipedia.org/wiki/Single-page_application

Re: “Users will only be able to view patents via HTTP. HTTPS will no longer work”

#123
post #34

Earlier quoted context omitted.

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.

Hiring freeze was lifted on April 12, 2017.

At which point they started hiring only loyal idiots.

Re: “Users will only be able to view patents via HTTP. HTTPS will no longer work”

#124
post #79
post #71

Earlier quoted context omitted.

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.

A Java app of my university does this too. Is this a practice shared by most Java programmers? How come?

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.

Re: “Users will only be able to view patents via HTTP. HTTPS will no longer work”

#125

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…

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 certificat…

sounds like the US government is ripe for disruption...

/s

Re: “Users will only be able to view patents via HTTP. HTTPS will no longer work”

#126

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.

Re: “Users will only be able to view patents via HTTP. HTTPS will no longer work”

#127
post #89

Earlier quoted context omitted.

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; th…

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!

I, at least, did not downvote the original post. I assumed it was honest ignorance of the practice I described in my reply.

Re: “Users will only be able to view patents via HTTP. HTTPS will no longer work”

#128
post #83

Earlier quoted context omitted.

Please provide rationale showing that the associated risks outweigh the immense fun of "meatspinning" coworkers. "Don't do this" is probably not very convincing.

https://it.slashdot.org/story/08/06/18/2213232/man-fired-whe... 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 e…

> Argue if you like about that, but the main point stands

No it doesn't.

> Yes, I'm equating "meatspinning" to malware

Don't be That Guy.

Re: “Users will only be able to view patents via HTTP. HTTPS will no longer work”

#129
post #89

Earlier quoted context omitted.

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; th…

What's being described above isn't simply template-based rendering How are you able to draw that conclusion? The GP didn't supply a link as an example. It is simply a non-specific anecdotal remark, with no further evidence provided.

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.

Re: “Users will only be able to view patents via HTTP. HTTPS will no longer work”

#130

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…

Wow.

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.

Post reply on HN