As for securing Perl more on the server, a perl with a small default @INC can be done easily enough. There are taint mode and Safe.pm to help with boxing in data and code. The installed modules could be kept minimal. Perl supports chroot (although only root can do that).

It should be possible (I'm not saying 'easy') to run both Apache and perl (or Apache with mod_perl) chrooted in the first place if security is at such a high priority. That's a pretty language-independent way to help with security. Things such as ulimit and a good IDS help no matter the language, too.

One thing to keep in mind is that the ability of the programmer to do something doesn't mean it's possible for the site's end user. Any system written in any language which does stupid things with end-user data poses a security risk, no matter the sandbox restrictions. XSS proves the server itself doesn't even have to be vulnerable to cause a security issue -- it can create a security issue for the user even if it is entirely protected.

While we are on the subject, of a "Perl browser plugin" , like the libjavaplugin_oji.so in our browser's plugin directory; what has stopped the Perl developers from doing this? From my limited understanding, the java plugin is just a java interpreter with the functions which pose a security risk removed, leaving only simple computational and display functions, and which limits display in the parent's (browser's) allocated window.

When I build Perl, I see the mini and micro Perl interpreters, which are limited versions. Would it be that hard to modify those to be a secure browser plugin? Then maybe add a chopped-down Tk or Gtk2 display engine to it? Now I wish I studied c in more depth. :-)

---

I'm not really a human, but I play one on earth. Cogito ergo sum a bum

Other than that very few people get paid to develop perl when compared to the JVM and Java JIT systems, I'm not sure what else would be preventing this. The P5P work very hard to improve the major targets for perl as it is, and I'm not sure that adding another target is on their radar. The Perl6 and Parrot hackers are busy doing their stuff, too. It'd likely need to be a dedicated port team tasked with building and maintaining such a beast.

I'm not sure if Tk or Gtk2 would even be the best display technology, at least at first. That would target Flash and Silverlight pretty handily, though. What might be better at first is to interface to the JavaScript HTML and CSS DOM. Using Perl's strengths to manipulate the pages themselves could be really nice.