Slashdot Mirror
Administration Admits Obamacare Website Stinks
Hugh Pickens DOT Com writes "The WSJ reports that six days into the launch of insurance marketplaces created by the new health-care law, the federal government finally acknowledged that design and software problems have kept customers from applying online for coverage. The website is troubled by coding problems and flaws in the architecture of the system, according to insurance-industry advisers, technical experts and people close to the development of the marketplace. Information technology experts who examined the healthcare.gov website at the request of The Wall Street Journal say the site appeared to be built on a sloppy software foundation and five outside technology experts interviewed by Reuters say they believe flaws in system architecture, not traffic alone, contribute to the problems. One possible cause of the problems is that hitting 'apply' on HealthCare.gov causes 92 separate files, plug-ins and other mammoth swarms of data to stream between the user's computer and the servers powering the government website, says Matthew Hancock, an independent expert in website design. He was able to track the files being requested through a feature in the Firefox browser. Of the 92 he found, 56 were JavaScript files... 'They set up the website in such a way that too many requests to the server arrived at the same time,' says Hancock adding that because so much traffic was going back and forth between the users' computers and the server hosting the government website, it was as if the system was attacking itself. The delays come three months after the Government Accountability Office said a smooth and timely rollout could not be guaranteed because the online system was not fully completed or tested. 'If there's not a general trend of improvement in the next 72 hours of use in this is system then it would indicate the problems they're dealing with are more deep seated and not an easy fix,' says Jay Dunlap, senior vice president of health care technology company EXL."
Not really.
They're built by lowest bidders Serco and QSS Inc. Neither an American company.
If they had decided to hire Americans to do this job, they would have had a very large pool of qualified and skilled workers from which to choose.
They're using their grammar skills there.
I am certainly NOT a proponent of out-sourcing (I will not debate my reasons here). However, let's put the blame squarely where it belongs - on the accepted process of hiring the lowest bidder with no vested interest in getting it right vs one where getting it right would have great impact on the users.
If this work was being done by Americans who actually need to rely on the ACA for their health care coverage, you can bet your ass that it would have been done right - the first time. And, those who are involved can say it was an American success story. Instead, we now have another reason for it's opponents to call the whole program a failure.
Brilliant.
There's a thing called HTTP 1.0, and in it there's a feature called Connection: Keep-Alive. It doesn't spawn a new TCP connection for each of those 56 javascript files. Only one TCP connection per (sub)domain is made when Keep-Alive is in use. This was such a nice feature that in HTTP 1.1, all connections are considered persistent "keep-alive" unless you write Connection: Close. From a network standpoint a few extra lines of HTTP headers between each script isn't going to matter, and if it's cached and/or co-located properly (eg: via Akamai), it actually does matter, since those requests are going to be served from the caches efficiently.
However, the biggest problem is that HTTP is fucking dumb. No, really, it's dumb. Not that it's designers were dumb, just that it's evolved over the years and security was never part of the design. For one, there is no such thing as a "Session". In this day and Age of Information that's ludicrous! Say you use a session cookie to validate every single request for every single resource is valid... because that's what you have to do, then EVERY COOKIE gets sent to the server EVERY TIME you make a request. It's so much face palm, I can feel the back of my skull.
On the security standpoint, neither HTTP or HTML really knows how to actually work with encryption. That happens in TLS. What a fucking crock of shit. HTTPS means you can't cache anything. Most of the files being served are NOT dynamic, but STATIC files. However, since HTTP/HTML are so fucking dumb they can't even provide a simple hash, then you can't trust mixed content. If in addition to the URL of a static resource, you could also include a known hash:
<img src="..." digest="d8b09c45b522e34d81ac9eed95f922c7028e7fb2; type=hex/SHA-1">
Then the browser could hash the unsecured (cache-able) resource as it's pulling it in at the behest of the secured dynamic (uncatchable) page, and verify that the requested unsecured content wasn't tampered with in transit so it wouldn't be a security issue and we could actually FUCKING USE SECURITY EFFICIENTLY, grrr. Especially if you could specify a few bits of salt with the hashes...
<img src="..." hmac="WkRoaU1EbGpORFZpTlRJeVpUTQo=, TlRJeVpUTTBaRGd4WVdNNVpRbwo=; type=base64/SHA-1">
But, no, that doesn't exist. No HTTPS content is cached. Apparently I'm the only one on the planet not drinking the damn cool-aide. The web is bloated and retarded, it needs to die. Long live the Internet, but fuck the web. It took HALF the age of the Internet just to get from HTTP 4.01 to HTML 5... Over a Decade, and this shit still isn't in the spec. Don't hold your damn breath for next version, or for anyone with a fucking clue how things should work to propose sane changes. Even Google with SPDY is just exacerbating the issue with bandaids over the inefficiencies of HTTP.
TL;DR: Yeah, it's a shitty website / backend design, but primarily it's because HTTP/HTML is just fucking retarded.