Before I reply to the other replies to my posting I like to lay common grounds. What do we have to restrict.

Python code = any code written in Python and included with MOUL as part of the Python standard library or age code.

* Python code must not read or write any files from the file system

* Python code must not be able to open sockets in order to make network connections to different hosts

* Python code must not be able to load extensions (DLLs) which might allow users to add new features
* Python code must not be allowed to load additional modules from the file system

There may be a distinction between code which is part of the game engine and code which is part of an age.

It's feasible to rely upon vetting for code which users have to explicitly choose to download. But I'm envisaging an ecosystem where ages are downloaded on demand the first time you use the age's linking book. The age might even be running on a different server to the age containing the linking book. In that situation, the interpreter has to be bulletproof against bugs in age scripts.

If it was JavaScript, I'd use a separate interpreter (JSRuntime) for the engine and for the age. But I don't know how feasible it is to do that in Python. In the worst case, you could have a completely separate process for running age scripts, but that has costs in terms of both effort and efficiency.

It must not have unrestricted access to the file system. It may be acceptable for an age to read or write some files. E.g. you could give each age its own subdirectory within the "Uru Live" directory, and only allow it to read or write files in that directory. It would need to be prevented from writing EXE or DLL files; in fact, it would probably have to be limited to a fixed set of safe types (which includes restricting the format as well as the extension; Windows sometimes ignores the extension and auto-detects the type based upon content).

Like with files, it might be reasonable to allow a fixed set of extensions. IOW, you might not want the entire range of available functionality to be visible without explicit "import"s. But we would probably want to limit extensions anyhow, so you don't run into a mess of "age X needs extension Y" dependencies.

The compiled Python code and age settings are downloaded from the server as encrypted data everytime you log into the game. The game takes so long to load because all data is downloaded and non is cached. It's not an ideal situation but it makes it impossible to read or tamper with the code. This won't change to prevent users from inserting their own code into the game.

No, a user must not be able to inject Python code. As soon as you allow to execute arbitrary Python code a user can hack the game.

You don't want spam bots, Fly Mode, UserKI or other stuff on the official servers.

Once the client source is released, you can't prevent users from modifying it. If you want to protect the server, you have to do so on the server, not the client.

I'm not talking about arbitrary Python code, I'm talking about standard libraries which scripts can use. There are reasons why you might not want to do this (e.g. compatibility issues), but security isn't one of them.

If Uru is to be open-source, you can't prevent people from playing with modified clients. It's hard enough to do that with a closed client; witness the amount of effort Blizzard puts into anti-cheating mechanisms.

If we would life in a perfect world you'd be right. With online games such as MOUL the server has to trust the client partially. It's not possible to verify every movement on the server. The lag would make the game sluggish and the load would kill the server. I predict that each game server is going to trust a known and verified set of files (ages, Python scripts and MOUL client) only.

By security I'm talking about two sides: security of the user's computer and the integrity of the server. Once you the user to execute code he may abuse the code to circumvent a puzzle or jump higher than others. The standard library of Python is designed with a different goal in mind.

An open source client and server doesn't necessarily mean you can connect to a server with any client.

The compiled Python code and age settings are downloaded from the server as encrypted data everytime you log into the game. The game takes so long to load because all data is downloaded and non is cached. It's not an ideal situation but it makes it impossible to read or tamper with the code. This won't change to prevent users from inserting their own code into the game.

Also note that each plPythonFileMod object runs in its own instance of the Python interpreter.

It seems to me that it is infeasible for the server to check the validity of everything coming from the client, and it is impossible to prevent the client from sending whatever it wants. This is the same problem that any other online game has. Of course, it will be easier to create malicious messages if the game is open source, but it's not a new problem by any means. Most people deal with it by banning the malicious clients.

Second, in the event that the server operators detect prohibited conduct, they can terminate the account. This actually means something when getting another account means buying another copy of the game or purchasing play-time. But if all you need to get a new account is a new email address, banning an account isn't a particularly effective weapon.

It would be nice to prevent people in common areas from flying around and such. Otherwise it might become a common occurrence in the city to see people flying, which would kind of ruin it. As people have said, what people do in their own ages is their own business.

But I suppose it's hard to validate if the client has control over all of the avatar's movements.

With regards to malicious Python scripts from the server -- not sure if this has been stated explicitly already, but it is generally not possible (at least in CPython, the standard Python implementation which I assume Cyan is using) to secure Python against malicious scripts. Even if you want a game which only lets Python scripts call functions within the game engine, they can still open networks, files, and anything else. Several attempts to secure Python, such as the deprecated rexec library, have been found to have unfixable holes.

The only way to guard against malicious Python scripts is to hand-inspect them before letting them go out to clients.

Incidentally, this is why games use Lua, not Python, because that language *is* restricted by default to only the game-supplied function calls.

MOUL uses a custom interpreter, so the situation is somewhat easier than trying to harden the stock Python interpreter.

Which would largely defeat the point of open-source.