Difference between revisions of "Web Textures"

From Second Life Wiki
Jump to navigation Jump to search
m (+cat)
(41 intermediate revisions by 14 users not shown)
Line 1: Line 1:
=Summary=
{{hint|mode=note|desc=This has been superseded by [[HTTP Texture]].}}
 
==Summary==
This page is about dynamic web textures, a feature to allow an LSL script to assign an image URL to a face and cause it to dynamically update from the script.  This is not HTML-on-a-prim, though it shares some of the same complications regarding anonymity.
This page is about dynamic web textures, a feature to allow an LSL script to assign an image URL to a face and cause it to dynamically update from the script.  This is not HTML-on-a-prim, though it shares some of the same complications regarding anonymity.


Line 6: Line 8:
<blockquote>We are looking toward making it possible for prims to reference external websites for texture information, which is where PNG textures would start to come into play. -Phoenix Linden</blockquote>
<blockquote>We are looking toward making it possible for prims to reference external websites for texture information, which is where PNG textures would start to come into play. -Phoenix Linden</blockquote>


=Benefits of this feature=
== Benefits of this feature ==


#Negates the need for scripts like XyText that are very laggy when dynamic displays are large.
#Negates the need for scripts like XyText that are very laggy when dynamic displays are large.
#Allows for things like streaming news service HUDs.
#Allows for things like streaming news service [[HUD]]s.
#Interactive games can present large amounts of off-world data.
#Interactive games can present large amounts of off-world data.
#Corporations that already have many dynamic web assets can reuse them in-world.
#Corporations that already have many dynamic web assets can reuse them in-world.
#Live porn.
#The L$10 upload fee can be avoided if the user hosts the content by him/herself.
 
== Possible benefits ==
 
#Live porn. ''Did we really have to mention this?''
#Web Cams.
#Web Cams.


=Potential LSL implementation=
The previous 2 are already possible via quicktime streaming which is more efficient.
<pre>
 
== Potential LSL implementation ==
<lsl>
llSetTextureURL(integer face, string url);
llSetTextureURL(integer face, string url);
llRefreshTextureURL(integer face);
llRefreshTextureURL(integer face);
</pre>
</lsl>
 
Example with text generation script:
Example with text generation script:


<pre>
<lsl>
llSetTextureURL(1, llUrlEncode("http://example.com/getpng.php?text= " + text + "&font=futura&rez=512x512");
llSetTextureURL(1, llUrlEncode("http://example.com/getpng.php?text= " + text + "&font=futura&rez=512x512");
llRefreshTextureURL(integer face);
llRefreshTextureURL(integer face);
</pre>
</lsl>
 


== Privacy problems ==
The agent IP is already exposed if the avatar is listening to streamed media, but this is limited to agents that (a) have streaming media enabled, and (b) visit the specific parcel that the 'media bug' is associated with. Attempting to use streaming media to build up a database associating avatars with IP addresses would be enormously expensive.


=Suggested Privacy Protections=
Despite the small exposure, there are a number of people who do not use streaming media because of privacy concerns.
Because this feature would expose the IP address of an agent in a way that could identify the agent, especially on a HUD, several suggestion were made to enhance privacy protections.  They are listed in order of least effort to implement to most effort.


==Do nothing, just implement it==
Textures, unlike streaming media, are ubiquitous and require no significant expenditure to distribute around the grid. The potential for large scale data mining to associate characters in SL with each other and with real-life identities is significantly higher.
*Pro: Feature itself is somewhat easy to implement, if images are powers of 2
*Pro: Sets precedent for other features that may expose IP association information.
*Con: Sets precedent for other features that may expose IP association information.
**I hate to be the bearer of bad news, but the IP is already exposed if the avatar is listening to streamed music. I check my stream host, and see a list of IP addresses of all who are listening, how long they've been listening. Not that I ''do'' anything with this info, but it's there for the gathering. [[User:Buckaroo Mu|Buckaroo Mu]] 18:31, 26 January 2007 (PST)
*Con: Unannounced loss of privacy.
**Mitigation: Announce it first.
*Con: Could become a public relations nightmare if users react badly.


==Global on/off, with one time dialog opt-in==
*The relative severity of this should be pondered.
 
== Suggested Privacy Protections ==
There are a number of mechanisms that could be used to mitigate this effect:
 
=== Do nothing, just implement it ===
* Pro: Feature itself is somewhat easy to implement, if images are powers of 2
* Pro: Most other protocols on the internet expose IP to the server, this isn't unprecedented.
* Con: Unannounced loss of anonymity.
** Mitigation: Announce it first.
* Con: Sets precedent for other features that may expose IP association information.
** Note: this might be seen as a "Pro".
* Con: Trivial to associate IP with agent using textures. Much easier than it is with a parcel media stream.
* Con: Could become a public relations nightmare if users react badly.
 
=== Global on/off, with one time dialog opt-in ===
The client could prompt the first time you encounter a web texture, and ask you if you want to enable it, warning you that it will expose your IP address to third parties.  This would be similar to the way parcel streaming media prompts the first time you encounter a parcel with it set.
The client could prompt the first time you encounter a web texture, and ask you if you want to enable it, warning you that it will expose your IP address to third parties.  This would be similar to the way parcel streaming media prompts the first time you encounter a parcel with it set.
*Con: The user is asked to make technical decisions they might not understand.
*Con: The user is asked to make technical decisions they might not understand.
Line 47: Line 64:
*Pro: No annoyance for those who don't care about exposing IP associations.
*Pro: No annoyance for those who don't care about exposing IP associations.


==Proxy Options==
For HUD attachments this could be handled as a special case (see below).
 
=== Proxy Options ===
 
''External Proxy''
 
Update (7/7/2007): [[SLSquid Proxy]] addresses this issue.
 
The client would provide a place to enter a HTTP proxy address for web textures.  This would allow the user to enter an anonymizing proxy service if they want to.
The client would provide a place to enter a HTTP proxy address for web textures.  This would allow the user to enter an anonymizing proxy service if they want to.
*Pro: Easy to implement
*Pro: Easy to implement
Line 55: Line 79:
*** But there isn't such a plugin mechanism yet.
*** But there isn't such a plugin mechanism yet.
*Con: Anonymizing proxies are slow and unreliable.
*Con: Anonymizing proxies are slow and unreliable.
** Only individuals that care about exposing their IP need to suffer this delay.
*Con: Proxy support is not even implemented yet for the help browser
*Con: Proxy support is not even implemented yet for the help browser
*Con: Default settings (no proxy) expose users to privacy violations.
*Con: Default settings (no proxy) expose users to privacy violations.
** Which means this is likely to be a PR disaster.
** Which means this is likely to be a PR disaster.


==Attachments==
''Built-In''
Using web textures in an attachment (particularly a HUD) provides an attacker the greatest oppportunity to ensure that they have a correct match to an IP address, so while this is not that useful for bulk data gathering it's particularly problematic for targeted attacks. It would probably be best not to make web textures on attachments an exception to any wider restrictions. Web textures on HUDs, though, are particularly useful, so there should be some mechanism to allow a user to grant their own attachments the right to load web textures even if they are otherwise disabled.
 
Linden Lab could create their own anonymizing proxy server.
*Pro: No setup on the user's part is required.
*Con: Cost / Support / Implementation on Linden Lab's plate.
 
=== Attachments ===
Using web textures in an attachment (particularly a [[HUD]]) provides an attacker the greatest opportunity to ensure that they have a correct match to an IP address, so while this is not that useful for bulk data gathering it's particularly problematic for targeted attacks. It would probably be best not to make web textures on attachments an exception to any wider restrictions. Web textures on HUDs, though, are particularly useful, so there should be some mechanism to allow a user to grant their own attachments the right to load web textures even if they are otherwise disabled.


*Pro: Allows cautious users to use web-enabled HUDs.
*Pro: Allows cautious users to use web-enabled HUDs.
*Pro: Promotes effective low-lag tools.
*Pro: Promotes effective low-lag tools.


'''Dialog Boxes'''
=== Server side (SIM) ===
Much like {{LSLG|llHTTPRequest}} the SIM could download the texture and be subjected to the same restrictions (no more than 20 requests per 100 seconds). This would ensure peoples privacy is protected. Another permutation of this would be to provide both a client side and server side implementation of web textures.
 
*Pro: Privacy is protected
*Pro: No user intervention required.
*Con: More pressure on the sim.
**Mitigation: Limits per sim.  Freedom for sim owners to decide.
*Con: Not suitable for highly dynamic applications, such as web cams or games.
**Mitigation: SIM should be able to cache Web-acquired content, the total cache can be limited similar to prim-limitations.  This forces creative management.  Cams should stream anyway, and game mediums usually require memory management.
*Con: Vulnerability of LL servers for image-load attacks
**Mitigation: Limitation similar to llHTTPRequest,llEmail, etc.
*Note: This is effectively equivalent to LL providing a proxy.
*Con: May run into DMCA issues retaining copyrighted material on sim.


The client could pop up some sort of dialog when attaching a HUD with web textures, asking if you want to allow the HUD to use them.
=== Dialog Boxes for HUD attachments ===
For the subset of targeted exploits using HUDs, a dialog box similar to the ones used for other permissions could be used when attaching a HUD with web textures, asking if you want to allow the HUD to use them.


*Pro: Easy on the scripter.
*Pro: Easy on the scripter.
*Pro: Implemented entirely in the client.
*Pro: Implemented entirely in the client.
*Con: This only protects against targeted attacks though HUDs, it provides no protection against data mining. A more general mechanism might still be required.
*Con: The user is asked to make technical decisions they might not understand.
*Con: The user is asked to make technical decisions they might not understand.
*Con: It's a unique mechanism.
*Con: It's a unique mechanism.
*Con: Dialog boxes are annoying.
*Con: Dialog boxes are annoying.
*Con: UI studies show that users automatically click yes in many dialog boxes without thinking.
*Pro: Establishes precedent for other useful client-side security and privacy tools
*Pro: Establishes precedent for other useful client-side security and privacy tools
**Or is that a con? :)
**Or is that a con? :)


'''The Permissions system'''
==== The Permissions system ====


Alternatively, this could be done through the normal LSL permission system with a permission request, and something like PERMISSION_TEXTURE_URL.
Alternatively, this could be done through the normal LSL permission system with a permission request, and something like PERMISSION_TEXTURE_URL.


*Pro: Already well-understood interface.
*Pro: Already well-understood interface.
*Con: Dialog boxes are annoying.
*Con: Relatively inflexible, especially if required for non-HUD objects that might want to reach a wide audience (like a billboard).
*Con: The user is asked to make technical decisions they might not understand.
**Compromise: Perhaps non-attached objects could default to having the permission.  But, attached or especially HUDs could not.  As stated in this sub-proposal.


'''Whitelists'''
==== Whitelists ====


This could simply be handled the same way as third-party textures in the proposal below. The same pros and cons apply.
This could simply be handled the same way as third-party textures in the proposal below. The same pros and cons apply.


==White/Black List==
*Pro: No need for separate mechanisms for HUD textures and non-HUD textures.
*Con: HUDs do not detach after leaving a SIM.  This could allow for pop-up like exploits.  Especially, for the novice who believes what they read.
 
=== White/Black List ===
Similar to Firefox/IE popup blocking, the client could manage white/black lists.   
Similar to Firefox/IE popup blocking, the client could manage white/black lists.   
*Pro: Flexible and complete control
*Pro: Flexible and complete control
Line 100: Line 149:
**Mitigation: Selecting a "safe default" would protect naive users. If it's easy to update the whitelist or disable the protections again this shouldn't cause any major inconvenience for anyone.
**Mitigation: Selecting a "safe default" would protect naive users. If it's easy to update the whitelist or disable the protections again this shouldn't cause any major inconvenience for anyone.


===Suggested implementation:===
==== Suggested implementation: ====


'''Safe but convenient default behaviour.'''
===== Safe but convenient default behavior. =====
*Textures on prims set to the land group are automatically loaded by default.
*Textures on prims set to the land group are automatically loaded by default.
*Optionally - Textures set by scripts created by you, or owned by and readable by you are automatically loaded by default.
*Optionally - Textures set by scripts created by you, or owned by and readable by you are automatically loaded by default.
*All other textures are left unloaded.
*All other textures are left unloaded.


'''No popups.'''
===== No popups. =====
*Unloaded HTML textures have a distinct appearance.
*Unloaded HTML textures have a distinct appearance.
*Optionally - Left-clicking on the object will load the unloaded texture(s).
*Optionally - Left-clicking on the object will load the unloaded texture(s).
Line 117: Line 166:
*You can also remove these permissions if they are set.
*You can also remove these permissions if they are set.


'''Simple preferences'''
===== Simple preferences =====
* Privacy setting: only three levels of privacy:
* Privacy setting: only three levels of privacy:
** Low - load all HTTP textures and HTML-on-a-prim automatically.
** Low - load all HTTP textures and HTML-on-a-prim automatically.
** Normal - default behaviour described above.
** Normal - default behavior described above.
** High - No HTTP textures are loaded.
** High - No HTTP textures are loaded.
* Button to clear textures.
* Button to clear textures.


'''What is required of the Sim'''
===== What is required of the Sim =====


When an HTTP texture is sent to the client, it's bundled with some UUIDs:
When an HTTP texture is sent to the client, it's bundled with some UUIDs:
*The owner of the object.
*The owner of the object. (Already available)
*Optionally - The creator of the script that set the texture.
*Optionally - The creator (and owner if the script was full perm when the texture was set) of the script that set the texture, to implement the "my scripts" option.
*Optionally - A flag indicating the user has granted permission to display this texture through the permission system as suggested under '''Attachments''', above.
*Optionally - A flag indicating the user has granted permission to display this texture through the permission system as suggested under '''Attachments''', above.
*The group of the object.
*The group of the object. (Already available)


==Change Users Privacy Expectation==
=== Change Users Privacy Expectation ===
Make it clear to the users that their IP address association with their avatar name is not private information and can't be protected while still providing dynamic and seamless integration with the rest of the Internet.
Make it clear to the users that their IP address association with their avatar name is not private information and can't be protected while still providing dynamic and seamless integration with the rest of the Internet.
*Pro: No technical implementation necessary.
*Pro: No technical implementation necessary.
*Con: Not easy.
*Con: Not easy.
*Assumes 'dynamic and seamless integration with the rest of the Internet' is necessarily desirable. The results of Microsoft attempting this with Active Desktop has been less than optimal to say the least.


==Trusted hosting partners==
=== Trusted hosting partners ===
Have one or more trusted hosting partners that would provide scriptable webspace on standard Linux servers.  The key difference is that the partners could not allow the IP address of clients to pass through to the scripting language.
Have one or more trusted hosting partners that would provide scriptable webspace on standard Linux servers.  The key difference is that the partners could not allow the IP address of clients to pass through to the scripting language.
*Pro: Fully fixes privacy problem, with no effort required from the end user.
*Pro: Fully fixes privacy problem, with no effort required from the end user.
Line 145: Line 195:
*Con: Not in the spirit of SL.
*Con: Not in the spirit of SL.


==Linden Lab Webhosting==
=== Linden Lab Webhosting ===
Linden Lab would could offer their own webhosting that withholds end user IP similar to above.
Linden Lab would could offer their own webhosting that withholds end user IP similar to above.
*Pro: Fully fixes the privacy problem
*Pro: Fully fixes the privacy problem
Line 151: Line 201:
*Con: LL is not a web hosting company.
*Con: LL is not a web hosting company.
**But they sort of are... it's just a "3d web".
**But they sort of are... it's just a "3d web".
== See also ==
* {{Jira|VWR-217}} - New Feature -> LSL -> Dynamic Web Textures
* [[SLSquid Proxy]]


[[Category:Feature Requests]]
[[Category:Feature Requests]]
[[Category:LSL_HTTP]]

Revision as of 20:52, 30 July 2010

Emblem-important-yellow.png Note!

This has been superseded by HTTP Texture.

Summary

This page is about dynamic web textures, a feature to allow an LSL script to assign an image URL to a face and cause it to dynamically update from the script. This is not HTML-on-a-prim, though it shares some of the same complications regarding anonymity.

This raises a potential issue regarding Expected Privacy. The only practical way to accomplish dynamic web textures is to let the client download the image directly. This will expose user's IP addresses. This issue is also there for HTML on a prim, though the limitations several Lindens have mentioned to reduce the processing overhead of HTML on a prim - similar to the current limitations for media textures - make it less likely to be easily abused.

We are looking toward making it possible for prims to reference external websites for texture information, which is where PNG textures would start to come into play. -Phoenix Linden

Benefits of this feature

  1. Negates the need for scripts like XyText that are very laggy when dynamic displays are large.
  2. Allows for things like streaming news service HUDs.
  3. Interactive games can present large amounts of off-world data.
  4. Corporations that already have many dynamic web assets can reuse them in-world.
  5. The L$10 upload fee can be avoided if the user hosts the content by him/herself.

Possible benefits

  1. Live porn. Did we really have to mention this?
  2. Web Cams.

The previous 2 are already possible via quicktime streaming which is more efficient.

Potential LSL implementation

<lsl> llSetTextureURL(integer face, string url); llRefreshTextureURL(integer face); </lsl> Example with text generation script:

<lsl> llSetTextureURL(1, llUrlEncode("http://example.com/getpng.php?text= " + text + "&font=futura&rez=512x512"); llRefreshTextureURL(integer face); </lsl>


Privacy problems

The agent IP is already exposed if the avatar is listening to streamed media, but this is limited to agents that (a) have streaming media enabled, and (b) visit the specific parcel that the 'media bug' is associated with. Attempting to use streaming media to build up a database associating avatars with IP addresses would be enormously expensive.

Despite the small exposure, there are a number of people who do not use streaming media because of privacy concerns.

Textures, unlike streaming media, are ubiquitous and require no significant expenditure to distribute around the grid. The potential for large scale data mining to associate characters in SL with each other and with real-life identities is significantly higher.

  • The relative severity of this should be pondered.

Suggested Privacy Protections

There are a number of mechanisms that could be used to mitigate this effect:

Do nothing, just implement it

  • Pro: Feature itself is somewhat easy to implement, if images are powers of 2
  • Pro: Most other protocols on the internet expose IP to the server, this isn't unprecedented.
  • Con: Unannounced loss of anonymity.
    • Mitigation: Announce it first.
  • Con: Sets precedent for other features that may expose IP association information.
    • Note: this might be seen as a "Pro".
  • Con: Trivial to associate IP with agent using textures. Much easier than it is with a parcel media stream.
  • Con: Could become a public relations nightmare if users react badly.

Global on/off, with one time dialog opt-in

The client could prompt the first time you encounter a web texture, and ask you if you want to enable it, warning you that it will expose your IP address to third parties. This would be similar to the way parcel streaming media prompts the first time you encounter a parcel with it set.

  • Con: The user is asked to make technical decisions they might not understand.
  • Con: The user must sacrifice all dynamic web content to get privacy for their IP.
  • Pro: No annoyance for those who don't care about exposing IP associations.

For HUD attachments this could be handled as a special case (see below).

Proxy Options

External Proxy

Update (7/7/2007): SLSquid Proxy addresses this issue.

The client would provide a place to enter a HTTP proxy address for web textures. This would allow the user to enter an anonymizing proxy service if they want to.

  • Pro: Easy to implement
  • Pro: Proxy support will be needed anyway for the general move to HTTP texture transfers for regular asset textures.
  • Con: Configuring proxy settings for anonymizing proxies can be extremely difficult even for professionals.
    • Mitigation: this work can be hidden by the browser or browser extensions, so SL or a plugin for SL could do the work.
      • But there isn't such a plugin mechanism yet.
  • Con: Anonymizing proxies are slow and unreliable.
    • Only individuals that care about exposing their IP need to suffer this delay.
  • Con: Proxy support is not even implemented yet for the help browser
  • Con: Default settings (no proxy) expose users to privacy violations.
    • Which means this is likely to be a PR disaster.

Built-In

Linden Lab could create their own anonymizing proxy server.

  • Pro: No setup on the user's part is required.
  • Con: Cost / Support / Implementation on Linden Lab's plate.

Attachments

Using web textures in an attachment (particularly a HUD) provides an attacker the greatest opportunity to ensure that they have a correct match to an IP address, so while this is not that useful for bulk data gathering it's particularly problematic for targeted attacks. It would probably be best not to make web textures on attachments an exception to any wider restrictions. Web textures on HUDs, though, are particularly useful, so there should be some mechanism to allow a user to grant their own attachments the right to load web textures even if they are otherwise disabled.

  • Pro: Allows cautious users to use web-enabled HUDs.
  • Pro: Promotes effective low-lag tools.

Server side (SIM)

Much like llHTTPRequest the SIM could download the texture and be subjected to the same restrictions (no more than 20 requests per 100 seconds). This would ensure peoples privacy is protected. Another permutation of this would be to provide both a client side and server side implementation of web textures.

  • Pro: Privacy is protected
  • Pro: No user intervention required.
  • Con: More pressure on the sim.
    • Mitigation: Limits per sim. Freedom for sim owners to decide.
  • Con: Not suitable for highly dynamic applications, such as web cams or games.
    • Mitigation: SIM should be able to cache Web-acquired content, the total cache can be limited similar to prim-limitations. This forces creative management. Cams should stream anyway, and game mediums usually require memory management.
  • Con: Vulnerability of LL servers for image-load attacks
    • Mitigation: Limitation similar to llHTTPRequest,llEmail, etc.
  • Note: This is effectively equivalent to LL providing a proxy.
  • Con: May run into DMCA issues retaining copyrighted material on sim.

Dialog Boxes for HUD attachments

For the subset of targeted exploits using HUDs, a dialog box similar to the ones used for other permissions could be used when attaching a HUD with web textures, asking if you want to allow the HUD to use them.

  • Pro: Easy on the scripter.
  • Pro: Implemented entirely in the client.
  • Con: This only protects against targeted attacks though HUDs, it provides no protection against data mining. A more general mechanism might still be required.
  • Con: The user is asked to make technical decisions they might not understand.
  • Con: It's a unique mechanism.
  • Con: Dialog boxes are annoying.
  • Con: UI studies show that users automatically click yes in many dialog boxes without thinking.
  • Pro: Establishes precedent for other useful client-side security and privacy tools
    • Or is that a con? :)

The Permissions system

Alternatively, this could be done through the normal LSL permission system with a permission request, and something like PERMISSION_TEXTURE_URL.

  • Pro: Already well-understood interface.
  • Con: Relatively inflexible, especially if required for non-HUD objects that might want to reach a wide audience (like a billboard).
    • Compromise: Perhaps non-attached objects could default to having the permission. But, attached or especially HUDs could not. As stated in this sub-proposal.

Whitelists

This could simply be handled the same way as third-party textures in the proposal below. The same pros and cons apply.

  • Pro: No need for separate mechanisms for HUD textures and non-HUD textures.
  • Con: HUDs do not detach after leaving a SIM. This could allow for pop-up like exploits. Especially, for the novice who believes what they read.

White/Black List

Similar to Firefox/IE popup blocking, the client could manage white/black lists.

  • Pro: Flexible and complete control
  • Pro: users not concerned about privacy could select "Accept everything"
  • Con: If poorly implementd, this would cause a lot of user input: (for example, thousands of prompts per second for someone flying over the mainland).
  • Con: The user is asked to make technical decisions they might not understand (the user might be tricked, they might not know who to trust).
  • Con: Very complex to implement, UI elements hard to design effectively.
    • Mitigation: Using existing controls (texture cues, pie menu) would simplify the implementation and make the interface more familiar.
  • Con: Reinstalling could lose settings.
    • Mitigation: Selecting a "safe default" would protect naive users. If it's easy to update the whitelist or disable the protections again this shouldn't cause any major inconvenience for anyone.

Suggested implementation:

Safe but convenient default behavior.
  • Textures on prims set to the land group are automatically loaded by default.
  • Optionally - Textures set by scripts created by you, or owned by and readable by you are automatically loaded by default.
  • All other textures are left unloaded.
No popups.
  • Unloaded HTML textures have a distinct appearance.
  • Optionally - Left-clicking on the object will load the unloaded texture(s).
  • Right-clicking on an unloaded HTML texture will bring up the pie menu, and a pie menu option will allow you to load the textures on the object or whitelist it.
    • Load the textures on this object.
    • Always load textures on this object
    • Always load textures from objects owned by this person
    • Always load textures from objects in this group
  • You can also remove these permissions if they are set.
Simple preferences
  • Privacy setting: only three levels of privacy:
    • Low - load all HTTP textures and HTML-on-a-prim automatically.
    • Normal - default behavior described above.
    • High - No HTTP textures are loaded.
  • Button to clear textures.
What is required of the Sim

When an HTTP texture is sent to the client, it's bundled with some UUIDs:

  • The owner of the object. (Already available)
  • Optionally - The creator (and owner if the script was full perm when the texture was set) of the script that set the texture, to implement the "my scripts" option.
  • Optionally - A flag indicating the user has granted permission to display this texture through the permission system as suggested under Attachments, above.
  • The group of the object. (Already available)

Change Users Privacy Expectation

Make it clear to the users that their IP address association with their avatar name is not private information and can't be protected while still providing dynamic and seamless integration with the rest of the Internet.

  • Pro: No technical implementation necessary.
  • Con: Not easy.
  • Assumes 'dynamic and seamless integration with the rest of the Internet' is necessarily desirable. The results of Microsoft attempting this with Active Desktop has been less than optimal to say the least.

Trusted hosting partners

Have one or more trusted hosting partners that would provide scriptable webspace on standard Linux servers. The key difference is that the partners could not allow the IP address of clients to pass through to the scripting language.

  • Pro: Fully fixes privacy problem, with no effort required from the end user.
  • Con: Hard to monitor trusted partners for compliance if more than one.
  • Con: If only one, then developers have no choice.
  • Con: Business risk from close external relationship with other company if only one provider.
  • Con: Not in the spirit of SL.

Linden Lab Webhosting

Linden Lab would could offer their own webhosting that withholds end user IP similar to above.

  • Pro: Fully fixes the privacy problem
  • Pro: Could also be used as a super low latency way to do HTTPRequest calls to a web server. HTTPRequest limits could be raised for requests to these servers.
  • Con: LL is not a web hosting company.
    • But they sort of are... it's just a "3d web".

See also