[sldev] Re: Texture Bugs

[Argent Stonecutter]

On Jan 25, 2007, at 4:45 PM, Gigs Taggart wrote:
> On 1/25/07, Argent Stonecutter <secret.argent at gmail.com> wrote:
>> The only widely used services I can think of that share information
>> this promiscuously predate TCP/IP.

> You mean like HTML inline images?

Nope.

When I fire up my browser I only fetch HTML inline images when they  
are requested by webpages that I actually visit, and HTML inline  
images in email and even in browsers are already blacklistable and  
whitelistable.

When I fire up SL I should be able to only fetch HTTP textures when  
they are requested by parcels that I actually visit, and HTTP  
textures on HUDs and even in parcels should be blacklistable and  
whitelistable.

That is:

1. When I visit a website, I only download images referred by the  
actual pages I visit. I don't download images referred by pages I  
don't visit, and I don't download images referred by other sites on  
the same server or subnet. In SL, when you visit a parcel, you view  
textures from other parcels on the same sim, and on multiple nearby  
sims... you shouldn't be grabbing HTTP textures referred by them.

2. If I want to only view images hosted on the same website, I can do  
so.

3. If I want to only view images of a given type, I can do so.

4. If I want to view images hosted on the same site or a set of other  
sites I've decided to allow, I can do so.

5. If I don't want to ever download images from doubleclick.net, I  
can do so.

6. If I change my mind and want to view an undownloaded image, or to  
whitelist the site it's hosted at, I can do so.

That is, web browsers ALREADY provide the functionality that I'm  
saying Second Life should provide.

> Browsers DO download images from external sites, by default.  It's  
> never on a site by site basis like you claim.

Not by default, AND I SAID IT WAS NOT BY DEFULT, but virtually every  
browser (including Internet Explorer) has options to blacklist, or to  
deny-by-default and whitelist, any content you want.

> Java applet security is not a good example of anything, it's  
> probably the most ill-concieved mess ever.

It's not perfect, no, but that's not the point. The point is that the  
norm on the web is for content to be more tightly restricted than  
you're implying.

>   In case you haven't noticed, no one uses Java applets anymore.

Sure they do, and they use them more than ActiveX. The only automatic  
plugins that are more common than Java applets is Flash, and...  
look... Flash blockers are popular extensions for web browsers even  
though Flash security is tighter than Java security.

Again, the standard on the web is for there to be fine-grained  
control over this kind of thing.

> That is not necessary.  The IP address of your account already is  
> public information.

There's a huge difference between getting access to the addresses of  
specific people who have explicitly chosen to associate with you, and  
promiscuously getting bulk address information for everyone.

>   Anyone who knows what an IP address is, and what it does, already  
> knows this.

I've done contract work for Time Warner and Comcast, and they don't  
seem to think so. In fact they made us generate random data for a  
demo instead of an old snapshot containing some live data, because it  
revealed addresses and street numbers (not even names or street  
names) of real customers.