To be fair, the article itself does state that the 7.1B figure does not represent unique users or handsets in use. Instead, it says that "The number of unique users is now 4.5 Billion or 63% of all humans alive are actually users of mobile phones. The remaining 2.6 Billion accounts are second or third accounts for the same user... So 20% of us, one in five who has a mobile subscription or account, actually walks around with two phones (and at least two accounts)."

Lots of people I know have at least two phones. Heck, I personally have a "work phone" and a "personal phone". My company is a lot less worried about their data mixing with other stuff, especially when combined with additional sandboxing mechanisms like GOOD. It helps me, too. If some organizational data gets out, my employer can erase the phone without me worrying that they'll erase my stuff. Also, I'm a lot freer to install apps than I would be if my company controlled what could be installed on the device that also housed my company's data.

This isn't even unusual. Phones are small and cheap enough to have two. Software-based security mechanisms leak all the time; making things physically separate is far more effective if protecting data actually matters. Not everyone needs to do this, but it's fairly common when data confidentiality really matters.

OpenSSL was actually examined by a lot of tools, but they all missed Heartbleed. My article How to Prevent the next Heartbleed lists approaches that could have found it. We need to improve how we examine this software so problems like this don't happen again.

But that's the point, we can and should take measures to prevent it. Even if we never eliminate all vulnerabilities, we can prevent many more vulnerabilities than we currently do.

Agreed, but not in C. You need to change C (and modify the code to use the functionality) or change programming language. The article does discuss switching languages.

The LLVM static analyzer finds this bug. So would warning about dead code, since the code past the point of the second goto...

Um, no. You're talking about the Apple "goto fail; goto fail;" vulnerability. That's a different vulnerability in a different program. They're both vulnerabilities in TLS/SSL implementations, but they are different programs.

Profiling w/ 100% code coverage would have caught this bug. - No, code coverage would not have worked in this case. Since the problem was that code was missing, you can run every line or branch without triggering the vulnerability. For more, see: http://www.dwheeler.com/essays...

Input fuzzing in the unit tests under memtest could have located this bug even faster. - No, not in this case. Fuzzers were countered because OpenSSL had its own set of memory allocators. When fuzzing you often are looking for crashes; to force buffer over-reads into a crash, the usual way to do that is to override memory allocation. Since OpenSSL managed its memory separately, the override had little useful effect. For more, see: http://www.dwheeler.com/essays...

I'm really glad you're trying to think of alternatives. However, when you say: 1). Initialize all allocated memory. Routinely and automatically.... They did. But the Heartbleed bug let you see currently-active memory. In particular, you have to have the private key available somewhere so you can use it.

Some of the weirdness was due to the spec itself (RFC 6520). I agree that error avoidance is better than parameter-checking, but it's not clear that parameter-checking could have been avoided in this case. But that's certainly worth checking out.

This referenced article is rediculous. First of all, the title says "Downfall of the Roman Empire", but Caesar FOUNDED the Roman Empire, so clearly it did not cause the empire's fall. I suspect they meant the fall of the Roman REPUBLIC, which preceded the empire. But it's still garbage. What most emperors wanted was power, not concrete buildings. The article doesn't even begin to make a connection between the two. If you want more about the history of the (Western) Roman republic and empire, listen to AWESOME "The History of Rome" podcast: http://thehistoryofrome.typepa... It's fantastic.

There's no "app" for screenshots because it's built into Android itself, and has been since 4.0 (which was released many years ago). It's volume down + power button. Just Google for "Android screenshot".

This makes no sense. If you want to search for code, the obvious way to do it today is use Google or some other search engine. Tomorrow, the obvious way to do it... will be to use Google or some other search engine. You don't need a "federated search", you just need a good search engine. There are a number of code-specific search engines that already work today too, again, there's no need for one system to rule them all.

I think there's great advantage in having an OSS management system for managing OSS projects.

One big improvement would be to make organ donation the *default* when obtaining a driver's license in the US. That way, people could opt out, but most people just "accept the default"... and then far more organs would be available to save the living.

I've had better luck with Chromebooks. Cloud printers are now very common, and in many cases buying a new printer costs little and is a big improvement anyway. For a list of printers that can work this way, see: http://www.google.com/cloudpri... I hate trackpads anyway, and I've had excellent success with normal mice on a Chromebook. Apple components often don't like working with non-Apple components, that may be the problem there. And all built-in laptop speakers are bad; if it matters, get speakers, they're cheap.

This is very common in the military and in defense contractors, and it happens elsewhere too. There is a reason for it. Many of these organizations are worried about malicious stuff going in and/or exfiltration of non-public data going out. Employer MITM makes it easy to examine every packet for these kinds of things (to counter them). In the US, at least, it's generally accepted that employer equipment is owned by the employer, and thus they expressly have the authority to examine what goes over their own network... and as a condition of employment or computer use you probably signed something agreeing to this. I'm not a fan of this approach, but it certainly happens.

Open source software that implements crypto protocols (e.g., SSL or SSH) will (correctly!) report that there's a MITM attack. So if you want to actually *use* the software in such settings, someone has to configure the software to trust the MITM. Some admins will do this automatically. If not, you may need to do it yourself. E.G., on Firefox, install the organization's certificate.

You configure Linux systems to work in these environments, but since the certs are often files in Windows aka DOS aka CP/M format, you need to convert the files as well as put the into somewhere useful. Here's one way to deal with it.

On Fedora, given a bunch of .crt files, you can do this:

dos2unix *.crt ; cat *.crt >> /etc/pki/tls/certs/ca-bundle.crt

On Ubuntu, you can do this given a bunch of .cer files:

dos2unix *.cer ; rename 's/.cer$/.crt/' *.cer ; ca=/usr/share/ca-certificates ; mkdir -p $ca/MYORG ; cp *.crt $ca/MYORG ; cd $ca ; ls MYORG/* >> /etc/ca-certificates.conf ; update-ca-certificates

You could avoid appending to the file if you want to, but I'll leave that as an exercise for the reader.