Comment by klibertp
1 day ago
> They all have failed.
That's not true. Most have failed, but those who used the right tool for the job - a rich, static type system in a functional language - did succeed. It's just that such type systems are rare, and even if nominally a type system is good enough, the required boilerplate might be uneconomical to maintain. Scala and F# are probably the only two languages that are mainstream-adjacent, at least, and have type systems expressive enough that using them to track escaping is not an absolute hassle. And they're both tiny in terms of the number of users.
In the end, we did settle on APIs that hide the escaping process (prepared statements, innerText vs. innerHTML, etc.) just because it's a) good enough; and b) possible to implement more or less uniformly across the TIOBE Top 20. That's good, but if you happen to use a language that's powerful enough, you probably also should track the escaped/unescaped status in the type system - it can be a cheap, additional safety net.
While all you said is essentially correct, I want to nitpick that things like prepared statements quite specifically separate instructions from data and innerText is designed to skip processing of instructions in the input. They are indeed solutions to the escaping problem, but they do not make the escaping better, they avoid escaping altogether by different design.
You proved their point and you don't even realize it. Those aren't escaped inputs, they're segregated precisely because escaping an input channel is an unwinnable jr engineer trap.
That doesn't seem to prove their point at all and it clearly demonstrates the tractability of escaping inputs for domains like sql/html.
The point is lost somewhere. Prepared statements for SQL, innerText for HTML and similar do not show tractability of escaping, they sidestep the escaping problem altogether.
Those are interfaces where escaping is no longer needed precisely because they deinterlace instructions from data. Escaping problem inherent to instruction+data channels. Yes, deinterlacing is not solution, not futile attempts to escape.
2 replies →