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

[Kyle Hamilton]

I believe that this does actually need to be in the end-user viewer,
simply because users create their own intentional communities.  The
larger/more egregious of these communities are more likely to have at
least one person using the official viewer without covering
tracks/preventing the squawk.  No community is likely to let a random
bot in to scan inventory periodically.

Really, since everyone must use a viewer, and you don't want to add
new message types to be blocked by a proxy, and the workability of the
entire system depends on as many eyes as possible keeping watch...
well, I can't think of any local place for this that will work but the
viewer.

As well, it would have to be completely transparent/invisible to the
user (obviously assented to in the viewer license agreement, but
otherwise doing no harm).

For optimization, the hashes could be preconputed by the server and
sent along with the asset; this would also provide a means of
identifying network data corruption between the viewer and region if
such ever came into question.

As for correlation overhead... what's the difficulty of determining if
a given key (the asset hash) already exists in a given hash bucket?

-Kyle H

On Thu, May 22, 2008 at 8:32 PM, Diva Canto <diva at metaverseink.com> wrote:
> Interesting idea.
> But you don't need to place this in people's viewers. The viewer would incur
> in a big performance penalty to correlate assets.
>
> However, what you're proposing suggests a monitoring system that could be
> achieved by other means, for example, by using libsl to develop a system
> specifically designed for detecting asset clones. (Clone detection is a cool
> nerdy thing to do for lots of purposes :-)
>
> In other words, there's an opportunity for developing crawlers that roam
> around looking for specific items that people want to protect. It would be
> the good twin sister of copybot, let's call it copyrightbot :-)
>
> This monitoring can be done on the web too, but I guess people don't bother
> to do it. In virtual worlds, they might bother to do it, because there may
> be people willing to pay. Maybe. There's certainly a [small] market for
> clone detection in source code and other artifacts that are time-consuming
> to produce.
>
> Yeah, this might be a reasonable way of addressing this issue. Much more
> doable than DRM.
>
> -----Original Message-----
> From: opensim-dev-bounces at lists.berlios.de
> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Kyle Hamilton
> Sent: Thursday, May 22, 2008 5:40 PM
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] Interrelated difficult problems related to asset
> portability
>
> The idea is basically an outgrowth of the "many eyes make bugs
> shallow" concept... since viewers/clients are the ones that actually
> get the data to display (assetservers stream to regionservers, which
> stream to viewers), the viewers are the ones in the perfect position
> to identify infringements.
>
> If the same asset data shows up in two different places under two
> different UUIDs, a client that has seen both will know it.  If
> metadata is available for those UUIDs (including 'if you see a
> duplicate, please send the UUID and the region you're connected to, as
> well as the hashes that you know how to generate on the data, to this
> URL' squawker addresses), then the client can simply notify all
> squawker addresses associated with all the UUIDs and grid/locations of
> the duplicate asset data.
>
> Some of this will be licensed use.  Some will not be.  However, it
> makes it possible for copyright owners to know where things are, and
> determine if it's worth sending a C&D or filing a full lawsuit over.
> (i.e., it makes it much more possible for the copyright owner to
> determine when his/her rights have been infringed, which makes it
> possible to use pre-DMCA copyright contours to litigate/enjoin/recover
> from.)
>
> It relies on code being put into the viewer.
> It relies on code being put into the server.
> It relies on additional fields being put into the inventoryserver.
> It relies on modification of the asset-retrieval protocol.
>
> It can't really happen without the cooperation of Linden, because
> Linden writes and distributes the official viewer.  Most people don't
> compile their own viewers, so the 'official' viewer (with the squawker
> behavior compiled in) becomes the default, and when someone who uses
> the official viewer goes to a private grid where there's a lot of
> infringement going on it all comes out.
>
> It also can't detect non-bit-perfect copies.  (unless, say, animation
> data was parsed and then deparsed, and the hashing done on the
> deparsed rendition of the data.  But that ignores the ideas of the
> primitives and the textures involved.)  This is, by the by, why DRM is
> very bad for this scheme -- if two people unwrap DRMed data via the
> analog hole, it's not going to be a bit-perfect copy.
>
> But regardless, there's additional things that can be done with this
> idea -- such as Google or other content indexers, squawking on content
> they see multiple times at multiple URIs.
>
> And in any case, it's certainly a lot more than we've got now.
>
> -Kyle H
>
> On Thu, May 22, 2008 at 5:12 PM, dan miller <danbmil99 at yahoo.com> wrote:
>>> Next, the problem of asset ownership.  DRM is a long, dark,
>>> ugly road
>>> to nowhere; however, this does not mean that nothing can be
>>> done.  I have an idea
>> ...
>>> I'll be writing another email on this.
>>
>> do tell!
>>
>> -danx0r
>>
>> _______________________________________________
>> 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
>