User:Haravikk Mistral/ExpandedGridInfoAvailability - Revision history

Haravikk Mistral: /* X-Grid-Location Header */

2017-08-15T12:26:33Z

‎X-Grid-Location Header

Haravikk Mistral: /* X-Grid-Location Header */

2017-08-15T12:25:53Z

‎X-Grid-Location Header

Haravikk Mistral: /* Alternatives Considered */

2017-08-14T22:15:04Z

‎Alternatives Considered

Haravikk Mistral: /* X-Grid-Location Header */

2017-08-01T11:21:00Z

‎X-Grid-Location Header

Haravikk Mistral: /* X-Grid-Location Header */

2017-08-01T11:19:10Z

‎X-Grid-Location Header

Haravikk Mistral: /* Alternatives Considered */

2017-07-31T14:11:31Z

‎Alternatives Considered

Haravikk Mistral: /* Overview */

2017-07-31T13:50:46Z

‎Overview

Haravikk Mistral: /* X-Grid-Location Header */

2017-07-31T11:54:06Z

‎X-Grid-Location Header

Haravikk Mistral: Created page with "= Overview = == Problem == An avatar's UUID is not guaranteed to be unique, thus it remains a possibility that two avatars on two different grids could have the same UUID eith..."

2017-07-31T11:53:06Z

Created page with "= Overview = == Problem == An avatar's UUID is not guaranteed to be unique, thus it remains a possibility that two avatars on two different grids could have the same UUID eith..."

New page

= Overview =
== Problem ==
An avatar's UUID is not guaranteed to be unique, thus it remains a possibility that two avatars on two different grids could have the same UUID either by accident or by design. This is compounded by a general lack of access to grid info, as many useful functions are restricted to an OSSL threat level of Low, placing them above the OSSL default threat level of VeryLow.

== Proposed Solution ==
The proposal is to make grid-awareness more readily available to scripts, and to any services with which they may communicate, making it easier to record an avatar, region, object etc. not only by UUID, but also by grid, thus ensuring no possibility of a cross-grid collision. For scripts and services this means that data can be more easily partitioned by the grid to which it belongs, and roaming avatars can be recorded differently (or ignored altogether).

= Detailed Design =
== Reduced Threat Levels ==
The first step to this proposal is to reduce the threat level of the following functions to VeryLow or None:

* [[osGetAvatarHomeURI]]()
* [[osGetGridCustom]]()
* [[osGetGridGatekeeperURI]]()
* [[osGetGridHomeURI]]()
* [[osGetGridLoginURI]]()

At a minimum, only [[osGetAvatarHomeURI]]() and [[osGetGridHomeURI]]() are required, however it is unclear why any of the above functions are rated above VeryLow to begin with, as all of this information is readily available to any connecting viewer, so it seems strange that objects within an actual region upon a grid should have such restricted access to their own environment; in terms of security there is no real threat to relaxing restrictions on these functions, as at best all they can do is try to provide security through obscurity, which is no real protection at all.

== X-Grid-Location Header ==
This step proposes simply to add an additional header to all outgoing HTTP requests generated by [https://wiki.secondlife.com/wiki/LlHTTPRequest llHTTPRequest()]. The proposed format for this header is as follows:

<pre>X-OpenSim-Location: x-grid-location://example.org:9000/region/Some%20Region/1/2/3</pre>

The header provides an <tt>x-grid-location://</tt> URI as supported by most Open Simulator compatible clients; while the URI provides a full location including region name and coordinates, the only new information is the grid's address, as the region name and coordinates are already provided by <tt>X-SecondLife-Region</tt> and <tt>X-SecondLife-Local-Position</tt> respectively, and these should in fact match the path of the URI.

The advantage of this header is that it eliminates the need for scripts themselves to add the information to requests in a non-standard way, and allows the information to be sent even if there is no access to any <tt>os*()</tt> functions at all, as any up-to-date simulator would simply send the header automatically, including for existing scripts.

== Alternatives Considered ==
The main alternative considered was generating some kind of grid UUID, probably by hashing the grid-address (i.e- a v5 UUID), with the idea being that this would avoid the need to send any actual details of the grid. The problem with this however is that it only makes things more awkward with no real benefit, as it would be fairly easy to identify common grids anyway, and hiding the address offers no real security for a grid, when this information is known by regions etc. anyway.

@@ Line 21: / Line 21: @@
 This step proposes simply to add an additional header to all outgoing HTTP requests generated by [https://wiki.secondlife.com/wiki/LlHTTPRequest llHTTPRequest()]. The proposed format for this header is as follows:
-<pre>X-OpenSim-Grid-Info: x-grid-info://example.org:9000/region/Some%20Region/1/2/3</pre>
+<pre>X-OpenSim-Location: x-grid-info://example.org:9000/region/Some%20Region/1/2/3</pre>
 The header provides an <tt>x-grid-info://</tt> URI as supported by most Open Simulator compatible clients; while the URI provides a full location including region name and coordinates, the only new information is the grid's address, as the region name and coordinates are already provided by <tt>X-SecondLife-Region</tt> and <tt>X-SecondLife-Local-Position</tt> respectively, and these should in fact match the path of the URI.

@@ Line 21: / Line 21: @@
 This step proposes simply to add an additional header to all outgoing HTTP requests generated by [https://wiki.secondlife.com/wiki/LlHTTPRequest llHTTPRequest()]. The proposed format for this header is as follows:
-<pre>X-OpenSim-Location: x-grid-info://example.org:9000/region/Some%20Region/1/2/3</pre>
+<pre>X-OpenSim-Grid-Info: x-grid-info://example.org:9000/region/Some%20Region/1/2/3</pre>
 The header provides an <tt>x-grid-info://</tt> URI as supported by most Open Simulator compatible clients; while the URI provides a full location including region name and coordinates, the only new information is the grid's address, as the region name and coordinates are already provided by <tt>X-SecondLife-Region</tt> and <tt>X-SecondLife-Local-Position</tt> respectively, and these should in fact match the path of the URI.

← Older revision		Revision as of 22:15, 14 August 2017
Line 32:		Line 32:
	The main alternative considered was generating some kind of grid UUID, probably by hashing the grid-address (i.e- a v5 UUID), with the idea being that this would avoid the need to send any actual details of the grid. The problem with this however is that it only makes things more awkward with no real benefit, as it would be fairly easy to identify common grids anyway, and hiding the address offers no real security for a grid, when this information is known by regions etc. anyway.		The main alternative considered was generating some kind of grid UUID, probably by hashing the grid-address (i.e- a v5 UUID), with the idea being that this would avoid the need to send any actual details of the grid. The problem with this however is that it only makes things more awkward with no real benefit, as it would be fairly easy to identify common grids anyway, and hiding the address offers no real security for a grid, when this information is known by regions etc. anyway.

−	Also, one key area for consideration is the naming of the proposed HTTP header, and which exact URI scheme it should use (would <tt>x-grid-info</tt> be a better fit?).	+	Also, one key area for consideration is the naming of the proposed HTTP header, and which exact URI scheme it should use (would <tt>x-grid-location-info</tt> be a better fit?).

@@ Line 21: / Line 21: @@
 This step proposes simply to add an additional header to all outgoing HTTP requests generated by [https://wiki.secondlife.com/wiki/LlHTTPRequest llHTTPRequest()]. The proposed format for this header is as follows:
-<pre>X-OpenSim-Location: x-grid-location-info://example.org:9000/region/Some%20Region/1/2/3</pre>
+<pre>X-OpenSim-Location: x-grid-info://example.org:9000/region/Some%20Region/1/2/3</pre>
-The header provides an <tt>x-grid-location-info://</tt> URI as supported by most Open Simulator compatible clients; while the URI provides a full location including region name and coordinates, the only new information is the grid's address, as the region name and coordinates are already provided by <tt>X-SecondLife-Region</tt> and <tt>X-SecondLife-Local-Position</tt> respectively, and these should in fact match the path of the URI.
+The header provides an <tt>x-grid-info://</tt> URI as supported by most Open Simulator compatible clients; while the URI provides a full location including region name and coordinates, the only new information is the grid's address, as the region name and coordinates are already provided by <tt>X-SecondLife-Region</tt> and <tt>X-SecondLife-Local-Position</tt> respectively, and these should in fact match the path of the URI.
 The advantage of this header is that it eliminates the need for scripts themselves to add the information to requests in a non-standard way, and allows the information to be sent even if there is no access to any <tt>os*()</tt> functions at all, as any up-to-date simulator would simply send the header automatically, including for existing scripts.

← Older revision		Revision as of 14:11, 31 July 2017
Line 31:		Line 31:
	== Alternatives Considered ==		== Alternatives Considered ==
	The main alternative considered was generating some kind of grid UUID, probably by hashing the grid-address (i.e- a v5 UUID), with the idea being that this would avoid the need to send any actual details of the grid. The problem with this however is that it only makes things more awkward with no real benefit, as it would be fairly easy to identify common grids anyway, and hiding the address offers no real security for a grid, when this information is known by regions etc. anyway.		The main alternative considered was generating some kind of grid UUID, probably by hashing the grid-address (i.e- a v5 UUID), with the idea being that this would avoid the need to send any actual details of the grid. The problem with this however is that it only makes things more awkward with no real benefit, as it would be fairly easy to identify common grids anyway, and hiding the address offers no real security for a grid, when this information is known by regions etc. anyway.
		+
		+	Also, one key area for consideration is the naming of the proposed HTTP header, and which exact URI scheme it should use (would <tt>x-grid-info</tt> be a better fit?).

@@ Line 4: / Line 4: @@
 == Proposed Solution ==
-The proposal is to make grid-awareness more readily available to scripts, and to any services with which they may communicate, making it easier to record an avatar, region, object etc. not only by UUID, but also by grid, thus ensuring no possibility of a cross-grid collision. For scripts and services this means that data can be more easily partitioned by the grid to which it belongs, and roaming avatars can be recorded differently (or ignored altogether).
+The proposal is to make grid-awareness more readily available to scripts, and to any services with which they may communicate, making it easier to record an avatar, region, object etc. not only by UUID, but also by grid, thus ensuring no possibility of a cross-grid collision. For scripts and services this means that data can be more easily partitioned by the grid to which it belongs, and roaming avatars can be recorded differently (or ignored altogether), and cross-grid data handled more intelligently.
 = Detailed Design =

@@ Line 26: / Line 26: @@
 The advantage of this header is that it eliminates the need for scripts themselves to add the information to requests in a non-standard way, and allows the information to be sent even if there is no access to any <tt>os*()</tt> functions at all, as any up-to-date simulator would simply send the header automatically, including for existing scripts.
 == Alternatives Considered ==
 The main alternative considered was generating some kind of grid UUID, probably by hashing the grid-address (i.e- a v5 UUID), with the idea being that this would avoid the need to send any actual details of the grid. The problem with this however is that it only makes things more awkward with no real benefit, as it would be fairly easy to identify common grids anyway, and hiding the address offers no real security for a grid, when this information is known by regions etc. anyway.