I think viewability is a big security issue. It plagued Second Life because people could move their camera into places that their avatars couldn't go, invading the privacy of others. In a previous job I tried to get my employer to use Second Life for a corporate training application, but our inability to solve the viewability problem prevented us from displaying any corporate intellectual property. In some Sloodle scenarios you might want rooms or quizzes to be invisible until students are authorized to see them. Region-level security doesn't address this fine-grained security. >From another point of view, we all know of security models which hide certain files, folders or tabs from view based on the user's security role. What we're discussing here is whether the system should provide viewability controls based on security role, or whether every space (a.k.a. application) has to program the visibility of objects. in a thorough treatment of role-based access we would also address every aspect that affects the mutability of the space - whether objects can be moved, destroyed, created, edited, grouped, etc., and which scripts might be executed implicitly or explicitly. A possible way to approach this would be through an AOP model where a security module could be registered to intercept actions on an object and decide whether to allow them based on the object's identifier, the user's ID or security role, the location of the object, the owner of the object, the time of day, the debug status, etc.
-- http://groups.google.com/group/realxtend http://www.realxtend.org
