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: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: 16 April 2009 01:01 To: [email protected] Subject: Opensim-dev Digest, Vol 20, Issue 51 Send Opensim-dev mailing list submissions to [email protected] 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 [email protected] You can reach the person managing the list at [email protected] 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 <[email protected]> Subject: Re: [Opensim-dev] The essence of "grid" To: [email protected] Message-ID: <[email protected]> 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 <[email protected]> Subject: Re: [Opensim-dev] The essence of "grid" To: [email protected] Message-ID: <[email protected]> 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 <[email protected]> >>>> *To:* [email protected] >>>> *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 >>>> > [email protected] >>>> <mailto:[email protected]> >>>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> > >>>> >>>> >>>> -- >>>> justincc >>>> Justin Clark-Casey >>>> http://justincc.wordpress.com >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>>> >>>> ------------------------------------------------------------------- >>>> ----- >>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> [email protected] >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev > > ------------------------------ Message: 3 Date: Wed, 15 Apr 2009 15:01:07 -0700 (PDT) From: Charles Krinke <[email protected]> Subject: Re: [Opensim-dev] The essence of "grid" To: [email protected], [email protected] Message-ID: <[email protected]> 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 <[email protected]> To: [email protected] 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 <[email protected]> >>>> *To:* [email protected] >>>> *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 >>>> > [email protected] >>>> <mailto:[email protected]> >>>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> > >>>> >>>> >>>> -- >>>> justincc >>>> Justin Clark-Casey >>>> http://justincc.wordpress.com >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>>> >>>> ------------------------------------------------------------------- >>>> ----- >>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> [email protected] >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ Opensim-dev mailing list [email protected] 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 [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev End of Opensim-dev Digest, Vol 20, Issue 51 ******************************************* _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
