<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:arial,helvetica,sans-serif;font-size:12pt"><div>You have completely lost me. <br><br>OSGrid uses the OpenSim UserServer for its "trust domain", as do all other OpenSim grids. <br><br>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.<br><br>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.<br><br>Charles<br></div><div style="font-family: arial,helvetica,sans-serif; font-size: 12pt;"><br><div style="font-family: arial,helvetica,sans-serif; font-size: 10pt;"><font size="2" face="Tahoma"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Diva Canto <diva@metaverseink.com><br><b><span style="font-weight: bold;">To:</span></b>
opensim-dev@lists.berlios.de<br><b><span style="font-weight: bold;">Sent:</span></b> Wednesday, April 15, 2009 2:50:28 PM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [Opensim-dev] The essence of "grid"<br></font><br>
I think we already have an understanding of what is needed for securing <br> users from malicious hosts: client-side control, that's all. Client <br>has direct control over user agents, user's inventory, IM, social <br>network, etc. The regions stay out of it, they are only simulators of <br>objects and agents. Grider is exploring that design space, and <br>instrumenting OpenSim for it. We're very close to having OpenSim support <br>these kinds of clients.<br><br>However, in some cases, the user may want to give control, at least <br>some, to the ... and this is where terminology gets tricky... <br>simulators? "grid"? And why would that be, you may ask. Well, because <br>that server-side (not to get into the choice of words again) may provide <br>some cool stuff if you pass it the control. It may, for example, give <br>you an additional world-specific inventory, or it may open agents for <br>you in interesting 3d spaces, or you won't be able to
play whatever game <br>is going on in there unless the server-side has control over some of <br>your data.<br><br>But even this is *sortof* relatively simple to do, IF we align the <br>concept of VW with the concept of trust domain. OSGrid, however, doesn't <br>do that. So what would it mean for a user to visit OSGrid? With which <br>server would the user's client share authority, if it were to share it?<br><br><br>Christian Scholz wrote:<br>> Hi!<br>> <br>> Cristina Videira Lopes schrieb:<br>>> I'm trying to understand what it is that we are supposed to secure, <br>>> because security depends entirely on that :-)<br>> <br>> That usually is my problem with most of these discussions be it on MMOX, <br>> AWG or social networking. So it would be good to have some sort of list <br>> of what needs to be secured against what sort of action.<br>> <br>>> I've seen way too many talks/chats/posts/blogs talking about a Web
of <br>>> VWs in some form, while making the unwritten assumption that the concept <br>>> of "grid" (aka Virtual World unit, or whatever you want to call it) <br>>> aligns with the concept of a domain of trust (i.e. a bunch of simulators <br>>> that trust each other, under the control of one authority). Then, a Web <br>>> of VWs is the interconnection of those domains of trust.<br>>><br>>> Well, OSGrid doesn't align with that. So either OSGrid is not a <br>>> valid/sustainable use case for OpenSim or there's something wrong with <br>>> that unwritten assumption. In my infinite tolerance towards variety, and <br>>> given the empirical evidence here, I'm leaning towards the latter (i.e. <br>>> there's something wrong with that assumption).<br>> <br>> Unfortunately I am not too familiar on how OSGrid works but I can <br>> explain how it could work with the scenario I described where
we have <br>> quite many separate services.<br>> <br>> In this case a user would login to a region with separate locations of <br>> the user's inventory, a list of links to group memberships, a link to <br>> the user's profile and so on.<br>> <br>> The region would then ask an authorization manager to get access to <br>> these resources on behalf of the user. The user will then be asked with <br>> a list of services the region wants access to and on "ok" this access <br>> will be granted in form of OAuth access token which can be used to <br>> perform signed requests to these services. (the concept of the auth <br>> manager needs to be developed as mentioned).<br>> <br>> So in this case the region can only access a user's data after getting <br>> those tokens. If this "ok" is given automatically though security will <br>> obviously be lacking.<br>> <br>> Now many regions could be grouped into one
region domain which might <br>> mean that they e.g. provide some mapping services and they could maybe <br>> use shared access to that data.<br>> <br>> In the case of a region domain consisting of regions operated by <br>> different providers this of course means that a rogue sim indeed could <br>> get access to that data. But in general I don't see a solution here <br>> unless you really give each sim access upon visiting. Which of course <br>> would be annoying.<br>> <br>>> Yes, OSGrid, as is, will always be extremely vulnerable towards insider <br>>> rogues; technically, it's impossible to secure OSGrid's UGAIM servers <br>>> from malicious sims connected to it. But so what? Maybe people want it <br>>> like that, maybe the OSGrid community wants to perform human <br>>> surveillance instead of applying technical solutions such as the <br>>> Hypergrid (once it's matured). Should we stop
supporting that use case?<br>> <br>> I think in the case of a grid which is operated by many people and you <br>> don't want just a shared map but also shared access for convenience <br>> there is not much left for kicking out rogue domains. In fact a user <br>> might not know that it's a bad sim when entering it anyway so even in <br>> the case of a confirmation on each crossing that sim would probably gain <br>> access.<br>> <br>> (Moreover I think bad clients is the more likely case of e.g. content <br>> theft).<br>> <br>>> If we continue to support the existence of grids like OSGrid, then we <br>>> need to think what it means for the users to visit such grids, and how <br>>> they can visit them securely -- that's all I'm trying to figure out.<br>> <br>> They should at least be made aware that there is not one entity running <br>> it you can sue (well, I don't know the TOS so I don't know if
you <br>> actually could sue somebody).<br>> <br>> -- Christian<br>> <br>> PS: I know that the OAuth stuff is far away from what would be possible <br>> right now as it would also mean quite some changes to the client, I am <br>> mostly mentioning it for discussion purposes and because those are <br>> standards which are on the rise right now.<br>> <br>>><br>>> Justin Clark-Casey wrote:<br>>>> Charles Krinke wrote:<br>>>>> OSGrid exists with two goals.<br>>>>><br>>>>> 1. Test OpenSim SVN on a regular basis and report results to aid in <br>>>>> software development.<br>>>>> 2. Nurture a community.<br>>>>><br>>>>> We need to start by considering that OpenSim splits the asset storage <br>>>>> between regions and the OpenSim assetServer. So, the OpenSim asset model <br>>>>> is a little different then
SecondLife since we already distribute some <br>>>>> assets between regions and the UGAIM.<br>>>> I didn't know you were doing this already. Is there anywhere you could point to with more details?<br>>>><br>>>>> Are we saying that OSGrid is doing something problematic and pertubating <br>>>>> the OpenSim development? I am confused about the OSGrid comments in this <br>>>>> philosophical discussion. As I see the whole situation, OSGrid is <br>>>>> testing the mainline trunk SVN from OpenSim in a manner consistent with <br>>>>> the desires of the community.<br>>>> Not at all. I think the debate is more about how the architecture will move forward in the future. As you know, <br>>>> regions on OSGrid have to be pretty trustworthy so as not to abuse the central grid services. This classic architecture <br>>>> won't go
away, but it might be that active development and research switches to other architectures (e.g. client side <br>>>> asset/inventory access, hypergrid), which can be better secured for a robust distributed virtual environment.<br>>>><br>>>> OSGrid may want to consider at some point whether it wants to migrate or switch to other architectures once these have <br>>>> matured further. I doubt that this maturity is all that imminent.<br>>>><br>>>> Anyway, I'm probably putting words into Diva's mouth now.<br>>>><br>>>>> Charles<br>>>>><br>>>>> ------------------------------------------------------------------------<br>>>>> *From:* Justin Clark-Casey <<a ymailto="mailto:jjustincc@googlemail.com" href="mailto:jjustincc@googlemail.com">jjustincc@googlemail.com</a>><br>>>>> *To:* <a ymailto="mailto:opensim-dev@lists.berlios.de"
href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>>>>> *Sent:* Wednesday, April 15, 2009 8:24:45 AM<br>>>>> *Subject:* Re: [Opensim-dev] The essence of "grid"<br>>>>><br>>>>> Diva Canto wrote:<br>>>>> > As I zoom in on issues of trust and security, I'm getting to the point<br>>>>> > where I need a sharp definition of "grid". What is a grid, besides being<br>>>>> > a map/lookup service and a user accounts service?<br>>>>> ><br>>>>> > a) nothing more than that<br>>>>> > b) a trust domain<br>>>>> ><br>>>>> > If we choose b) then we need to think about OSGrid-like grids. How can<br>>>>> > we trust that a collection of regions administered by different people<br>>>>> > will
behave? Can OSGrid-like grids survive without ToS being signed<br>>>>> > between the grid operator and the region operators? What if the ToS is<br>>>>> > such that it delegates to the region admins any liability on bad things<br>>>>> > happening in their regions? -- that leaves the user with no central<br>>>>> > authority to complain, which is as good as not having a trust domain.<br>>>>> ><br>>>>> > If OSGrid-like grids (i.e. no contracts, or very loose ones; just a map<br>>>>> > service) are to exist, then it's clear that b) doesn't hold in general.<br>>>>> > It means that there can be grids that are simply a collection of regions<br>>>>> > that come together in virtual space, but whose trustworthiness as a<br>>>>> > whole doesn't
exist.<br>>>>> ><br>>>>> > The Hypergrid is specifically designed to cross trust boundaries. Should<br>>>>> > the OSGrid-like grids become HG-ed sims that share the same map, and let<br>>>>> > "grids" be, fully, trust domains?<br>>>>> ><br>>>>> > You may think I'm getting into philosophy, but this is critical for the<br>>>>> > technical work I'm doing right now related to authentication,<br>>>>> > server-side vs client-side authority, etc. If we can assume that a<br>>>>> > "grid" is a uniform trust domain with a central authority, things will<br>>>>> > be simpler in many ways. If not, things will be a bit more complicated.<br>>>>> ><br>>>>> > Thoughts?<br>>>>><br>>>>> I think that
you could adopt b) without having a philosophical problem <br>>>>> with OSGrid. I would say that even the 'loose<br>>>>> contracts' on OSGrid are a form of trust. If someone were to abuse that <br>>>>> trust then I be very surprised if they were not<br>>>>> removed from the grid.<br>>>>><br>>>>> If OSGrid wanted better security by not sharing the current central <br>>>>> services then perhaps they could stipulate that new<br>>>>> regions had to connect by Hypergrid rather than the current model (once <br>>>>> the various gaps in Hypergrid are ironed out)?<br>>>>> Then, in a sense, all the directly connected regions becomes a large <br>>>>> Hypergrid node in the federation that makes up OSGrid.<br>>>>><br>>>>> ><br>>>>> ><br>>>>> >
_______________________________________________<br>>>>> > Opensim-dev mailing list<br>>>>> > <a ymailto="mailto:Opensim-dev@lists.berlios.de" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a> <mailto:<a ymailto="mailto:Opensim-dev@lists.berlios.de" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>><br>>>>> > <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>>>>> ><br>>>>><br>>>>><br>>>>> -- <br>>>>> justincc<br>>>>> Justin Clark-Casey<br><span>>>>> <a target="_blank" href="http://justincc.wordpress.com">http://justincc.wordpress.com</a></span><br>>>>> _______________________________________________<br>>>>> Opensim-dev mailing
list<br>>>>> <a ymailto="mailto:Opensim-dev@lists.berlios.de" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a> <mailto:<a ymailto="mailto:Opensim-dev@lists.berlios.de" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>><br>>>>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>>>>><br>>>>><br>>>>> ------------------------------------------------------------------------<br>>>>><br>>>>> _______________________________________________<br>>>>> Opensim-dev mailing list<br>>>>> <a ymailto="mailto:Opensim-dev@lists.berlios.de" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>>>>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev"
target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>>> _______________________________________________<br>>> Opensim-dev mailing list<br>>> <a ymailto="mailto:Opensim-dev@lists.berlios.de" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>> <br>> <br>_______________________________________________<br>Opensim-dev mailing list<br><a ymailto="mailto:Opensim-dev@lists.berlios.de" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br></div></div></div></body></html>