yes, but i didn't say "in a malicious way" but rather "in the same malicious way as $decode()"

while i don't fully agree with the initial decision to include it in the lock settings, i understand why it was added and why it would be difficult to remove it at this point.

see, the reason why $decode() was first locked was due to its popularity in spreading IRC worms. while mIRC code can be obfuscated in many different ways, $decode() became the de facto method for doing so, and IRC worms involving $decode() probably still exist on various shady sites and possibly a few infected machines in the IRC universe. therefore, there is a case to be made for it still being in the lock settings and still enabled by default.

$utfdecode() is relatively new and more difficult to figure out how to abuse. it doesn't share any of the above facts with $decode() and its addition to the lock settings was nothing more than a preemptive measure against potential abuse. the mere fact that it was added will have tipped off a few would-be skiddies who, if this setting were ever reversed, may use the opportunity to develop worms involving $utfdecode. but this is all unlikely. anyway, this was a deliberate change that we have to learn to live with, no matter ill-founded or inadvisable it may have been!

i'll show you an example on IRC :P