The document distinguishes between enterprise-facing and public-facing systems. For enterprise-facing (government employees, contractors, etc.), it's talking about discontinuing use of TOTP. For public-facing systems, it doesn't impose any restrictions, since (as you're saying) the general public really needs options.
In those 5 years, HTTPS has gone from being the minority of traffic to being ~90% of the connections observed by most Chrome clients (scroll down a few graphs for the Chrome-observed one):
https://transparencyreport.google.com/https/overview
That doesn't mean that HTTP is banned, but given the magnitude of the change and the size of the web, I think it's fair to say that it's being deprecated.
More practically, anyone who wanted to build a product (or a government process) on intercepting or modifying people's unencrypted web traffic would find their dataset to be an order of magnitude smaller, and orders of magnitude less useful (since so much of the remaining HTTP traffic is in the long tail of small/older sites).
There's not federalism within states in a legal sense the way there is between states and the feds, but cities value their independence too and prefer to have their own infrastructure. I would expect the city, rather than the state, to be the reason they don't use a subdomain of the state's .gov domain.
CLAs are frowned upon by some, but they don't completely kill contribution from 3rd parties. I've signed plenty, and I've encountered plenty of projects that use them that continue to have a good community of outside unaffiliated contributors.
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.
Cloud Foundry doesn't have a problem injecting headers, as HTTP traffic is plaintext inside the system itself. It's once it starts traveling across the public internet that encryption is needed. This does make it harder for network edge caches and for middleboxes, but that's not totally a bad thing either.
What you're trusting the browser for there is the extra protection that preloading provides, but that's not the whole benefit here. The larger benefit is that it makes it infeasible for services to neglect to support HTTPS. So, even if your browser's preload list is busted, the site will be guaranteed to support HTTPS because of this effort, which you'll still benefit from.
Yes, I do know that hostnames are typically outside the HTTPS envelope. However, user-agent is not, and would be exposed (and could then possibly be correlated to other HTTPS traffic from the same IP address). Also, potentially cookies from a previous session -- even a previous HTTPS session -- could be exposed, depending on how careless the server operator is. (You can set flags to make sure cookies only go over HTTPS, but that doesn't always happen.)
From an integrity perspective, connecting to alerts.fema.gov over HTTP does potentially subject the user to code injection attacks. Those do happen:
Now, are any of these likely to happen on an arbitrary request to alerts.fema.gov? Maybe not. (Especially since Verizon has since been fined by the FCC.) But I'm trying to point out that it's not just the service owner whose safety has to be weighed in policies like this.
FWIW, the GSA plan announced in this post is intentionally crafted to be gradual and to avoid breaking things. It only affects future domains, not present ones, and so we'll have plenty of time to see whether being a total hardass about HSTS causes negative effects. Agencies can still do specialized services on their existing domains.
There's also going to have to be some carveout somewhere for specialized services like OCSP/CRL, which are already exempted from the policy mandate that came out in June 2015:
But in any case, the push should be, clearly and loudly, towards changing the defaults that browsers and users accept, and I think GSA's change weighs the tradeoffs appropriately in making such a push.
@prodtorok - This is one of the nice things about HSTS. The includeSubDomains directive can create automatic client enforcement for all subdomains. If some component of an agency ignores this and doesn't configure HTTPS, they'll find that users of modern browsers won't be able to access the site.
The one downside of includeSubDomains is that, with dynamic HSTS (without preloading), you have to get the user to visit https://agency.gov to "see" the HSTS header once to get that coverage. Visiting https://www.agency.gov or http://agency.gov won't do it.
So another benefit of preloading is that you remove that problem from the table -- browsers will enforce HTTPS for all subdomains, even if the user has never visited the root site. It's a powerful tool, and there is no analogue for other protocols (like IPv6 or DNSSEC) to set policies for an entire zone that you can expect most clients to enforce.
To quote my comment from above - bear in mind that when it comes to plain HTTP, it's not just the system's confidentiality and integrity that you need to weigh against availability: it's the user's confidentiality and integrity.
That's a larger moral responsibility, in my opinion. And consider that the fallback to prioritize availability in case of a non-attack cert error (e.g. revocation or expiration) is to ask the user to look at a certificate warning and make a personal trust decision about it. There are precious few users who can safely make that kind of a decision. And even if they "get it right" that time and click through and aren't attacked, you're training users to click through warnings, and helping them subject themselves to attacks in the future.
I would argue that that kind of "availability" is a very weak sort of availability. The government has enough problems with training people to click through certificate warnings (see: https://www.iad.gov) -- intentionally leaving that hole open seems unwise.
I wouldn't say this is reinventing the CA system. You don't need to trust any particular browser here. The effect is that web services must offer a secure HTTPS connection, using the existing CA system (or an enterprise CA, if their user base is truly all-enterprise), no matter what browser is being used.
Bear in mind that when it comes to plain HTTP, it's not just the system's confidentiality and integrity that you need to weigh: it's the user's confidentiality and integrity. That's a larger moral responsibility, in my opinion.
These issues were already worked through for the executive branch as part of the White House HTTPS policy published in June 2015:
Personally, I'd say that plain HTTP is insecure enough, and today's internet is hostile enough, that plain HTTP provides a very weak form of "availability". It's on site operators to ensure that when their services and information is available, that it's available in a manner that doesn't subject the user to risk.