Difference between revisions of "Web Textures"

From Second Life Wiki
Jump to navigation Jump to search
m (New Download Approches moved to Web Textures: Moving after cut and paste move...still don't edit yet)
Line 1: Line 1:
=Summary=
#REDIRECT [[New Download Approaches]]
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 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. -- [[User:Argent Stonecutter|Argent Stonecutter]] 09:06, 26 January 2007 (PST)''
 
<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=
 
#Negates the need for scripts like XyText that are very laggy when dynamic displays are large.
#Allows for things like streaming news service HUDs.
#Interactive games can present large amounts of off-world data.
#Corporations that already have many dynamic web assets can reuse them in-world.
#Live porn.
#Web Cams.
 
=Potential LSL implementation=
<pre>
llSetTextureURL(integer face, string url);
llRefreshTextureURL(integer face);
</pre>
 
Example with text generation script:
 
<pre>
llSetTextureURL(1, llUrlEncode("http://example.com/getpng.php?text= " + text + "&font=futura&rez=512x512");
llRefreshTextureURL(integer face);
</pre>
 
 
=Suggested Privacy Protections=
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==
*Pro: Feature itself is very easy to implement, if images are powers of 2
*Con: Some users would freak out.
 
==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.
 
==Proxy Options==
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
*Con: Users are exposed to a very high level of complexity to retain current environment.
*Con: Anonymizing proxies are slow and unreliable.
 
*Pro and Con: Linden Labs doesn't seem to be able to manage proxy support even for the help browser, and they will need to implement a proxy anyway once they have HTTP texture support.
 
==Dialog boxes==
The highest risk is when using web textures on a HUD.  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.  Alternatively this could be done through the normal LSL permission system with a permission request, and something like PERMISSION_TEXTURE_URL.
*Pro: More fined grained control
*Con: The user is asked to make technical decisions they might not understand.
*Con: More Complex to implement.
 
''This could simply be handled the same way as third-party textures in the proposal below.
-- [[User:Argent Stonecutter|Argent Stonecutter]] 09:02, 26 January 2007 (PST)''
 
==White/Black List==
Similar to Firefox/IE popup blocking, the client could manage white/black lists. 
*Pro: Flexible and complete control
*Con: This would cause a lot of user input/prompting required for someone flying over the mainland, for example.
*Con: The user is asked to make technical decisions they might not understand.
*Con: The user might be tricked, they might not know who to trust.
*Con: Very complex to implement, UI elements hard to design effectively.
*Con: Reinstalling could lose settings.
 
''These "Con" points all assume a bad implementation that's almost deliberately obtrusive.
-- [[User:Argent Stonecutter|Argent Stonecutter]] 08:58, 26 January 2007 (PST)''
 
===Suggested implementation:===
 
'''Safe but convenient default behaviour.'''
*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.
*Left-clicking on the object will load the unloaded texture(s).
*Right-clicking on an unloaded HTML texture will bring up a pie menu option that allows you to change the behaviour.
**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
 
'''Preferences'''
* Preferences setting to set three levels of privacy:
** Low - load all HTML textures automatically.
** Normal - default behaviour described above.
** High - No HTML textures are loaded.
 
'''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.
*Optionally - The creator of the script that set the texture.
*The group of the object.
 
==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.
 
==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.
 
[[Category:Feature Requests]]

Revision as of 09:25, 26 January 2007

Redirect to:

Retrieved from "https://wiki.secondlife.com/w/index.php?title=Web_Textures&oldid=7017"