in reply to 'Restricted' data, an additional security mechanism for Perl.

# Should there exist restricted data which cannot be cleaned? Eg, passwords or decryption keys?
# Should there exist a hierachy of restricted information (Eg, 'Top Secret' data cannot be sent via a 'Secret' channel, but the reverse would be fine.), or should data simply be restrict/unrestricted, in the same way that data is either tainted/untainted.
Should there be, could there be? If you are in my backyard, don't expect to 1. trip and break your ankle, 2. get shot at. That's the general perspective. But someone pointed out to me, during an entire java discussion here, it incures a cost to do that type of checking. It also incures an inconvenience. But I'm of the OOP camp and like the idea of "private data". Yeah, messing with my internals may get me to do a neat trick now, but when I chnage my internals in v2.0, your code breaks and thus, a money costing bug gets introduced by accident. That's my view.

As a run-time directive, it'd be nice. sorta like perl -r (argh), for restrictive, but it'd create a cost for every access. Do people care? Yes and no. Will it happen? Who knows :)


Play that funky music white boy..
  • Comment on Re: 'Restricted' data, an additional security mechanism for Perl.