[sldev] Permissions

[Abh Serechai Belxjander]

On Mon, 2007-09-24 at 08:01 -0500, Argent Stonecutter wrote:

> > also, perhaps modify it slightly to read "refuses to hand it out to  
> > one
> > owned by somebody else and not trusted by the original domain"?
> 
> What if SL trusts GNUGrid but you don't want to?
> 
> [X] Exportable to worlds certified by:
>    (X) Second Life
>    ( ) OpenSim
>    ( ) DeepSim
>    ( ) GNUGrid
>    ( ) There.COM
>    ( ) Activeworlds
>    ( ) Habbo
>    ( ) Verisign
>    ( ) Sony Online
>    ( ) Squaresoft
>    ( ) Blizzard Entertainment
>    ( ) Microsoft
>    (X) Department of Homeland Security
>    ( ) Virtual Vatican Certificate Authority
>    ( ) Pizza Hut Game Token Redemption
>    (X) My certificate authority at [192.168.100.1]
> 
> (yes, some of those items are a little optimistic)
> _______________________________________________

Please excuse my ignorance,  and I am new to this list,

The whole problem seems to be the same as "chain of evidence" in
forensics...
  do you trust the server/client chain as any single point of failure
breaks the whole
  security model unconditionally,

either you have a complete chain of trust or no chain of trust, no
middle ground is the apparent situation,

and you have to have end-to-end and transaction security... as soon as
any attribute is readable
  it is copy-enabled,  digital systems are that way from the get go,
the only secure system is a
  non-connected system,

for the grid itself to be secure with its content then either the
protocols and tools themselves are
  restricted to defined behaviours *1 or limit the entire grid to
defined interactions *2,

How do you secure a digital system? DRM has failed,  or do we flip the
security the other way,
  everyone denied until permitted,  exception being "owner/creator" who
have default rights?

this comes down to how to handle securing the system itself,

Mapping the world into something usable for region maintainable
constructs is workable similar to DNS,
  mapping objects within that realm,  how about temporary instantiation
within the realm server that the client
  is currently using and the server [accept/denie/reject]s the given
action request of the client,

disconnection of the client from the security chain is one mechanism,
and limits it to the servers for the grid itself,
  since each region/realm is then down to persistence rules at the
server,  is any given client allocated a content cache
  on the server or is the cache entirely handled at the client end?,
splitting the object into displayed/non-displayed and pairing it?
  the displayed being useless without the non-displayed? 

Argent:  what is to stop an individual purchasing a certificate and
providing such as a server certificate and being "trusted"
  and then forwarding to untrusted servers?

Im ignoring whether it is for secondlife or another network application
at this point,  it is already possible to snoop the connection,
  and with the open source codebase the protocol in-use is readily
described,

the "closed server space" model seems to be the only means by which
anyone has any "content control" at all at this time,
  or are we going to push everything into the server and have the server
provide everything of the security with regards content?

DRM has already been proven to be a failure, DeCSS / OpenFairPlay and
other tools as applied to existing DRM schemes,
  how is secondlife to be any different than those other schemes?

*1= unable to be maintained with open source as anyone can use a
modified client for themselves.
*2 = content is locked to origination client/server pairing additional
servers are "proxy forward" access to original content,
  again the problem is in the proxy system for end-to-end linkage,  see
*1

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070925/397815af/attachment.htm