Much as JSON is without a doubt far from perfect, I think most of the article is rather meh.<p>Protobuf won't stop people from trying to put a license keys, card numbers, or other IDs in a 64-bit float or int. All it'll do is make someone be able to smugly point to a certain person and say "you're stupid, you did this incorrectly as per the spec". The extra assurance could even make things worse, e.g. using 64-bit ints for credit card numbers and having something break that interprets it as a signed int (or perhaps become unusable if 20-digit numbers happen), or have code that converts it to a float anyway, devolving back to 53-bit precision. The "fix" for both formats for normal people is still exactly the same - "please please please don't put things that aren't strictly counts of things or imprecision-tolerant real numbers in number types".<p>Unpaired surrogates is just a question of which component fails. If any! An arbitrary user input containing an unpaired surrogate would likely be better off quietly transformed (or preserved) than become a DoS vector.<p>Lack of NaNs, infinities, and compact ways to encode arbitrary bytes are the things I personally find the most unfortunate. The special constants are especially weird as null/false/true exist, but byte strings do have the problem that not all languages have a reasonable distinct thing for such to map to.<p>A funky side-note is that JSON being so tolerant/imprecise (and as such most suppliers not pushing it to edge-cases) means that crappy parsers/producers aren't typically particularly problematic, though this perhaps isn't really a thing to judge data formats by.