Talk:Hypergrid
From OpenSimulator
(John's comments) |
m (Formatting cleanup) |
||
| Line 22: | Line 22: | ||
* A coarse-grained selection via the concept of Suitcase (explained [[Hypergrid_Inventory_Access | here]]). This is the simplest thing to do, it doesn't require any changes to the viewer. | * A coarse-grained selection via the concept of Suitcase (explained [[Hypergrid_Inventory_Access | here]]). This is the simplest thing to do, it doesn't require any changes to the viewer. | ||
| + | |||
| + | |||
| + | ------------------ | ||
'''John says:''' | '''John says:''' | ||
| Line 28: | Line 31: | ||
I think this is making too many assumptions about "local" vs. "foreign". An inventory or asset server should be an independent concept from a simulator or grid of simulators. Requiring that I define one grid as my local grid if I go into the content storage/distribution business places a lot of burden on the Akamai's and AmazonS3's of the metaverse. If an inventory server is an independent service, every grid becomes foreign. Maybe my ACL looks like this: | I think this is making too many assumptions about "local" vs. "foreign". An inventory or asset server should be an independent concept from a simulator or grid of simulators. Requiring that I define one grid as my local grid if I go into the content storage/distribution business places a lot of burden on the Akamai's and AmazonS3's of the metaverse. If an inventory server is an independent service, every grid becomes foreign. Maybe my ACL looks like this: | ||
| − | RW: http://grid.uci.edu/users/diva | + | RW: http://grid.uci.edu/users/diva |
| − | RW: http://osgrid.org/users/* | + | RW: http://osgrid.org/users/* |
| − | R: * | + | R: * |
And a second level of checks would further restrict read access. Everyone can grab a texture if they know the UUID (in this particular config), but only the owner of a script can access it unless someone owns an inventory item giving them read access. Maybe someone is trying to setup a walled garden grid, and the ACL looks like this: | And a second level of checks would further restrict read access. Everyone can grab a texture if they know the UUID (in this particular config), but only the owner of a script can access it unless someone owns an inventory item giving them read access. Maybe someone is trying to setup a walled garden grid, and the ACL looks like this: | ||
| − | RW: http://identity.ibm.com/users/* | + | RW: http://identity.ibm.com/users/* |
The only hurdle left is how to delegate trust so simulators can access the content they need without compromising identity or additional assets/inventory. One solution could be Google's recently released spec on combining [http://step2.googlecode.com/svn/spec/openid_oauth_extension/latest/openid_oauth_extension.html OpenID+OAuth]. OAuth was designed for exactly this purpose; to delegate limited trust to an automated service without having to give away your login credentials. | The only hurdle left is how to delegate trust so simulators can access the content they need without compromising identity or additional assets/inventory. One solution could be Google's recently released spec on combining [http://step2.googlecode.com/svn/spec/openid_oauth_extension/latest/openid_oauth_extension.html OpenID+OAuth]. OAuth was designed for exactly this purpose; to delegate limited trust to an automated service without having to give away your login credentials. | ||
Revision as of 10:02, 3 February 2009
Diva says:
Contents |
Some thoughts on how to go about inventory security
These thoughts pertain to the problem of inventory security only, not to the other issue of potential property piracy after a sale.
The very first decision point is whether we want to continue to be compatible with Linden Lab's official viewer or whether we should start looking for alternative viewers that are more in sync with where OpenSim is going. Here's why.
Technically, the viewer plays a leading role in this story. Linden Lab's architecture has the viewer always contact the regions for inventory asset downloads. I'm not sure why they did this, but that's how things are. By doing this, there is implicitly a trust relation between the viewer and the region with respect to assets: the viewer requests the inventory assets to the region which, in turn, fetches them from the asset server and then sends them to the viewer; the user trusts that the region is not going to steal or delete or infect those inventory assets. This works well in closed systems like Linden Lab's, but it's terrible for open systems, where different regions are controlled by different people. We really can't trust the regions in general!
Alternative Architecture
The obvious alternative to that is to have the viewer contact the inventory/asset server(s) directly for all operations related to inventory manipulation, without having the region in between. This would solve *all* the inventory security issues we face by abiding to LL's architecture. Granted, this is a radical architectural change, and I'm not even sure I can foresee all the consequences. It's just makes a lot of sense to me, intuitively. Regions should never be trusted with the users' confidential data, and the viewer should be a hub for interaction with lots of servers that the user needs to interact with. The region should stay out of it.
- This solution makes two unjustified assumptions. (1) All regions are on a grid with a separate asset server. (2) Grid assets servers are trustworthy. The first assumption ignores the proliferation of standalone sims with built-in asset servers, unconnected to any grid. That the metaverse will come more and more to resemble the anarchy of websites may disturb some. But that is what is happening, like it or not. The second assumption is also false, as demonstrated by Linden Labs. I, like many former SL users, was ripped off by Linden Lab's policy changes depriving me of paid-up (openspace) land and months of construction labor without even refunding my initial fee. Never again will I or others like me trust anyone else with the fruits of my labor. My assets will always remain in my possession on my own asset server. As the Scots put it, "Fool me once, shame on you, fool me twice...." Frank W Sweet 17:51, 3 February 2009 (UTC)
Back to Reality
OK, so that probably won't happen any time soon, not in the official LL viewer, and not in all the other derivative viewers out there (anyone wants to prove me wrong? I would love that! :-). What's the next best thing?
- An extra flag in the item's Properties indicating that the item is to be shared with foreign regions. In this case the inventory server can selectively send the user's inventory to the foreign regions, sending only those item marked with that flag. This requires a small change in the viewer to add that extra flag and send out the corresponding bit in a message to the inventory server. However, we need to figure out a way to coerce the viewer to make that contact to the inventory server directly without going through the region, otherwise the region may just flip the bit; we're not sure how to do this.
- A coarse-grained selection via the concept of Suitcase (explained here). This is the simplest thing to do, it doesn't require any changes to the viewer.
John says:
Moving Away from Local vs. Foreign
I think this is making too many assumptions about "local" vs. "foreign". An inventory or asset server should be an independent concept from a simulator or grid of simulators. Requiring that I define one grid as my local grid if I go into the content storage/distribution business places a lot of burden on the Akamai's and AmazonS3's of the metaverse. If an inventory server is an independent service, every grid becomes foreign. Maybe my ACL looks like this:
RW: http://grid.uci.edu/users/diva RW: http://osgrid.org/users/* R: *
And a second level of checks would further restrict read access. Everyone can grab a texture if they know the UUID (in this particular config), but only the owner of a script can access it unless someone owns an inventory item giving them read access. Maybe someone is trying to setup a walled garden grid, and the ACL looks like this:
RW: http://identity.ibm.com/users/*
The only hurdle left is how to delegate trust so simulators can access the content they need without compromising identity or additional assets/inventory. One solution could be Google's recently released spec on combining OpenID+OAuth. OAuth was designed for exactly this purpose; to delegate limited trust to an automated service without having to give away your login credentials.
One big plus with this approach is that it should be feasible without rewriting the Linden Lab viewer. The LL viewer already makes heavy use of capabilities, which is just another way of using access tokens to talk to services. Inventory is supposed to be switched over to all CAPS in the near future (libOpenMetaverse and OpenSim devs are surely cringing) which means OAuth tokens could be mangled into CAPS URLs and handed to the client to make things work seamlessly.
In practice, the simulator never needs access to inventory (except in the current scenario where inventory is proxied through the simulator, which is going away soon). It does need access to some assets. An additional CAPS URL could be generated that is stored on the simulator side and handed around with HyperGrid teleports that allows limited access. In a tightly coupled grid approach, logging in to the user server alleviates the need to do a direct OpenID login to an asset server, which gives you the entire security model without the client ever understanding what OpenID or OAuth are. However, you can still use your third party tools to communicate directly with the inventory/asset server using OpenID (and optionally OAuth).
The downside is that this still requires some notion of tight coupling to make the backward compatible paths work (logging into the user server pings a local asset/inventory server to prevent the need for a second login). However, this is no different from today's setup and it provides a roadmap to completely decentralizing grid services.
