El problema de tinyurl y otros servicios similares (reciclando)
Curiosamente hace poco en una lista en que participo pedí que usaran TinyUrl, olvidando lo que escribí hace un tiempo sobre lo problemas de este servicio, un tema que ha resurgido en estos días y que se puede constituir en un problema de seguridad serio. Aca vá, reciclado, y con alguna mejoras, mi post del 27 de diciembre de 2007:
El problema de tinyurl y otros servicios similares
Este post estaba en borrador, y ahora lo completé como respuesta a una pregunta de FT via twitter,
Si algún día TinyURL o Dev.cl dejan de prestar servicio... ¿mueren todas las URLs cortas creadas?
La respuesta corta es Sí.
Incidentalmente, cuando traté de acortar la url de este post dev.cl me devolvio la url http://dev.cl/.
Ahora la respuesta entretenida:
Aunque las urls cortas tienen varias aplicaciones y ventajas, incluso sirven para comprimir imágenes ;) la verdad es que hay varios problemas:
Jeff Atwood resume varios de estos problemas:
- Si el servicio desaparece, las urls quedan rotas para siempre. Tal como teme FT.
- El otro problema es la calidad del servicio, efectivamente un servicio de este tipo que funcione esporádicamente (con "apagones") puede ser una situación aún peor.
- Se pierde la cualquier pista sobre el contenido de la url, al ser todas esta homogéneas, y estar resumidas en un codigo críptico. Esto es malo para la experiencia usuario del que está haciendo click en el enlace (y para la seguridad), porque la url no te da pista de adonde llegarás.
- Hay servicios de redireccionamiento de urls que han sido usados en formas cuestionables, por ejemplo spammers (fue el caso de lnk.to).
Otros problemas que Atwood no identifica son:
- La redirección introduce latencia.
- Una url reducida puede ser usada para hacer phishing.
- Se convierte en una capa por sobre el DNS.
- Es una brecha de seguridad, puede ser usada para inyectar un XSS, por ejemplo.
- No es bueno usar esto para cosas como ajax, o web services.
- Si tu firewall o proxy reverso bloquea el servicio lo hace inutilizable
- El servicio puede estar lleno de basura, como urls que ya no estan vigentes, al perder la pista no te enteras hasta que haces el click.
- Si una url falla no sabes si es el servicio de compresion el que falló o si la url original la que tiene problemas.
- Tinyurl no maneja bien algunas "urls extrañas" con caracteres como la coma (',').
A pesar de esto, las urls cortas son útiles en diversos contextos, como lo demuestra su uso en twitter, o para enviarlas en emails, o en mensajes SMS.
¿Por qué Google no provee este servicio?
Esa es una buena pregunta, y como dice Atwood, probablemente esto le
daría mayor seguridad al servicio.
A lo mejor han analizado el problema y no ven el negocio para este
servicio, o no quieren complicarse con el problema de los spammers.
Aunque sospecho que no quieren ponerse en una situación tan incomodamente hegemónica.
Una alternativa sería descentralizar el servicio, una especie de P2P de urls cortas, una idea que no he explorado, pero puede ser interesante.
(Lo que sí he explorado es la idea de eliminar el DNS, pero eso quedará para otro post.)
Quizás un análisis interesante sería ver que pasa con estos servicios y el principio de que las urls cools no cambian (expuesto por Tim Berners Lee).
En primera instancia uno pensaría que al agregar un nivel de indirección
esto servicios pueden ayudar a preservar este principio, pero si
observamos con mayor detención, en realidad complican más el problema.
Efectivamente, si la url inicial cambia, además hay que propagar ese
cambio a todas las urls cortas de todos los servicios de este tipo.
Ahora bien, el problema de la persistencia de las URLs es más complejo aún, y la caida de servicios tipo tinyurl es sólo una clase de los problemas asociados a la persistencia de las URLs.
¿Cómo implementar un servicio como este?
Ahora, para finalizar, déjenme criticar la propuesta de Atwood de usar hash como mecanismo para generar URLs cortas.
Aunque a primera vista parece bueno (algoritmo O(1)), no parece la forma más práctica para implementar este servicio. Los hashes que muestra generan strings mucho más largos que los que observamos en estos servicios.
Mejor optar por un algoritmo O(N log (N)) como el siguiente:
- Existe una tabla URL, indexado por ID y URL_LARGA
- Se recibe una url y se busca por URL_LARGA obteniendo ID o NULL.
- Si se obtiene NULL se inserta un nuevo elemento en la tabla y la URL corta sera la raiz del sitio mas el ID expresado en base 64.
Que nos permite generar urls bastante cortas, y es facil de
implementar.
No creo que sea fácil encontrar una función hash que genere strings más
cortos que los que genera este algoritmo.
Como Tip adicional, en vez de realizar la redirección usando PHP, o Python, yo optaría por escribir un modulo apache en C, o en PERL, esto aceleraría en al menos un orden de magnitud el servicio (si es que no más). O quizás creando mi propio servidor web. Y por último, trataría de mantener la tabla en memoria, o al menos un caché de las URLs más visitadas. :::
::: {.comments}
¿Te gustó? Danos tu auspicio en Patreon Become a Patron! :::
::: {.comments}
Comentarios
::: {#disqus_thread aria-live=“polite”} Please enable JavaScript to view the comments powered by Disqus. ::: ::: ::: :::
::: {.row} ::: {.col-sm-offset-1 .col-sm-10} [La Naturaleza Del Software]{.small} [© Eduardo Diaz Cortes]{.small}
[Publicado usando Prosa - release 0.3.9]{.small} ::: ::: ::: :::
