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

[dan miller]

this is such an important topic, and I think Kyle has focused on a really important point: the technology cannot be the enforcer, but it can be the whistleblower.

DRM is doomed for reasons too innumerable to repeat, and all too obvious to anyone who understands the technology and a bit about human nature.  However, allowing clients to *voluntarily* inform apparent IP owners of possible violations is both doable and, to my mind, a good idea.  

My question for Kyle is this however: aren't you potentially opening a pandora's box of privacy concerns?  You are basically encouraging a community of tattletales, who whisper to the powers that be any time they think they see a copyright violation.  There's something vaguely disquieting about the ramifications of such a world, even though I think it may be preferable to a locked-down shackled DRM world.

-danx0r


--- On Tue, 5/27/08, Kyle Hamilton <aerowolf at gmail.com> wrote:

> From: Kyle Hamilton <aerowolf at gmail.com>
> Subject: Re: [Opensim-dev] Interrelated difficult problems related to asset portability
> To: opensim-dev at lists.berlios.de
> Date: Tuesday, May 27, 2008, 6:32 PM
> 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
> >
> >
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev