User:Haravikk Mistral/ExpandedGridInfoAvailability

From OpenSimulator

< User:Haravikk Mistral(Difference between revisions)
Jump to: navigation, search
m (Overview)
m (Alternatives Considered)
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?).

Revision as of 06:11, 31 July 2017

Contents

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), and cross-grid data handled more intelligently.

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:

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 llHTTPRequest(). The proposed format for this header is as follows:

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

The header provides an x-grid-location:// 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 X-SecondLife-Region and X-SecondLife-Local-Position 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 os*() functions at all, as any up-to-date simulator would simply send the header automatically, including for existing scripts.

This would be particularly useful when combined with the ability to verify a region.

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.

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

General
About This Wiki