Difference between revisions of "Web Textures"

From Second Life Wiki
Jump to navigation Jump to search
(the other name is silly.)
(reorg)
Line 1: Line 1:
This page is for showing the different pros and cons of different approaches of new ways of getting new URL's to the client.  A big question on the minds of developers is LL's policies on [[Expected Privacy]].  Understanding what LL thinks on this may lead us to understanding what LL will do.  Let's do our best to fill this out with both sides.
This page is for showing the different pros and cons of different approaches of new ways of getting new URL's to the client.  A big question on the minds of developers is LL's policies on [[Expected Privacy]].  Understanding what LL thinks on this may lead us to understanding what LL will do.  Let's do our best to fill this out with both sides.


=Client downloading of URL=
=Client direct downloading of Images=
The client directly downloads the URL.
The client directly downloads the Image from the web and displays it on a face.
==Pros==
==Pros==
===Technical===
===Technical===
Line 11: Line 11:
==Cons==
==Cons==
===Technical===
===Technical===
Minor risk that some users won't be able to reach some URLs, causing support issues because a user can't download a spacific image.
#Minor risk that some users won't be able to reach some URLs, causing support issues because a user can't download a spacific image.
#Images may have to be generated as size powers of 2.
===Privacy===
===Privacy===
Risk due to items that can track users, possibly allowing alts to be matched to their owners.
Risk due to items that can track users, possibly allowing alts to be matched to their owners.


=LL Downloading of URL, passing back to client=
=LL Downloading of URL, passing back to client/LL as an anonymizing proxy=
This solution suggests that if anyone needs to download a URL, that LL will download the URL, then host a copy of that image on LL's servers.  It will then be treated like any other asset hosted by LL.  The client will request the URL from the file server, and the file server will spit back a copy of the requested image.
This solution suggests that if anyone needs to download a URL, that LL will download the URL, then host a copy of that image on LL's servers.  It will then be treated like any other asset hosted by LL.  The client will request the URL from the file server, and the file server will spit back a copy of the requested image.
==Pros==
==Pros==
Line 25: Line 26:
==Cons==
==Cons==
===Technical===
===Technical===
Lots of bandwidth on LL's part. Possible additional latency because when the first time an image is requested, LL will have to pull a copy of the requested assets from the web server.
#Lots of bandwidth on LL's part. Every time an image is requested, LL will have to pull a copy of the requested assets from the web server and send it back out.  If they implement caching, it defeats the dynamic purpose of pulling a texture off the web.  Therefore little caching can be done on LL servers.  This feature isn't "use random images off the web"... it's specifically for images generated dynamically for this purpose.


Difficulty in determining which textures are dynamic and cannot be cached, leaves the potential for a dynamic image creating an unlimited number of cached copies on the LL asset server.
#Images may have to be generated as size powers of 2.
 
Puts more load on the asset server as it has to fetch and cache foreign data, adds new code paths with more potential security risks to the most critical service in Second Life.


===Privacy===
===Privacy===
None known.
None known.
=LL Hosted proxy network=
LL hosting proxies for our clients to connect with.  Possibly a dupe of LL Downloading URL
==Pros==
===Technical===
===Privacy===
==Cons==
Has a negative benefit-cost equation for LL, keep dreaming
===Technical===
===Privacy===


=P2p-based=
=P2p-based=

Revision as of 23:39, 25 January 2007

This page is for showing the different pros and cons of different approaches of new ways of getting new URL's to the client. A big question on the minds of developers is LL's policies on Expected Privacy. Understanding what LL thinks on this may lead us to understanding what LL will do. Let's do our best to fill this out with both sides.

Client direct downloading of Images

The client directly downloads the Image from the web and displays it on a face.

Pros

Technical

Simple and straightfoward.

Privacy

Parcel owners in Second Life will be able to implement the same defense techniques that have been used in IRC for years. The problem of griefing on unverified alts will be mitigated.

Cons

Technical

  1. Minor risk that some users won't be able to reach some URLs, causing support issues because a user can't download a spacific image.
  2. Images may have to be generated as size powers of 2.

Privacy

Risk due to items that can track users, possibly allowing alts to be matched to their owners.

LL Downloading of URL, passing back to client/LL as an anonymizing proxy

This solution suggests that if anyone needs to download a URL, that LL will download the URL, then host a copy of that image on LL's servers. It will then be treated like any other asset hosted by LL. The client will request the URL from the file server, and the file server will spit back a copy of the requested image.

Pros

Technical

Guarantees that the image will be served up in a timely fashion because it will be hosted by LL's content servers. NOTE: Actually this is not true because LL would still have to fetch the image from the source and if the source is down or has a slow connection LL won't be able to fetch it any better than a client

Privacy

Good for privacy because the user never connects to a foreign server.

Cons

Technical

  1. Lots of bandwidth on LL's part. Every time an image is requested, LL will have to pull a copy of the requested assets from the web server and send it back out. If they implement caching, it defeats the dynamic purpose of pulling a texture off the web. Therefore little caching can be done on LL servers. This feature isn't "use random images off the web"... it's specifically for images generated dynamically for this purpose.
  1. Images may have to be generated as size powers of 2.

Privacy

None known.

P2p-based

A Bittorrent-like p2p downloading system.

Pros

Technical

Privacy

Cons

Technical

The overhead in time and bandwidth of having to find a peer hosting every requested asset would make this infeasible for a real-time metaverse like Second Life

Privacy

This doesn't address any of the privacy concerns at all. Bittorrent-like protocols expose IP addresses of people sharing and requesting textures so it would still be possible to tie sensors in-world to requests for unique textures also at that location. Maybe the person proposing this was thinking of a multiple hop network like Tor or a darknet protocol like Freenet?

Anonymous P2p-based proxy

A Tor-like p2p downloading system.

Pros

Technical

Privacy

Cons

Technical

Ever tried to use Tor or Freenet?

Privacy