La tabla "w" permite que los usuarios posean una IP Virtual Personalizada a su gusto, de la forma: "xxxxxx.xxxxxx.PERSONAL.virtual", donde "PERSONAL" es una elección del usuario, y "xxxxxx.xxxxxx" es la IP cifrada del usuario.

Por una decisión puramente comercial (que no ha dado sus frutos) se decidió prescindir de la IP cifrada del usuario en las IPs personalizadas, pretendiendo con ello que fuesen más atractivas a los usuarios. Como ya he dicho, no se ha conseguido ese efecto.

Ese cambio, aparentemente nímio, tiene importantes consecuencias:

• El usuario puede personalizar su IP de la forma "xxxxxx.xxxxxx.virtual", de forma que parezca que no tenga una IP personalizada y pudiéndose hacer pasar por cualquier usuario. Es decir, puede simular que tiene la misma IP que otro usuario, aunque no pueda saber cual es.
• El usuario puede alterar su IP virtual personalizada de forma arbitraria y en cualquier momento, por lo que es imposible seguirle la pista, ya que su IP real no aparece por ninguna parte.
• Como consecuencia del punto anterior, el usuario puede saltarse cualquier baneo, en cualquier canal.
• Para poder analizar cualquier problema, es preciso tener acceso a los logs de los "services".
• Muchos bots "normales" lo pueden tener "complicado" para implementar controles de acceso, sin poder ver la IP.
• Personas distintas con IPs reales distintas, pueden tener la misma IP virtual personalizada, siendo indistinguibles.
• La necesidad de filtros en la elección de la IP virtual personalizada se vuelve ya no una opción, sino una absoluta necesidad.

Por todo lo anterior, yo (jcea) siempre me he opuesto a este cambio, pero se decidió hacer el experimento.

La elección entre el formato largo y corto de la IP virtual personalizada se controla mediante la base de datos distribuída. En concreto, la clave "ocultar.ip.cifrada.en.la.virtual2" en la tabla "z".