The author of this post isn't properly characterizing langsec:
The basis of language security is starting from a programming language with a well-defined, easy-to-understand semantics. ... This approach is taken, for example, by Google's Caja compiler to isolate components from each other, even when they run in the context of the same web page.
From what I can tell, he's talking about the broader area of "programming languages and security". That is not the same thing as http://langsec.org/, which is essentially about using grammars to recognize network PROTOCOL formats.
As far as I remember, one motivating vulnerability is that there were two different parsers for SSL certificates, which allowed attackers to trick browsers into accepting invalid certificates. That doesn't have anything to do with programming languages per se; you can write this vulnerability in any language. It's analogous to the fact that using a safe language doesn't prevent you from SQL injection.
Just FTR, your critique is answered by Stefan Lucks, Norina Grosch, and Joshua Koenig's paper[0] from last year's langsec workshop at IEEE Security and Privacy. They define a formalism, calc-regular languages, to handle length-prefixed strings.
The basis of language security is starting from a programming language with a well-defined, easy-to-understand semantics. ... This approach is taken, for example, by Google's Caja compiler to isolate components from each other, even when they run in the context of the same web page.
From what I can tell, he's talking about the broader area of "programming languages and security". That is not the same thing as http://langsec.org/, which is essentially about using grammars to recognize network PROTOCOL formats.
As far as I remember, one motivating vulnerability is that there were two different parsers for SSL certificates, which allowed attackers to trick browsers into accepting invalid certificates. That doesn't have anything to do with programming languages per se; you can write this vulnerability in any language. It's analogous to the fact that using a safe language doesn't prevent you from SQL injection.
Some examples of what they are trying to address:
http://langsec.org/papers/langsec-cwes-secdev2016.pdf
I wrote a critique of langsec a few months ago here:
https://lobste.rs/s/uyjzjc/science_insecurity_meredith_l_pat...
tl;dr I think they are using the wrong formalisms.
I found it odd that the author was assuming that langsec is a widely used thing when I think it is nascent research.
Even Google Caja, a totally different project outside of langsec, is not widely deployed, although I very much like its ideas.