One of my current roles is to provide technical support/advice for a group of project managers and business analysts. This morning a few of them had watched the Crash News Network over breakfast and came in convinced that privacy, as we know it, had come to an end. My job is to talk them off the ledge (and I actually enjoy it, they're smart people and as long as I explain it correctly, they get it... I've found that's pretty rare).

1. The issue only exposes 64k at a time. Let's assume that the average enterprise application has at least a 1G footprint (and that's actually on the low end of most applications I work with). That's 1,048,576K. At best, this means that this exploit can access 0.006% of memory of an applications memory at one time.

Ahh you say, I will simple make 16,667 requests and I will retrieve all the memory used by the application.

2. The entire basis of this issue is that programs reuse memory blocks. The function loadAllSecrects may allocate a 64k block, free it and then that same block is used by the heartbeat code in question. However, this code will also release this same block which means that the block is free for use again. Chances are very good (with well optimized code), that the heartbeat will be issued the same 64k block of memory on the next call. Multi-threaded/multi-client apps perturb this but the upshot is that it's NOT possible to directly walk all of the memory used by an application with this exploit. You can make a bazillion calls and you will never get the entire memory space back. (You're thinking of arguments to contrary, your wrong... you wont.)

Congratulations, much success... you have 64k internet.

3. Can you please tell me where the passwords are in this memory dump:

k/IsZAEZFgZueWNuZXQxFzAVBgNVBAMTDk5ZQ05FVC1ST09ULUNBMB4XDTEwMDMw
MzIyNTUyOFoXDTIwMDMwMzIyMTAwNVowMDEWMBQGCgmSJomT8ixkARkWBm55Y25l

There will be contextual clues (obvious email addresses, usernames, etc) but unless you know the structure of the data, a lot of time will be spent with brute force deciphering. Even if you knew for a fact that they were using Java 7 build 51 and Bouncy Castle 1.50, you still don't know if the data you pulled down is using a BC data structure or a custom defined one and you aren't sure where the boundaries start and end. The fact that data structures may or may not be contiguous complicates matters. A Java List does not have to store all members consecutively or on set boundaries (by design, this is what distinguishes it from a Vector).

Long story short. Yes, there is a weakness here. However, it's very hard to _practically_ exploit... especially on a large scale (no one is going to use this to walk away with the passwords for every gmail account... they'd be very, very lucky to pull a few dozen).

This doesn't excuse developers from proper programming practices. It's just putting "Heartbleed" in perspective.

People lining up at food banks aren't going to be going to costco and buying peanut butter in bulk. The same goes for families whose children benefit from school meal programs.

Unfortunately there is a degree of truth to the OP's comment about Costco being afraid of getting sued. I used to volunteer at "under privileged" schools and staff were specifically told not to give food to children in need but to direct them to one of the official programs. Litigation was cited as one of the reasons, as well as concern about children flying under the radar and not getting all the help they needed, etc. The cafeteria wasn't even allowed to give out unused food. The school district in this case was very concerned about getting their butts sued off because of a well intentioned act that went bad (it had happened before). It was a disheartening situation all the way around.

By definition a true exchange should never lose your money. You can lose your money, but they won't. An exchange is a barter system, you trade X for Y. Legitimate exchanges charge for a "seat" on the exchange, a percentage of the transaction, or both. However, they never just take your money. They may require that you put money in escrow to cover your position but this is set aside, usually drawing risk free interest (or as near as you can get to it) unless you specify otherwise.
No one should be able to prevent you from putting your money into unregulated vehicles/investments but if consider it any more than gambling and expect any protection then you're an idiot. In the US, gambling is actually more regulated than bitcoin transactions (at this time). If you hand off your "wealth" (of any kind) to any unregulated, un-vettted nob who managed to register a TLD then I would like to discuss a long-term, can't lose investment in the Brooklyn Bridge with you.

Let me repeat this. If you just hand over your wealth to someone with no legal safeguards in place, you're a dumba$$. Clear?

AMD's Bulldozer cores have Clustered Integer Core which has two true ALU "cores" and one shared FPU. For integer instructions this is two true cores and not "hyper-threading". For FP instructions this is "hyper-threading" and why Intel has been regularly handing AMD it's arse in all benchmarks that aren't strictly ALU dependent (gaming, rendering, etc). AMD's FPU implementation, clock for clock, is a bit weaker on most instructions as well. And yes, the FPU _is_ shared on AMD processors.

EMT64 is not "32 bits on each 1/2 of the clock cycle". That doesn't even make any sense. EMT64 is true 64 bit. x86-64 does have 32 bit addressing modes when running on non-64bit operating systems. This is part of the x86-64 standard and hits AMD, Intel and VIA.

Hardware Queuing Support is part of the Heterogeneous System Architecture open standard and won't even be supported in hardware until the Carizzo APU in 2015. Since this is an open standard, Intel can chose to use it.

Both architectures have shared caches.

WTF does nVidia's IEE-754 compliance have to do with Intel vs AMD?

I'm not an Intel or AMD fanboy, I try to use the right one for the job. I prefer AMD for certain work loads like web servers, file servers, etc because they have the most integer-bang for the buck. If I'm doing anything that involves FP, I'm going to use an Intel Chip. Best graphics solution?... yeah, I'm not even going to go down that hole.

And don't forget about bugs with Java itself. We spent about half a day trying to figure out why an application that had been functioning until a Java upgrade stopped talking to the MS-SQL server it used, until we stumbled across JDK-7103725. We had to rollback until it was fixed (which actually took a few builds). There is a tiny bit of truth to the "Write once, break everywhere." troll.

It doesn't matter if he suspected or knew... in either case transactions should have been suspended. Let me demonstrate the issue for you:

"DaveV1.0 paid me to house sit while he was on vacation. I suspected that a friend had stolen the key, was taking his valuables and defiling his gerbil but I didn't bother to change the locks or even drive by the house to see if anything was amiss."

I suspect you wouldn't care if I suspected or knew at this point, you would still hold me responsible.

You did mis-read the article. They're not proposing it as a quantum computing solution, nor are they proposing to improve RAM speeds by using electron spin. They're proposing to use the electron orbital state to store information. Currently a charge (multiple electrons) are used to store one bit. This solution would allow one single electron to store one or more bits. This could be used to produce faster storage but it has other applications as well, such as faster switching logic. The end result would be a substantially faster computer and improved information density but it will still be deterministic.
I'm not sure how you inferred any claims to quantum computing or NDTM's from that article.

Actually, it could prove to be radically different than current computers/computing. Almost all current computers are based on binary logic, your bit is either on or off. Electrons can actually have several orbital states so it is possible that computing could be approached in a different manner. This assumes that logic could actually be performed with the orbital states and it's not just a bit store. All of this is quite a long way off though, per the article you currently need a two mile long accelerator to change the orbital state of an electron this accurately.

"Bloat" is a feature common to all engineering tasks, not just software. Anyone who follows the aviation industry can tell you that this happens over, and over and over again. Requirements are put out, designs are submitted and then the wonks start coming in and saying "well, we could also add this", "well we could also add that". Every time this is allowed to happen, it's a complete failure. The designs that succeed are the ones that stay true to the original requirements. e.g.
U-2: I fly high and far, nothing else.
SR-71: I fly fast, nothing else (attempts we're made to add intercept capability and rejected).
F-14: I intercept, nothing else (attempts we're made to add bombing capability and rejected).
F-15: I will own the skies and do nothing else (bombing has been added on but it has not strayed from it's mission).
AV-8B: I will provide forward air base support and nothing else.

While I'm not arguing that they should not be held accountable, what you're proposing is not a "fix". The system should be designed so that they can't be negligent in the first place.

The primary justification for not overhauling the inherently weak credit card system in the US has been the cost to the retailers, banks and credit card processors. And there's some validity to this, upgrading the system would have a major impact everyone from the banks and large retailers on down the the mom and pops and the card holders themselves. However, the cost of continually cleaning up these messes is going to start adding up. It's time to accept the fact that the current system is horribly outdated and fix it (most retailers in Europe won't even accept chip-less us cards anymore).

This story is pushing a month old and has already made the rounds on the DrudgeReport, Digg and other aggregators and is dead and buried. Note to /. editors... you can actually find and post new content ... your job isn't limited to filtering out dupes.

Carriage laws in the US prevent a ticket price from being changed after it is purchased. This includes canceling the ticket because of the price it was issued at (because this is effectively the same as changing the price of the ticket since the consumer would have to repurchase it). You'll notice that Delta's carriage policy specifically outlines that they will never sell a ticket for $0 so they can excluded it. Since they can't state this for any other fare price, they can't exclude it and it falls under the general carriage policy. http://www.delta.com/content/dam/delta-www/pdfs/legal/contract_of_carriage_dom.pdf It would be different if, say, Kayak or Expedia screwed up and gave the wrong ticket price... but since this was on the carriers website and they are dealing directly with the customer, they are SoL.

Aluminum is a perfectly sound material as long as it's used correctly. It's been used in aircraft, rockets and other vehicles that take stresses far beyond what you will ever do to your truck. Flying may seem like it doesn't generate much stress but the loads on a 747 or A380 when they are landing are tremendous. The regular compression/decompression cycles that a plane goes through when going from ground level to altitude are also impressive when you look at the numbers. The fact that we consider it so commonplace is a testimony to how durable aluminum is. The average person is shocked when they see the thickness of the tubing used in bicycles, including downhill mountain bikes which take one hell of a beating.

But this is all contingent on how the aluminum is employed. If they have good, experienced engineers then this can only end well (I'd love to have a truck that didn't rust).