[Proposal] Expanded Grid Info Availability

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Proposal] Expanded Grid Info Availability

Haravikk
This is a subject very much related to my topic on IP and region validation, and the proposal is very simple; the idea is to make it easier to find out which grid an object or avatar belongs to, as this is useful for a variety of reasons.

It's already possible to get this information with some os*() functions, but they have a current threat level of Low or Moderate, placing them above the default of VeryLow and thus preventing them from being widely available. However, I'm not convinced that the threat level of these functions actually needs to be so high, as the information can be obtained by other means, it just seems like an unnecessary restriction on scripts. You can view the full proposal here:
http://opensimulator.org/wiki/User:Haravikk_Mistral/ExpandedGridInfoAvailability


I'm interested in feedback about which functions should/should not have their threat level downgraded, and also about my proposed addition of a header on llHTTPRequests() that identifies the grid.

In discussion on IRC there was a question raised about privacy, particularly tracking between grids, but I'm not sure this is a problem; currently hyper grid travels works on the assumption that an avatar's UUID is unique, which scripts are free to do as well, in which case they are already able to track an avatar fairly reliably if they want to. Thing is though, to do this they'd need to have an external service in common, and devices spread about widely enough across different grids to get any kind of meaningful tracking, and even then, what can be done with this information is fairly limited. Knowing what a user's home-grid is won't make this any easier; the only difference is that with knowledge of the grid you can be certain there is no cross-grid UUID collision (i.e- UUID uniqueness is a bit less uncertain), it opens up no real capabilities to track avatars that I can see, and there are better ways to prevent tracking that could be implemented if it were a problem.

However, the advantage of having this information more readily available is that it becomes possible for in-world devices to handle avatars differently depending upon whether they are from the current grid or not. It would also, crucially for me, make handling of data on a web-service much easier, as it becomes possible to easily partition data by the grid it belongs to, and to handle crossover (i.e- travelling avatars) more intelligently.
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal] Expanded Grid Info Availability

David Saunders-2
Hey,

   Some good idea :)

     I am with a large active grid,  We have gotten 80+ avatars at events,
and yes it strains the code.  But seeing it work is great. We run about 100
simulators with 1 region each.  And we have split the grid services(robust)
between the public, what s is needed to service the client, and the private
 ports to service the simulators.  And the grid is consider private, and we
don't get the rouge regions connecting. Oh, before going on I will say the
strain is on the code and not the computers, The barely pass 25% usage.

 Ok, wit that any query for information should be throttled somehow, you
can count on the client to cache it.  The easy way is just make a cached
web service to handle the calls, offloading the simulator or rubust from
handling it.  This function can be written in only a few lines.

 One thing that might be nice is the ability to add more X headers in the
config file. (I never needed it to be added before but can think of some
need for it ) .  This way in the future when grid ops need another x-header
they don't have to crack open the code and modify.

UUIDs across grids would be nice except for who will control it? And who
will keep it from being polluted?   It also will put a new overhead on the
robust, for each object gets it own UUID, each copy of its own. So think of
having 10 avatars, building a region, each putting down a object in the
region. The region would have to call the central resource, could call
 100/min easy, Then put in an active grid, we can have 20-30 people
building across the grid at once.  If we have to make an internet call to a
server , would add a new bottle neck into the cog of things.

I would think the hyoernet people would of resolved this to some extent.
And we can be happy filling up out asset server with all our little
objects. (7,000,000+ for 1600 avatar)

So, a work around for this would be talk to the grid operators about adding
a properly written php script to run on the web server that will allow read
access to the regions table.  To do the following functions:

1> Do I have a region  on this host name / IP
2> Is this 'Region Name' on this host/ip

 you can implement immediately.
    Just watch out for the snag of reverse dns may return the wrong host
name.  You cant count on a few host names, osgrid can have many 100's and a
simple grid can have 1 or 2.
 on our grid all the hosts are names and not IPs in the region table, And
should reverse back to us EXCEPT for remote hosted simulators  :)   So, can
be bit confusion on what you need to do.


David.




On Mon, Jul 31, 2017 at 9:49 AM, Haravikk <[hidden email]> wrote:

> This is a subject very much related to my topic on IP and region
> validation, and the proposal is very simple; the idea is to make it easier
> to find out which grid an object or avatar belongs to, as this is useful
> for a variety of reasons.
>
> It's already possible to get this information with some os*() functions,
> but they have a current threat level of Low or Moderate, placing them above
> the default of VeryLow and thus preventing them from being widely
> available. However, I'm not convinced that the threat level of these
> functions actually needs to be so high, as the information can be obtained
> by other means, it just seems like an unnecessary restriction on scripts.
> You can view the full proposal here:
> http://opensimulator.org/wiki/User:Haravikk_Mistral/
> ExpandedGridInfoAvailability
>
>
> I'm interested in feedback about which functions should/should not have
> their threat level downgraded, and also about my proposed addition of a
> header on llHTTPRequests() that identifies the grid.
>
> In discussion on IRC there was a question raised about privacy,
> particularly tracking between grids, but I'm not sure this is a problem;
> currently hyper grid travels works on the assumption that an avatar's UUID
> is unique, which scripts are free to do as well, in which case they are
> already able to track an avatar fairly reliably if they want to. Thing is
> though, to do this they'd need to have an external service in common, and
> devices spread about widely enough across different grids to get any kind
> of meaningful tracking, and even then, what can be done with this
> information is fairly limited. Knowing what a user's home-grid is won't
> make this any easier; the only difference is that with knowledge of the
> grid you can be certain there is no cross-grid UUID collision (i.e- UUID
> uniqueness is a bit less uncertain), it opens up no real capabilities to
> track avatars that I can see, and there are better ways to prevent tracking
> that could be implemented if it were a problem.
>
> However, the advantage of having this information more readily available
> is that it becomes possible for in-world devices to handle avatars
> differently depending upon whether they are from the current grid or not.
> It would also, crucially for me, make handling of data on a web-service
> much easier, as it becomes possible to easily partition data by the grid it
> belongs to, and to handle crossover (i.e- travelling avatars) more
> intelligently.
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal] Expanded Grid Info Availability

Haravikk

> On 1 Aug 2017, at 17:28, David Saunders <[hidden email]> wrote:
>
> One thing that might be nice is the ability to add more X headers in the
> config file. (I never needed it to be added before but can think of some
> need for it ) .  This way in the future when grid ops need another x-header
> they don't have to crack open the code and modify.

That's a neat idea, I can certainly look into adding that at the same time!

> UUIDs across grids would be nice except for who will control it? And who
> will keep it from being polluted?   It also will put a new overhead on the
> robust, for each object gets it own UUID, each copy of its own. So think of
> having 10 avatars, building a region, each putting down a object in the
> region. The region would have to call the central resource, could call
> 100/min easy, Then put in an active grid, we can have 20-30 people
> building across the grid at once.  If we have to make an internet call to a
> server , would add a new bottle neck into the cog of things.

I'm not proposing to introduce true GUIDs; in fact part of the idea behind making the grid address more easily available is that it would eliminate the need to do so, as you can easily resolve conflicts by comparing grids.

i.e- if your device(s) encounter two avatars with the same key, but different grid addresses, then you can treat them as different if you want to.

It is however an area I've thought a bit about, but as you say, a challenging one technically as the last thing anyone wants to have to have some complex cross-grid communication going on. My main concern is just in making sure I know two UUIDs are either definitely the same, or probably not, anything beyond that does get pretty complicated!

> you can implement immediately.
>    Just watch out for the snag of reverse dns may return the wrong host
> name.  You cant count on a few host names, osgrid can have many 100's and a
> simple grid can have 1 or 2.
> on our grid all the hosts are names and not IPs in the region table, And
> should reverse back to us EXCEPT for remote hosted simulators  :)   So, can
> be bit confusion on what you need to do.

Any idea why they're stored that way? I suppose it might smooth out some issues for simulators with dynamic IPs and such?

I'd hoped not to have to do anything involving database modification, as storing IP alongside dns name could be awkward to keep up to date.

A possible alternative would be to have the simulator also send its dns name as another header; this way the server can just do a regular (forward) DNS lookup, which is faster and more reliable and confirms the IP of the request before sending any query to the grid. If that's how the grid stores region addresses then it'll be the easiest way to handle the query.

> On Mon, Jul 31, 2017 at 9:49 AM, Haravikk <[hidden email]> wrote:
>
>> This is a subject very much related to my topic on IP and region
>> validation, and the proposal is very simple; the idea is to make it easier
>> to find out which grid an object or avatar belongs to, as this is useful
>> for a variety of reasons.
>>
>> It's already possible to get this information with some os*() functions,
>> but they have a current threat level of Low or Moderate, placing them above
>> the default of VeryLow and thus preventing them from being widely
>> available. However, I'm not convinced that the threat level of these
>> functions actually needs to be so high, as the information can be obtained
>> by other means, it just seems like an unnecessary restriction on scripts.
>> You can view the full proposal here:
>> http://opensimulator.org/wiki/User:Haravikk_Mistral/
>> ExpandedGridInfoAvailability
>>
>>
>> I'm interested in feedback about which functions should/should not have
>> their threat level downgraded, and also about my proposed addition of a
>> header on llHTTPRequests() that identifies the grid.
>>
>> In discussion on IRC there was a question raised about privacy,
>> particularly tracking between grids, but I'm not sure this is a problem;
>> currently hyper grid travels works on the assumption that an avatar's UUID
>> is unique, which scripts are free to do as well, in which case they are
>> already able to track an avatar fairly reliably if they want to. Thing is
>> though, to do this they'd need to have an external service in common, and
>> devices spread about widely enough across different grids to get any kind
>> of meaningful tracking, and even then, what can be done with this
>> information is fairly limited. Knowing what a user's home-grid is won't
>> make this any easier; the only difference is that with knowledge of the
>> grid you can be certain there is no cross-grid UUID collision (i.e- UUID
>> uniqueness is a bit less uncertain), it opens up no real capabilities to
>> track avatars that I can see, and there are better ways to prevent tracking
>> that could be implemented if it were a problem.
>>
>> However, the advantage of having this information more readily available
>> is that it becomes possible for in-world devices to handle avatars
>> differently depending upon whether they are from the current grid or not.
>> It would also, crucially for me, make handling of data on a web-service
>> much easier, as it becomes possible to easily partition data by the grid it
>> belongs to, and to handle crossover (i.e- travelling avatars) more
>> intelligently.
>> _______________________________________________
>> Opensim-dev mailing list
>> [hidden email]
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal] Expanded Grid Info Availability

David Saunders-2
Hey,

 I can assume it is because that how the region registers itself :) It does
send the IP to the client tho.  :)  And we have had dynamic IP hosting our
sims at one time, We would have to reload the firewall when it changed. And
then it works :) But this is because we white-list simulators to our grid.

I was looking at some ideas from
http://opensimulator.org/wiki/Category:OSSL_Functions , but the problem is
how are you going to know the correct verification URL, if the regions
tells you what it is?   Only way if you start with a verified URL.  The
script it self can find out what grid its on. So you really need to know
the grid has set up this check for you to have any kind of confidence in
having the script tell where it is :)  You can send the info needed by the
script.



 DAvid.





On Tue, Aug 1, 2017 at 5:00 PM, Haravikk <[hidden email]> wrote:

>
> > On 1 Aug 2017, at 17:28, David Saunders <[hidden email]> wrote:
> >
> > One thing that might be nice is the ability to add more X headers in the
> > config file. (I never needed it to be added before but can think of some
> > need for it ) .  This way in the future when grid ops need another
> x-header
> > they don't have to crack open the code and modify.
>
> That's a neat idea, I can certainly look into adding that at the same time!
>
> > UUIDs across grids would be nice except for who will control it? And who
> > will keep it from being polluted?   It also will put a new overhead on
> the
> > robust, for each object gets it own UUID, each copy of its own. So think
> of
> > having 10 avatars, building a region, each putting down a object in the
> > region. The region would have to call the central resource, could call
> > 100/min easy, Then put in an active grid, we can have 20-30 people
> > building across the grid at once.  If we have to make an internet call
> to a
> > server , would add a new bottle neck into the cog of things.
>
> I'm not proposing to introduce true GUIDs; in fact part of the idea behind
> making the grid address more easily available is that it would eliminate
> the need to do so, as you can easily resolve conflicts by comparing grids.
>
> i.e- if your device(s) encounter two avatars with the same key, but
> different grid addresses, then you can treat them as different if you want
> to.
>
> It is however an area I've thought a bit about, but as you say, a
> challenging one technically as the last thing anyone wants to have to have
> some complex cross-grid communication going on. My main concern is just in
> making sure I know two UUIDs are either definitely the same, or probably
> not, anything beyond that does get pretty complicated!
>
> > you can implement immediately.
> >    Just watch out for the snag of reverse dns may return the wrong host
> > name.  You cant count on a few host names, osgrid can have many 100's
> and a
> > simple grid can have 1 or 2.
> > on our grid all the hosts are names and not IPs in the region table, And
> > should reverse back to us EXCEPT for remote hosted simulators  :)   So,
> can
> > be bit confusion on what you need to do.
>
> Any idea why they're stored that way? I suppose it might smooth out some
> issues for simulators with dynamic IPs and such?
>
> I'd hoped not to have to do anything involving database modification, as
> storing IP alongside dns name could be awkward to keep up to date.
>
> A possible alternative would be to have the simulator also send its dns
> name as another header; this way the server can just do a regular (forward)
> DNS lookup, which is faster and more reliable and confirms the IP of the
> request before sending any query to the grid. If that's how the grid stores
> region addresses then it'll be the easiest way to handle the query.
>
> > On Mon, Jul 31, 2017 at 9:49 AM, Haravikk <[hidden email]> wrote:
> >
> >> This is a subject very much related to my topic on IP and region
> >> validation, and the proposal is very simple; the idea is to make it
> easier
> >> to find out which grid an object or avatar belongs to, as this is useful
> >> for a variety of reasons.
> >>
> >> It's already possible to get this information with some os*() functions,
> >> but they have a current threat level of Low or Moderate, placing them
> above
> >> the default of VeryLow and thus preventing them from being widely
> >> available. However, I'm not convinced that the threat level of these
> >> functions actually needs to be so high, as the information can be
> obtained
> >> by other means, it just seems like an unnecessary restriction on
> scripts.
> >> You can view the full proposal here:
> >> http://opensimulator.org/wiki/User:Haravikk_Mistral/
> >> ExpandedGridInfoAvailability
> >>
> >>
> >> I'm interested in feedback about which functions should/should not have
> >> their threat level downgraded, and also about my proposed addition of a
> >> header on llHTTPRequests() that identifies the grid.
> >>
> >> In discussion on IRC there was a question raised about privacy,
> >> particularly tracking between grids, but I'm not sure this is a problem;
> >> currently hyper grid travels works on the assumption that an avatar's
> UUID
> >> is unique, which scripts are free to do as well, in which case they are
> >> already able to track an avatar fairly reliably if they want to. Thing
> is
> >> though, to do this they'd need to have an external service in common,
> and
> >> devices spread about widely enough across different grids to get any
> kind
> >> of meaningful tracking, and even then, what can be done with this
> >> information is fairly limited. Knowing what a user's home-grid is won't
> >> make this any easier; the only difference is that with knowledge of the
> >> grid you can be certain there is no cross-grid UUID collision (i.e- UUID
> >> uniqueness is a bit less uncertain), it opens up no real capabilities to
> >> track avatars that I can see, and there are better ways to prevent
> tracking
> >> that could be implemented if it were a problem.
> >>
> >> However, the advantage of having this information more readily available
> >> is that it becomes possible for in-world devices to handle avatars
> >> differently depending upon whether they are from the current grid or
> not.
> >> It would also, crucially for me, make handling of data on a web-service
> >> much easier, as it becomes possible to easily partition data by the
> grid it
> >> belongs to, and to handle crossover (i.e- travelling avatars) more
> >> intelligently.
> >> _______________________________________________
> >> Opensim-dev mailing list
> >> [hidden email]
> >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> >>
> > _______________________________________________
> > Opensim-dev mailing list
> > [hidden email]
> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal] Expanded Grid Info Availability

Mike Lorrey
At the IMA's Commerce Working Group we are discussing developing a
blockchain standard, if not an actual blockchain, that would be useful for
making a lot of user-centric data (like UUIDs, user content licenses, money
etc) independent of any one grid, decentralized so that users can
communicate with and do commerce with other users.
In my teams work at http://galacticsystems.net, we have found difficulty
finding consistency across the hypergrid in issues like email modules,
http-request functionality, not to mention the perrenial teleportation and
IM issues. We feel that grids should focus on hosting worlds, and let users
control their identities, commerce, and interactions, secured
cryptographically by blockchain technologies.
One example of the problems inherent with having user registration on a per
grid basis is in commerce:
If I am shopping on a gloebit or podex mall somewhere on the hypergrid, I
can buy things from vendors for myself. If I want to gift content to
people, the vendor must be specifically coded to allow that, and unless the
customer knows the UUID of the recipient of their gift out on the
hypergrid, unless the recipient is a resident of the grid that vendor is
located on, there is no way for the vendor to use a script function to
request the UUID of that avatar across the hypergrid.

I would propose therefore, to make commerce work better, for all sorts of
uses, there be a function osGetHGName2Key( string user.name, string
gridURI);  The script would query via Robust the indicated grid for the
UUID of the indicated user name, and return it to the script.
Some might say "but thats a privacy issue". Sorry, no it isn't. If I can tp
to a grid on the hypergrid, look up their profile in that grid and see
their UUID key on their profile dialog, the UUID is not a private key. If I
can create an account on a grid without providing any relevant information
about myself, log in, and look up a name and get their key off their
profile, it is likewise, not a privacy issue, even if it is a closed grid.

On Tue, Aug 1, 2017 at 7:28 PM, David Saunders <[hidden email]> wrote:

> Hey,
>
>  I can assume it is because that how the region registers itself :) It does
> send the IP to the client tho.  :)  And we have had dynamic IP hosting our
> sims at one time, We would have to reload the firewall when it changed. And
> then it works :) But this is because we white-list simulators to our grid.
>
> I was looking at some ideas from
> http://opensimulator.org/wiki/Category:OSSL_Functions , but the problem is
> how are you going to know the correct verification URL, if the regions
> tells you what it is?   Only way if you start with a verified URL.  The
> script it self can find out what grid its on. So you really need to know
> the grid has set up this check for you to have any kind of confidence in
> having the script tell where it is :)  You can send the info needed by the
> script.
>
>
>
>  DAvid.
>
>
>
>
>
> On Tue, Aug 1, 2017 at 5:00 PM, Haravikk <[hidden email]> wrote:
>
> >
> > > On 1 Aug 2017, at 17:28, David Saunders <[hidden email]> wrote:
> > >
> > > One thing that might be nice is the ability to add more X headers in
> the
> > > config file. (I never needed it to be added before but can think of
> some
> > > need for it ) .  This way in the future when grid ops need another
> > x-header
> > > they don't have to crack open the code and modify.
> >
> > That's a neat idea, I can certainly look into adding that at the same
> time!
> >
> > > UUIDs across grids would be nice except for who will control it? And
> who
> > > will keep it from being polluted?   It also will put a new overhead on
> > the
> > > robust, for each object gets it own UUID, each copy of its own. So
> think
> > of
> > > having 10 avatars, building a region, each putting down a object in the
> > > region. The region would have to call the central resource, could call
> > > 100/min easy, Then put in an active grid, we can have 20-30 people
> > > building across the grid at once.  If we have to make an internet call
> > to a
> > > server , would add a new bottle neck into the cog of things.
> >
> > I'm not proposing to introduce true GUIDs; in fact part of the idea
> behind
> > making the grid address more easily available is that it would eliminate
> > the need to do so, as you can easily resolve conflicts by comparing
> grids.
> >
> > i.e- if your device(s) encounter two avatars with the same key, but
> > different grid addresses, then you can treat them as different if you
> want
> > to.
> >
> > It is however an area I've thought a bit about, but as you say, a
> > challenging one technically as the last thing anyone wants to have to
> have
> > some complex cross-grid communication going on. My main concern is just
> in
> > making sure I know two UUIDs are either definitely the same, or probably
> > not, anything beyond that does get pretty complicated!
> >
> > > you can implement immediately.
> > >    Just watch out for the snag of reverse dns may return the wrong host
> > > name.  You cant count on a few host names, osgrid can have many 100's
> > and a
> > > simple grid can have 1 or 2.
> > > on our grid all the hosts are names and not IPs in the region table,
> And
> > > should reverse back to us EXCEPT for remote hosted simulators  :)   So,
> > can
> > > be bit confusion on what you need to do.
> >
> > Any idea why they're stored that way? I suppose it might smooth out some
> > issues for simulators with dynamic IPs and such?
> >
> > I'd hoped not to have to do anything involving database modification, as
> > storing IP alongside dns name could be awkward to keep up to date.
> >
> > A possible alternative would be to have the simulator also send its dns
> > name as another header; this way the server can just do a regular
> (forward)
> > DNS lookup, which is faster and more reliable and confirms the IP of the
> > request before sending any query to the grid. If that's how the grid
> stores
> > region addresses then it'll be the easiest way to handle the query.
> >
> > > On Mon, Jul 31, 2017 at 9:49 AM, Haravikk <[hidden email]> wrote:
> > >
> > >> This is a subject very much related to my topic on IP and region
> > >> validation, and the proposal is very simple; the idea is to make it
> > easier
> > >> to find out which grid an object or avatar belongs to, as this is
> useful
> > >> for a variety of reasons.
> > >>
> > >> It's already possible to get this information with some os*()
> functions,
> > >> but they have a current threat level of Low or Moderate, placing them
> > above
> > >> the default of VeryLow and thus preventing them from being widely
> > >> available. However, I'm not convinced that the threat level of these
> > >> functions actually needs to be so high, as the information can be
> > obtained
> > >> by other means, it just seems like an unnecessary restriction on
> > scripts.
> > >> You can view the full proposal here:
> > >> http://opensimulator.org/wiki/User:Haravikk_Mistral/
> > >> ExpandedGridInfoAvailability
> > >>
> > >>
> > >> I'm interested in feedback about which functions should/should not
> have
> > >> their threat level downgraded, and also about my proposed addition of
> a
> > >> header on llHTTPRequests() that identifies the grid.
> > >>
> > >> In discussion on IRC there was a question raised about privacy,
> > >> particularly tracking between grids, but I'm not sure this is a
> problem;
> > >> currently hyper grid travels works on the assumption that an avatar's
> > UUID
> > >> is unique, which scripts are free to do as well, in which case they
> are
> > >> already able to track an avatar fairly reliably if they want to. Thing
> > is
> > >> though, to do this they'd need to have an external service in common,
> > and
> > >> devices spread about widely enough across different grids to get any
> > kind
> > >> of meaningful tracking, and even then, what can be done with this
> > >> information is fairly limited. Knowing what a user's home-grid is
> won't
> > >> make this any easier; the only difference is that with knowledge of
> the
> > >> grid you can be certain there is no cross-grid UUID collision (i.e-
> UUID
> > >> uniqueness is a bit less uncertain), it opens up no real capabilities
> to
> > >> track avatars that I can see, and there are better ways to prevent
> > tracking
> > >> that could be implemented if it were a problem.
> > >>
> > >> However, the advantage of having this information more readily
> available
> > >> is that it becomes possible for in-world devices to handle avatars
> > >> differently depending upon whether they are from the current grid or
> > not.
> > >> It would also, crucially for me, make handling of data on a
> web-service
> > >> much easier, as it becomes possible to easily partition data by the
> > grid it
> > >> belongs to, and to handle crossover (i.e- travelling avatars) more
> > >> intelligently.
> > >> _______________________________________________
> > >> Opensim-dev mailing list
> > >> [hidden email]
> > >> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> > >>
> > > _______________________________________________
> > > Opensim-dev mailing list
> > > [hidden email]
> > > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > [hidden email]
> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> >
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>



--
Mike Lorrey
CEO Galactic Systems, Inc
VP Stokens Venture Capital
[hidden email] <[hidden email]>
[hidden email]
International Spaceflight Museum
[hidden email]
Skype: michael.lorrey
LinkedIn: https://www.linkedin.com/in/mikelorrey
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal] Expanded Grid Info Availability

Haravikk
In reply to this post by David Saunders-2

> On 2 Aug 2017, at 00:28, David Saunders <[hidden email]> wrote:
>
> I was looking at some ideas from
> http://opensimulator.org/wiki/Category:OSSL_Functions , but the problem is
> how are you going to know the correct verification URL, if the regions
> tells you what it is?   Only way if you start with a verified URL.  The
> script it self can find out what grid its on. So you really need to know
> the grid has set up this check for you to have any kind of confidence in
> having the script tell where it is :)  You can send the info needed by the
> script.

This is actually the subject of my other topic on IP/region verification, I keep forgetting that I separated it into two topics thinking that simplified things 😏
Basically, imagine a script sends you the following:

        X-OpenSim-Location: x-grid-info://example.org:9000/My%20Region/1/2/3
        X-OpenSim-Region-Address: haravikk.com:9001

What your web-service could then do is send a request like:

        http://example.org:9000/verify_region?region=My%20Region&address=haravikk.com%3A9001

If the grid returns a positive response then I know that not only does the grid exist, but it has confirmed that a region by the given name is hosted by a machine at the given address, thus I know that the request came from a legitimate source (or at least, that the grid is willing to tell me so). Basically the idea is that grids would gain a /get_grid_info style service, but for verifying regions.

I created a wiki article on region verification here: http://opensimulator.org/wiki/User:Haravikk_Mistral/RegionVerification
And there's a separate topic on the mailing list under Verifying IP and Region.

I thought I'd keep the issues separate as the main thing I wanted to discuss here is whether people agree that making grid info more widely available is a good idea, or if there are real potential security/privacy issues. If that part is okay then the idea is to build upon it.
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal] Expanded Grid Info Availability

Haravikk
In reply to this post by Mike Lorrey

> On 2 Aug 2017, at 00:49, Mike Lorrey <[hidden email]> wrote:
>
> At the IMA's Commerce Working Group we are discussing developing a
> blockchain standard, if not an actual blockchain, that would be useful for
> making a lot of user-centric data (like UUIDs, user content licenses, money
> etc) independent of any one grid, decentralized so that users can
> communicate with and do commerce with other users.
> In my teams work at http://galacticsystems.net, we have found difficulty
> finding consistency across the hypergrid in issues like email modules,
> http-request functionality, not to mention the perrenial teleportation and
> IM issues. We feel that grids should focus on hosting worlds, and let users
> control their identities, commerce, and interactions, secured
> cryptographically by blockchain technologies.
> One example of the problems inherent with having user registration on a per
> grid basis is in commerce:
> If I am shopping on a gloebit or podex mall somewhere on the hypergrid, I
> can buy things from vendors for myself. If I want to gift content to
> people, the vendor must be specifically coded to allow that, and unless the
> customer knows the UUID of the recipient of their gift out on the
> hypergrid, unless the recipient is a resident of the grid that vendor is
> located on, there is no way for the vendor to use a script function to
> request the UUID of that avatar across the hypergrid.

Wow, that certainly would be a much more substantial system! Probably a bit out-of-scope for this particular topic, but very interesting that someone's looking into it!

> I would propose therefore, to make commerce work better, for all sorts of
> uses, there be a function osGetHGName2Key( string user.name, string
> gridURI);  The script would query via Robust the indicated grid for the
> UUID of the indicated user name, and return it to the script.
> Some might say "but thats a privacy issue". Sorry, no it isn't. If I can tp
> to a grid on the hypergrid, look up their profile in that grid and see
> their UUID key on their profile dialog, the UUID is not a private key. If I
> can create an account on a grid without providing any relevant information
> about myself, log in, and look up a name and get their key off their
> profile, it is likewise, not a privacy issue, even if it is a closed grid.

This does seem like it'd be useful; since it would need access to a grid URI, I assume then that you agree with the idea of making that information more widely available? As I say, currently this information is only available to scripts if the OSSL threat level is set to Low or higher; I'm hoping the relevant functions for getting that info can instead be downgraded to at most VeryLow, but ideally I'd like to see them be available as standard (i.e- no threat level at all, available even if other OSSL functions are disabled).

Of course it's not something I just want to go and change unilaterally; it'd be great to hear from anyone that knows why the threat level on functions like osGetAvatarHomeURI() and osGetGridHomeURI() was set so high in the first place! My suspicion that it was just being overly cautious, in which case a downgrade should be fine.
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Proposal] Expanded Grid Info Availability - php

Kurt Pudniks
In reply to this post by Haravikk
Hi all,

I'm not across all the technical details, rusty old LAMP & C++ coder here.

Would a central server running certain good php help to provide a proof of concept?

The grids could report users on an opt in basis (if both grid & user agree)... the central server notes grid, username, objects...

In my hazy view, this would allow cross-grid commerce, such that asset transfers can be held in escrow then routed to the correct avatar grid servers...?

or am i just being a totes n00b right now?! 😅

Cheers
Kurt

PS. i have 40x domains & web hosting package im doing zero with... perhaps i can host said good (centralized at least) php...? i promise not to sell any IPs to max-alpha-male-vitamins.com etc!! :P

Sent from my iPhone

> On 2 Aug 2017, at 4:47 pm, Haravikk <[hidden email]> wrote:
>
>
>> On 2 Aug 2017, at 00:28, David Saunders <[hidden email]> wrote:
>>
>> I was looking at some ideas from
>> http://opensimulator.org/wiki/Category:OSSL_Functions , but the problem is
>> how are you going to know the correct verification URL, if the regions
>> tells you what it is?   Only way if you start with a verified URL.  The
>> script it self can find out what grid its on. So you really need to know
>> the grid has set up this check for you to have any kind of confidence in
>> having the script tell where it is :)  You can send the info needed by the
>> script.
>
> This is actually the subject of my other topic on IP/region verification, I keep forgetting that I separated it into two topics thinking that simplified things 😏
> Basically, imagine a script sends you the following:
>
>    X-OpenSim-Location: x-grid-info://example.org:9000/My%20Region/1/2/3
>    X-OpenSim-Region-Address: haravikk.com:9001
>
> What your web-service could then do is send a request like:
>
>    http://example.org:9000/verify_region?region=My%20Region&address=haravikk.com%3A9001
>
> If the grid returns a positive response then I know that not only does the grid exist, but it has confirmed that a region by the given name is hosted by a machine at the given address, thus I know that the request came from a legitimate source (or at least, that the grid is willing to tell me so). Basically the idea is that grids would gain a /get_grid_info style service, but for verifying regions.
>
> I created a wiki article on region verification here: http://opensimulator.org/wiki/User:Haravikk_Mistral/RegionVerification
> And there's a separate topic on the mailing list under Verifying IP and Region.
>
> I thought I'd keep the issues separate as the main thing I wanted to discuss here is whether people agree that making grid info more widely available is a good idea, or if there are real potential security/privacy issues. If that part is okay then the idea is to build upon it.
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Loading...