Python as client-side browser script language

[Rune Strand]

What would it take to create a Firefox extension that enables Python as
a script language in the browser - just like Javascript? Is it at all
possible? Are the hundred good reasons not to bother?

I once made an application that used MozPython[1]. It was fun and very
fast compared to the Mod_Python I eventually replaced it with. I had
to, because of all the mess updating Mozilla caused. ActiveState has a
project too [2]. But none of these can replace Javascript

Grail used Python as scrpt language, I believe. And by the
Win32-wonders of Mr. Hammeond it's possible to use Python in IE. But
what aboit a easy-to-install extension for Firefox? Wouldn't that be
cool?


[1] http://www.thomas-schilz.de/MozPython/README.html
[2] http://www.mozilla.org/catalog/architecture/xpcom/pyxpcom/

 

[Magnus Lycka]

What would it take to create a Firefox extension that enables Python as
a script language in the browser - just like Javascript? Is it at all
possible? Are the hundred good reasons not to bother?

There are certainly security issues. A simple implementation
that started a "normal" Python script fetched from a web page
on the shady parts of the web, could certainly create a real
mess. Ouch. Today, there are really no security features in
Python. Those that used to exist were remvoed since they weren't
considered good enough, and giving a false sense of security
wasn't considered a good idea...

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.

 

[Paul Rubin]

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.

 

[Greg Ewing]

Huh? The language itself has to provide the sandbox.
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.

If the DOM objects are implemented as built-in Python
types, there shouldn't be any difficulty with that.
Python objects have complete control over which attributes
can be read or written by Python code.

That, together with restricting what the open() function
can do, ought to provide a pretty good sandbox.

 

[Paul Rubin]

If the DOM objects are implemented as built-in Python
types, there shouldn't be any difficulty with that.
Python objects have complete control over which attributes
can be read or written by Python code.

No, they don't. See the sorry history of the rexec/Bastion modules.

 

[Paul Boddie]

If the DOM objects are implemented as built-in Python
types, there shouldn't be any difficulty with that.
Python objects have complete control over which attributes
can be read or written by Python code.

That, together with restricting what the open() function
can do, ought to provide a pretty good sandbox.

Is that really enough, though? Previous discussions [1] suggested that
the problem was pretty extensive, and the topic has been proposed [2]
for the Summer of Code thing [3], although $4500 may not be a lavish
enough amount if the work requires a complete overhaul of CPython.

But on the subject of Python as a browser *extension* language where
you download extensions from trusted sources and run them from the
browser, PyKDE can be used with Konqueror to explore this area,
although it does require a very recent PyKDE to work fully - see the
kpartplugins on this page for more information:

http://www.boddie.org.uk/david/Projects/Python/KDE/index.html

It would also be great to unify Konqueror and Mozilla in some way by
providing a common API for Python extensions - this could be done by
wrapping Mozilla's DOM, presumably exposed via PyXPCOM [4], in a way
similar to qtxmldom [5], and then making sure the boilerplate
(initialising the extension, getting initial references to browser
documents) is separated out from the actual extension code.

Paul

[1] http://www.amk.ca/python/howto/rexec/rexec.html
[2] http://wiki.python.org/moin/RestrictedExecution
[3] http://code.google.com/summerofcode.html
[4] http://www.mozilla.org/catalog/architecture/xpcom/pyxpcom/
[5] http://www.python.org/pypi/qtxmldom

 

[Magnus Lycka]

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.

 

[jeoffwilks]

Sorry to resurrect a slightly older topic, but I want to clarify some
points about how the browser DOM and the script language interact.

Huh? The language itself has to provide the sandbox.
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.

If the DOM objects are implemented as built-in Python
types, there shouldn't be any difficulty with that.
Python objects have complete control over which attributes
can be read or written by Python code.

In web browsers, Javascript does not provide the sandbox. The browser
provides scripts with certain objects like "document" or "window" but
these are not native script objects at all. They're wrappers for
browser-native objects, usually written in C/C++ and exposed via an
ActiveX or XPCOM interface. (IE uses ActiveX, Mozilla uses XPCOM). The
interfaces to these browser-native objects enforce the security model
by restricting what the scripting language is allowed to do within the
browser context.

If you attempt any foul play with a browser-native object, it can
simply feed an exception back to the script wrapper, and your script
code fails. That's the sandbox.

Following are some relevant links for those interested in further
details:

DOM Intro (especially the section, DOM vs Javascript
"That is to say, [the script is] *written* in JavaScript, but it *uses*
the DOM to access the web page and its elements."
http://www.mozilla.org/docs/dom/domref/dom_intro.html

"Mozilla's DOM is coded almost entirely in C++. ... When, in
JavaScript, a client tries to access a DOM object or a DOM method on a
DOM object, the JS engine asks XPConnect to search for the relevant C++
method to call."
http://www.mozilla.org/docs/dom/mozilla/hacking.html

"The DOM makes extensive use of XPCOM. In fact, to do anything with the
DOM implementation you need XPCOM."
http://www.mozilla.org/docs/dom/mozilla/xpcomintro.html

Talking to XPCOM in Python
"The techniques for using XPCOM in Python have been borrowed from
JavaScript - thus, the model described here should be quite familiar to
existing JavaScript XPCOM programmers."
http://public.activestate.com/pyxpcom/tutorial.html

So in theory you should be able to create a python script interpreter,
at least for Mozilla. In practice you'd either need to be an expert
with the Mozilla source code, XPCOM, and Python... or you'd find
yourself becoming an expert by necessity.