Content protection: an incomplete proposal

This post comes on the heels of a conversation Ubit and I had about protecting content on the Hypergrid. As all of you know, content protection, in general, is a big problem, and not just for the Hypergrid. Even for closed grids that can enforce permissions, content theft happens via modified viewers: a sufficiently skilled developer can grab the source code of any of the legit viewers and add modifications to it that allows them to copy all the content they see, and alter their permissions on the copies. The Hypergrid opens up yet another avenue for abuse: when an avatar travels to another grid, their appearance and the inventory items on their Suitcase folder become available to the destination grid. If the owner of that destination grid is a decent developer but a bad actor, they can add modules to OpenSim that grab copies of those items and change their permissions on the database.

Some time back, Melanie added a new flag to items, the “Export” flag, which some viewers started to support. The Export flag allows creators of content to mark them as exportable or not exportable — meaning ok to export to other grids or not. That gives some level of flexibility to content creators, but it doesn’t solve the problem. If an item is marked “No copy” but “Exportable”, a bad grid operator can easily change the permissions on it. So, at the moment, our recommendation to viewer developers is that they only allow to mark the “Export” flag when the item is fully “free”: no constraints on copy, transfers, and modifications. This is so people don’t get a wrong sense of security.

I should note that there are no reports of Hypergrid thefts, even though they are technically possible. As far as I know, most copy-botted content comes from using altered viewers on closed, non-HG grids; those loots are then imported into other OpenSim-based grids via those viewers too. So altered viewers, not HG thefts, are the main problem. Nevertheless, the fact that the HG opens additional doors for abuse has been a deterrent for commerce on the Hypergrid, so much so that we recommend “Export” only for freebies. It would be nice to change that perception. The incomplete proposal I have here solves the problem not just for the Hypergrid but also for viewer-based thefts in closed grids, even if those grids don’t ever want to connect to the Hypergrid. It solves the problem so thoroughly that, if implemented, it would allow commerce on the Hypergrid to bloom. The problem is in the implementation; hence, the “incomplete” in the title of this post…

The proposal, in a nutshell: ledgers.
Specifically for the Hypergrid: distributed, decentralized ledgers. Yes, blockchain, but minus the coin.

How it works, birds-eye view

Let’s ignore implementation details for a moment. I’ll cover them at the end.

Here is the main idea of a ledger: every time an item changes hands (from one avatar to another) a record about the transaction should be entered on a database. The information should include: the item ID, the time of original creation of the item, the timestamp of the transaction, the owner ID, the receiver ID, and the item’s permissions at the time of the transaction. Ledgers are append-only databases: they hold the historical record of all transactions since the beginning of time. (A side note to mention that OpenSim already has append-only databases: the assets.) So if any item’s origin is ever in question, the ledger can be queried for the ground truth.

Next, I will go through various theft scenarios, and explain how the ledger gives honest grid operators the technical justification for punitive action against thieves, and how it it will help identify (and, hopefully, socially isolate) dishonest grid operators.

Detecting theft within a closed grid

Let’s ignore the HG for a moment, and focus on centralized ledgers.

Let’s consider the viewer-based theft scenario in closed grids: some bad actor logs in with an altered viewer and copies all content that it sees into this bad actor’s inventory, changing permissions, and even authorship, along the way. This bad actor goes on to sell this content as their own on that same grid. Nothing in this proposal prevents this from happening. However, if and when the original creator detects this shenanigan, they can file a complain with the grid, who now is armed with the ledger, the historical record of all transactions. A simple query on the ledger can find out when the items in question were first transactioned; the offender’s item’s timestamp will be later than the original creator’s item’s timestamp. If the items are, indeed, similar, as per the original creator’s complaint, then the timestamps, and the lack of a transaction chain between the items, are proof that there was a theft, and who the offender was. The grid owner can act swiftly.

Detecting theft across grids

Let’s continue to ignore HG for a little longer.

Let’s consider the same viewer-based theft scenario, but now the bad actor imports the stolen content from closed grid X into another closed grid Y via the altered viewer. Assume both grids have their own separate ledgers, and both grid operators are honest. Again, this proposal doesn’t prevent theft from happening. It’s only when suspicion of theft is raised that the matter can be investigated.

In this scenario, suppose the bad actor with the altered viewer imports the stolen content into grid Y as their own. Grid Y will store the item as if it was legitimately created by this person at time T1, when it was imported there. It knows nothing about its true origin. Some time later, there is a complain from the original creator who first created this item in grid X at time T0 < T1. Both grids can easily investigate by agreeing that the items are, indeed, very similar, and by checking their own ledgers independently. If they find that T0 < T1, then it’s clear theft was at play, and who the thief was. They can act.

Detecting theft between a closed grid and OSGrid

Continuing to ignore HG, let’s focus on hybrids like OSG: in OSG-like grids, many independent people control their regions, but they are all connected to central grid services operated by osgrid.org, specifically inventory; this ledger would be another grid-wide service. Assume the region operators may be bad actors, but that the grid services operators are honest.

In this scenario, a bad actor, armed with an altered viewer, logs in to a closed commercial grid, steals content via the viewer, and then imports it to OSG using their own region, where they not only have God-like powers but can also alter the simulator code. They have a lot more opportunities to tamper with the timestamps of creation, ownership, etc. But that doesn’t matter much, as long as inventory and ledger are centralized services of the grid, and are capable of correcting any region-sent information. When suspicion of theft is raised, both grids can check their ledgers for timestamps.

Managing transactions across the Hypergrid

Having separate ledgers is fine for grids that trust each other, but in the Hypergrid, some grid operators may be bad actors themselves, and they control their grid’s ledgers. If they steal something, they can then enter those items on their own databases as having been created in a date that is sufficiently in the past to escape proof of theft, or, even worse, to harass the original content creators! “I created this before you did!” That’s bad.

For this to work on the Hypergrid, we need to establish a distributed, decentralized ledger system, blockchain style. Here is how it works.

Every time an item changes hands (from one avatar to another) a record about the transaction should be entered onto the distributed ledger. The distributed ledger is a kind of replicated database over a peer-to-peer network, but where peers can independently verify the veracity of the information that is sent to them — sometimes directly and sometimes via some voting algorithm. If we trust the information on the distributed, replicated ledger, rather than on any single node, then we can always verify whether something was stolen or not across grids that are part of the network.

The weak link of decentralized ledgers is false information. How can we prevent false information from entering the ledger? Here are a couple of scenarios of false information:

  • Problem: a bad grid operator creates a false record of a transaction between a visiting avatar and a local avatar. That is, they send to the ledger “HG visitor A gave a copy of item H to local avatar B at time T1″ when that transaction never happened.
    Solution: any transactions between avatars should always take place on the grid of origin of the avatar that gives the item. In other words, visitors can get things, but should not give things. All transactions should be local to the originator avatar. This can easily be checked at ledger-entry time by verifying that the issuer grid is the grid of the originator avatar. If it isn’t, nodes of the distributed ledger won’t accept the transaction.
    (We can implement non-local transactions, too, but that will complicate the giving procedure substantially, as it will require confirmation from the originator when it comes back to their grid)
  • Problem: a bad grid operator changes the items’ creation time to the past. For example, they import stolen content with an altered viewer, and then they send the following record to the ledger “Item H was created in 12/12/2012.”
    Solution: ledger nodes need to verify that the timestamps of a creation record are credible.

Implementation Issues: Where Things May Come to a Halt

While the general idea will definitely be the best solution for protecting content, implementing it in practice for the Hypergrid is not a trivial matter.

Ledgers are append-only databases; their size can grow very large. This is a common problem of all blockchain solutions. For example, the Bitcoin ledger currently 275G, and it will continue to increase forever. In our case, we could either do some garbage collection when items are removed from inventory, or we could do what blockchain operators do: archive old records into separate, slower, databases. But these solutions aren’t very good for the Hypergrid, where a large number of single person grids exist, many of them running in people’s home networks. Those small shops would end up having to deal with a very large database, most of which is irrelevant to them; they would get it just because they would be part of this ledger network.

We can estimate how large a distributed ledger for the HG would be, and how fast it would grow based on the current estimates of people’s inventories. One thing that will definitely contribute to the large size of the ledger is if we enter every inventory item on the ledger: if anything created in inventory, whether it will be passed around or not, is entered into the ledger, the ledger will become unsustainably large very quickly. For reference, there are hundreds of millions of entries in OSGrid’s inventory service, and probably billions of items have been created there. Multiply that by 1000 grids. This would quickly grow to be a terabyte-size database.

We could focus only on the items that are transferred from one avatar to another, and use the timestamp of the first transaction as a proxy for time of creation. This approximation will fail to detect thefts if the item is stolen before the first transaction happens, and then the thief quickly makes a first transaction themselves. This should be rare, and people could be aware and compensate for it. It will definitely decrease the size of the ledger by several orders of magnitude, as the vast majority of items in people’s inventories aren’t passed to another avatar.

Still, even with optimizations, the ledger will be large, and this will be a problem for small standalone grids.

Perhaps the right thing to do is to decouple the ledger from the grids. We can implement a distributed ledger system that is operated by a few trusted people in the community, with access to enough resources, and that ledger can hold the transactions of everyone who wants to ensure the use of legitimate content in their grids. Any grid not on this ledger will be suspicious; social pressure will make them look bad.

Of course, nothing prevents a single entity from creating a centralized ledger for many independent grids, as a service. That will require complete trust in the ledger operator.

Anyway, I hope this post will trigger some discussion and maybe even some action, as it is clear that without a mechanism for content protection, commerce on the Hypergrid will never take off, and the nice professionally-created items will not be available to those with good intentions, such as Universities.

Wifi and Other Diva Addons

Hello everyone! OpenSim 0.8.1 brings a few minor bug fixes to core OpenSim and a significant change to how the web app Wifi is deployed in grids (no changes for D2 standalones). In general, this release introduces a mechanism for me and others to provide 3rd-party addons via mono addins, a mechanism that has been in OpenSim for a very long time, but that was severely underutilized. Let me explain how to deploy Wifi in your grid from here on, and then I’ll explain how to install additional Diva addons in either grids or standalones.

NOTE: mono addins works in both .NET and mono. If you run Wifi in Windows you do not need to install mono in order to run mono addins. Everything you need is already included in the OpenSim distribution.

Continue reading →

OnLook Viewer

onlook_icon

As I’ve announced at OSCC’14, I am working with Liru on a Singularity-based viewer whose main goal is to make the viewer’s UI as programmable as possible server-side. You know, more like Web browsers.

The idea here is to allow OpenSim operators to have more control over the experience that their users will have; specifically, I want to be able to design much simpler user interfaces that are more appropriate for people who have no experience with Second Life and/or may be even uncomfortable with seeing themselves as avatars. But more importantly that any specific UI, I want to be able to provide those UI specifications dynamically as the user enters the simulator, rather than being hard-coded during the viewer’s build process. This way, we can change the UI without forcing users to install new versions of the viewer. And no one needs to agree on any specific UI.

I’m happy to announce that the very first alpha release of OnLook is now available for testing! Without the server-side UI specs, OnLook behaves exactly like Singularity, so you won’t see any difference when you login to your world. In order to help people test it, I have deployed a small test world that can be accessed via the Hypergrid. So here is a description of the steps that you can do to test this, along with pictures of what you’ll see.

Continue reading →

New in 0.8: Profiles and Variable-Sized Regions

Snapshot_001

OpenSimulator 0.8 brings one much requested feature, profiles, and a fantastic new feature, variable-sized regions (varregions for short), something we got from an offshoot of OpenSim with collaboration from viewer developers. Profiles and varregions both work out of the box for new installations of D2, so if you’re doing it from scratch, you don’t need to read this. But if you are upgrading your D2, there is some manual upgrading to do. Please read on!

Continue reading →

OSCC 2013 — Why You Should Care and How You Can Help

Load Test

As all of you probably already know, we are organizing the first OpenSimulator Community Conference on the first full weekend of September, 7-8. This event has been in the making since, roughly, March. But it took us a couple of years before that to actually convince ourselves that it was worth doing it. Here are all the reasons why I think this event a great thing, and why everyone who uses OpenSimulator should be involved in some way.

Continue reading →

D2 Addons: Groups, Offline IM, TOS module

The latest release of D2 (diva-r22043) includes a few new addons that are missing from the core of OpenSim, namely: Groups, Offline IM and a Terms of Service feature. I’ve waited this long to implement these, but it has finally come to a point that I can’t live without them. Groups are pretty important for access control and permissions, and it has been a battle to work without them; offline IM is convenient; and showing a Terms of Service agreement has become important to me, especially for foreign visitors.

D2 is meant to be a personal virtual world server, so some of these addons have limitations that reflect the spirit of a personal virtual world. For example, in D2 you can create at most 2 groups. I have an unlimited version of Groups, too, but that is meant for larger worlds.

Anyway, you can find all the information about these addons here. The Wifi web app has been extended with some minimal support for managing groups.

These addons are works in progress, and I will keep improving them. This is their first release to the public, so expect some hickups. Please report those issues here, but make sure to read the documentation first.

Have fun!

 

Updating D2 to r22043 in Linux

NOTE: This affects only Linux installations. D2 on Windows machines is fine.

If you are updating your D2 in Linux from r20232-b to the latest, you will very likely encounter the following problem:

$ mono Update.exe
Using download link http://metaverseink.com/download/diva-r22043.zip
Your current release is diva-r20232-b. Available release is diva-r22043
New release available. Updating…
Downloading new release from http://metaverseink.com/download/diva-r22043.zip to /tmp/diva-r22043.zip. This may take a few minutes.
……………………………………………………………:-)
Extracting new release to /home/opensim
* Unable to unzip. Please try updating later. (Reason: Path is empty)
*********************************************************************
Your installation has been updated. The new release is in
>> /home/opensim/diva-r22043 <<
Your regions have been migrated.
Please read the RELEASENOTES to know what changed.
If you made changes to OpenSim.ini, please copy that file over
or change the new one.
*********************************************************************

<Press return to exit>

In other words, the Update tool fails to unzip the new package.

This is due to a bug in a library included in OpenSim 0.7.4, on which diva-r20232-b is based. The offending library is called Ionic.Zip.dll. Here is what you need to do in order to get past this issue.

1 – Download this version of that library and place it in your current d2 bin folder, diva-r20232-b/bin. You can overwrite  the one that’s there, or move it somewhere before placing the new version there. Note that some download tools (e.g. wget) don’t overwrite files and instead give them new names. Make sure the new version has the right name.

2 – Run the Update tool again.
$ mono Update.exe

Voila! Problem solved.

The latest D2 release has the correct version of Ionic.Zip.dll, so hopefully this won’t happen next time you need to update.

Bad Ubuntu!

$ less /etc/hosts
127.0.0.1 localhost
127.0.1.1 nile.ics.uci.edu nile
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Yesterday, I spent a lot of time harassing just about everyone in my University’s Networking Support department because I couldn’t get an OpenSim server to serve clients anywhere. We know that OpenSim networking is hard. But, damn it, I’m one of the core devs of OpenSim, and I have a pretty good idea of what’s involved in the protocols between the server and the client. I’ve had lots of OpenSim servers running successfully in all sorts of networks, including my University’s. Well, the problem turned out to be… Ubuntu!

Continue reading →