but I doubt that this is true, especially considering that both will be given the same permissions. PerlScript only runs with the permissions it's given, and obviously those permisions are different based on whether it's through Internet Explorer, through ASP, or through something entirely seperate.
What "permissions" is that? OS-level access to files and certain abilites is based on the user attached to the thread. Does a script in a client run as a restricted user? I don't think so, since I used PerlScript in a local window for an application (before Win32 Tk was mature enough) and didn't run into access problems.
Do you mean it sandbox's various Perl abilities, like accessing files at all, in the same manner as Java? I can see how that's possible on the surface because the Perl DLL is customized by the main program to point to the system interfacing code including file I/O, and the ActiveX script engine could put logic there. But, does it also have hooks to prevent loading of unapproved pm's, and does every XS writer also put in these permission checks? I don't think it would stay sandboxed, unless it was totally gagged from the beginning.
Basically, it's an intractable problem. Unless sandboxing is built into the language (and its extension features) from the onset, any fully-capable language can get around any after-the-fact security.
Windows XP is supposed to have a totally different security model, which restricts access to things based on the program that's asking rather than the logged on user. That sounds like a major improvement, thanks to the way most Win32 systems are set up.
