An attempt to get back on topic, which was MOUL security:
I think we can possibly all agree that there is a small thing we can do: make sure Ages we create don't cause problems.
Security is, before anything else, a question of quality. If you write buggy code (or Ages), it can become a security problem. If your Age crashes the player's game, it is a security problem (availability is a security concern).
So, from the original topic list, I submit that we can still discuss these:
- Providing a secure API for coders (thanks Trylon)
- Precise QA procedures for user-submitted content (unit testing in the prp file (could be automated), functional testing by Maintainers)
A "secure" API would simply be an API that prevents problem. This would be useful because it could:
- expose high-level functions with limited sets of parameters;
- perform input validation and sanity checks on parameters;
- simplify the use of the most commonly needed functions so newbie writers wouldn't have to understand the details of how the prp objects work);
- simplify code review by reducing the amount of custom code;
- provide more helpful error messages by trapping low-level exceptions.
Maybe (less related to security) we could even provide "GoW-approved" sets of components for easy integration into an Age. For example, a standard "linking book" kit including a .blend file with a pedestal and a textured book, .uof files with the proper objects for sound and animation, font files, etc. The newbie writer could use it in confidence, knowing it wouldn't cause crashes.
Of course, more advanced writers would still use the Cyan functions directly when more flexibility is needed.
Guild of Writers
