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, 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.

8 replies on “Content protection: an incomplete proposal”

  1. Mike Chase says:

    It would be interesting to see what feedback the “core team” provided,. I’ve been looking at ledgers for over a year to protect assets. Truth is I don’t think most of the HG wants this. Also I’m not convinced that solving this issue alone is enough to create a creator friendly economy. There are some examples of using ledgers in gaming environments. But they really assume control of all the points contributing to the ledger. A ledger really isn’t dependent on trust but to do it that way is very expensive in computation and time. Probably the first step is to secure the rest of the HG to support web of trust controls and then building services like the ledger you mention on top of that. All of the tiny Dreamgrid instances wont likely participate but I’m not sure thats a bad thing. Thats not the market a commercial creator is trying to serve anyway.

  2. Diva Canto says:

    The feedback, so far, is cautiously positive. The idea was first bombarded with conceptual objections, which is what I was expecting, but I think I was able to defend it. The key here is to make it very clear that this does not prevent theft from happening, it just gives a powerful tool for honest grid operators to police content on their grids, without a shadow of a doubt. (I also learned that some very primitive form of this is what honest grid operators already do when they get complaints: they check timestamps. The public ledger would make that process much easier and more reliable for everyone, everywhere)
    After that bombardment phase, the conversation switched to how to actually implement this, given the socio-technical context of the HG. I heard excellent ideas! There are many centralized/decentralized hybrids we can do to simplify and scale things. We need to bounce more ideas.
    The force of small grids is in their numbers. In fact, many content creators use their small islands to build their things, and then make them available in popular grids. That use case needs to be part of this.

  3. Ai Austin says:

    The privacy implications of storing inter-agent transactions into databases under the control of any third party needs to be addressed… in terms of legality, risk of hacking, exploitation and governmental or corporate misuse. Imagine some of the “trusted” sites to support the methods adopted were in countries whose policies and laws were altered as leaders changed, politics radically altered and emergency legislation forced disclosures of any stored data. This is not a hypothetical situation.

    We should assume the number of grids can be very large. DreamGrid distribution alone has multiple thousands of sites openly accessible, and possibly many more run up on personal servers, as we used to do with SimOnAStick. With the benefits of HG, that number of grids could grow a lot.

    Technically, you mention that inventory is the basis for what is stored and what may be garbage collected. I don’t understand that. Assets surely are the key. Items nay be stored in offline OARs and UARs long after the grids they were created in, the avatars that created or owned copies, or their inventories have disappeared, only to be resurrected decades later to show some earlier build.

    Could you point at the discussions, comment and replies to date? Which forum was that in?

    • Diva Canto says:

      That’s a good point. This would need to be privacy-preserving, obvs. In fact, there are some advantages of removing all avatar information from these public records: it keeps the focus on items rather than on people. So someone can claim that an item has been stolen and the verification is based on time stamps alone; no information about who stole it or even who created it. This can lead to less contention between grid operators and thiefs, since no one will be accused; the stolen items will simply be removed. Note, however, that grid operators already have all the personal information of their users, including who owns what in their inventory. But that’s a shared secret between the users and their grid operators.

  4. Misterblue Waves says:

    Buildings and other region content that is just viewed is never “transacted”. That is, everything one can see in the viewer is sent to the viewer (in complete, editable form) without the viewer ‘buying’ anything. Would the ledger also record every time someone viewed an item?

    • Diva Canto says:

      Good question. I think the answer is no. In fact, viewing is not ‘owning’, and that’s the crux of all the problems related to the copyrights issue in general. That’s what happens also when we get a PDF or even a paper copy of an article: we need it to read it, but there are no rights transferred with the transfer of the data. On the contrary, the document usually says it’s subject to copyrights, and what the reader can and can’t do with the copy.

      A copy of an inworld object sent to viewers is equivalent to a copy of a PDF sent to PDF viewers.

      The ledger would focus on ownership and permissions, not on viewership. Copies are needed for viewing, but that does not come with the right to own. Like for all other copyable and copyrightable media, the data can be stolen, and that’s why we’re having this conversation :-) It’s impossible to prevent theft, but it’s possible to prove that something has been stolen by having a ledger of what was created and when.

      • Diva Canto says:

        Right now, it’s super easy to steal content, and super hard to prove that theft has happened, because there are no reliable records about when things were created. The ledger would not change the ease of stealing things, but it would radically change the ease to verify claims of theft. That tip of the scale may completely change the incentives for content theft.

  5. Mike Chase says:

    I’m not sure how you do “privacy preserving” for a function that’s designed to record transactions between grids/users over assets. Certainly you need to be able to handle GDPR and similar requests to render a specific user anonymous but then that user loses transaction history and any benefits that might accrue to it. The larger question to answer IMO is 1) who runs such a service and how is trust to it established and 2) who can query the ledger and for what information. Just having it isn’t really valuable unless you identify the requirements for using it.

    The biggest issue I see is that you have a widely distributed capability (anyone can turn up a grid) with no real mechanism for forming trust relationships which leads to making statements about the reliability of the data being collected. Anyone can hack server code as well. You can make the ledger resilient to hacking but garbage in garbage out still applies for the app running on the ledger.

Comments are closed.