[Opensim-dev] The essence of "grid"
DZO
dzo at cybertalon.net
Thu Apr 16 10:41:06 UTC 2009
I like to think of opensim as the VW version of Apache.
I think something that is confusing us is that moving from region to region
in opensim is pratically seemless, and the joins between the regions almost
invisible. IE when walking from one region to another, you can see the new
region appearing on the horizon, as if its just a continuation of the region
you are in.
In apache you can also move between sites / pages, but the change is much
more visible, you have to actually click on a link and move away from your
current page, its obvious that you have gone from one area to another, more
so when moving between sites.
Both opensim regions and apache(internet) sites allow you to move between
content hosted by different people and/or on different servers. I believe
THIS is the area where the confusion comes in. In the conventional internet
we don't mind typing a zillion passwords because we can obviously see that
the pages are different. But in opensim it would seem strange to type in a
password just to be able to take an extra step on the road you are already
on.
Personal opinion:
- I don't believe centralising user profiles and managing permissions from
there is a good idea for an open source project.
- I do believe, as I have mentioned earlier, that opensim should have a very
simple region based password system and the client should be allowed to
manage multiple passwords such as a messenger or email application. This
would divide the task of security up between components in an equal and
logical way.
So opensim would allow grids and regions to ask for passwords from different
user server components, and the client software would allow the creation of
a user profile with multiple saved passwords.
This would not break anything as it stands as it would be possible to set a
region security to "grid" so anyone allowed to used the grid would also be
able to use the regions, however, a region owner would be able to restrict
useage in their own region and take ownership of their own user base, while
managing their own hardware and content useage. This would facilitate social
groups, business interests, and various other applications for the VW.
In my view:
Grid: Hosting company
Region: Web page (perhaps only using the hosting company to link to a
private server)
-----Original Message-----
From: opensim-dev-bounces at lists.berlios.de
[mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of
opensim-dev-request at lists.berlios.de
Sent: 16 April 2009 01:01
To: opensim-dev at lists.berlios.de
Subject: Opensim-dev Digest, Vol 20, Issue 51
Send Opensim-dev mailing list submissions to
opensim-dev at lists.berlios.de
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.berlios.de/mailman/listinfo/opensim-dev
or, via email, send a message with subject or body 'help' to
opensim-dev-request at lists.berlios.de
You can reach the person managing the list at
opensim-dev-owner at lists.berlios.de
When replying, please edit your Subject line so it is more specific than
"Re: Contents of Opensim-dev digest..."
Today's Topics:
1. Re: The essence of "grid" (Thomas Grimshaw)
2. Re: The essence of "grid" (Diva Canto)
3. Re: The essence of "grid" (Charles Krinke)
----------------------------------------------------------------------
Message: 1
Date: Wed, 15 Apr 2009 22:41:57 +0100
From: Thomas Grimshaw <tom at streamsense.net>
Subject: Re: [Opensim-dev] The essence of "grid"
To: opensim-dev at lists.berlios.de
Message-ID: <49E654A5.5080300 at streamsense.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Charles Krinke wrote:
> At this point, the only way to stop a region from attaching to an
> OpenSim grid is to put a fake entry into the regions table.
Or.. change the password?
------------------------------
Message: 2
Date: Wed, 15 Apr 2009 14:50:28 -0700
From: Diva Canto <diva at metaverseink.com>
Subject: Re: [Opensim-dev] The essence of "grid"
To: opensim-dev at lists.berlios.de
Message-ID: <49E656A4.1030505 at metaverseink.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I think we already have an understanding of what is needed for securing
users from malicious hosts: client-side control, that's all. Client has
direct control over user agents, user's inventory, IM, social network, etc.
The regions stay out of it, they are only simulators of objects and agents.
Grider is exploring that design space, and instrumenting OpenSim for it.
We're very close to having OpenSim support these kinds of clients.
However, in some cases, the user may want to give control, at least some, to
the ... and this is where terminology gets tricky...
simulators? "grid"? And why would that be, you may ask. Well, because that
server-side (not to get into the choice of words again) may provide some
cool stuff if you pass it the control. It may, for example, give you an
additional world-specific inventory, or it may open agents for you in
interesting 3d spaces, or you won't be able to play whatever game is going
on in there unless the server-side has control over some of your data.
But even this is *sortof* relatively simple to do, IF we align the concept
of VW with the concept of trust domain. OSGrid, however, doesn't do that. So
what would it mean for a user to visit OSGrid? With which server would the
user's client share authority, if it were to share it?
Christian Scholz wrote:
> Hi!
>
> Cristina Videira Lopes schrieb:
>> I'm trying to understand what it is that we are supposed to secure,
>> because security depends entirely on that :-)
>
> That usually is my problem with most of these discussions be it on
> MMOX, AWG or social networking. So it would be good to have some sort
> of list of what needs to be secured against what sort of action.
>
>> I've seen way too many talks/chats/posts/blogs talking about a Web of
>> VWs in some form, while making the unwritten assumption that the
>> concept of "grid" (aka Virtual World unit, or whatever you want to
>> call it) aligns with the concept of a domain of trust (i.e. a bunch
>> of simulators that trust each other, under the control of one
>> authority). Then, a Web of VWs is the interconnection of those domains of
trust.
>>
>> Well, OSGrid doesn't align with that. So either OSGrid is not a
>> valid/sustainable use case for OpenSim or there's something wrong
>> with that unwritten assumption. In my infinite tolerance towards
>> variety, and given the empirical evidence here, I'm leaning towards the
latter (i.e.
>> there's something wrong with that assumption).
>
> Unfortunately I am not too familiar on how OSGrid works but I can
> explain how it could work with the scenario I described where we have
> quite many separate services.
>
> In this case a user would login to a region with separate locations of
> the user's inventory, a list of links to group memberships, a link to
> the user's profile and so on.
>
> The region would then ask an authorization manager to get access to
> these resources on behalf of the user. The user will then be asked
> with a list of services the region wants access to and on "ok" this
> access will be granted in form of OAuth access token which can be used
> to perform signed requests to these services. (the concept of the auth
> manager needs to be developed as mentioned).
>
> So in this case the region can only access a user's data after getting
> those tokens. If this "ok" is given automatically though security will
> obviously be lacking.
>
> Now many regions could be grouped into one region domain which might
> mean that they e.g. provide some mapping services and they could maybe
> use shared access to that data.
>
> In the case of a region domain consisting of regions operated by
> different providers this of course means that a rogue sim indeed could
> get access to that data. But in general I don't see a solution here
> unless you really give each sim access upon visiting. Which of course
> would be annoying.
>
>> Yes, OSGrid, as is, will always be extremely vulnerable towards
>> insider rogues; technically, it's impossible to secure OSGrid's UGAIM
>> servers from malicious sims connected to it. But so what? Maybe
>> people want it like that, maybe the OSGrid community wants to perform
>> human surveillance instead of applying technical solutions such as
>> the Hypergrid (once it's matured). Should we stop supporting that use
case?
>
> I think in the case of a grid which is operated by many people and you
> don't want just a shared map but also shared access for convenience
> there is not much left for kicking out rogue domains. In fact a user
> might not know that it's a bad sim when entering it anyway so even in
> the case of a confirmation on each crossing that sim would probably
> gain access.
>
> (Moreover I think bad clients is the more likely case of e.g. content
> theft).
>
>> If we continue to support the existence of grids like OSGrid, then we
>> need to think what it means for the users to visit such grids, and
>> how they can visit them securely -- that's all I'm trying to figure out.
>
> They should at least be made aware that there is not one entity
> running it you can sue (well, I don't know the TOS so I don't know if
> you actually could sue somebody).
>
> -- Christian
>
> PS: I know that the OAuth stuff is far away from what would be
> possible right now as it would also mean quite some changes to the
> client, I am mostly mentioning it for discussion purposes and because
> those are standards which are on the rise right now.
>
>>
>> Justin Clark-Casey wrote:
>>> Charles Krinke wrote:
>>>> OSGrid exists with two goals.
>>>>
>>>> 1. Test OpenSim SVN on a regular basis and report results to aid in
>>>> software development.
>>>> 2. Nurture a community.
>>>>
>>>> We need to start by considering that OpenSim splits the asset
>>>> storage between regions and the OpenSim assetServer. So, the
>>>> OpenSim asset model is a little different then SecondLife since we
>>>> already distribute some assets between regions and the UGAIM.
>>> I didn't know you were doing this already. Is there anywhere you could
point to with more details?
>>>
>>>> Are we saying that OSGrid is doing something problematic and
>>>> pertubating the OpenSim development? I am confused about the OSGrid
>>>> comments in this philosophical discussion. As I see the whole
>>>> situation, OSGrid is testing the mainline trunk SVN from OpenSim in
>>>> a manner consistent with the desires of the community.
>>> Not at all. I think the debate is more about how the architecture
>>> will move forward in the future. As you know, regions on OSGrid
>>> have to be pretty trustworthy so as not to abuse the central grid
>>> services. This classic architecture won't go away, but it might be that
active development and research switches to other architectures (e.g. client
side asset/inventory access, hypergrid), which can be better secured for a
robust distributed virtual environment.
>>>
>>> OSGrid may want to consider at some point whether it wants to
>>> migrate or switch to other architectures once these have matured
further. I doubt that this maturity is all that imminent.
>>>
>>> Anyway, I'm probably putting words into Diva's mouth now.
>>>
>>>> Charles
>>>>
>>>> -------------------------------------------------------------------
>>>> -----
>>>> *From:* Justin Clark-Casey <jjustincc at googlemail.com>
>>>> *To:* opensim-dev at lists.berlios.de
>>>> *Sent:* Wednesday, April 15, 2009 8:24:45 AM
>>>> *Subject:* Re: [Opensim-dev] The essence of "grid"
>>>>
>>>> Diva Canto wrote:
>>>> > As I zoom in on issues of trust and security, I'm getting to the
>>>> point > where I need a sharp definition of "grid". What is a grid,
>>>> besides being > a map/lookup service and a user accounts service?
>>>> >
>>>> > a) nothing more than that
>>>> > b) a trust domain
>>>> >
>>>> > If we choose b) then we need to think about OSGrid-like grids.
>>>> How can > we trust that a collection of regions administered by
>>>> different people > will behave? Can OSGrid-like grids survive
>>>> without ToS being signed > between the grid operator and the
>>>> region operators? What if the ToS is > such that it delegates to
>>>> the region admins any liability on bad things > happening in their
>>>> regions? -- that leaves the user with no central > authority to
complain, which is as good as not having a trust domain.
>>>> >
>>>> > If OSGrid-like grids (i.e. no contracts, or very loose ones;
>>>> just a map > service) are to exist, then it's clear that b) doesn't
hold in general.
>>>> > It means that there can be grids that are simply a collection of
>>>> regions > that come together in virtual space, but whose
>>>> trustworthiness as a > whole doesn't exist.
>>>> >
>>>> > The Hypergrid is specifically designed to cross trust
>>>> boundaries. Should > the OSGrid-like grids become HG-ed sims that
>>>> share the same map, and let > "grids" be, fully, trust domains?
>>>> >
>>>> > You may think I'm getting into philosophy, but this is critical
>>>> for the > technical work I'm doing right now related to
>>>> authentication, > server-side vs client-side authority, etc. If we
>>>> can assume that a > "grid" is a uniform trust domain with a
>>>> central authority, things will > be simpler in many ways. If not,
things will be a bit more complicated.
>>>> >
>>>> > Thoughts?
>>>>
>>>> I think that you could adopt b) without having a philosophical
>>>> problem with OSGrid. I would say that even the 'loose contracts'
>>>> on OSGrid are a form of trust. If someone were to abuse that trust
>>>> then I be very surprised if they were not removed from the grid.
>>>>
>>>> If OSGrid wanted better security by not sharing the current central
>>>> services then perhaps they could stipulate that new regions had to
>>>> connect by Hypergrid rather than the current model (once the
>>>> various gaps in Hypergrid are ironed out)?
>>>> Then, in a sense, all the directly connected regions becomes a
>>>> large Hypergrid node in the federation that makes up OSGrid.
>>>>
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Opensim-dev mailing list
>>>> > Opensim-dev at lists.berlios.de
>>>> <mailto:Opensim-dev at lists.berlios.de>
>>>> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>> >
>>>>
>>>>
>>>> --
>>>> justincc
>>>> Justin Clark-Casey
>>>> http://justincc.wordpress.com
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> -----
>>>>
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
------------------------------
Message: 3
Date: Wed, 15 Apr 2009 15:01:07 -0700 (PDT)
From: Charles Krinke <cfk at pacbell.net>
Subject: Re: [Opensim-dev] The essence of "grid"
To: diva at metaverseink.com, opensim-dev at lists.berlios.de
Message-ID: <678807.81030.qm at web82604.mail.mud.yahoo.com>
Content-Type: text/plain; charset="us-ascii"
You have completely lost me.
OSGrid uses the OpenSim UserServer for its "trust domain", as do all other
OpenSim grids.
Perhaps you need to change your semantics or argument a bit as there is
nothing different about OSGrid then any of the other OpenSim grids.
If you could perhaps make your debate a bit more focused on OpenSim grids in
general, then maybe we can figure out how to accomodate your thought
processes.
Charles
________________________________
From: Diva Canto <diva at metaverseink.com>
To: opensim-dev at lists.berlios.de
Sent: Wednesday, April 15, 2009 2:50:28 PM
Subject: Re: [Opensim-dev] The essence of "grid"
I think we already have an understanding of what is needed for securing
users from malicious hosts: client-side control, that's all. Client has
direct control over user agents, user's inventory, IM, social network, etc.
The regions stay out of it, they are only simulators of objects and agents.
Grider is exploring that design space, and instrumenting OpenSim for it.
We're very close to having OpenSim support these kinds of clients.
However, in some cases, the user may want to give control, at least some, to
the ... and this is where terminology gets tricky...
simulators? "grid"? And why would that be, you may ask. Well, because that
server-side (not to get into the choice of words again) may provide some
cool stuff if you pass it the control. It may, for example, give you an
additional world-specific inventory, or it may open agents for you in
interesting 3d spaces, or you won't be able to play whatever game is going
on in there unless the server-side has control over some of your data.
But even this is *sortof* relatively simple to do, IF we align the concept
of VW with the concept of trust domain. OSGrid, however, doesn't do that. So
what would it mean for a user to visit OSGrid? With which server would the
user's client share authority, if it were to share it?
Christian Scholz wrote:
> Hi!
>
> Cristina Videira Lopes schrieb:
>> I'm trying to understand what it is that we are supposed to secure,
>> because security depends entirely on that :-)
>
> That usually is my problem with most of these discussions be it on
> MMOX, AWG or social networking. So it would be good to have some sort
> of list of what needs to be secured against what sort of action.
>
>> I've seen way too many talks/chats/posts/blogs talking about a Web of
>> VWs in some form, while making the unwritten assumption that the
>> concept of "grid" (aka Virtual World unit, or whatever you want to
>> call it) aligns with the concept of a domain of trust (i.e. a bunch
>> of simulators that trust each other, under the control of one
>> authority). Then, a Web of VWs is the interconnection of those domains of
trust.
>>
>> Well, OSGrid doesn't align with that. So either OSGrid is not a
>> valid/sustainable use case for OpenSim or there's something wrong
>> with that unwritten assumption. In my infinite tolerance towards
>> variety, and given the empirical evidence here, I'm leaning towards the
latter (i.e.
>> there's something wrong with that assumption).
>
> Unfortunately I am not too familiar on how OSGrid works but I can
> explain how it could work with the scenario I described where we have
> quite many separate services.
>
> In this case a user would login to a region with separate locations of
> the user's inventory, a list of links to group memberships, a link to
> the user's profile and so on.
>
> The region would then ask an authorization manager to get access to
> these resources on behalf of the user. The user will then be asked
> with a list of services the region wants access to and on "ok" this
> access will be granted in form of OAuth access token which can be used
> to perform signed requests to these services. (the concept of the auth
> manager needs to be developed as mentioned).
>
> So in this case the region can only access a user's data after getting
> those tokens. If this "ok" is given automatically though security will
> obviously be lacking.
>
> Now many regions could be grouped into one region domain which might
> mean that they e.g. provide some mapping services and they could maybe
> use shared access to that data.
>
> In the case of a region domain consisting of regions operated by
> different providers this of course means that a rogue sim indeed could
> get access to that data. But in general I don't see a solution here
> unless you really give each sim access upon visiting. Which of course
> would be annoying.
>
>> Yes, OSGrid, as is, will always be extremely vulnerable towards
>> insider rogues; technically, it's impossible to secure OSGrid's UGAIM
>> servers from malicious sims connected to it. But so what? Maybe
>> people want it like that, maybe the OSGrid community wants to perform
>> human surveillance instead of applying technical solutions such as
>> the Hypergrid (once it's matured). Should we stop supporting that use
case?
>
> I think in the case of a grid which is operated by many people and you
> don't want just a shared map but also shared access for convenience
> there is not much left for kicking out rogue domains. In fact a user
> might not know that it's a bad sim when entering it anyway so even in
> the case of a confirmation on each crossing that sim would probably
> gain access.
>
> (Moreover I think bad clients is the more likely case of e.g. content
> theft).
>
>> If we continue to support the existence of grids like OSGrid, then we
>> need to think what it means for the users to visit such grids, and
>> how they can visit them securely -- that's all I'm trying to figure out.
>
> They should at least be made aware that there is not one entity
> running it you can sue (well, I don't know the TOS so I don't know if
> you actually could sue somebody).
>
> -- Christian
>
> PS: I know that the OAuth stuff is far away from what would be
> possible right now as it would also mean quite some changes to the
> client, I am mostly mentioning it for discussion purposes and because
> those are standards which are on the rise right now.
>
>>
>> Justin Clark-Casey wrote:
>>> Charles Krinke wrote:
>>>> OSGrid exists with two goals.
>>>>
>>>> 1. Test OpenSim SVN on a regular basis and report results to aid in
>>>> software development.
>>>> 2. Nurture a community.
>>>>
>>>> We need to start by considering that OpenSim splits the asset
>>>> storage between regions and the OpenSim assetServer. So, the
>>>> OpenSim asset model is a little different then SecondLife since we
>>>> already distribute some assets between regions and the UGAIM.
>>> I didn't know you were doing this already. Is there anywhere you could
point to with more details?
>>>
>>>> Are we saying that OSGrid is doing something problematic and
>>>> pertubating the OpenSim development? I am confused about the OSGrid
>>>> comments in this philosophical discussion. As I see the whole
>>>> situation, OSGrid is testing the mainline trunk SVN from OpenSim in
>>>> a manner consistent with the desires of the community.
>>> Not at all. I think the debate is more about how the architecture
>>> will move forward in the future. As you know, regions on OSGrid
>>> have to be pretty trustworthy so as not to abuse the central grid
>>> services. This classic architecture won't go away, but it might be that
active development and research switches to other architectures (e.g. client
side asset/inventory access, hypergrid), which can be better secured for a
robust distributed virtual environment.
>>>
>>> OSGrid may want to consider at some point whether it wants to
>>> migrate or switch to other architectures once these have matured
further. I doubt that this maturity is all that imminent.
>>>
>>> Anyway, I'm probably putting words into Diva's mouth now.
>>>
>>>> Charles
>>>>
>>>> -------------------------------------------------------------------
>>>> -----
>>>> *From:* Justin Clark-Casey <jjustincc at googlemail.com>
>>>> *To:* opensim-dev at lists.berlios.de
>>>> *Sent:* Wednesday, April 15, 2009 8:24:45 AM
>>>> *Subject:* Re: [Opensim-dev] The essence of "grid"
>>>>
>>>> Diva Canto wrote:
>>>> > As I zoom in on issues of trust and security, I'm getting to the
>>>> point > where I need a sharp definition of "grid". What is a grid,
>>>> besides being > a map/lookup service and a user accounts service?
>>>> >
>>>> > a) nothing more than that
>>>> > b) a trust domain
>>>> >
>>>> > If we choose b) then we need to think about OSGrid-like grids.
>>>> How can > we trust that a collection of regions administered by
>>>> different people > will behave? Can OSGrid-like grids survive
>>>> without ToS being signed > between the grid operator and the
>>>> region operators? What if the ToS is > such that it delegates to
>>>> the region admins any liability on bad things > happening in their
>>>> regions? -- that leaves the user with no central > authority to
complain, which is as good as not having a trust domain.
>>>> >
>>>> > If OSGrid-like grids (i.e. no contracts, or very loose ones;
>>>> just a map > service) are to exist, then it's clear that b) doesn't
hold in general.
>>>> > It means that there can be grids that are simply a collection of
>>>> regions > that come together in virtual space, but whose
>>>> trustworthiness as a > whole doesn't exist.
>>>> >
>>>> > The Hypergrid is specifically designed to cross trust
>>>> boundaries. Should > the OSGrid-like grids become HG-ed sims that
>>>> share the same map, and let > "grids" be, fully, trust domains?
>>>> >
>>>> > You may think I'm getting into philosophy, but this is critical
>>>> for the > technical work I'm doing right now related to
>>>> authentication, > server-side vs client-side authority, etc. If we
>>>> can assume that a > "grid" is a uniform trust domain with a
>>>> central authority, things will > be simpler in many ways. If not,
things will be a bit more complicated.
>>>> >
>>>> > Thoughts?
>>>>
>>>> I think that you could adopt b) without having a philosophical
>>>> problem with OSGrid. I would say that even the 'loose contracts'
>>>> on OSGrid are a form of trust. If someone were to abuse that trust
>>>> then I be very surprised if they were not removed from the grid.
>>>>
>>>> If OSGrid wanted better security by not sharing the current central
>>>> services then perhaps they could stipulate that new regions had to
>>>> connect by Hypergrid rather than the current model (once the
>>>> various gaps in Hypergrid are ironed out)?
>>>> Then, in a sense, all the directly connected regions becomes a
>>>> large Hypergrid node in the federation that makes up OSGrid.
>>>>
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Opensim-dev mailing list
>>>> > Opensim-dev at lists.berlios.de
>>>> <mailto:Opensim-dev at lists.berlios.de>
>>>> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>> >
>>>>
>>>>
>>>> --
>>>> justincc
>>>> Justin Clark-Casey
>>>> http://justincc.wordpress.com
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at lists.berlios.de <mailto:Opensim-dev at lists.berlios.de>
>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> -----
>>>>
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
https://lists.berlios.de/pipermail/opensim-dev/attachments/20090415/4dea0749
/attachment.html
------------------------------
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
End of Opensim-dev Digest, Vol 20, Issue 51
*******************************************
More information about the Opensim-dev
mailing list