Asset Protection (Essential for a market economy)


#1

Looking forward, and being completely aware that the entire platform is in the early stages of development, I would like to engage in the subject of protection of assets, which is a critical step to allow for an economy to emerge for content producers - which is essentially how the world will survive as a platform. Content creators will feel safer to flock in to sell their products, end-users and venue owners will purchase the products to use, and a competitive market will be born.

I know that at the current stage, a permissions system similar to the SL platform would be impractical as there is no standard inventory system where the content is safe, so the next step will be circumvention, considering the following;

Client Side

(For this, I will use the term Mesh to describe a product that has been made, i.e. a piece of furniture)

  1. If I rezzed out the Mesh in my virtual establishment (i.e a Club or a Hangout) then can visitors easily get the URL for where the Mesh file exists on my http server?

  2. Does the Mesh file get cached in it’s raw FBX format on the visitor’s hard drive? or can it be compressed in a Virtual File System layer behind the Interface?

  3. If the Mesh file does get obfuscated on the hard drive, including the name, is the index of obfuscated files also obfuscated or protected?

  4. Can cached objects have a lifetime before getting automatically purged by the client interface?

  5. Can a license clause be implemented to prevent forking of the main source code where the security steps have been disabled?

This doesn’t allow for a transfer of rights system, essentially meaning nothing can be handed around… But I wouldn’t want to engage in the topic of an inventory system if content isn’t centralised…

However, I would be willing to enter into the discussion of a hive system where server-owners like myself can begin to form a cloud system for the inventory, dedicating a set amount of storage space for use if compensated in some form of way.


#2

Obscurity is no security. This ends up in the domain of encryption, keys to decrypt, signed code and hardware mediated trusted execution to prevent tampering. It’s a big topic area.


#3

I think we could use some kind of security encryption chain. That’s a chain I whip you with if u steal my models


#4

It is a big topic area indeed, but one that I personally feel must be touched upon, especially to offer assurance that content will be safe and marketable in the future.

Encryption is of course the best remedy, but would such a security model be viable with an OS client and server stack? It would be just as easily circumvented for anyone who can access the source tree and make the necessary adjustments to disable, or reverse the encryption.


#5

Plays Devils advocate a while
In Secondlife and open sim all the assets can be copied by anyone with a will to do so.Are you suggesting Highfidelity adds in a level of model encryption that other virtual worlds don’t have?
Our choices are as it seems to me we create an elaborate encryption system , or rely on the law.
It comes down to who is responsible for the protection of your work, you or someone else.


#6

High Fidelity as far as I can gather seeks to champion the VR platform experience, especially with the level of investments in the project. Would it be a bad thing to pioneer a new system?

Leaving the responsibility up to the content creators is an option, but it’s only as effective as the platform the content exists on.

Jayne is one method, but there is only one of him (resists urge to watch a Firefly marathon)


#7

We had a chat else where in the forum where @KevinMThomas was suggesting some kind of encryption system.
Imagine dropping your file into something like a password protected rar or zip file with the password authenticated by hifis name server tied to the users name.This would mean a customer could buy the mesh host it for their own use but have no actual access to its content. The question is if this is possible , would it give us all an extra level of lag and then would someone hack it the next day?

Also feels a Firefly marathon coming on, i cry every time in season 2 episode 5 where Mal marries Inara :wink:


#8

I suppose a solution could be that the asset gets stored a server with a metadata file that outlines the policy for permissions and assigns a UUID (much like SL), but when the client requests that asset, the server could send it through a encryption/obfuscation layer that tailors the data depending on the client user’s own unique ID.

That way it would exist on the client’s computer in a semi-secure way, and then the client could ask the server for a key to decode it.

Not bullet proof, but one step more secure than using HTTP get on the raw unprotected data.

Plus with metadata, an entity can be defined fully including attachments, any script that should be used on the mesh(es) and any dependency elements like sounds TV


#9

Sounds cool, ok next step is to go code it, or go looking for an open source system like you suggest and put it up on worklist. see if anyone wants to take it on.


#10

As tempting as it is, it would probably be best to flesh out the idea a bit more.

I’ll let this coffee absorb some more then have a dig around for solutions


#11

Is it possible to get an official stance on this ? Is it actually wanted by the devs that we take this into our own hands ? Because i can see all sorts of trouble coming from this, mostly legal trouble. before we do any work on this it should be clear that this is something that the Hifi Dev team is not willing to do.


#12

As Adin rightly put, before we embark on actually putting a model together for a potential solution, it would be great to know if there is anything planned to be used in conjunction with the Market element of the system.


#13

Looking at this http://highfidelity-site-live.s3.amazonaws.com/blog/wp-content/uploads/2014/04/hifi-system-architecture.pdf tells me that some sort of protection should not be tha hard to implement, but it is internal, i think. And to be perfectly honest, that seems like a good idea.


#14

No matter how elaborate the encryption, call backs to verify rights to rez/view/transfer etc… at some point it’s all a collection of unecrypted mesh geometry and textures. Given the will to do so - it will always be possible to steal.

Making that difficult as possible is the best one can do. My feeling is and always will be use encrypted assets packages allowing those packages to exist in many places with callbacks to authorization services vs a centralized fenced off asset service. Plus use of steganography encoded chain of ownership in images and meshes. Yes. You can encode robust data into a mesh that’s difficult to remove and will survive things like resizing etc. Between a difficult to remove mark of asset ownership and robust packaging to eliminate “easy mode” copying… you have a chance. But - end of day the best system to prevent content theft is one that refuses to display anything to anyone. Let’s not do that one. : )

While the open nature of this will allow for service providers to roll their own systems for their own domains and, I suspect, some will… it seems at some point HiFi must enter this as it will be essential for the marketplace.


#15

Anyone given the will and access to a computer can steal content sure

where there is a will there is a way, but this should at least not be used as an excuse to avoid the issue entirely; Make it as difficult to steal as possible, rather than simply shooting the idea down, on the probability that someone will always find a way around it. (and in the TC’s make it clear that such activity can result in a ban?)

A system that works to a degree is more favourable than no system at all.


#16

Agreed - I don’t believe for a moment that there will be NO system. It’s just not something that has come to the forefront for a project that is so early in development and, by all indications, so far away from being a production ready system.


#17

The idea here is to give content creators some basic security. Basic.

The absense of such security was what kept them from OpenSim largely. Now i am perfectly aware that everything can and will be hacked, but it has to remain an exception, not the norm. Only then will people risk their high value models and code.


#18

Oh I agree, but with the Marketplace already in existance, surely it’ll be better now to provoke such a thought before the Marketplace evolves anymore, just so the supports for the foundation of a security model are there for when the time comes.


#19

Well that’s where it got kind of stupid. I’ve been here a while (last September) and was somewhat shocked to see a marketplace before things like permissions and asset controls were even talked about let alone implemented. What I’ve found in my time here is that, sometimes, things that seem to make no sense are done that, later, once someone explains the reasoning behind it makes a lot more sense.

I look at it this way - it’s all alpha testing and subject to being something entirely different tomorrow. We once had voxels and metavoxels and in world chat that didn’t require using IRC or hacky things. All those are now gone and, while disturbing at first, do kind of make sense once some blanks are filled in. I suspect the subject of assets/market will be seen much differently once it passes a proof of concept stage to something more concrete. I don’t think for a moment the current state will be the final state.


#20

I’m very keen to see a roadmap or progress update on what is going to happen with the Marketplace.