<br><br><div><span class="gmail_quote">On 6/26/06, <b class="gmail_sendername">Ka-Ping Yee</b> <<a href="mailto:python-dev@zesty.ca">python-dev@zesty.ca</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi, Brett.<br><br>> I have been working on a design doc for restricted execution of Python<br><br>I'm excited to see that you're working on this.</blockquote><div><br>Yeah, I just hope I have a design that works. =) <br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> as part of my dissertation for getting Python into Firefox to replace<br>> JavaScript on the web.
<br><br>Wow. What's your game plan? Do you have a story for convincing the<br>Mozilla folks to include Python in the standard Firefox distribution,<br>even though the whole browser UI is already written in Javascript?<br>
Do you want Python to be used to scripts in web pages, Java-style<br>embedded objects, or both? I'm curious to know what you have in mind...</blockquote><div><br>The plan is to allow pure Python code to be embedded into web pages like JavaScript. I am not going for the applet approach like Java.
<br><br>As for convincing the Mozilla folks, I want working code first before I try to do a big push. But the idea is that JavaScript does not scale well for large applications, which more and more people want. Python provides a more structured approach to programming that can help facilitate designing large web applications that have a complicated client-side component. There is also a large userbase already that I hope will like this and speak up to say, "I want this!" But otherwise, no, no plan to get Mozilla to go along with it. =) If they don't pick it up I can probably go with an extension or something. It is my dissertation; can't expect too much real-world usage out of it. =)
<br><br>I am not expecting Mozilla to rip out JavaScript. I just want the ability to do client-side scripting in a web page to be doable in Python instead. If they want to rewrite parts of Mozilla's UI in Python, then wonderful! But I would not be hurt or whatever if they didn't bother since that would be a huge undertaking. JavaScript can live side-by-side with Python until people realize Python is better and slowly begin to migrate over. =)
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I'll post again with more detailed feedback on your document, but here's<br>a general comment. I'd really like to see some worked examples of how
<br>you want to see restricted execution mode used, in order to motivate<br>and evaluate the design and implementation.</blockquote><div><br>The idea is that there be a separate Python interpreter per web browser page instance. So each tab in Mozilla would be running a Python interpreter. I don't think JavaScript's security model is really that bad so I am trying to follow it within reason. So the main goal is for people who embed the interpreter and do not need any form of trusted interpreter to run to be able to easily have an interpreter(s) running in various states of restricted execution.
<br><br>So, launch an interpreter, set the restrictions, pass in the DOM, and then execute the Python code in the HTML in this untrusted interpreter.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In particular, how do you envision restricted execution interacting<br>with the standard library? ("Not at all" is a possible answer.)<br>Are there existing modules or existing Python programs you expect<br>to just work using restricted execution mode, or are you willing to
<br>ask programmers who use restricted execution to adopt a new style?<br><br></blockquote></div><br>I expect everything to work within the restricted bounds of security restrictions turned on for an interpreter. This means that if you allow file reading you can unpickle a file from disk. But if you don't, then you can still import 'pickle', but it will fail when you try to use
pickle.load() with a restricted execution exception. That is why I am placing the security restriction at the import level and then at key points in key objects (file, socket, sys.stdin, etc.); to minimize possible slip-ups in security by catching them at the OS/code boundary at the C level in the interpreter/stdlib.
<br><br>I really don't want to ask programmer to adopt a new style. They might have to change very slightly ("where is the __file__ attribute on modules?"), but overall I want to minimize as much as possible a shift in Python programming style.
<br><br>-Brett<br>