By standard and by law, a "k" is x1000, an "M" is x1,000,000, and so on, and NOTHING else. Standards groups like IEC and IEEE are unanimous: they ALWAYS mean a power of 10. There have already been a number of court cases where someone used "K" etc. to mean binary prefixes, and every time they have had to concede (and typically end up paying up in out-of-court settlements). Examples include Willem Vroegh v. Eastman Kodak Company and Cho v. Seagate Technology (US) Holdings, Inc.

And don't tell me that computers "always" use base 2 measurements. Hard disk drives, clock cycles, and bandwidth are typically measured using base-10 prefixes (multipliers of 10^3). Yes, RAM has been traditionally been measured using prefixes that imply powers of 2, but the errors have been getting worse and worse as the numbers get larger.

Technologists should care about being precise. If you can't tell what a number means, that is a problem. The binary prefixes are a nice solution to a widespread problem. If you don't care about precision, use whatever term you want. But when you want to measure accurately, use the right units.

The practical problem is a difficulty of communication. The purpose of words is to help us communicate. If we have no word for a common idea we want to express, then we usually create a new word or phrase.

Let's say we observe an object, with mass less than a star, that is orbiting a star other than our Sun. What, exactly, do you call it? Under the IAU rules, you cannot call it a planet, because we generally cannot know if it has cleared its orbit. The standard solution in English is to call it a "planet". But if we call it a planet, then we should use the same definition everywhere.

As I commented years ago, the worst problem with the current IAU definition of "planet" is a practical one: we can't practically use it for objects orbiting other stars.

We are too far away to observe small objects around other stars, and I think we will always be able to detect larger objects but not smaller ones in many faraway orbits. So when we detect an object in another galaxy with the mass of Jupiter, and it’s orbiting a star, is it a planet? Well, under this current definition we don’t know if it’s a planet or not. Why? Because we may not be able to know what else is there in orbit. And that is a real problem. I think it’s clear that we will always be able to observe some larger objects without being able to detect the presence of smaller ones. If we can’t use the obvious word, then the definition is useless - so we need a better definition instead.

I think a much better definition of "planet" is "orbits a star, enough mass to become round". Yes, that means that Ceres and some Kuiper Belt objects become planets. That's a GOOD thing. A lot of people don't know of Ceres, yet that one object has about 1/3 of the ENTIRE mass of the asteroid belt.

Of course, none of this affects reality; this is merely a definition war. But clear terminology is important in any science.

This is a big deal. If you use a browser on Windows that does NOT counter this, such as Internet Explorer, then you ARE vulnerable. I imagine Microsoft will come out with a special-purpose patch, but still, this is a pretty nasty issue.

Untrustworthy CAs have been a problem for a long time; we need mechanisms to address them. The terrible cert revocation system makes it even worse; you can't be sure that the certs are checked in many cases. Chrome's CRLSets are not the answer; they are not even the beginning of an answer. We need to fix the whole revocation system. Sadly, there hasn't been enough work or enough urgency on these problems; maybe this will light a fire under those efforts. I doubt it, but it's worth hoping.

The difference is that in a conspiracy someone plans to DO something unlawful, or cause someone else to do it... and not just talk about it. A "conspiracy" is "a secret plan by a group to do something unlawful or harmful". A fantasy is just the "activity of imagining things".

I'm glad that people are learning about this problem. Sadly, it's not new, it's been known for decades. CERT’s “Secure Coding” item MSC09-C (Character Encoding — Use Subset of ASCII for Safety) specifically discusses the vulnerabilities due to filenames. The Common Weakness Enumeration (CWE) includes 3 weaknesses related to filenames (CWE 78, CWE 73, and CWE 116), all of which are in the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors. My freely-available book on writing secure software has a whole section about filenames. And so on.

We need to fix the problems with Unix/Linux filenames, not just keep rediscovering them. In particular, ensuring that filenames had no control characters, no leading dashes, and used UTF-8 encoding would simplify developing correct programs. Most people writing software already follow these rules. We don't need to make it easy for attackers.

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...