1. Finding out if data was restricted?

How do you currently find out what data is tainted? Taintedness spreads the same way as I expect restrictedness would, that is any operation (including assignment) involving restricted data ends up with the result being restricted too. At the most simple you could do this:

sub is_restricted 
{
     my ($in) = @_;
     my $cmp;
     eval { $cmp = qx/echo $_[0];/ };
     if(@_ or $cmp ne $in) {
           return 1;
     }
     return 0;
}
[download]

just as you can write a very similar one to detect tainting. This subroutine catches the error if there isn't a filter and otherwise sees if the filter performed any changes. It doesn't catch the case where your filter is useless however. If you think that knowing if something is restricted is important we can probably write something in for checking it.

2. Unrestricting/Re-restricting

How would you unrestrict the data for an operation? The suggested filter idea I provided only "unrestricts" the data on its way out. Every operation using restricted data results in a restricted output, just the same as every operation (excepting capturing from a regular expression) on tainted data results in a tainted output.

As I'm uncertain as to what motivation there would be in unrestricting data internal to the program, the issue of restricting it again doesn't come up.

3. Encouraging carelessness

If using taint checking encourages programmers to become more careless - because the taint checking will rescue them, or if using strict and warnings encourage carelessness then this certainly will. Even if those things don't cause carelessness in certain programmers this might.

I'm inclined to generalise programmers who might use this feature into two groups relevant to this discussion. You have the good programmers who know that printing out passwords, private information and credit card numbers to logs is a bad idea. Hopefully they'll see this as just another tool (like strict and taint) to assist them not to make mistakes, not a magic panacea. They'll code in a clean and reasonable manner which doesn't rely on strict and taint and data restrictions but uses them just in case.

The other group are the programmers wanting to get things done now! but have heard that using data restrictions is the thing to do. These programmers may be lead towards greater carelessness because they may choose to rely on data restrictions rather than ensuring that their code is clean and tidy regardless. Unfortunately these are the same programmers who'd probably create dud filters or be prolific in granting output permissions if their programs were being constantly tripped up by these restrictions. That is, if they didn't decide to dump the whole restricted data thing first.

There are lots of programmers in both camps. Fortunately most CPAN modules (for example) are written by people from the first group. :) And Perlmonks does a great job of helping move up from the second group.

I hope this answers some of your questions.

jarich