Take a look at the top-voted answers to "How to explain Heartbleed without technical terms?" on security.SE and repeat that:

http://security.stackexchange.com/questions/55343/how-to-exp...

The two top-voted answer includes WAAAAAY more information than the XKCD comic, so they're not really comparable. The third one explains it pretty simply.

That's exactly the point: some experts, when asked for a simple explanation, produce a huge info-dump in simplified terminology, and most experts thought that an appropriate response (see upvotes) - failing to realize that the result is anything but simple.

It takes a special skill to eliminate all the non-essential information and produce something truly simple to understand, like the comic.

Myself included. So many interesting topics to touch on when explaining something.

The only reason I ever manage to be short in text form is being able to go back and delete.

Oh, gotcha, agreed!

Sure, it's simple if you realize that memory heaps are sequential and the server's private key can be found after the address of a short-lived packet buffer... It is not trivial explaining all that with simple analogy my grandmother would understand.

> it's simple if you realize that memory heaps are sequential and the server's private key can be found after the address of a short-lived packet buffer…

Your comment seems to imply an out of bounds access (read past the allocated buffer), but heartbleed has no out of bounds access.

Instead, it's a problem of malloc (and even more so openssl's freelist scheme) returning non-zeroed memory which can (and often does) hold previously allocated data combined with read(2) not overwriting the whole buffer and not checking read(2)'s return value, which means the aforementioned previously allocated data gets sent back.

I had no problem explaining it to my non-technical family members. The way I described it is that the server would return whatever happened to be there.