[popey456963]

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.

[anigbrowl]

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.

[fapjacks]

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.

[k_sh]

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

/s

[curiouscats]

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.

[tormeh]

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.

[monochromatic]

> relatively small government

Are we talking about the same government??

[a3n]

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.

[shimon_e]

Hiring freeze was lifted on April 12, 2017.

[r00fus]

Plenty of time to hire someone and sort out all the issues!

[DonHopkins]

At which point they started hiring only loyal idiots.

[drdaeman]

Maybe someone sued them over some highly-innovative encryption patent they've previously granted? :) /s

[jbob2000]

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.

[stonesam92]

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.

[mcbits]

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.

[sgt101]

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...

[mcbits]

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.

[dom0]

Didn't your country just drop the privacy protection rules that hindered ISPs from selling any American's browser history?

[ErikBjare]

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).

[bcook]

Plausible deniability? Shifting blame?

I'm just playing Devil's advocate here.

[zkms]

> 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.

[jagger27]

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"?

[copperx]

What do you mean by that? Is knowing the URL of a HTTPS request a solved problem?

[jagger27]

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.

[cookiecaper]

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.

[dsmithatx]

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.

[otoburb]

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/

[pbhjpbhj]

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?

[otoburb]

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