> I don't follow you here. What I read in the above was a combination > of a well defined client side extension API and a mechanism to load > code that can be granted a level of trust based on criteria it needs > to do its job. That might include code signing and metadata about > the capabilities the client plugin needs. I don't see any mention of > "untrusted binaries" other than the implication that a module that > doesn't negotiate additional capabilities gets started in a > sandboxed environment with minimal capabilities. > Any code not explicitly installed by the user is "untrusted". Executing untrusted code in a sandbox is an extremely difficult operation to perform safely. Doing so in a way that also accepts "trusted" code through the same mechanism is something that even Microsoft has notoriously failed to successfully pull off... a good number of the exploits of the late '90s and early '00s were due to failures of this security model.
Doing this securely enough to ship is an extremely difficult undertaking, ranking alongside the whole of Second Life in ambition and scope, and not doing it securely could destroy Second Life. I would not use nor recommend using any viewer that implemented it. _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
