[Opensim-dev] Interrelated difficult problems related to asset portability

[Kyle Hamilton]

On Tue, May 27, 2008 at 12:20 PM, Jani Pirkola <jpirkola at gmail.com> wrote:
> Kyle,
>
> Using the viewer to detect copies is an excellent idea! Anyone can hack his
> or her version of the viewer, or even a group of users can use a hacked
> viewer, but there will always be one who isn't.
>
> I also agree that copy prevention will not work, ever. If I see (or hear) an
> asset on my computer, I have  a copy of it already.
>
> My personal vision of how this could be solved is to rely on people's own
> attitudes towards theft. If I could use my viewer to check whether things I
> see are stolen, e.g. I could see red marks on all avatar clothes that are
> stolen, I would not use anything stolen on my own avatar, because people
> would start to think me as a thief. (Oh look, that is the man who stole his
> hat from that poor student girl)

I've turned this idea over and over in my head, and I simply can't
figure out a way to do it -- I'll go into the reasons why in a bit.

> How this could be achieved technically then? I suggest an object hash
> server, where asset content hash value is stored along with the owner and
> the license and permissions to use for those who bought it, for example.
> When I upload some asset to some opensim server, then that opensim server
> would calculcate the hash (and why not to use it as UUID as well to make
> caching work better at client?) and send it to object hash server with
> permissions from the viewer.

I like this idea, and in fact I initially thought about a design like
this... except that it allows for some denial-of-service attacks
against the legitimate owner/legitimate licensees, as well as provides
more incentive to introduce one-bit modifications (so that the content
hashes don't match and thus aren't identified).  As well, and I must
make this point very strongly: it is not the job of the system to
determine what is theft.  That is a determination which can ONLY be
done by the court system.    (DRM tries to define theft, and breaks
Fair Use accordingly.)

As much as we might want to think otherwise, we are not creating a
government or anything which does anything like a government for
virtual worlds.  We /can't/ create a government for virtual worlds.
(Unless we can, but even then, the government must be recognized by
other governments or else its sovereignity won't be acknowledged by
the real-world courts.  This is a discussion FAR outside the scope of
a simple detection mechanism.)

I rather like the idea of a cooperative assethash server which can be
used solely to locate collision-notification URLs, but... well,
remember that we must also operate in a world where collisions can't
(we hope) be easily forced -- but collisions will by necessity
spontaneously occur.  This is why other information (perhaps the
output of other hash algorithms, the content size, and content type)
is important to be compared as well.  This is also why using the hash
as the UUID directly is inadvisable, because if two different bits of
content exist with the same hash, either the older or the newer one is
going to get removed from the network.

(Really, if you're distilling arbitrarily-large sets of data down to
128 bits, you're *going* to have collisions. :))

The mandatory imposition of a cooperative assethash server, though,
would seriously degrade network performance on most machines.  This is
what I'm most leery about, related to it.

There are situations where multiple people do have independent right
to sell or distribute precisely the same content without needing
permission of any of the other copyright holders.  Why should the
first one to get the drop on the network get the Sanctioned Right?
How can the system know that the first copy on the network is actually
legitimately there?

> The object hash servers would be hosted by organizations we trust
> (realXtend? LL? Verizon?), and they would have a network of trust in between
> them. The object hash servers should of course also replicate data back and
> forth to make sure that all the asset rights are correctly updated.

You're going, once again, down the DRM road.  "asset rights" are what
"Digital Rights Management" systems are supposed to manage.  The only
thing that can arbitrarily determine what the rights are and who owes
whom money is the court.  Not the system (by which I refer to the
system of viewers and sims and servers).

The system cannot manage the rights.  The system cannot judge what the
rights are.  The system cannot judge whether something is a copyright
violation.  The system cannot judge whether something is authorized or
not.

The system doesn't know whether something is creative-commons, whether
something is public-domain, whether something is GPL, whether
something is all-rights-reserved.  The system doesn't transmit enough
(cryptographic) evidence of licensure to be able to make any decision.
 The system doesn't know whether the initial uploader is telling the
truth about the license that the work is supposed to be under (for
example, look at the PDF e-books of various public domain things that
Adobe put out that put use restrictions on, such as 'no copying text'
and 'no speaking text'.  The system can't determine whether any given
use is in compliance with any given license.  The system doesn't know
whether the initial uploader is truly the one who is supposed to have
the copyright in the first place.  With all these unknowns, it's
absolutely foolhardy to assume anything about any rights that any
party may have, and I'm rather unenthused about propagating that
error.

> This does not need necessarily any modifications to the SL Viewer itself,
> there could be a separate tool  (e.g. a copyrightbot as Diva suggested) to
> make check on a place or avatar first and when the system comes widespread
> enough, maybe it could be built in to SL Viewer as well.
> realXtend viewer could support that from the beginning.

er, you just said that the viewer /is/ the correct place to do it, and
now you're saying it doesn't need to?  Remember, the viewer is the
only thing that does cross the grid boundaries.  If we rely on grid
operators to connect to the network solely for the purposes of
copyright notification for purposes of changing their users'
experiences, you can bet that they won't and that they'll disable the
system entirely.

Also remember that grids operated as intentional communities are not
likely to allow a copyright bot to scan their stuff... and under the
current legal regime, they don't have to.

See, the changes that are necessary to get the viewer to do most of
the work are relatively miniscule.  They're also able to be done
/now/, not waiting until "the system comes widespread enough".  They
rely simply on calculating content hashes of and collecting a bit of
metadata about assets seen.

The changes necessary on the server and in the protocol are extremely
simple: they rely on the addition of some metadata fields to the asset
database, including a "squawker URL" and various content hash fields
(calculated on upload, and verified by the client on download).

The application necessary for the squawk-listener requires an XML-RPC
or JSON parser and defined schema for the notification format.

> Also, Kyle's suggestion that the viewer reports abuse of copyrighted
> material is easy to implement in this scenario. His point that even there
> were a hacked client available without that copyrighted material detection,
> there would always be someone with a non-hacked version can be used as vice
> versa: Even if standard SL Viewer didn't have the copyright violation
> reporting feature, always someone would be using a viewer which includes
> that!

I'm trying to find a way to get into the engineering and business
development aspects of Linden, to pitch the case for including
asset-collision detection into the Linden viewer and the main Linden
protocol.  It's a relatively minimal change, as I've said.  I'm still
looking at potential security issues (including information-leakage
vulnerabilities, DOS attacks against the squawk-listener, DOS attacks
against the viewer, DOS attacks against the network, DOS attacks
against the assethash servers, etc) before I make a formal proposal.

(I tend to be somewhat libertarian/conservative when it comes to
making systems small and workable.  I don't want to have to pass new
laws to get something to work.  I don't want to waste money or time
designing something that reduces capability.  I don't want to damage
anyone's online experience.  I don't want to impose Yet Another
Limitation.  I just want to do my part to ensure that people who have
intellectual property rights under the current regime can have a bit
of help in reaping the benefits of their work.)

> That kind of system could be done by OpenSim and it would be taken into use,
> given that someone with enough trust takes the hosting of the first object
> hash server.

The way to reduce crime is not to increase the penalty... but to
increase the risk of detection.  The way to reduce antisocial behavior
is to increase enforcement and inconvenience when the detection is
enforced.

Honestly, I can even see a way for this to work even without an
"object hash server", and increase participation among asset servers
to boot... use a distributed hash table like Kademlia (or one of the
C#-language implementations of DHTs) to query for the assethash,
collect all the answers and pull out the squawker URLs, and then
squawk to all of them.

But, I must make you aware of two trends that I have seen.

If you try to use the server to change-degrade the users' experiences,
the server will disable that functionality.
If you try to use the viewer to change-degrade the user's experience,
the user will disable that functionality.

The only way for this system to work is to not degrade the users'
experiences.  That's the only way to get users not to turn off the
degradation.  (And if you try to enforce it, and mandate it, the only
thing you'll end up with is hacked viewers with the degradation turned
off.)

-Kyle H

>
> Best regards,
> Jani Pirkola
> realXtend program manager
>
> 2008/5/27 Antti Ilomäki <antti.ilomaki at adminotech.com>:
>>
>> Kyle H: "From where to where would the authentication traffic run?  What
>> would
>> interpret it?  What would make the policy decision to show it?  What
>> would decide whether to follow the policy decision handed down from
>> on-high?"
>>
>> Note that I'm by no means a data security expert and I'll gladly leave
>> technical questions to someone else. That's one of the reasons I'm so
>> interested in discussing these things in public.
>>
>> Anyway, There would be two separate parties making the policy decisions:
>> the server and the client. In this scheme knowledge on assets to be
>> downloaded would probably have to pass through servers, because the server
>> administrators would probably want to influence what their visitors see.
>> Then the client would have some controls to restrict display of assets if
>> the user (or more likely his parents) wants to. Like you (and I think me
>> too) said, the client is easy to hack and trying to add strict protection
>> schemes there would probably prove fruitless. The authentication traffic
>> would most likely run between the world servers and authentication stuff
>> servers, but also to the client. I'm not the person to design the details,
>> however, hopefully someone can come up with good ideas.
>>
>> "What about assets with legitimate copyright confusion?"
>>
>> Can you be more specific?
>>
>> "What about attempted denial-of-service by hacking the authentication
>> system?"
>>
>> DoS attacks are a potential problem for any network service, do you see
>> potential problems specifically for the authentication of inventory assets?
>>
>> "What if someone gets a leaked bitwise copy of an asset, uploads it to
>> and registers it with the authentication service, and prevents the
>> legitimate owner of the asset from registering it?"
>>
>> Getting bitwise copies of an asset can't really be prevented or even made
>> very difficult AFAIK. That's why I'm more interested in controlling their
>> visibility over the net. If someone got a pirate bitwise copy somewhere on
>> the net it's likely that the original object would already be registered in
>> the authentication service and re-registering the same asset would likely
>> fail. An interesting question is the building phase when the objects aren't
>> finished yet, but if there's enough interest there's probably a workaround
>> for that as well. Perhaps something like version history for objects or so
>> on, I don't know. Note that especially professional content creation can be
>> done behind protective walls and the object can be registered on
>> authentication lists before it ever appears in the public virtual web.
>>
>> "What if some grid chooses, for these or other (perhaps more nefarious,
>> perhaps more practical -- such as overloading and very poor response)
>> reasons, not to run the authentication traffic?"
>>
>> Well there's really quite little anyone can do about it - pretty much the
>> only thing would be to make the authentication as lightweight and seamless
>> as possible so that there would be no technical reasons to turn it off. Some
>> sites would of course still turn it off, but the really important thing is
>> to have all or at least a vast majority of the most popular sites to utilize
>> the protection scheme. The reason they might actually want to do it is their
>> somewhat probable involvement in item trading or (virtual) money
>> transactions in general. Content creation business and virtual world (and
>> other services) subscription business are interconnected; more people means
>> there's a bigger market for content, which in turn means more interesting
>> stuff to see and do for the users, which in turn means there will be more
>> users.
>>
>> "I must simply reiterate what I've said before... DRM simply does not
>> work.  DRM relies on all parties except the end-user (you know, the
>> entity that everyone is most concerned about) cooperating to restrict
>> access.  Independent VWs don't want to damage their users'
>> experiences, so they're unlikely to want to cooperate, and without
>> their cooperation there's no chance of implementing any kind of DRM
>> solution."
>>
>> In my opinion the record and games industries, for example, are going the
>> wrong way by trying to charge you money for a product that is inferior to
>> what you get for free if you resort to piracy. The best way to entice
>> customers to pay for their music is to make purchases extremely simple and
>> offer extra service such as automatic backup system in addition to the
>> actual files being as easy to use as a pirated mp3.
>>
>> The difference between the virtual assets and music, for example, is at
>> least two-fold. First of all, virtual assets are almost exclusively used
>> over the internet. This gives options for determining copying and access
>> wirghts on the fly. Secondly, Virtual worlds ARE the digital content and
>> creating systems that can be used to set rules and bring a level of security
>> not only for the assets but also site owners and users, would probably have
>> a positive effect on the business as a whole.
>>
>>
>> "DRM relies on "keeping secrets".  The core secret is "the asset
>> content to be displayed".  And, Benjamin Franklin put it best: "Three
>> may keep a secret, if two are dead."  An authentication system would
>> simply offload the task of who makes the decision to keep the secret,
>> not do anything more to keep the secret in place."
>>
>> Well it depends. If the future of the virtual web would actually involve
>> something like the system I described there would be little need for
>> secrets. The thing you would have to do to use pirated goods would be to
>> hack a server and insert your ID on the authorized users' list for the
>> specific object. If the security of the server was any good, that would be
>> quite a bit more complex than downloading an mp3 through bit torrent or
>> something similiar.
>>
>> Another hurdle for the pirates might be a check in the Official 3D
>> Internet browser (the realXtend one, naturally) that would prevent any
>> transactions in a zone that doesn't have content protection on. There's
>> actually need for some kind of a security system anyway, similiar to web
>> certificates and so on, to create a level of security for the entire
>> experience AND communicate it to the users, so that they feel confident
>> enough to make purchases and let the virtual content business flourish.
>>
>> In fact one of the good things about virtual reality is the fact that when
>> the user is logged in, he/she most likely has some kind of a payment system
>> ready to go, be it LindeX, PayPal or whatever. Ths would completely remove
>> the hurdle of digging out your credit card and giving personal info to some
>> site on the net to be able to pay for the goods. This would, of course,
>> remove one hurdle from the legitimate customer's road to enjoying the
>> purchase, making legitimate goods more competitive with the pirated stuff.
>>
>> Although probably not the most decisive issue for legitimate customers,
>> but not having t ofeel stupid for paying something most others are using for
>> free is sort of a service as well. The really important thing is making sure
>> that the content creation business is a huge success and there's plenty of
>> exciting stuff for everyone to enjoy. Ensuring that will be important for
>> the success of the virtual reality, especially in the near future and if
>> this DRM scheme can help, it's worth considering.
>>
>> "And if you want to rely on the viewer to run it?  Someone's going to
>> hack the viewer to avoid authentication, and distribute their hacked
>> viewer."
>>
>> Well I wouldn't want to rely on the viewer doing anything the user doesn't
>> want to. The integration of DRM features to the viewer would probably be in
>> the form of parental locks and such.
>>
>> "I've been trying to find a way to design a system that doesn't rely on
>> making bits harder to copy.  I've been trying to find a way to design
>> a system that doesn't rely on some arbitrary third party making
>> decisions.  I've been trying to find a way for evidence to be
>> collected that would be sufficient to satisfy the only
>> currently-authorized-by-law third party (the court system), and then
>> only in situations where it's been specifically asked to intervene."
>>
>> Sounds interesting. The thing to remember is that there probably never
>> will be a foolproof system, we're always talking about percentages.
>> Personally I don't think making bits harder to copy would raise the
>> percentage of legitimate customers very much, but I don't have any
>> statistics here and who knows, maybe the entertainment industry earns a
>> couple of bucks by using copy protections systems?
>>
>> Court system and virtual worlds is an interesting issue. One of the
>> problems with copyright stuff and global networks is the difficulty of
>> across the borders -co-operation and lack of internationally useful laws.
>> But that's a huge issue in itself, althoug han important one, laws can bring
>> about an atmosphere of trust and security, which is usually good for
>> business.
>>
>> "The entire VW community, and the entire Internet community, has been
>> designing things at odds with the current legal regime since its dawn.
>> We've seen the courts reach in and mandate things, and our tools have
>> been extremely unsuited to the task of compliance.  I'd much prefer to
>> have a design on the table that satisfies all the compliance issues in
>> a way that is easily understood.  I'd much prefer to have a design on
>> the table that stops viewing the end-user as an entity to be feared
>> solely because they can take what they're shown and change themselves
>> from 'end-user' to 'content presenter' without authorization of the
>> owner of the content they're presenting.  I'd like to move away from
>> any attempt to mandate content handling, and instead cooperate with
>> the end-user to identify locations where unauthorized copies of
>> content are distributed from, and leverage those to reduce the content
>> misappropriation."
>>
>> One of the problems with virtual worlds is that they're difficult to
>> understand for the parties that handle legislation and hold political power.
>> So far we've seen pretty negative press from a couple of cases, and that's a
>> problem for the young industry. Virtual worlds haven't been established as a
>> necessity for life and business like the Internet, and are thus a much
>> easier target for fishing concerned parents' votes for the next election.
>> Again, if we want the industry to blossom in the near future, we have to
>> consider all sorts of issues and hopefully solve them in a way that suits
>> everyone. Or at least someone.
>>
>> "This is why I want the viewer to be cooperative in a way that doesn't
>> damage the end-user's experience.  I realize I'm in the minority...
>> but I'm sick of being treated like something less than a dignified
>> human being.  I'm sick of being treated like a criminal.  I'm sick of
>> my money going toward systems that prevent me from using what I've
>> licensed."
>>
>> I don't disagree.
>>
>>
>> Antti Ilomäki
>> antti.ilomaki at adminotech.com
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>