Approaches for Perl and Ruby are somewhat different. One difference is that in Perl you have some operations that untaint variables automagically, while in Ruby you have always to explicitly declare a variable non tainted anymore.
Also, Ruby has different levels of protection, so tainging can be light nuisance on the low level or full sandbox mode on a high level. That’s another interesting thing ot explore – using tainting to sandbox scripts. Though in PHP due to the fact that all runtime data are isolated per-request and the engine is built to support multiple requests, it might be easier to implement sandboxing in a different way, but the Ruby approach is interesting to explore.
Of course, due to the multitude of functions in PHP the approach of “mark unsafe functions” which Ruby seems to use is prone to the same failures as the safe mode – there’s always at least one function that isn’t properly restricted – so if one wants to implement proper tainting or sandboxing, it probably should be based on more generic approach that would account for existance of functions unknown in design time. It’s still not 100% as carefully miswritten extension can do anything the OS permissions allow C code to do, but some restrictions might still be done – e.g., on some security level function calls to functions not marked “safe for tainted data” with tainted arguments might be prohibited by the engine. That’d probably break 99% of the existing code, so it would come at cost in any case. But the benefit would be that once the application passes such test, we can reasonably claim certain level of security – not 100% security, but at least decent level of protection for people that do not remember to validate their data properly.
This can also be connected to zval custom info idea, as taitning flag is a good example of the custom info.