How HG 2.0 is coming along

Diva Canto — Sun, 23 Sep 2012 02:29:18 +0000

It’s been a while since I last posted about HG 2, but it’s finally coming to life! HG 2 is all about letting grid operators define policies for access control to their grid’s assets and users. I thought I’d show how it is taking shape, so that you’ll be ready for it in the next OpenSim release.

HG Inventory

Inventory is much more secure than in HG 1.5, and the My Suitcase folder is playing an even more important role in that.

The first difference you will notice is that this folder is now under the root folder — see picture on the left. In HG 1.5, My Suitcase was at the same level as the root folder. That posed some issues, because the viewers can’t really handle that. So we had to make up Web applications (like D2 Wifi) to make inventory manipulations between the Suitcase and the other folders. Kind of hacky. That’s not happening anymore. In HG 2, My Suitcase is inside your normal inventory tree, so you can easily copy items back and forth between that folder and others.

Like in HG 1.5, the My Suitcase folder is special: it is the folder tree that receives objects you collect while you are visiting other grids. But now it is even more special: it is the only folder tree that is accessible to you (and therefore to the rest of the Internet) while you are traveling. Period.

Look at how your inventory will look like in HG 2 when you are outside your home world — see picture on the left. As the picture shows, all your folders except My Suitcase are shown as (Unavailable). You can still see them, and unfold them. You may even be able to access items that are already cached in your viewer’s cache (textures, notecards, etc.). But if you try to access any items outside My Suitcase that aren’t cached in your viewer while you are outside your home world, the operation will fail. For example, rezzing objects from those folders will fail.

Items inside My Suitcase, however, will be available. My Suitcase will also be the tree where all the items collected while traveling will go. Once you are back home you can then move them into other folders.

In short: the Suitcase is now really the only thing you’ll have available while traveling (but keep on reading for some exceptions). That means that it is also only the only thing that is available for rogue grids to mess with. Treat it as your own real-world suitcase: it may be stolen or badly damaged. But the rest of your belongings are safe in your home world.

[UPDATE 9/23] I should be more clear. The existing HG1.5 inventory service, which lets users still access their entire inventory abroad, will still be available in the future. Grids can continue to use that. They can even use the normal inventory service (HG1.0 style) on the Hypergrid, which has no restrictions whatsoever about inventory manipulation. Both of these, however, especially the normal inventory service, are horribly insecure and expose users to all sorts of risks regarding their inventory. Unless the networked grids have 100% trust in each other, I don’t recommend using them.

Appearance

Appearance in SL/OpenSim is a very tricky thing. Your appearance as an avatar consists of two things: wearables (shape, clothes, etc.) and attachments (prim hair, etc.), which can be arbitrarily complex objects with textures, scripts, etc. Additionally, the viewer “bakes” all the wearables into a set of textures, and those are the ones that are actually passed around between your viewer and the viewers of all other people around you. To make things even more complicated, the attachments have a nasty dependency with your inventory — they are objects that must be somewhere in your inventory, and the viewer must know about them being attached to you.

Why am I telling this? So that you understand some of the challenges regarding inventory access and asset access control related to your appearance.

Your appearance’s assets will be copied to the worlds that you are visiting, even if the items that you are wearing are not in the Suitcase folder. If we didn’t do that, you’d always have to switch into an appearance whose items would be in your Suitcase, and that would be a pain. So, your appearance items (your clothes, body parts and attachments) are the only exceptions to the rule “the only items available outside are items under the My Suitcase folder.” They are copied, and, as such, assume that they will be publicly available.

But this is not good enough for some grids. Suppose you are a user of a commercial grid wearing a very expensive avatar. That grid may not want any of its assets to be exported to other grids, including the avatar that you are wearing — that refusal of service can now be done (read on). But if you arrive at the destination without any wearables and attachments, you will be seen there as Ruth, even if you see yourself wearing the same expensive avatar because it is cached in your viewer as you travel. Projecting a Ruth image to others is not something we consider a good user experience, so we had to fix this somehow.

There is a configuration variable that grids can set regarding the use of “allowed appearances for Hypergriding.” That is, grids can create one or more appearances with assets that they don’t mind being publicly shared, and then force their users to wear one of those appearances before hypergriding out. The picture on the left shows the warning message when a user is wearing something that is not part of the allowed HG appearance assets, in this case, it was the sphere attachment.

Unfortunately, due the lack of appropriate viewer features, the appearance switch has to be done explicitly by the user, it can’t be done automatically. So if the user gets this warning message when she’s trying to HG TP, she needs to replace her outfit with one of the official ones. In the case in the picture, it’s a folder called HGOutfit.

Assets Access Control

The access to a grid’s assets in the Hypergrid is done via a service called the HG Asset Service. Grid owners can now configure that service by specifying policies for exporting their grid’s assets to the outside world. For example, they can say that it’s ok for others to access textures and sounds but not scripts or meshes, or any other combination — the policy specification language takes the entire set of asset types. Grid owners can also specify which kinds of assets the grid can import from other grids.

The specification is done under the section [HGAssetService], something like this:

[HGAssetService]
    HomeURI = "http://127.0.0.1:9000"
    ;; The asset types that will never be exported
    DisallowExport ="LSLText, LSLBytecode"
    ;; The asset types that will never be imported
    DisallowImport ="LSLBytecode"

When these policies are specified, those types of assets will never be imported/exported, no matter what users and the rest of the world may do.

Going one step deeper into content protection, commercial grids with protected content may want to physically separate their internal asset server from their HG asset server, i.e. they can operate over completely different databases. Their internal asset server can continue to be behind the firewall. With the Robust architecture, this has been possible for a while. But now it is possible to make that physical separation meaningfully regarding the user’s Suitcase folder. When that separation is in place, the assets for the Suitcase items will be stored in the HG asset server database, and users cannot copy items back and forth between the Suitcase and the other folders. The items in the Suitcase folder will be unavailable in the users’ home world, and become available only when the user is traveling. This may be a desired feature, as commercial grids may not like the import of freebies from the outside. This requires some advanced configuration, but that’s the kind of security barriers that need to be in place for commercial grids to start experimenting with the HG.

For the time being, asset access control is done in bulk, based on asset types, and specified by the grid operator. There is no fine-grain asset access control [yet]. What this means is that grid users cannot express their own policies regarding their own objects, they are at the mercy of the grid operator. Bringing that specification up to the users will require some User Interface work (possibly on the viewers) that isn’t done yet. We’ll leave that for HG 2.5.

Users Access Control

In an HG Teleport, there are always two independent authorities involved: the home world of the user and the destination world. These can now be configured, also independently, regarding HG travels. It is now possible to control who goes where. This is the basis for the emergence of HG sub-networks — groups of grids connected to each other, but not to everyone, via the HG.

Incoming HG visitors

The control of which kinds of users can visit our world is done in a service called the Gatekeeper. It is now possible to specify whether the grid accepts foreign users or not, and, if it does, from which domains those users should be. When a user tries to HG TP to a grid in which she is not allowed, she gets a message like the one seen on the picture on the left “Destination does not allow users from your world.”

The configuration looks like this:

[GatekeeperService]
...
  ; ForeignAgentsAllowed = true
  ;;

  ;; If ForeignAgentsAllowed is true, make exceptions using AllowExcept.
  ;; Leave blank or commented for no exceptions.
  AllowExcept = "http://griefer.com:8002, http://enemy.com:8002"
  ;;
  ;; If ForeignAgentsAllowed is false, make exceptions using DisallowExcept
  ;; Leave blank or commented for no exceptions.
  ; DisallowExcept = "http://myfriendgrid.com:8002, http://myboss.com:8002"

The fine-grain control of specific users can continue to be done with ban lists and other mechanisms that already exist. The kind of control we added in HG 2.0 is domain-based, so all users from those domains will / will not be allowed in. That is what allows the emergence of HG sub-networks.

Outgoing local users

Conversely, the home world of users also has a say about where the users can and cannot go. That is done in a service called User Agents. When a user tries to HG TP to a grid which her home world doesn’t want her to go, she gets a message like the one seen on the picture on the left “Your world does not allow you to visit the destination.”

On this side of things, the policy specifications are based on the user-level. That is, users at different levels may be subjected to different restrictions.