Python as client-side browser script language

[Magnus Lycka]

Paul Rubin wrote:
> Magnus Lycka <lycka at carmen.se> writes:
> 
>>Of course, one might suggest that it's the task of the browser,
>>and not of the scripting language, to provide a safe sandbox
>>where scripts can mess around and without causing havoc on
>>your computer. Such a system in the browser could be used to
>>grant different rights to different parts of the net, regardless
>>of what kind of scripting language the resources on those parts
>>of the net use. When Firefox has something like that, it's time
>>to start marketing Python for client side scripting I think.
> 
> 
> Huh?  The language itself has to provide the sandbox.  If the
> browser's control over the script language is so fine-grained as to
> control every attribute access then the browser and the language are
> no longer separate.  Remember that scripts have to be able to see
> certain DOM elements but not others, and some of them have to be
> read-only, etc.

I'm not sure I agree with you. This is certainly not the way
security is typically handled in computer systems. Operating
systems limits access to OS resources such as files, memory,
I/O etc. Resource managers such as database systems limit
access to data based on some kind of authentication. It's
not up to e.g. the database client to control this. The same
underlying mechanisms work regardless of the programming
language used to code the applicaqtion that wants access to
the resources. There are no particular securty issues in
writing DB apps in Python instead of Java for instance.

Why shouldn't the browser manage resource access for a "foreign"
script running embedded in it? I think it's fairly obvious
concerning pure browser resources such as the DOM. Concerning
pure OS resources such as files, it seems to me that something
like a chrooted environment would be best, and I assume this
must somehow be provided by the OS.

I'm sure it's a non-trivial task to develop such an environment
so that it's practical, efficient and safe, but it would open a
lot of doors if it could be done. It's possible that new scriping
languages must be trimmed a bit to be able to work in such a
confinement, but it would certainly enable the use of alternatives
to Java as powerful client side application languages in web apps.