[Opensim-dev] Global identifiers
Karen Palen
karenpalensl at gmail.com
Thu Sep 2 17:28:02 UTC 2010
More to the point there is simply no way to determine which of two versions
of the object (or whatever) are the genuine "original".
This is an exact analog of web site images today there are all kinds of
schemes which will detect the casual or inadvertent copying, but nothing
which cannot be defeated. thepiratebay.org provides endless examples of
this!
Karen
On Thu, Sep 2, 2010 at 5:34 AM, Melanie <melanie at t-data.com> 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.
>
> 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.
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20100902/4945cd36/attachment-0001.html>
More information about the Opensim-dev
mailing list