On Tue, 2011-07-05 at 05:47 -0700, Peter Quirk wrote: > 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
Right -- thank you, and others, for the experiences and insight. It seems that viewabality controls might be a good addition. Although there are also other options for some cases, like simply having different versions of the scene for different users. > 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. Unless we do our multiscene system so that it supports arbitrarily sized rooms placed inside bigger worlds etc. > 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 (..) > 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. This is what we are doing for the editing rights now -- the core scene / syncmanager just has hooks which additional modules can use to intercept. Same was made earlier for authentication at login. In both cases everything is allowed by default, but modules can impose restrictions -- such as requiring a password for login, or limiting the editing to certain objects. The Tundra core will never implement some certain security model. But we can have reusable modules that implement some models, which can be used across applications so everyone doesn't need to redo them from scratch. These can be bundled in the standard distribution and have even GUIs etc. for easy configuration. The terminology we use is that 'core' is the basics that's always there, basically the parts in the table with the purple background in http://www.realxtend.org/doxygen/ . But there is lots of other things in the central repository and in the releases around that, that whole I've been calling the 'default distribution' which has e.g. the reference avatar implementation (we could also agree to make a standard avatar app if it's useful). So the answer to your question, whether 'the system' should provide these things, is that the core must facilitate / enable it in a minimalistic way independent of implementation specifics, so that optional parts of the system can provide those as features. That approach seems to be working fine so far, not only for authentication and permissions but also for example for how Enne's optional UiModule adds docking capability to the GUI widget handling (intercepts core ui AddWidget). I didn't realize it is AOP, but indeed I think you're right, it is :) ~Toni -- http://groups.google.com/group/realxtend http://www.realxtend.org
