Bob writes: > I don't know how JavaScript is doing it yet. The critical thing > for me for this month was trying to come up with a security model.
I don't fully understand how JS does it either, certainly not in any detail. I know that it uses the concept of a "principal" (the IDL file can be seen at http://lxr.mozilla.org/seamonkey/source/caps/idl/nsIPrincipal.idl) and I think that the absence of any principals == "trusted code". I believe the principals are obtained either from the JS stack, or from the "event source" and a few other obscure exceptions. There is also lots of C code littered with explicit "is this code trusted" calls that makes implicit and explicit javascript assumptions - not particularly deep assumptions, but they exist. Cross-language calls will also need consideration. JS will be able to implicitly or explicitly call Python functions, which again will implicitly or explicitly call JS functions. Some of those frames will always be unrestricted (ie, they are "components" - often written in C++, they can do *anything*), but some will not. We have managed to punt on that given that Python is currently always unrestricted. In the early stages though, Mozilla is happy to have Python enabled only for trusted sources - that means it is limited to Mozilla extensions, or even a completely new app using the Mozilla framework. From a practical viewpoint, that helps "mozilla the platform" more than it helps "firebox the browser" etc. This sandboxing would help the browser, which is great! I'm confident that when the time comes we will get the ear of Brendan Eich to help steer us forward. Cheers, Mark. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
