How HG 2.0 is coming along

 

 

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.

The configuration looks like this:

[UserAgentService]
...
;; Are local users allowed to visit other grids?
;; What user level? Use variables of this forrm:
 ;; ForeignTripsAllowed_Level_<UserLevel> = true | false
 ;; For example:
 ForeignTripsAllowed_Level_0 = false
 ForeignTripsAllowed_Level_10 = true ; true is default
 ;;
 ;; If ForeignTripsAllowed is true, make exceptions using AllowExcept.
 ;; Leave blank or commented for no exceptions.
 AllowExcept_Level_10 = "http://griefer.com:8002, http://enemy.com:8002"
 ;;
 ;; If ForeignTripsAllowed is false, make exceptions using DisallowExcept
 ;; Leave blank or commented for no exceptions.
 DisallowExcept_Level_0 = "http://myfriendgrid.com:8002, http://myboss.com:8002"

 

5 replies on “How HG 2.0 is coming along”

  1. Susannah Avonside says:

    Interesting stuff, and provides some enlightenment on what to expect from HG 2.0. Whilst I personally welcome the configureability of HG 2.0 it still allows, in my opinion, too much control over virtual goods that an individual has paid for – true, in ‘reality’ all that has been paid for is a licence to use that item. In Real Life I don’t have to duplicate my wardrobe item for item every time I move to a different country, and so I don’t expect to have to do that in the virtual world. However, grid controllers are of course free to make their own decisions over how their grids function, but if they are too restrictive they risk being boycotted by those of us with a more open and tolerant approach. Eventually sanity will reign I guess and the paranoia and greed of some grids and creators will be replaced by common sense and reasonableness on the commercial front:charge reasonable prices and the incidence of ‘content theft’ will reduce. I hope that attempts to entice the commercial grids towards experimenting with Hypergrid are more aimed at creating credibility for the concept amongst those who are at present sceptical about the economic potential of the 3D web. I personally have nothing against fair trade and economic activity that creates opportunities for the many, but I do have serious concerns over those who would strangle an otherwise wonderful idea because it threatens their profits. Though I do welcome anything that makes the metaverse a better, more interesting place, I still think the security worries are a red herring predicated on the fallacy that Open Sim is a hotbed of copyboters, something that some peddlars of FUD are keen to spread, which seem to be those who have the most to lose from an opening up of the metaverse. HG 2.0 won’t do anything to change this, and one of the first questions that those contemplating visiting or moving to other girds will ask is “Can I take my inventory with me?”. A fair question, as many of us have invested considerable sums of RL cash on our inventories. HG 2.0 ignores the real elephant in the room, and that’s the fact that most copying of items goes on within closed grids, not without as is often erroneously assumed. This is not to say that there is no copied content in the open girds, but that it’s occurrence is grossly exaggerated. It’s my guess that the implementation of HG 2.0 will not serve to open up the commercial grids to the wider world, and if it does, what point does it have if you subsequently are not allowed to take your purchases home with you and use them on your home grid? True, it’s early days, but I think in terms of user base Open Sim have far more to worry about than this kind of ‘security’… far more important is the awareness, or lack of your average SL user has about the even the existence of other virtual worlds ‘out there’. I understand some of the dilemma, as to be successful, the 3D web needs to be economically viable, and for that to happen it needs users, and for users to come, (well the bulk of them who are more consumerist oriented) there needs to be content and activities…it’s all a bit Catch 22.

  2. Gaga says:

    Thank you Diva. This is looking good. It would have been nice to have creator perms in HG2 as it would have been a strong message to send to merchants and content creators but I understand the problems with the viewers. Hopefully, now Linden Labs are effectively going to force that hand of TPV developers we might get some of them turning their attention to Opensim’s needs. I hope so. Anyway, I am glad you mentioned HG2.5 for creator perms.

    Thank you for all your hard work!

  3. Diva Canto says:

    @Susannah See the Update note under HG Inventory. Go ahead and put your inventory on the Internet if you want. The restriction is not on the grids you are visiting, it’s on whoever hosts your inventory. If you host your own OpenSim world, you can do whatever you want.

  4. Han Held says:

    I’m very concerned about the user access control feature -and I think that will end up being used by grids to herd their users away from competing grids (“you can go see bob’s 4-sim grid on a stick, but we don’t want you seeing avination and gettin ideas in your head of moving over there”).

    I think that anything that needlessly censors what adult hypergridders are exposed to is bad for the metaverse. Potentially, the free market would route around rouge grids that try to misuse that feature because people would simply choose to avoid grids that engage in that behavoir, I think instead they would hide behind hysterical PR instead (“but-but-but avination is full of copybotters! ooooo” [when clearly it’s not]).

    Time will tell how this will all play out, and hopefully my concerns will be for naught. I read on hypergrid business that people will be able to communicate/hop between 1.5 and 2.0 enabled grids so hopefully people like me who are uncomfortable will be able to stick w/ 1.5 for a while.

  5. Diva Canto says:

    @Han, policies are specified by whoever runs these worlds. The specification language is as expressive as can be — “all, except…” and “none, except…”. Grid operators have all the freedom in the world to decide what the right policy is for their specific grids. For large grids, I would imagine that the operators would pay attention to what their users want. But that’s not a discussion to have here.

Comments are closed.