No, it is not validly cached, at least not in any useful sense given the sea of caching proxies and user agents in the field. The headers presented merely hint that discretionary caching is okay, and do nothing to encourage caching either by proxies nor end user agents, nor inform such recipients of additional criteria which affects these factors. Please read RFC 2616 and come back when you're done.
Do the needful? Is this supposed to be something an Indian tech suport person might say?
It's not supposed to be. It is.
I'm not confusing anything. I've actually written a caching proxy from scratch, and there's a difference between saying the content could be cached and aggressively encouraging it. The headers are incomplete in this regard. Please refer to RFC 2616.
I'll just go ahead and directly quote from your notes:
This response allows a cache to assign its own freshness lifetime.
You apparently don't spend very much time actually working with various caching proxies or examining the default behavior of various user agents when presented with various options (some caches follow RFC 2616 better than others, and different or incomplete response header combinations may well cause unexpected behavior as a result), or you wouldn't have wasted your time with a misleading and ultimately misleading response.
I've actually written a caching proxy and HTTP/1.1 accelerator from scratch. I suspect you haven't, which would have a lot to do with why you don't know what you're talking about.
Incidentally, I'm keenly aware they're using Akamai for CDN purposes. That doesn't make this any better; in fact, given some of their functionality, it makes it worse. Time for bed.
Let's examine an HTTP request for a rather beefy portion of the JavaScript in question from healthcare.gov:
pparadis::palegray-mobile { ~ }-> curl --head https://assets.healthcare.gov/global/js/lib/jquery-1.8.2.js
HTTP/1.1 200 OK
Server: Apache
ETag: "cfa9051cc0b05eb519f1e16b2a6645d7:1370524513"
Last-Modified: Thu, 23 May 2013 15:59:12 GMT
Accept-Ranges: bytes
Content-Length: 93436
Content-Type: application/x-javascript
Date: Tue, 08 Oct 2013 09:44:20 GMT
Connection: keep-alive
They're not even bothering to set the HTTP Cache-Control, Proxy-*, or Expires headers on this content, which will most assuredly limit intermediary proxy and client caching. To say this is amateur hour would be a gross exaggeration of the skills being fielded by these developers.
Much larger issues undoubtedly exist in their backend infrastructure. Given the shit I've seen in this area, I could probably spend the next hour making educated guesses about how badly they've fucked up in various regards, spend another hour partially validating those guesses, and wind up just saying "yup, they're idiots." Instead, I think I'll go to bed now. I have work in the morning.
So the story here is that a large team of software developers with no demonstrated experience in developing, testing, performing quality assurance for, and administering large scale enterprise application deployments get a federal contract and botches it horribly. Color me shocked.
I've been working in development and architecture roles for fifteen years, and have seen exactly the same pattern on a variety of scales over and over again. I've seen a number of rather large infrastructure development projects that worked out very well too, but none of those were public sector projects.
Just remember that the folks responsible for this mess are certainly still taking paychecks while an enormous number of government workers are suffering due to the inability of our Congress to do its job. Good times, huh?
For one, there was no back up plan, no person he delegated responsibility to make transfers in his absence. He said as much in his forbes interview; that he delegated customer service responsibilities but it was him and only him that could manage the site or it's bitcoins. No reason to disbelieve it. Maybe early on, he had delegated but after the first employee theft (the first alledged hit), certainly he would have moved to change that , as paranoid as he seemed to be in some regards.
You continue to make the assumption that he had no backup plan, and you offer (perhaps understandably, as you're not inside his head) no supporting evidence aside from statements on his part that any sane person would make, regardless of the truth of those statements. I've known a couple of guys who got in some trouble and had seven figures to lose, and be assured they both had contingency plans despite their pleas to the contrary. You aren't privy to his personal network of relationships; stop pretending you are. You shouldn't assume getting burned by one employee equates to never "hiring" again. I was once burned to the tune of USD $40K by an employee, which was not a small sum of money for me. I didn't stop hiring, but I did get smarter about it.
Second, even if somehow he gets his sentence reduced, it'll certainly be preconditioned on his turning over his remaining proceeds. They won't say "give us your money and you're free" to his "I'm sorry, I would I forgot my key though" and reply "ok, sounds good, you're free"
Aside from a fundamental misunderstanding of how scenarios on this level typically play out (they don't actually care about his money; they care much more about who he can help them grab to further pad their resumes), you make the mistake of assuming he'll be convicted and sentenced to anything more than a decade in prison. Conviction is uncertain, anything more than ten years is unlikely. Most men can do ten years with the knowledge that they have a fortune waiting on the other side, as long as they're smart about how they conduct themselves following release. Again, he wouldn't be the first guy to play it smart in this regard.
No. There's no way he's being released any time in the future if there's even a question that he could access those funds. Maybe he should start praying that bjtcoin finally reaches its overdue demise so that the Feds don't think he has anything of value any longer. One day...
Once again, the people prosecuting him don't give two shits about Bitcoin. Think about that for a while.
Fair enough
When referring to the Perl programming language, the correct usage is Perl. Given the fact that you're apparently in a position to make hiring decisions on programmer positions, you would be well advised to be well versed in proper naming conventions. Incidentally, I've been coding in multiple languages, although predominantly in Perl, for twenty years. I'm not looking for a job, though.
You're cute. Good luck seizing encrypted material that's probably replicated to fifteen servers in fifteen countries, while the servers themselves are unknown to you. Have fun, champ.
He'll probably just let the process play out with his public defender, aiming for the lowest legal penalty possible, and promptly leave the country for a non-extraditing locale at the first opportunity. Then he'll able to recover his funds and go about his life, more or less as he wishes. There's virtually no chance of those funds being recovered by the authorities; I'd be very surprised to learn that the BTC in question are still in the wallet in question even now. Setting up contingency plans for transfers and further action, based anywhere on the planet, are simply too simple a concept to have been overlooked.
I believe you lack adequate information on how Bitcoin works. If he or someone he trusts and gave instructions to beforehand has access to another copy of the wallet, it's just as good as the original, and the coins may be transferred elsewhere and converted to other currencies, etc via the normal exchanges. I'll be surprised if the prosecuting authorities manage to figure out how to track that; they certainly won't be able to stop it. If by some chance they manage to gain access to the encrypted keys that protect the wallet in their possession, it almost certainly won't be of any value (to them) by then.
I don't get pissed off at public records being made available to the public. I get pissed off at unreasonable legal requirements that lead to things being entered into the public record in the first place, and I fully support every individual's right to make his/her own decision on whether their ownership and use of firearms should be a matter of public record or not.
People who follow the law in this case wind up unreasonably burdened and subject to information disclosure beyond their control. People who do not follow the law aren't burdened by it, and do as they like without the mere existence of the laws or threats of prison sentences doing anything to stop them from committing violent acts. Put simply: neither nanny state mentalities nor "tough on crime" policies actually work very well. See how this works?
Do you support privacy rights? I certainly do, and I support equality as well, meaning I don't pick and choose which citizens deserve privacy and which don't.
For the record, if you're planning on creating your own app to show who owns firearms, you can add me as your first entry. I gladly volunteer this information; kindly respect the privacy of others until you're told otherwise. Have a nice day, champ.
I'm happy to broadcast it, despite the risks associated with such a broadcast. I'll gladly support anyone subjected to illegal seizure by any means necessary, and for those who would attempt an amateur grab: try it.
Those who can, do; those who can't, write. Those who can't write work for the Bell Labs Record.
