“Users will only be able to view patents via HTTP. HTTPS will no longer work”(uspto.gov)
uspto.gov
“Users will only be able to view patents via HTTP. HTTPS will no longer work”
https://www.uspto.gov/blog/ebiz/
171 comments
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.
Another hilarity of the patent system.
This is largely outmoded advice in the wake of in re seagate. Simply having looked at a patent is not enough to create willful infringement.
I've just been informed that in re seagate got over turned last year. Bad news.
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.
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.
And Java was disproportionately used for very large complex systems which would be expensive to replace, in any case.
It's a similar story with Windows, due to continuous backwards compatibility as demonstrated in videos such as:
https://www.youtube.com/watch?v=PH1BKPSGcxQ
https://www.youtube.com/watch?v=PH1BKPSGcxQ
This is being conflated as a Java thing, because of a sideways remark about Brazilian programmers.
Reading other comments, it's now clear that in this instance we are dealing with a Microsoft Server. [0]
[0] https://news.ycombinator.com/item?id=14173595
Reading other comments, it's now clear that in this instance we are dealing with a Microsoft Server. [0]
[0] https://news.ycombinator.com/item?id=14173595
Not in modern Java... or any I've seen in the last several years. There's a lot of fucked up legacy code and frameworks out there though.
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.
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).
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.
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!
I, at least, did not downvote the original post. I assumed it was honest ignorance of the practice I described in my reply.
What's being described above isn't simply template-based rendering
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.
> 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).
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).
[deleted]
It's called a "Single Page Application" or SPA, and it's made with JavaScript.
https://en.wikipedia.org/wiki/Single-page_application
https://en.wikipedia.org/wiki/Single-page_application
Uhm... A server side session Web apps is pretty basic stuff:
https://en.wikipedia.org/wiki/Session_(computer_science)#Ser...
This existed since the Perl CGI times. "Bizarre practice", wow.
https://en.wikipedia.org/wiki/Session_(computer_science)#Ser...
This existed since the Perl CGI times. "Bizarre practice", wow.
Server side sessions aren't the bizarre practice - Keeping track of navigation state on the server side is.
This is like your whole website existing as a single endpoint and making POSTs to the same URL to get to different parts of the site.
This is like your whole website existing as a single endpoint and making POSTs to the same URL to get to different parts of the site.
...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.
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.
If you look at the url, you notice they are using CGI and Win32 EXEs
You can't know that.
It could have been redeveloped in anything, but kept the original url scheme for backwards compatibility.
It could have been redeveloped in anything, but kept the original url scheme for backwards compatibility.
Oh, come now. Whether he can or cannot know such a thing is however many angels, dancing on the head of a pin.
Do you honestly believe anything this terrible went through a rewrite? I sure don't.
Do you honestly believe anything this terrible went through a rewrite? I sure don't.
I know! I takes at least three rewrites to make it that terrible.
The URLs in question have no backwards compatibility, by design.
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.
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.
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.
For patents what about: https://assignment.uspto.gov/patent/index.html#/patent/searc...
they actually recommend google on their search page! [1]
"You can also try this same search on Google."
[1] https://www.uspto.gov/blog/ebiz/search?q=
[1] https://www.uspto.gov/blog/ebiz/search?q=
That's for searching the USPTO website. Not searching patents, or Google's patent search.
> to release system resources allocated for you
Jesus christ.
Jesus christ.
See also the HTTP shopping cart: http://ebiz1.uspto.gov/vision-service/ShoppingCart_P/ShowSho...
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.
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.
Of course - obscure as it gets, session state based navigation and top of it off with username/password form over unencrypted HTTP.
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.
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.
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.
sounds like the US government is ripe for disruption...
/s
/s
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.
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.
> relatively small government
Are we talking about the same government??
Are we talking about the same government??
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.
Plenty of time to hire someone and sort out all the issues!
At which point they started hiring only loyal idiots.
Maybe someone sued them over some highly-innovative encryption patent they've previously granted? :) /s
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.
If that were the case and USPTO were in on the trick, why the need to drop HTTPS?
They'd have that data already, so could just share it directly.
They'd have that data already, so could just share it directly.
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.
Didn't your country just drop the privacy protection rules that hindered ISPs from selling any American's browser history?
[deleted]
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).
Plausible deniability? Shifting blame?
I'm just playing Devil's advocate here.
I'm just playing Devil's advocate here.
> 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.
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 do you mean by that? Is knowing the URL of a HTTPS request a solved problem?
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.
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.
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.
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].
[1] https://patents.google.com/
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].
[1] https://patents.google.com/
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?
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.
[1] http://archiveteam.org/index.php?title=Main_Page
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.
[1] http://archiveteam.org/index.php?title=Main_Page
Fun fact: HSTS
https://securityheaders.io/?q=www.uspto.gov&followRedirects=...
HSTS is 1 year at the time this comment is posted. They're in for some pain.
https://securityheaders.io/?q=www.uspto.gov&followRedirects=...
HSTS is 1 year at the time this comment is posted. They're in for some pain.
That should be considered a non-fun fact :)
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.
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.
> EDIT If it is for portal.uspto.gov then HSTS is a non-issue but still a very bad move.
Is it? I still see HSTS from portal.uspto.gov with the same age.
Is it? I still see HSTS from portal.uspto.gov with the same age.
chrome://net-internals/#hsts
doesn't seem to show anything for the domain
doesn't seem to show anything for the domain
https://obamawhitehouse.archives.gov/blog/2015/06/08/https-e...
Has this been superseded by a new policy?
Has this been superseded by a new policy?
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.").
[1] https://cio.gov/resources/it-policy-library/
[1] https://cio.gov/resources/it-policy-library/
The policy is still in effect, and its supporting home page is here: https://https.cio.gov
To be picky:
>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 ...
A URL beginning with HTTPS ALSO begins with HTTP
>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 ...
A URL beginning with HTTPS ALSO begins with HTTP
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.
I see what you did there.
They have a valid cert in use that only expires in 2019, and it's SHA256. But when you visit over HTTPS, this happens:
HTTP/1.0 302 Found
Location: http://portal.uspto.gov/pair/PublicPair
Server: BigIP
Does TLS termination cost extra for BigIP? Maybe their license expired or something?
TLS offload is usually extra on F5 BigIP
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.
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.
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.
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.
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.
crypto offloading isn't hard, and can be done on the NIC if you want/need: https://www.nextplatform.com/2016/10/03/server-encryption-fp...
SSL offloading is license-limited (TPS-wise) on physical F5 appliances, E.G., `10250v` vs `10200v-SSL`.
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.
HTTPS isn't bulletproof either, the argument could still be made with TLS
You also can't verify that the CA isn't rogue.
Or that the browser vendors that trust the CA the signed the certificate aren't just puppets for our lizard overlords.
Or that the browser vendors that trust the CA the signed the certificate aren't just puppets for our lizard overlords.
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.
The law doesn't work like that. Sorry.
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?
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?
The USPTO has a bulk download option[0]. The datasets are available from ReedTech[1].
[0] https://www.uspto.gov/learning-and-resources/bulk-data-produ... [1] http://patents.reedtech.com/Public-PAIR.php
[0] https://www.uspto.gov/learning-and-resources/bulk-data-produ... [1] http://patents.reedtech.com/Public-PAIR.php
Legal issues from mirroring something that's sort-of government property? I have no idea if it is or not, but I'd guess it's some sort of grey area.
As in, fear of extra-legal persecution or fear of legal prosecution?
Copyright generally doesn't stop people from copying what they want to copy. Do only BigCo's have a use for patents?
Copyright generally doesn't stop people from copying what they want to copy. Do only BigCo's have a use for patents?
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.
1: https://www.digitalgov.gov/2017/04/12/dotgov-domain-registra...
I wonder if 18f can help at all, it seems agencies must contact 18f themselves.
1: https://www.digitalgov.gov/2017/04/12/dotgov-domain-registra...
That's regressive as fuck, it's like saying that cars will no longer be allowed, only horse carriages
The gap between those two technologies is larger than you suggest.
Horse carraiges: 1400 Automobiles: 1890
Horse carraiges: 1400 Automobiles: 1890
Horses and cars were in use at the same time, just like HTTP and HTTPS; I'm not sure why their invention times are relevant?
Gunpowder and ICBMs were also in use at the same time
I'm claiming the technological backstepping is not nearly as drastic as the GP implies.
I'm claiming the technological backstepping is not nearly as drastic as the GP implies.
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.
Pretty sure horse carriages were around a lot earlier than 1400, unless you were thinking BC.
Even better. I was giving the benefit of the doubt.
That's around the time carraiges got suspension and were pretty much like the modern form.
That's around the time carraiges got suspension and were pretty much like the modern form.
Is there any way to find out who originally made the USPTO site? A contract company, government employees, etc?
Does anyone here actually read patent filings?
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.
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.
Isn't failure to perform a search with due diligence an equal liability in US patent cases?
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.
Patent lawyers read them and check if your work doesn't infringe. In my company that's standard procedure.
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.
Not sure if it's everything, but the USPTO provides this http://patents.reedtech.com
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.
This however seems to be everything:
https://pairbulkdata.uspto.gov/
Looks like people tend to be satisfied with Google Patent as well.
This however seems to be everything:
https://pairbulkdata.uspto.gov/
Looks like people tend to be satisfied with Google Patent as well.
Is this a joke?
HTTPS Everywhere*
* except uspto.gov
Are there any other .gov sites doing this? Can anyone shed more light on this?
* except uspto.gov
Are there any other .gov sites doing this? Can anyone shed more light on this?
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 ...
Fortunately, there are quite a few workarounds and opportunities that minimize all the associated risks ...
Also, at the bottom of the page "This page is owned by Service Desk." What does that mean?
And it's legal to publish a .GOV site using Drupal?
And it's legal to publish a .GOV site using Drupal?
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...)
I have no idea.
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.
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.
> Also, at the bottom of the page "This page is owned by Service Desk." What does that mean?
It indicates what department of the USPTO manages that page of the website. All pages have a "page-owner" tag in the footer.
It indicates what department of the USPTO manages that page of the website. All pages have a "page-owner" tag in the footer.
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?
Its not just the US government using Drupal. The Australian Government loves it and pays its contractors very well.
I bet 10$ that "errors" were reported by people who still run iexplore on Windows XD which doesn't support modern https.
[deleted]
As far as I know, this is illegal because of this:
https://obamawhitehouse.archives.gov/blog/2015/06/08/https-e...
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.
https://obamawhitehouse.archives.gov/blog/2015/06/08/https-e...
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.
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?
claimparse.com at least shows recent patents that have issued.
There has been a XSS vulnerability in the USPTO site since 2008 I reported. It still worked in 2014. Meatspinned quite a few coworkers using it.
> Meatspinned quite a few coworkers using it.
Don't do this.
Don't do this.
Please provide rationale showing that the associated risks outweigh the immense fun of "meatspinning" coworkers.
"Don't do this" is probably not very convincing.
"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 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.
(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.)
> 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.
No it doesn't.
> Yes, I'm equating "meatspinning" to malware
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?
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 ;)
If he was fired for meatspin or lemonparty, he would publicly accuse them of homophobia on twitter and things would be different ;)
claimparse.com
The answer to just about every question posed on this thread is the same: "it's the government!"
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
*https://thestack.com/security/2017/04/12/netflix-found-to-le...
*https://thestack.com/security/2017/04/12/netflix-found-to-le...
Never mind that HTTP can easily be man in the middled and tampered with and I have no way to ensure I am communicating to who I think I am.
> beginning at 12:01 a.m., Friday, April 21 and ending at 2 a.m., Friday, April 21 ET.
> 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 https://portal.uspto.gov/pair/PublicPair, will no longer work.
So it seems that the maintenance will turn of HTTPS, not that it's unavailable during the maintenance.
So it seems that the maintenance will turn of HTTPS, not that it's unavailable during the maintenance.
[deleted]
I don't think you read the whole thing.
> 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 https://portal.uspto.gov/pair/PublicPair, will no longer work.
> 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 https://portal.uspto.gov/pair/PublicPair, will no longer work.
I think that's the maintenance period, after which https won't be available.
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 https://portal.uspto.gov/pair/PublicPair, will no longer work.
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 https://portal.uspto.gov/pair/PublicPair, will no longer work.
> During the maintenance period, Public PAIR will be unavailable.
> Immediately after the maintenance, users will only be able to access Public PAIR through URLs beginning with HTTP,
> Immediately after the maintenance, users will only be able to access Public PAIR through URLs beginning with HTTP,
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/