<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:arial,helvetica,sans-serif;font-size:12pt"><div>Backing up a step.<br><br>OpenSim does not allow a way to *stop* a region from attaching to a UGAIM, be it OSGrid, or any other OpenSim grid. There is nothing unique about OSGrid except its history. OSGrid runs the OpenSim software as it exists. No more, no less.<br><br>I would think the first step would be to have a way to control whether or not a region can attach to a grid first before we get too wrapped up in other things.<br><br>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.<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> Christian Scholz <cs@comlounge.net><br><b><span style="font-weight: bold;">To:</span></b> lopes@ics.uci.edu; opensim-dev@lists.berlios.de<br><b><span style="font-weight: bold;">Sent:</span></b> Wednesday, April 15, 2009 2:27:31 PM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [Opensim-dev] The essence of "grid"<br></font><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>> <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>> _______________________________________________<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>COM.lounge GmbH<br><span><a target="_blank" href="http://comlounge.net">http://comlounge.net</a></span><br>Hanbrucher Strasse 33, 52064 Aachen<br>Amtsgericht Aachen HRB 15170<br>Geschäftsführer: Dr. Ben Scheffler, Christian Scholz<br><br>email: <a ymailto="mailto:info@comlounge.net" href="mailto:info@comlounge.net">info@comlounge.net</a><br>fon: +49-241-4007300<br>fax: +49-241-97900850<br><br>personal email: <a ymailto="mailto:cs@comlounge.net" href="mailto:cs@comlounge.net">cs@comlounge.net</a><br><span>personal blog: <a target="_blank" href="http://mrtopf.de/blog">http://mrtopf.de/blog</a></span><br><span>personal podcasts: <a target="_blank" href="http://openweb-podcast.de">http://openweb-podcast.de</a>, <a
target="_blank" href="http://datawithoutborders.net">http://datawithoutborders.net</a></span><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>