That’s because even though the values of non-static strings may be unknown until run time, the types of the strings will be known at compile time, and that’s enough for the system to do its work. If the system knows, for example, that some function takes an HTML template and a string representing plain-old text, the system can verify at compile time that the way the function combines the text with the template is safe, even though the system may have no idea what values the template or the text will take until run time.

Cheers! –Tom

You are missing something fundamental to the nature of (modern) static type systems. You wrote that:

[With a compile-type safety system] you’re only protecting a programmer from leveraging an unsafe string during code-compilation time. I think (opinion mind you) that your time would be better spent […] designing ways to cope with these issues/attacks at runtime.

What you are missing is that that compile-time system proves that these issues cannot occur at run time. Once you have that guarantee, you have no need to attempt to cope with the issue anymore, at all, let alone at run time. The issue is gone.

And as far as being “shackled” into the system goes, the only thing you are shacked into is not doing things that would be potentially unsafe if allowed at occur at run-time. In my Haskell-based implementation, for example, it’s no more difficult to write safe-string code than it is to write unsafe everything-is-just-a-string code, but it’s a whole lot safer.

Cheers,
Tom

I threw together a proof of concept implementation of that a few days ago. It’s currently available at http://dpaste.com/17329/

If you’re going to go as far as to shackle a developer into the SafeString type you’ve defined, you also have to block/deny any sort of object polymorphism as well — I can’t see you able to enforce the compile-time rules without blocking the that as well.

It’s food for thought — although when it comes to most applications, it’s user-input or input-generated from an untrusted third party that most people/programmers concern themselves with. For example, it would be interesting to enforce these style rules within an DB ORM (both to and from) and things such as networking/other communications layers. It’s this type of hardening that only really exposes itself at runtime in most instances.

I’m wondering about the scope of safety you’re providing by baking in a new safe type into the language — you’re only protecting a programmer from leveraging an unsafe string during code-compilation time. I think (opinion mind you) that your time would be better spent doing exactly what you pointed out as a flaw in my suggestion: designing ways to cope with these issues/attacks at runtime.

If you treat all data (strings) as untrusted data to begin with — both user and programmer generated alike and build into your system a clean/abstracted way of dealing with and capturing dangerous objects your application would be infinitely more secure without the need to enforce it at compiler-time.

While you can certainly implement a run-time system for detecting potentially unsafe string interactions, what sensible options do you have when you detect one? Remember, what you have just detected is not that an attacker tried to stuff some nasty code into a form; rather, you have detected a programming error: the programmer used a string in one place as if it were, say, untrusted user input and in another as if it were, say, part of a trusted, programmer-supplied template. It’s just that until some user (maybe a bad guy but very possibly a good guy) manged to walk a particular path through your application that exercised both uses of the string, the programming error went undetected.

Now, however, your run-time system has detected it. The problem is, your system detected it in a live-running application, at the site of a potential unsafe string interaction, not at the error’s origin in your code, which could be a long ways distant. That is, this particular string interaction may very well not be the error. The error may have been caused in the distant past by code that has already executed. What’s worse, all the code in between the error’s origin and the present site of detection could have been causing side effects: writing to the database, updating session variables, launching the missiles, etc. How do you safely undo all those effects?

That’s the real problem.

In a compile-time system, when a potentially unsafe string interaction is detected, you have all the time in the world to hunt the problem down to its true source, wherever that may be, and fix it.

In sum, a compile-time system offers you the assurance that none of the checked-for problems can occur at run-time. A run-time system can only guarantee that, if a checked-for problem occurs, it will be caught. By then, however, it may already be too late to avoid the consequences.

Cheers. –Tom