Web Textures

This article is obsolete, but kept as a historical record. Do not rely on this information in any way. However, it may be used in the future, so please do not delete or modify.


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

llSetTextureURL(integer face, string url);
llRefreshTextureURL(integer face);

Example with text generation script: 

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

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.

Suggested Privacy Protections

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

Do nothing, just implement it

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.

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.

Built-In

Linden Lab could create their own anonymizing proxy server.

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.

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.

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.

The Permissions system

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

Whitelists

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

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

Suggested implementation:

Safe but convenient default behavior.
No popups.
Simple preferences
What is required of the Sim

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

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.

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.

Linden Lab Webhosting

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

See also