Administration Admits Obamacare Website Stinks 516
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."
Computer ? Website ? (Score:4, Interesting)
Silly question, but... what happens when you want to apply and you don't have a computer ? Surely, by definition, a sizable portion of the population that requires Obamacare doesn't necessarily have the means to have a computer or an internet connection.
And no, "anybody has a computer these days" is not an answer. I know plenty of people who don't have enough to feed themselves, let alone buy a computer - let alone one that's recent enough to cope with plugins that invariably tell you "your operating system / browser is not supported anymore, please upgrade." every 6 months.
Re:What does IT run on .. (Score:4, Interesting)
Re:I'm confused (Score:1, Interesting)
" thought that nobody wanted obamacare?"
Many millions will lose their current insurance on Jan 1 because of Obamacare. The law makes it illegal to sell certain types of insurance, and they're forced to sell you prepackaged insurance similar to the way cable companies package channels.
Those millions don't want obamacare. They just have no choice. But on the plus side, most will get to pay more for it.
Re:Gov't project (Score:5, Interesting)
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.
Re:Gov't project (Score:3, Interesting)
How does Mongo help prevent stupid amounts of javascript files to transfer?
Anything more than just a couple of javascript files is inexcusable for the kind of requirements a site like this has.
There are plenty of ready-made solutions to merge javascripts files for live sites.
I have no doubt there are other problems though, and the persistant storage may well be one of them.
Re:What does IT run on .. (Score:4, Interesting)
Often times the killer is something stupid like incorrect http headers that prevent caching, which means every request to akamai hits the origin.
Re:Healthcare.gov problems are real (Score:2, Interesting)
Isn't it odd how, until 2009, it was considered every citizen's sacred duty to disobey the law and trash the government? If the government did something good, it was every citizen's duty to set it on fire, just on general principles. Then suddenly it changed overnight, and anyone opposing the government was a scary weirdo. People are sternly advised to follow the law in all circumstances, and lawbreakers are our worst enemies.
I used to think the "we have always been at war with Eastasia, we have always been allied with Oceania" was the least believable, most contrived part of Orwell's Nineteen Eighty-four. That is, until 2009 when I experienced the flip-flop in real life.
Re:Gov't project (Score:5, Interesting)
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.
Re:What does IT run on .. (Score:5, Interesting)
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.
Re:I'm confused (Score:4, Interesting)