You are quite correct as far as your analysis goes, however what happens when there are TWO very similar objects/textures/images/whatever?<br><br>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.<br>
<br>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!<br>
<br>"A" appears in 100M web site, and "B" only on 5 - does that make "A" the "genuine original" somehow?<br><br>How about the 5 sites being from a history written 100 years ago? The possibilities are endless.<br>
<br>Then lets talk about the concepts of "fair use" and "scholars exemptions".<br><br>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.<br>
<br>Karen<br><br><div class="gmail_quote">On Thu, Sep 2, 2010 at 5:08 PM, Robert G. Jakabosky <span dir="ltr"><<a href="mailto:bobby@sharedrealm.com">bobby@sharedrealm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Changed subject to reflect new topic, sorry for thread hijacking.  I should<br>
have started a new thread.<br>
<br>
On Thursday 02, Melanie wrote:<br>
> There is no way to prevent malicious spoofing. Leastways, no easy<br>
> way that doesn't involve losing data at some point or other. Even<br>
> keys can't be verified once the original grid has vanished.<br>
<br>
Spoofing can be prevented with signing.  People have been using public/private<br>
keys to digitally sign e-mail messages to authentication that the message was<br>
written by them and not changed/written by someone else.  If the original<br>
grid vanishes then all prims that where created on that grid will have the<br>
creator name marked with "(unverified)".  Prims only need to be verified when<br>
they are being imported (either from an inventory/region archive or when<br>
rezed from a foreign user).  If the creator's public key is still available<br>
and the prim's signature is invalid, then the grid can either deny the import<br>
or clear the creator id.<br>
<br>
> We have to accept some things can't be perfect. In the end, you have<br>
> a gatekeeper. Use it. Allow user only from grids you trust or have a<br>
> contract with.<br>
<br>
Wasn't Hypergrid trying to make it easy for users from any grid to TP to any<br>
other grid (as long as both are Hypergrid enabled)?<br>
<br>
> Melanie<br>
><br>
> Robert G. Jakabosky wrote:<br>
> > On Monday 30, Melanie wrote:<br>
> >> While you have a case with using a central table, rather than<br>
> >> storing the URL string, and therefore the name, all over the place,<br>
> >> your request schema would not work.<br>
> >><br>
> >> First off, it overcomplicates (IMO) things if you even attempt to<br>
> >> show the current name of an identity. My plan has been to show the<br>
> >> name AT CREATION TIME on a prim, e.g. the displyed creator name of a<br>
> >> prim will not change, even if the underlying identity changes their<br>
> >> name. This removes much complaxity.<br>
> >><br>
> >> Second, your system breaks when a prim is taken to a new grid after<br>
> >> the grid it was created on has vanished from the internet. In that<br>
> >> case, even the initial lookup will fail and you have no data to display.<br>
> ><br>
> > If grids don't verify the Creator URL when receiving a prim from another<br>
> > grid (not the original grid where it was created), then anyone can spoof<br>
> > the prim's creator to be any creator from any other grid.  A spoofer<br>
> > would only have to create there own Hypergrid enabled region that they<br>
> > control and make spoofed prims (with griefer content) then hypergrid to<br>
> > another grid and rez a copy of the spoofed prim there.  Now they can<br>
> > grief people on other grids and tarnish someone else's name.<br>
> ><br>
> > hmm, there might still be a way to spoof the creator of a prim, even if<br>
> > the "Creator URL" is validated with the grid that creator is from.  How<br>
> > would Hypergrid validate the original creator for a prim that comes from<br>
> > some other grid?  Lets say a prim is created on grid ABC, then copied to<br>
> > grid XYZ, then copied to grid Acme.  How would the last grid "Acme"<br>
> > validate the prim's original creator?  It received the prim from a third<br>
> > party grid, which might be run by a spoofer.<br>
> ><br>
> > One way to stop spoofing is to add a public/private key to the creators<br>
> > profile (only the public key would be available to other grids) and have<br>
> > all exported prims be signed with the creators private key.  Then any<br>
> > grid receiving that prim could verify that the prim hasn't be modified<br>
> > using the creators public key (which would have to be requested from the<br>
> > "Creator URL").<br>
> ><br>
> >> Therefore, I'd prefer to go with my initial recommendation and<br>
> >> indeed store the URL, including the name, "all over the place". The<br>
> >> client view can always decide to ignore that part and to a table<br>
> >> lookup, or even contact the grid of origin.<br>
> >><br>
> >> It seems that a lot of people here are all for omitting information<br>
> >> that would be helpful for the 90% case in order to make their<br>
> >> particular corner case the norm. 90% of avatars never change names.<br>
> ><br>
> > You can still get most of the speed-up you are looking for with a table<br>
> > that caches the URL -> display name.  I am not trying to argue against<br>
> > putting the display name in the URL, just against using it without<br>
> > verifying it.<br>
<div class="im">><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<br>
<br>
<br>
</div>--<br>
<font color="#888888">Robert G. Jakabosky<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br>