Proposal: Add HTTP Request Headers to be used for Content Protection


#1

While on my morning commute, I was discussing with @Medhue about the
implications on content protection through a marketplace and monopolization
in the earlier thread

I had a sudden conceptual idea for content protection that would placed on
the file hosts them selves and would maintain the open source nature and
web based interaction.

I’ll flesh this idea over time, but generally watch this space:

June 11th:

Changed domain ID to to public address of the server.

The concept works with the following idea:

  • Each cached request for assets must provide in the header the following:
  • the UUID of whoever placed the object / or whomever the entity is attached to. (“HiFiEntityOwner”). Should not distinguish if attached / entity in world.
  • Name of domain where the entity is at (“HiFiDomain”)
  • Public Server Address where the entity is at (“HiFiDomainAddress”)
  • Hash of Domain’s secret time based value (randomly generated salt and pepper scheme), “HiFiDomainAddress” and “HifiEntityOwner” (“HiFiHash”)
  • If said agent is guest (not logged in, and has been able to somehow
    add entities) or has changed avatars, the agent uuid is provided
    as empty or null uuid (0).
  • The asset provider’s backend may use this information to
    check if it wants to provide the file to the user or not. (The Rules can be set by backend),
  • Each Requests respects cache-control settings.

Privacy concerns; this information must NOT tell what account was used to load up the model.

Granted, ** every modern day web request already have ip addressed in each request,** but we should not be provided with info on what account was used to load up the model (as far as we know, it could have just been a proxy address).

If the backend doesn’t do anything with this information, it will work like it currently does.

As header information is used, and is standard to http(s), the header check logic these can be written using any backend language

As an example, the authentication could, for example work in the following manner: (the asset host should be able to decide)

  1. Receive Request. Check if from Hifi interface client.
  2. Check if owner uuid is valid (which ever method, through database ownership, or just simple validity check)
  3. Do a request to HiFiDomainAddress. Send Owner and Domain UUID, Should get the same hash result back.
  4. Do a validity check with the request hash and the retrieved hash from the domain.

If everything goes through, allow access to the asset data. Else return 401.
This entire shake should happen within 250ms, which considering the potential file sizes should be small enough.

This would mean people can also create their own storefronts / Third party marketplaces, and overall be them selves responsible for the rights on the content they provide.

The Concept of “Your own” and “inventory” would have to be revised though: Inventory would be more of a list of bookmarks of objects.


Breakdown

##Benefits:

  • Allows for multiple marketplaces and for direct vendor - consumer relations
  • Continuing the Decentralization: Does not rely on a single marketplace, avoiding of monopolisation / will encourage competition. If one asset service fails, only content from that service will not show.
  • Allows for gameplay building and rewards from domain owners / host cooperation possibilities with domain/cross-domain specific entities that only work within those domains (preview?) and maybe open up as rewards to be used elsewhere. Wearable Achievements :smiley:
  • Basic Item Rights can be managed from where the assets are hosted.
  • You cannot rez the object without the rights from the asset host - Licensing through host.
  • Revenue possibilities for Hifi: If not using secret key from domain, use API requests to domain check, or DRM validation could be charged via tiers after an # amount of requests per domain uuid request per length time.
  • Content creators do NOT have to apply this unless they want it
  • Protection will proves intent of piracy if content is copied elsewhere. instead of “Oh I didnt know”.
  • Could be basis on how the marketplace works - Maybe even extend on this that the marketplace is the metaverse marketplace from which you can go to vendors and other marketplaces that fit ones interest? Maybe even blur the line between the metaverse and the web?
  • Analytics : How many times has an asset been loaded, and in what domain? instead of just how many times loaded. Vendors could then maybe market more to / for those domains.
  • Throttling: Throttle free stuff hogging up server bandwidth, one could throttle their views per domain to save bandwidth on server end. or limit use to a domain. This could make sure no one can DDoS an asset provider.

##Faults:

  • Requires backend or service if vendors want this protection. While due to technical limitations for some, most will still be sticking to Hifi market (Hifi should provide also a hosting service for that).
  • Currency is harder to force due to fragmentation
  • Even if decentralized requires an API from hifi for validation checks. This api would be the achilles heel. If this api fails and the asset server relies on it, then content is not visible, although asset server could skip validation if api gives a specific error related to unable to serve the hash.
  • Starting out could be costier for business for setting up the lookup API;
    risk of getting too many requests from some asset providers, especially if providers dont cache.
  • Relies on the performance of where the content is hosted at to do the communication quickly
  • Throttling - Could be used against end-users and domain holders. (I wont let user X or Domain Y use my products because waah) this is especially dangerous if a provider gets too big. Maybe an EULA for the API could avoid this sort of thing?
  • It requires end users to trust that the service/vendor:
  • That vendor has the rights to sell content and keep providing content as is.
  • Does not turn against the end users or domains where the end users are in.
  • It doesn’t stop piracy, it only makes it a way more difficult (you need a specialised client, and know the owners and uuid of domain), proving intent if stuff is copied (but easier to chase, web hosts dislike illegal stuff on their servers, hosting direct assets is not as grey as hosting links to assets.) .
  • Privacy issues: Vendors have logs of where the asset is present in and who placed it there.
  • Permanence - like with current issue with a single non hosting marketplace, if server hostong content goes down, content on that server will be gone until links are established again. But this issue same as with the web. We will run into issue of content permanence as time goes on as content can expire.
  • Time Sync Issue not all time on machines is synced, might be off a second, time hashes would be done every minute or so.
  • ** Cache Ghost** if user has seen a valid model, using the url allows them to see it locally, but cached. This could be fixed by the cache still doing a header request. The instance for the file should be reset if an 406 (“Not Acceptable”), or 401 (“Unauthorized”) response is gotten, then the model should be forcefully discarded from cache.

Additionally The Hifi Marketplace should also be configurable to send specific requests to a configured url, if a purchase has occured with the purchaser’s uuid. (No name info. only uuids for some anonymity)


Dictionary:

Asset server - web host where the assets are hosted at. Does the decision of whether or not to serve content

API - Application Programmable Interface. Used by other application and services to do exchange data. In this case for check

DNS - specifically HIFIs version of DNS. Otherwise known as Domain Name Service. Handles linking of names to server uuids. Could also provide an API for security checks.

Domain server - the domain in HiFi where the content is shown.


This would only needs a transaction and currency engine from HiFiInc and the requirement of headers in requests.

Whats everyones opinion on this?


#2

What can the user do with the file ?
What do you mean with user ?

A object that’s placed on domain always need to be accessable for everybody to view. (the user) So if you don’t want to provide the file, then your domain don’t show the object.

I think you mean something else. But that’s how i understand it right now.


#3

If the request information has info on “who placed the entity in the field” then that is used to determine who ever placed it in there is the owner of the asset.

If it was placed by anyone else, the agent uuid would change, and so would the ownership.

So the request would not based on who views the asset, but actually by who placed it. So user would be anyone who views it.

If the content is authorized to be shown by the providing service, then everyone can see it.


#4

https://alphas.highfidelity.io/t/viability-of-cors/6129


#5

We should hash this out sometime in June / July. Commercial VR is less than 6 months away… you know what that means in ‘dev-hours’ time. :smile:


#6

Its funny just yesterday I was thinking of writing a little php program to act as a server for my assets and I was looking into HTTP Request Headers. I was planning on having it check the useragent and see if it matches Interface. Easily spoofed but at least it would prevent casual access of my assets from a browser or something.

I actually haven’t played with http headers before so I’m not sure if that works or not. I’ll probably play with it this weekend.


#7

There is a simple .htaccess workaround for that already which doesnt require anything else but placing on the content folder. posted by @Coal and @MarcelEdward


#8

Oh wow, I don’t know how I missed that. Thanks.


#9

But yeah, generally this idea is an extension on the User Agent idea , utilizing the Header information to have information on who has placed the object.


#10

@Jerric I was thinking the same thing!


#11

Since I was mentioned, I’ll comment, but I can’t really say much. Most of this is far over my head. I just make 3D stuff and sell it. I’ve helped to create games, and been the lead on a number of projects, but my knowledge in the realm of code and exactly how everything works is limited. I’ve scanned over the proposal, but I should come back when I have more time to process it.

I’ll just state here where my head is now tho. Although I understand that Philip wants things to be as open as possible, as a creator, I don’t see why asset servers are a problem. I’m not sure if HF is planning on charging a commission on the Marketplace, but if they are, I’d wonder why I would pay them, when I’m hosting my own content. If a good secure system was created, and HF didn’t host it, then it would only be fair for me to pay the host, not HF. I pay for a host now, for content I sell elsewhere for Unity and such, and I’m extremely happy with the service. Ultimately tho, in my mind, HF is running the show, and if they expect me to pay them anything at all, then I expect them to provide the hosting. Just my thoughts tho.


#12

Forgive me for jumping in here again, but I had some more thoughts on this topic. It seems to me that we are going at this wrong. Sitting here, I’ve been asking myself what the key issue is. The key issue is that HF is making us put an FBX in a web address, and it’s an issue because FBX is now the most universal format for models, avatars, and animations. So, what if it was not an FBX? I not saying we should use a different format. What I’m saying is that HF could have their own format, that is based off an FBX. HF could still allow FBX files to be used, but they could also create a converter that makes that FBX special, with not only all the data, but also data specific to HF. Yeah, it won’t make the system full proof, but it also won’t allow someone to just grab the file and drop it into any program, engine, or game. Ok, it’s been a long day, and I’m very sleep deprived, so if this is ignorant, then please forgive me. lol


#13

It is generally a decent idea, however its sorta downed by the fact that we are after all running on open source software, so it wouldn’t take long before model converters just do to a conversion between a Hifi format or another type of format if someone really wanted to aim for that sort of protection: Technically speaking anything you put into any software can be ripped and extracted, Even with Unity or Unreal Engine. There are even tools to rip them straight from memory.

Rather they should focus on supporting as many other format as possible than work on a file format just for Hifi specific (although, with enough support, Hifi model format could solve issues we currently have with FBX due to it being a reverse engineered version of the fbx sdk)

And in ripping of models from games is quite common, and quite simple to do. This is why the steam marketplace monetisation failed: many mods are simply reimports of models from other games.

Generally the rule is anything you put online or in software can be copied in one way or another. All you can do is slow down the process or make it more difficult for people to do so.

However, as the content creator, if you’d catch -anyone- using your models for production and commercial purposes you can easily create a lawsuit or even a class action one if multiple creators have been content has been ripped. Which is why this isn’t done within the game industry that often.

If someone does copy your content and spreads it in Hifi, it should be easier to find out who hosts the assets (even the main service provided that gives the host the server space) and slap a DMCA or EUCD to take down the content; if you really own it: and they couldnt be able to dispute this if you have all the original working files. Its much harder to dispute if you have the actual assets instead of just links to assets.

This sort of method is worse to get caught on because it will damage their own relations with the service provider they host their copied assets on: usually which they pay alot of money to. When you take it down, so do the copies of the product.

But that isn’t the main DRM issue currently within High Fidelity; This currently is in my opinion that anyone with the url can just paste it to show the content anywhere within High Fidelity. Throwing the concept of having the right to do so.

My Solution is within-Hifi specific DRM, so that the host of the asset can decided who can show the asset and where but it doesn’t define who can see and who cant see. It also makes it alot more difficult to download the file via just a regular browser, as you’d have to the keys, and domains the asset and hashes in the head of the web request can be shown in. It however doesn’t solve the issue of people copying models and using elsewhere:** as thats an issue with all engines…**


#14

Yeah, we have already gone over this, but again it’s a mute point, and not a very good argument for not protecting the content. Plus, the ripper you point to only rips the model, not the FBX, which contains much more than just a model. With tools like the 1 you pointed to, the user is actively doing something that they know is wrong, hence why they need the program. Most people are honest and fair people, and the fact that they need a tool keeps most people from actually doing it. With an open web address, you are seemingly begging the users to take the models. Notice how nobody that uses Unity, or Unreal is all that worried about ripping.

There is no reason at all to support more formats. Every 3D software that is used today exports to FBX, and the HF converter I’m talking about only needs to convert FBX.

Ripping models from games is not really a common thing at all. There is no point to it, unless you have a platform to put it on. At best, a fraction of 1% of user would even consider or understand how to do this. Maybe our definitions of common are different tho.

And if you don’t make it easy, then you stop 99% of people from doing it.

Easily? Easy is grabbing a model directly from a webpage, not filing a lawsuit and spending thousands of dollars. It isn’t done within the industry, because everyone with laugh at them and many of the gamers would directly call the company out on it, and get a very bad impression of the company. Actual lawsuits around ripped content are rarely filed.

Again, nobody has time for this, or the money.

Of course, I do not have stats, but I would challenge the notion that ripping content is common, even in the least. Just about the only content you can find on the net, that is ripped from a game, are the most popular characters ever created. This alone shows that it is really a 1 in a million type of thing, not rampid for every game, or every content created. That said, as I pointed out early, the content is useless without a willing platform to use the ripped content on.


#15

@Medhue I do hope you notice that the solution that I did mention does stop 99% from just directly accessing and downloading the file using anything else but the High Fidelity Client or clients based on it:

To work around this Protection you’d have to have the following knowledge and skills:

  • Know what and how HTTP Requests and Headers work
  • Know how to override your browsers HTTP headers / user requests
  • Know what the keys used are (UUID of the Domain, UUID of the owner, Name of the Domain)
  • Know the secret key used by the domain. (which only the Hifi DNS and Domain should know)
  • Know what the keys the asset backend is looking for (is the uuid the owner of the object, domain or both, and whom?)
  • Know what time the request was made and what time the asset server checks for
  • Make sure that the hash of the uuid of the domain (or secret that must be requested from the domain), owner and the time is match for both request and the asset server. This value would be in a constant state of change. Getting a single character in any of the states wrong will mean failure.

All of this assumes that the backend software that hosts the assets is programmed to do these sanity checks and cross check with an API which Hifi could provide us.

Without all these being correct you will get an Access denied, and cannot download, rez or view the model.

For end users, this would work the following:

  • For keypair combination with access (Owner and Domain is correct), model can loaded.
  • Anyone who sees this model will use the Owners key and the Domain to load it. If the ownership or domain is changed so it the keypair, and so will the access.
  • For keypair without access (Owner or/and Domain is incorrect), the model cannot loaded.
  • Anyone who sees this will not also see the model. The model will never resolve loading.

Only side effect I just now though:

  • Anyone who has seen the model once can load it but it is only local and from cache. No one else can see the model, and they will lose it the moment they relog. But this can be resolved with using HTTP headers properly such as using 402, 401, 405, or 406 error codes from servers and hide / remove the objects visibility.

Ofcourse, you could also use a modified “pirate” client + pirate host to download the model (its the only way for the pirate to know the secret key for the domain, that is if the domain even has access to the model in the first place!), similar to how a ripper would work. Its unavoidable but it will happen, but then its the similar case as with the ripper: You have to use other grey/blackhat software to do the extraction of models. So both have their issues


By lawsuits, I do mean just filing DMCAs, no lawsuits result from that other than if they -really- want to compete with the dispute: Usually if no dispute is filed, then the webhost will just bring the content down. And if they do, theyll have to provide RL info.
Webhosts nowdays even allow you to file these reports via electronic forms without -any- costs attached. Enough of complains will shut the websites down (see any TOS of any reputable Webhost) If they bothered to do all of the above to just grab your content, you should have enough time to then file a DMCA: because it will happen. I’ve had to file them a couple of times in SL due to copy-botters.



#16

If your system does what you say, then I don’t see why I’d be against it. Of course tho, I’m barely a script kitty, so I would not know.

As far as DMCAs, it is a terrible system, and if any person just wanted to ruin your business cause of personal disagreement, no DMCA is going to stop that. The process itself is flawed, massively. Yeah, I can file 1, but they can counter, at no cost to them either. Then, the only way is a lawsuit, which most content creators don’t make enough to actually do. So, in reality, the DMCA does almost nothing. If the person doesn’t live in your country, it’s even worse.

I hope you know, I’m not trying to be combative, just trying to hit things from all angles.


#17

Yes I admit you do make good points, as dmcas are not the full answer it all, but copyright law has been needing a update the last quarter of a century. Unfortunately as of the moment its the last line in the sand I see as an attempt of content protection.

Its still healthy to argue as there are flaws that may have been overlooked, in fact I did have to do some iterative improvements to the idea (secret keys) so its not all in vain :wink: but there is always room for improvement.


#18

Good information to consider that you bring up regarding the practicality of enforcing copyright violations.

To go off topic a bit,
I have been thinking about the need for legal disclaimers and terms for domain operators.
It seems prudent to provide indemnity with the same sort of terms as websites. If anyone’s in violation of your rights you could take action.
The question would be with who, and how feasible would this be due to logistical issues in reality?


#19

Such domain software cant fully be bound to them considering the software licenses used.

However HiFiInc could technically bind the terms of use and legalese into the DNS for domain operation, linking, asset client sharing, account and the entire transaction system. That way for you to use your domain server with HiFis network, you must agree with the terms. Without agreeing, no one else can connect through the official client


#20

I’m thinking if someone wanted to run say a scary domain, they may need to add some additional disclaimers.
Also some domains might be made of entirely public domain assets, others might not.
I’m thinking the domain operator will need to state that the assets being used are under license.