[sldev] Lookup Tables and Texture Bugs

Argent Stonecutter secret.argent at gmail.com
Thu Jan 25 06:52:12 PST 2007


> Likewise there is a lookup table with keys and addresses. The  
> reason the
> cache is limited in size, has more to do with searching then  
> anything else.
> When you have a lookup table of 16000 items, it is very time  
> consuming to
> find anything in the table. Very few file systems can handle this  
> quantity
> of items gracefully.

I have a program that stores information on IP addresses to detect  
and reject spam, and it has to look them up for every TCP connection  
to my mailserver. It uses a 3 level directory three, with up to 256  
entries at each level. It currently has 451430 entries, one file for  
each IP address, and (for example) the data on 192.168.42.13 would be  
stored in the file C0/A8/2A/0D.dat.

In SL, I would have expected splitting the UUID up similarly to  
create the hashes at each level would be the best solution.

> Minimum security?  I'm sure you do realize you get the IP address of
> your visitors regardless of their security settings.

The problem isn't IP addresses, it's using IP addresses to cross- 
reference information on accounts. The IP address is shared between  
all accounts belonging to the same person, so if you know the IP  
address of a large number of accounts you can identify which accounts  
are alts.

Currently this is not practical, because you have to be a landowner  
to create a "bug" using streaming, and you can only gather IP-to- 
account information on avatars that actually visit your land... a  
tiny fraction of the avatars online. Even if a Land Baron wanted to  
do it, they would be hard pressed to get more than a few hundred  
unique addresses a day. With a texture bug you can gather that  
information simply by teleporting about the grid wearing an  
attachment. If you release a popular enough attachment, you can get  
thousands of unwitting helpers: You could even run a series of alts  
through Help Island and pick people off as they arrived in Second Life.

> This reminds me of the "debate" on the name2key services.  It was  
> silly
> then and it's silly now.

There's no relationship between the keys associated with different  
accounts, so the can't be used as a cross-reference to establish  
which accounts are associated with the same people.

> Even so, most IRC networks still don't cloak by default.  Everyone in
> #secondlife is exposing their IP and nick!  I bet they didn't even  
> think
> twice about it.  It really isn't a big deal.

Again, that's a tiny fraction of the accounts. It's the difference in  
scale that makes this a problem.

> I think, at most, there should be a tick box in preferences to  
> "disable
> http texture fetching".  If someone is that paranoid, they can just  
> look
> at gray goo.  Such a simple and greatly useful feature shouldn't be
> bogged down by bogus security concerns.

It's a useful feature, but the security concerns are real, and  
restricting it to prims in the land group would reduce the problem to  
the level of media bugs.

> Just like the
> client asks you if you want to enable parcel streaming media  
> (once), it
> could ask you once if you want to enable dynamic textures.

That will not substantially reduce the scale of the problem, as has  
been demonstrated over and over on the internet, since most people  
would eventually have to enable it just to (as you say) see a world  
that isn't full of loading textures.

Here's something that would:

> That way people who want full anonymity get it without punishing  
> people
> who aren't paranoid by annoying them with dialog boxes every time they
> attach a HUD.

+----
| The object SpyHud by Ima Greifer requests that you download a  
texture from www.example.com.
|
|    O Always allow or deny SpyHud.
|    O Always allow or deny Ima Griefer
|    O Always allow or deny www.example.com
|    * Allow or deny this time
|
|  (Allow)                    (Deny)
|

> Better maybe, but much more complex to implement, and for users to  
> deal
> with.  How would you even know which one of the 15000 prims with 6  
> faces
> each in the immediate vicinity initiated the request?

* Objects created by you or in the group of the land *you* are on  
would, by default, automatically be allowed.
* Objects owned by you but not created by you would require the above  
dialog by default.
* Objects in the group of the land THEY are on, but in a different  
group than the land you are on, would by default get a slightly  
extended dialog (below).
* All other objects would be denied by default.

+----
| The object Billboard by Advertising Magnate in Advertising Landgroup
| requests that you download a texture from adtracker.example.com.
|
|   O Always allow or deny Billboard
|   O Always allow or deny Advertising Magnate
|   O Always allow or deny objects in Advertising Landgroup
|   O Always allow or deny adtracker.example.com
|   * Allow or deny this time
|
|  (Allow)                    (Deny)
|

This could be implemented and tracked in the client. The client would  
need:

UUID of object (already known)
UUID of the object's creator
UUID of object's owner
UUID of object's group
UUID of the land group for the land the object is on
UUID of the land group for the land you are on (already known)

So at the very least four additional UUIDs should be transmitted to  
the client along with the URL:

UUID of the object's owner.
UUID of the object's group, for objects not owned by you.
UUID of the object's creator.
UUID of the land group for the parcel the object is in, for objects  
not in the same parcel as you.

In addition, it would be useful to have:

UUID of the creator of the script that set the texture.

This information would allow the client to present the dialogs  
listed, without burdening the sim with a great deal of overhead. The  
resulting combination of black- and white- lists would be sufficient  
to prevent the widespread abuse of texture bugs, and be much simpler  
and less intrusive than the more powerful set of restrictions  
suggested by John Hurliman.

As another poster writes:
> Reading below I can only conclude that if all that were impemented  
> then html
> textures are not worth it and should not beimplemented at all.

I can only agree. A scheme of easy whitelisting and blacklisting like  
this is more than enough. As an added bonus, it's already familiar to  
people from browsers and other Internet software. But if that's too  
complex, I agree with:
> Simply making HTML textures the right of a parcel owner
> only (Yes and NOT usable on huds or attached objects with a single  
> on/off
> switch in the UI  as an initial safe step seems advisable.

With HTML textures off by default: the parcel owner would need to  
switch them on.

Another poster with a useful suggestion:
> I have to agree with you on this Argent. A regex whitelist &  
> blacklist of
> urls would be a good addition to your suggestion (Adblock?).

That could be implemented in the client, of course, and I'm sure it  
would be a popular extension.



More information about the SLDev mailing list