We want to secure many things:

- Simulators data and performance against malicious users -- this is the 
most vocally spoken problem, but it's not specific to a web of VWs; it 
happens in closed worlds too. Obviously, we need to address it in some 
way if we want to be friendly to content producers.

- User's data against malicious simulators -- e.g. the ability that a 
rogue sim currently has of wiping out a user's inventory, doing false 
impersonations, etc etc. This is specific to a web of VWs; this problem 
doesn't exist in closed worlds, because there are no rogue sims in those 
worlds, all sims are within the same domain of trust. These are the 
kinds of problems I'm most worried about, because they come with 
decentralization of control.

So we're talking about safety of users' data. Currently when a user 
visits a sim that sim has access to just about everything related to 
that user.


Ideia Boa wrote:
> I think the big confusion is that most posts are referring to USERS and 
> safety is not the topic.
> I suppose what is at stake is how to interconnect grids and regions in a 
> safe or not and nothing is related to the USERS.
> Please correct me if I am wrong in my way of seeing "The essence of grid"
> 
> Ideia Boa
> 
> 
> Diva Canto wrote:
>> I think you may be thinking of OpenSim's equivalent to OGP's
>> "agent domain" -- that's different, and yes, that is our User Server.
>>
>> "Trust domain", in the context of this discussion, is what Melanie and I 
>> said over a few emails: a collection of simulators that trust each other 
>> and that are all under one single authority. They may be associated with 
>> User services or not -- they may simply be simulators without associated 
>> user accounts. I think OGP has a name for it too, "region domain" perhaps?
>>
>>
>> Charles Krinke wrote:
>>   
>>> I have had this discussion with Adam and Lbsa in the past.
>>>
>>> The OpenSim equivalent to SecondLife's AgentDomain is our UserServer.
>>>
>>> So, the "trust domain" is the UserServer executable on a given grid.
>>>
>>> Now, it may be incomplete, but that is the direction we have been going 
>>> for the last two years.
>>>
>>> Charles
>>>
>>> ------------------------------------------------------------------------
>>> *From:* Ideia Boa <ideia...@gmail.com>
>>> *To:* opensim-dev@lists.berlios.de
>>> *Sent:* Thursday, April 16, 2009 1:16:52 PM
>>> *Subject:* Re: [Opensim-dev] The essence of "grid"
>>>
>>> Finally someone to explain in brief what is "trust domain" and is 
>>> precisely what we need. We need to create something that the grids and 
>>> regions connected by hypergrid can behave as "trust domain"
>>> Cristina got 100000% of reason in your security considerations for links 
>>> between grids and regions.
>>> Melanie, thanks for the help given by your post.
>>>
>>> Ideia Boa
>>>
>>> Melanie wrote:
>>>     
>>>> In the future, the avatar and his inventory will be independent of 
>>>> the grid. This is already almost a reality.
>>>>
>>>> To address another post, a "trust domain" doesn't imply that the 
>>>> visitor trusts it. It merely means that all regions within it trust 
>>>> each other. Like the servers that make up a web application.
>>>>
>>>> Melanie
>>>>
>>>> Charles Krinke wrote:
>>>>   
>>>>       
>>>>> Backing up a bit, I think we need to start with the fact that a grid 
>>>>> provides a common start point for an avatar logon. By that, I mean, a 
>>>>> grid will have some quantity of users in the users MySQL or MSSQL table 
>>>>> with a particular avatar appearance and some semblance of an inventory.
>>>>>
>>>>> For the purpose of HyperGrid, many folks wish to travel from grid->grid, 
>>>>> standalone->grid, standalone->standalone or grid->standalone. And most of 
>>>>> those folks will expect to have their avatar appearance constant based on 
>>>>> their original logon place as they HG around.
>>>>>
>>>>> So, from the most basic point, we can say that our current and most 
>>>>> reasonable use case is an avatar with custom edits and some inventory 
>>>>> that logs onto a particular standalone or grid and then expects to be 
>>>>> able to HyperGrid to a different grid and have that avatar and inventory 
>>>>> stay reasonably constant. That is, the avatar should not be ruthed.
>>>>>
>>>>> In order to accomplish this
>>>>>  in the general case is a bit tricky and I believe is one of the issues 
>>>>> being worked on currently. A number of other things begin falling out of 
>>>>> this notion after this one is working reliability and consistently such 
>>>>> as the other things brought up in this thread. 
>>>>>
>>>>> But, I think it all begins with a desire for a consistent avatar and 
>>>>> inventory experience while HyperGridding.
>>>>>
>>>>> Charles
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Opensim-dev mailing list
>>>>> Opensim-dev@lists.berlios.de
>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>>     
>>>>>         
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev@lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>
>>>>   
>>>>       
>>> -----Inline Attachment Follows-----
>>>
>>> begin:vcard
>>> fn:Ideia Boa
>>> n:Boa;Ideia
>>> note;quoted-printable:Best regards,=0D=0A=
>>>     Ideia Boa=0D=0A=
>>>     WorldSimTerra=0D=0A=
>>>     =0D=0A=
>>>     Join the new 3D world revolution : http://www.worldsimterra.com/ 
>>> <http://www.worldsimterra.com/>
>>> x-mozilla-html:TRUE
>>> url:http://www.worldsimterra.com <http://www.worldsimterra.com>
>>> version:2.1
>>> end:vcard
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev@lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>     
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>   
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

Reply via email to