Design and direction for protecting content using the Marketplace


#1

OK, so here is where we are headed and what we have done so far regarding the marketplace and content protection:

At a high level, what we intend to do is to implement a secure tagging system that allows anyone to easily confirm for certain that a piece of content they find in the world (for example an object or avatar) was actually purchased from the High Fidelity marketplace. This is partially implemented today: you can right-click on an entity and see either a link back to the marketplace where it was downloaded, or the message “No Marketplace Info”. Without going into the nitty-gritty crypto details, this type of tagging is completely secure - although there are many different digital copies on different servers, there can still be a single public registry of who owns what. We can even allow that registry to be stored by many people, in a manner similar to how the Bitcoin ‘blockchain’ is stored by many different people.

What this means is, for example, that if someone makes an unauthorized copy of a piece of content and puts it on a server, anyone who happens to see it will easily be able to confirm that it was NOT purchased or downloaded from the marketplace.

As many here have correctly observed, digital world content is just like online music: it’s really easy to make a copy of something if you really want to. This is because, just like audio, the ‘raw’ version of mesh/texture/model content is easily accessible on any computer that is able to view it. There isn’t any way around this or any way to make effective ‘DRM’ systems for 3D content, once it is visible to others.

But that’s OK, for two reasons: First, tagging content from the marketplace with ID’s that serve as a proof of purchase that everyone can easily see will be a powerful deterrent from inappropriate copying. Beyond the stigma of it being publically obvious if unauthorized copies are made, this feature will pave the way for all kinds of ‘Better Business Bureau’ organizations that will certify good behavior and/or take action against violations. Second, because we will operate a single central marketplace that will hopefully be large and successful, we can respect content permissions at the point of submission, meaning that you won’t be able to upload content to the marketplace that violates other people’s content rights choices. So, for example, attempting to re-use content from the marketplace in a new marketplace submission won’t be allowed.

On that last point, another feature that we think will be very effective at keeping well-intentioned people honest and help people build together is an automatic derivative rights system. What this means is that you’ll be able to submit things to the marketplace, and then set the permissions in such a way that your marketplace item will be useable by others in their own creations for either a fixed fee or a percentage of their own sale price. We haven’t started working on this yet, but it should be straightforward.

So that is the summary of what we are doing with content protection. Obviously a very important and complex topic, and it is certain that we will change these designs somewhat as we get rolling and widespread creation of content starts. Discussion very welcome.


No avatar, no business
#2

Thank you for providing a clear insight :slight_smile:

Presumably submitted content for the marketplace will be centralised in terms of storage?

Also, @philip, how will objects (meshes) cater for scripts being linked to them… SL entities have their own inventories which allow for scripts to add functionality to items, and at the same time, protects those scripts from the viewer - will such a system be implemented? If the object contains meta data saying ‘rezz but apply this script to the instance in-world’ can the script be stored securely in the marketplace too?


#3

This clears up a lot. SO what you are saying is that we need not meddle with this ourselves and can rely on a solution provided by you ?

Will there be an option to auto block incorrectly tagged content for servers/Will servers be able to work with feedback from the marketplace concerning this issue ?


#4

A few thoughts:

  • One’s own custom-built models won’t necessarily be available in the market place. (Model has “No Marketplace Info”.)
  • You may have purchased models from other market places. (Model has “No Marketplace Info”.)
  • Someone’s bound to copy model purchased from another market place and upload it to the market place as their own. (New model has Marketplace Info but the original validly purchased model will have “No Marketplace Info”.)

#5

One thing I’d like to see is an expansion to the loading protocol as in;

https://somedomain.com/content/somemodel.fbx?some_metadata

Where “some_metadata” would be an appropriate data fragment containing the asset’s placed location domain id/place name and the context of is it being placed or simply viewed, and for placement - an id of placer. Some anti-spoofing logic would be part of this as well, but that’s not worth going into now. Reason for this would be having ability to restrict content to a specific domain or set of domains and have some control over who can request and place an asset. This would be optional in that you wouldn’t have to include the additional data in request. Having this one could have a lot of control over assets .


#6

Would a .htaccess file in the dir where the fbx files be a good idea, to allow only access when downloading from a hf domain ?

This would prevent the dirs to be indexed by search engines and making it too easy to just grab the fbx, scripts and other files from where they are hosted.


#7

That’s worth taking a look at if your domain has a static ip and you have access to the .htaccess. Hadn’t thought of that but will give it a try later. Though - I think (may be wrong) the request comes from the viewer’s IP not the domain server. DS only coughs up the URL for client to request. So maybe that won’t work so well.

Will check logs and ponder.


#8

Rely is a big word… but certainly we will build what we’re describing here around tagging. It won’t fix every case - there may be ideas or systems that are more additive that are built by others. But we think makes sense for what we are doing first.

If I understand you correctly - yes - I think we will add a feature allowing a domain operator to only allow insertion of content into their domain that is correctly tagged as being from the marketplace.


#9

Yes, The marketplace will support scripts (it already does), and will allow groups of objects to be created together.


#10

That brings up the can of worms… what about scripts? Will we at some point have a script engine where the script’s source is not there for the taking? Perhaps something like Chrome’s V8 JS Engine that can take compiled JS code vs plain text source?


#11

@ctrlaltdavid:

We’ll manually review submissions to the marketplace and build comparison tools that will hopefully catch these cases. If something is in the marketplace that is found (or reported) to use unauthorized content that was submitted at an earlier time, we’ll remove it.


#12

I was not thinking of ip’s, that would be too restrictive, I would be oke with it if models and scrtips are used on other domains. but more like alowing just a user agent

RewriteCond %{HTTP_USER_AGENT} ^hfDomainAgent
RewriteRule ^(.*)$ http://www.example.com/$1 [L,R=301]

I will have to read the docs a bit and figure out what kind of user agent hf uses


#13

I see - that’s worth looking into. @ctrlaltdavid knows the user agent string well. : )


#14

This is also one of my concerns.


#15

It’s not that easy to check the validity of a creator externally. If someone uploads something they didn’t make and that doens’t have the right licence, it’s them who are culpable by law (and morality).

It’s good to know that content will be protected in HF. Thank you @philip


#16

Thank you for answering my questions.

As i said in the original thread: I am perfectly aware there is no 100% secure system. But this should give our customers the peace of mind i was looking for. Nobody can expect us to plan against organised cybercrime durung the alpha. But this is good, looking forward to see it implemented.


#17

THIS is important. By far the most difficult part of old school virtual worlds has been the lack of automatic derivatives. Without it, collaboration, or n-tier intermediate products are quite difficult to do. Without this one has to rely on the trust of anonymous people - it has not worked well to date.


#18

Cloud Party had this derivatives method on their marketplace. It worked well. I bought a few things (animations I think) and also sold some items that had the ability to be reused. I either paid a commission when I sold something containing the animation or received one when someone sold an item that used something I had made. That was an OPT IN feature there. You could just also sell things NOT to be reused and sold.


#19

This is all well and good, but what will you do about the DMCA process, which does not favor an artist not selling on your marketplace? If the system is fairly secure, I can’t imagine why I would not want to sell in HF. That said, what if I do not, or I don’t sell all my items here? In the normal DMCA process, you are required to pull the content once the original creator files the required paperwork, or whatever, then the accused can counter, which leave the original creator stuck. They must then pay for lawyers and what not to move the process further. Most of us don’t have the cash to waste fighting this kind of crap. Will you consider a system where known 3D artists can sign up, even if we don’t sell on the marketplace, and sign a contract with HF to better protect our content? Or something, cause it is going to get messy if many of us are abused because the DMCA system is not perfect. Basically, how will you handle these disputes? I would rather HF be the judge, whom I can show proof to, rather than spending thousands of dollars trying to stop someone on the other side of the earth.


#20

When a company decides to get involved in the handling of disputes beyond the exact stipulations of content dispute resolution, aka DMCA takedown, they lose their safe harbor status and thus become liable for any and all claims. This is why companies follow the DMCA process to the letter, no more, no less.

Now, all that said, the content is not kept in the company. It is distributed across all the servers a myriad of people own. I can’t begin to think how to manage that configuration in terms of takedowns.