[Opensim-dev] Signing content to prevent malicous creator spoofing was "Re: Global identifiers"

Fri Sep 3 03:19:15 UTC 2010

You are quite correct as far as your analysis goes, however what happens
when there are TWO very similar objects/textures/images/whatever?

You can certainly determine that "A" originated from "X" and "B" originated
from "Y", bur there is simply NO way to determine which of the two is the
"genuine original" work.

As a retired IP lawyer I can cite endless case law which is directed at this
question and no one has yet found any "bright line" to determine this -
certainly not with the kind of certainty and clarity that would be required
to actually write code to make this determination!

"A" appears in 100M web site, and "B" only on 5 - does that make "A" the
"genuine original" somehow?

How about the 5 sites being from a history written 100 years ago? The
possibilities are endless.

Then lets talk about the concepts of "fair use" and "scholars exemptions".

I use US law here because I am most familiar with US law, but please believe
that the situation in other countries is very similar because their concepts
of "justice" really boil down to being very similar. The methods and
expression are very different, but the underlying concepts are almost
universal.

Karen

On Thu, Sep 2, 2010 at 5:08 PM, Robert G. Jakabosky
<bobby at sharedrealm.com>wrote:

> Changed subject to reflect new topic, sorry for thread hijacking.  I should
> have started a new thread.
>
> On Thursday 02, Melanie wrote:
> > There is no way to prevent malicious spoofing. Leastways, no easy
> > way that doesn't involve losing data at some point or other. Even
> > keys can't be verified once the original grid has vanished.
>
> Spoofing can be prevented with signing.  People have been using
> public/private
> keys to digitally sign e-mail messages to authentication that the message
> was
> written by them and not changed/written by someone else.  If the original
> grid vanishes then all prims that where created on that grid will have the
> creator name marked with "(unverified)".  Prims only need to be verified
> when
> they are being imported (either from an inventory/region archive or when
> rezed from a foreign user).  If the creator's public key is still available
> and the prim's signature is invalid, then the grid can either deny the
> import
> or clear the creator id.
>
> > We have to accept some things can't be perfect. In the end, you have
> > a gatekeeper. Use it. Allow user only from grids you trust or have a
> > contract with.
>
> Wasn't Hypergrid trying to make it easy for users from any grid to TP to
> any
> other grid (as long as both are Hypergrid enabled)?
>
> > Melanie
> >
> > Robert G. Jakabosky wrote:
> > > On Monday 30, Melanie wrote:
> > >> While you have a case with using a central table, rather than
> > >> storing the URL string, and therefore the name, all over the place,
> > >> your request schema would not work.
> > >>
> > >> First off, it overcomplicates (IMO) things if you even attempt to
> > >> show the current name of an identity. My plan has been to show the
> > >> name AT CREATION TIME on a prim, e.g. the displyed creator name of a
> > >> prim will not change, even if the underlying identity changes their
> > >> name. This removes much complaxity.
> > >>
> > >> Second, your system breaks when a prim is taken to a new grid after
> > >> the grid it was created on has vanished from the internet. In that
> > >> case, even the initial lookup will fail and you have no data to
> display.
> > >
> > > If grids don't verify the Creator URL when receiving a prim from
> another
> > > grid (not the original grid where it was created), then anyone can
> spoof
> > > the prim's creator to be any creator from any other grid.  A spoofer
> > > would only have to create there own Hypergrid enabled region that they
> > > control and make spoofed prims (with griefer content) then hypergrid to
> > > another grid and rez a copy of the spoofed prim there.  Now they can
> > > grief people on other grids and tarnish someone else's name.
> > >
> > > hmm, there might still be a way to spoof the creator of a prim, even if
> > > the "Creator URL" is validated with the grid that creator is from.  How
> > > would Hypergrid validate the original creator for a prim that comes
> from
> > > some other grid?  Lets say a prim is created on grid ABC, then copied
> to
> > > grid XYZ, then copied to grid Acme.  How would the last grid "Acme"
> > > validate the prim's original creator?  It received the prim from a
> third
> > > party grid, which might be run by a spoofer.
> > >
> > > One way to stop spoofing is to add a public/private key to the creators
> > > profile (only the public key would be available to other grids) and
> have
> > > all exported prims be signed with the creators private key.  Then any
> > > grid receiving that prim could verify that the prim hasn't be modified
> > > using the creators public key (which would have to be requested from
> the
> > > "Creator URL").
> > >
> > >> Therefore, I'd prefer to go with my initial recommendation and
> > >> indeed store the URL, including the name, "all over the place". The
> > >> client view can always decide to ignore that part and to a table
> > >> lookup, or even contact the grid of origin.
> > >>
> > >> It seems that a lot of people here are all for omitting information
> > >> that would be helpful for the 90% case in order to make their
> > >> particular corner case the norm. 90% of avatars never change names.
> > >
> > > You can still get most of the speed-up you are looking for with a table
> > > that caches the URL -> display name.  I am not trying to argue against
> > > putting the display name in the URL, just against using it without
> > > verifying it.
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
> --
> Robert G. Jakabosky
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20100902/5e386759/attachment-0001.html>