Lo efímero del hipervínculo III: Archivos web pasados y enlaces cortos

No puedo proporcionar un índice de los artículos futuros porque voy cambiando de idea conforme los escribo en cuanto a su estructura e incluso contenido, así que sólo incluyo un listado de los anteriores artículos y de los temas que me quedan por tratar:

1-LEDH I, 2-LEDH II. Queda por analizar: extensiones, pasarelas, programas de escritorio, "archivado estilo favoritos"; futuros desarrollos y herramientas; iniciativas públicas, iniciativas empresariales; ventajas de usar los archivadores y problemas a los que se enfrentan.

Intentaré que los futuros artículos sean más breves que el primero para que sean más accesibles. Pensaba que este iba a ser más corto pero al final ha salido también algo largo. Además, la información más útil y práctica está en los dos primeros y algunos de los artículos futuros (y este mismo) son curiosidades y repetiré datos. Por ejemplo, empiezo con una introducción que repasa los conceptos ya explicados en el primer artículo.

Listado: (Introducción). peeep.us, mummify.it, ¿Por qué los enlaces cortos son un problema? (URLTEam), Warrick, Furl, tesoro.io, hiyo.jp, Svonk.

(Introducción)

Según este excelente artículo que aparece en la página de Gwern Branwen: Archiving URLs [1], la descomposición de enlaces será un problema tremendamente generalizado. El artículo está enfocado de manera específica a usuarios más avanzados que yo: propone métodos para detectar y corregir enlaces rotos mediante uso de terminal y programación básica de scripting —y con apéndices con cuestiones tan curiosas como sellado de tiempo (criptographic timestamping)—. Muy interesante también es que incluye un índice con archivadores web como el que hice en el primer artículo y algunos servicios similares (pero no del mismo tipo), que mencionaré en futuros artículos.

Incluye algunas frases lapidarias como:

«Incluso en entornos altamente estables, financiados o "seleccionados" (curated), la descomposición de enlaces ocurre de todas maneras».

Continúa con una perspectiva desalentadora:

«En la estimación más baja de un 3% de descomposición de enlaces, pocos sobrevivirán hasta 2070. Si cada enlace tiene un 97% de posibilidades de sobrevivir cada año, entonces la posibilidad de que un enlace sea funcional en 2070 es de 0.97≈0.16 (o, diciéndolo de otra manera, hay un 84% de posibilidades de que cualquier enlace se descomponga para esa fecha). [...] Si intentamos la predicción usando una estimación más razonable del 50% de descomposición de enlaces, entonces [...] sería una buena idea simplemente asumir que no habrá ningún enlace que sobreviva».

Se ha estimado que hay un 84% de posibilidades de que cualquier enlace actual se descompondrá antes de 2070 incluso con las perspectivas más favorables. Si asumimos un factor más razonable, se puede asumir simplemente que no habrá ningún enlace que sobreviva.

Todo esto pasa con las webs que nos encontramos cada día en Internet. Pero ¿y los recursos físicos u otros recursos digitales? Una genial viñeta de xkcd expone el problema de manera muy contundente:

Y si el problema de los enlaces descompuestos afecta a las webs, a los dispositivos digitales ¿porqué no iba a afectar a los archivos web mismos? ¿Quién archiva al archivador?

2 - Archivadores web que han desaparecido (pasado)

Formulario de captura de URL de Peeep.us, mostrando también otros aspectos interesantes como: 1) poder archivar páginas web que requieren de registro (a través del botón de acción de favoritos) —la característica que definía este servicio—, 2) el inicio de sesión a través de una cuenta de Google y 3) que la URL resultante es alfanumérica.

Nombre: Peeep.us (versión archivada).

Fecha de lanzamiento y de defunción: 2009-2015 / 2015-2018.

Descripción: En el caso de peeep.us su desaparición estaba pronosticada con bastante anterioridad a su caída definitiva. En alternativeto.net aparecía como no disponible años antes de que esto pasara (debido, probablemente a la interrupción del servicio de la mayor parte de 2015). Posteriormente, era necesario una extensión, Disable Content-Security-Policy (en Chrome), para poder usarla, con las consiguientes quejas del navegador (y en general de privacidad, por tener que hacer la transmisión de datos a través de una conexión https rota a propósito). El golpe final vino dado porque Google, Facebook, etc., detectaban como malware el contenido de peeep.us seguramente debido a un uso intensivo de dicha plataforma como medio de phising, alojamiento de malware, etc. Después de 2015 estaba alojado en Google Apps y seguramente fuera Google quien decidiera cancelar la cuenta.

Mi búsqueda en Google acerca del tema sólo arroja un artículo que escribí sobre mi uso de peeep.us en una base de datos de iconos que tengo. Como Peeep.us estaba alojado en Google Apps, seguramente Google decidiera cancelar la cuenta.

Cuentas: Antes de 2015 permitía su uso de manera anónima. Después de los problemas que tuvo el sitio en 2015 se eliminó la posibilidad de archivar anónimamente requiriendo una cuenta de Google.

Ventajas: En cualquier caso tenía varias características que la hacían muy interesante. Una de ellas era poder archivar un sitio web una vez conectado a dicho lugar, lo que si seguían prácticas seguras (cambiar contraseña, etc.), abría la puerta a poder archivar contenido que no se podía de ninguna otra manera (archive.is limita mucho el número de archivos diferentes a imágenes o a texto que se pueden archivar en su plataforma). En una época en la que yo no conocía la existencia de WARCreate servía de "pasarela" para archivar documentos en Wayback Machine. Una página web con robots.txt, una vez archivada con peeep.us podía ser incluida en WM.

También era una vía para archivar Flickr cuando aún no existía WR (Webrecorder) e incluir ese archivo en archive.is (con una relación de los enlaces) o en WM.

Desventajas: La necesidad de utilizar una extensión (al final de su existencia) para eliminar una política de seguridad incluida por defecto en Chromium no era cuestión baladí. Al fin y al cabo, un script que rompe la seguridad HTTPS de una página se podía utilizar masivamente para robar datos o que terceros (teniendo la información adecuada) capturasen todo el tráfico intermedio. Que se haya utilizado como plataforma para realizar phising o como almacén de malware tampoco eran puntos a su favor. Otro punto destacable es que "se reservaban el derecho a eliminar contenido que no haya sido accedido en un mes" (aunque no vi cumplir eso con mis enlaces). Ya en 2017, cuando comencé a escribir esta serie de artículos, debido a que percibía la fragilidad de peeep.us, todos los enlaces que archivaba allí los archivaba en otro servicio adicional.

Las páginas podían ser modificadas antes de su archivo mediante edición HTML y conocimientos de JavaScript. En futuros artículos trataré sobre este problema, más grave de lo que pensaba antes de investigarlo, cómo detectarlo y evitarlo.

Que haya una página de acceso entre tus datos y el exterior del servicio, nunca debería ser motivo suficiente para pensar que esa información está a salvo de ser archivada.

Otra desventaja es que la URL era alfanumérica.

Otros datos: Aunque alguien pueda argumentar que es una desventaja (o falla de privacidad) poder tener acceso al "interior" de un servicio, exponiendo conversaciones privadas, etc., esto no es del todo así. La falla de privacidad es anterior, es que esos datos lleguen a ambientes semipúblicos de redes sociales. Existen empresas dedicadas a este tipo de archivado (PageFreezer —diferente de FreezePage—) que no tienen ningún problema a la hora de registrar estos datos. Tampoco los programas locales como WAIL, la extensión WARCreate o simplemente guardar la página, presenta dificultad alguna para realizar estos archivos (archivadores web como Webrecorder.io sí tienen problemas para archivar dicho contenido, pero se pueden superar haciendo modificaciones a las cookies, aunque eso obviamente no está al alcance de cualquiera). La diferencia entre guardar una página mediante el botón derecho del ratón o hacerlo mediante "servicios WARC", es que dichos archivos se pueden ver en línea por más personas que las originales. Que exista la necesidad de registrar un usuario entre tus datos y el exterior del servicio, NUNCA debería ser motivo suficiente para pensar que esa información está a salvo de ser archivada. Un ejemplo concreto de ese pensamiento erróneo lo promueve Mark Zuckerberg (asociado también con la creencia de que si está disponible poco tiempo es privado).

Peeep.us fue bloqueada en Rusia en 2015 debido a su «contenido de materiales con copyright, materiales extremistas y materiales que vulneraban la ley rusa: "Sobre la protección de los niños contra la información que es perjudicial para su salud y desarrollo"», que puede hacer referencia a pornografía (ilegal) de diverso tipo.

Acusaciones similares se han realizado en contra de otros archivos web. Por ejemplo en Reino Unido, actualmente los ISP como Vodafone, Three, O2 y EE bloquean todo archive.org con motivo de los filtros de "pornografía"). Internet Archive/Wayback Machine también ha sido atacada, bloqueada y ha sido acusada en varias ocasiones de albergar contenido terrorista sean estas acusaciones verídicas o no [2].

Por lo tanto cualquier acusación en este sentido (aunque es seguro que sí hay contenido extremo de ese tipo en los archivos) hay que tomarla con algo de escepticismo, sobre todo si su denuncia se produce a todo un archivo y no se discriminan las URL infractoras.

Página de inicio de mummify.it en 2014 mostrando un ejemplo de uso. Ironía pura. Eso sí, el logotipo y el nombre me encantan.

Nombre: Mummify.it (versión archivada).

Descripción: Debido a que desapareció antes de que usara este servicio y no hay información más que la que daban en su página web, no puedo decir mucho. Sí que es interesante leer su página principal donde se recogen varios datos a cada cual más irónico: por ejemplo, cómo archivan una versión de archive.org de una página web (posterous) que ya no existe o que su modelo de negocio era sostenible a largo plazo.

Utilizar códigos alfanuméricos para substituir la dirección de una página web nunca es una buena idea.

Problemas: En este archivo web (y en otros como peeep.us o la todavía existente perma.cc) se utilizan/ban códigos alfanuméricos para reemplazar la URL de una web. Aunque la idea de redireccionar la página mientras exista y cuando dé un error 404 utilizar la versión guardada es buena, (y es lo que se implementa en los Robust Links), no es recomendable usar las versiones acortadas que da un servicio, porque si desaparece no podremos conocer cuál era el enlace original que, a lo mejor, se podría recuperar por otros medios. Obviamente, si dicho enlace corto se acompaña de la versión original (tal como recomendaba WebCite) pues no habría problema. Una "solución" podría ser el agregar un fragmento con la URL (?url=URI): ejemplo, pero entonces ¿para qué queríamos el enlace corto en primer lugar?

Foto de pantalla de la página del URLTeam Tracker el 13 abril de 2019 a las 07:06:21.

¿Por qué los enlaces cortos son un problema?

Pero los enlaces cortos no sólo generan un potencial problema de descomposición de enlaces. También generan otro tipo de problemas [3]: de privacidad: documentos que no están indexados por los buscadores pero sí se ha acortado sus URL son de facto públicos, debido a que los servicios de acortamiento de URL son vulnerables a escaneos masivos [4]. Otro ejemplo es que puede servir para rastrear la procedencia de quien pincha en el enlace. Yo mismo, en vez de usar la URL de mi blog en mi perfil de menéame uso una versión "acortada" (bit.ly/tuscriaturas-mnm), para saber vuestra procedencia y el número de visitas que vienen de aquí :P ; seguridad (se produce una ocultación de la URL de destino, con el consiguiente peligro de exposición a troyanos, malware, mineros de criptomonedas, rastreo, secuestro de tráfico), bloqueo (hay páginas web que bloquean esos enlaces), generan desinterés en los usuarios, o malgasto de recursos (no sólo tardan más en cargar los recursos enlazados a través de servicios de acortamiento de enlaces sino que se duplican o triplican las peticiones (búsqueda de DNS, peticiones HTTP adicionales) y, si se piensa en escala, generan un gasto de energía adicional perfectamente evitable.

En noviembre de 2009 los enlaces acortados de uno de estos servicios fueron accedidos 2.1 mil millones de veces. La cosa desde entonces no ha hecho más que empeorar.

El concepto y la idea detrás del acortamiento de enlaces responde a la situación de que los seres humanos no tenemos la capacidad de diseñar URL cortas, con un diseño claro. Algunas veces hay motivos técnicos o de espacio pero en otras ocasiones están detrás desarrolladores web cortos de miras o gerentes de proyectos a los que simplemente les importa una higa (o un bledo) [3].

Archive TEAM ha creado URLTEam para combatir este problema, archivando miles y miles de correspondencias entre la URL corta y la URL larga.

Otros archivos web pasados

Warrick (de la Old Dominion University) era un servicio algo diferente que permitía recuperar una página entera haciendo una petición y esperando el procesado de Warrick. No tenía versión en línea, sino que cada archivo era preparado individualmente, después de su confirmación a través de un enlace enviado al correo electrónico. Mediante una clave se proporcionaba al usuario en na descarga en formato .tar.gz (comprimido) con los datos recuperados de las páginas solicitadas. El servicio web desapareció en 2014, pero el programa no ha desaparecido sino que se puede encontrar en github. Al ser sofware libre (GPL), cualquier persona o institución que desee redistribuirlo, modificarlo, adaptarlo o, incluso, montar un servicio comercial utilizando este código podría hacerlo.

Un servicio actual similar activo en la actualidad sería Archivarix, con una vocación comercial.

Furl. Por la apariencia, un servicio de marcadores con algún tipo de preservación.

tesoro.io. Similar y parece que la dirección propia de lo archivado era alfanumérica.

hiyo.jp. Archivado web (no sé de qué manera) y acortador de enlaces.

Svonk. Archivo web misterioso lanzado en 2009 en modo beta. En 2013 dejó de estar disponible y su autor anunció que "estaba buscando un mercado" para posiblemente volverlo a lanzar. Encontré un tutorial en YouTube.

Problemas: Es necesario que surjan nuevos archivos web independientes cada cierto tiempo, pero cada vez es más difícil que tengan éxito en un mercado amplio pero ya muy diversificado. Es útil desconfiar de las promesas de sostenibilidad de los proyectos, aunque provengan de instituciones de confianza como universidades. Los proyectos aún existentes que están avalados por empresas o que sean obscuros en este aspecto podrían presentar problemas a corto o a largo plazo (archive.is, freezepage, megalodon.jp, etc.).

Bibliografía en línea

[1]: Branwen, G. (10 de marzo de 2011). Archiving URLs. Gwern.net. www.gwern.net/Archiving-URLs . Consultado el 25 de marzo de 2019.

[2]: En Menéame: Agencias europeas reportan falsamente más de 550 enlaces de Archive.org como "contenido terrorista". [EN]. Original: Butler, C. (10 de abril de 2019). Official EU Agencies Falsely Report More Than 550 Archive.org URLs as Terrorist Content. Internet Archive Blogs. blog.archive.org/2019/04/10/official-eu-agencies-falsely-report-more-t . Consultado el 11 abril de 2019.

[3]: Jacek, J. (12 de mayo de 2011). Why URL shortening services and shortURLs are bad. Rield.com - The Crawltrack Blog. Versión archivada del 25 de octubre de 2013: web.archive.org/web/20131025182943id_/http://rield.com/faq/why-url-sho . Consultado el 26 de marzo de 2019.

[4]: Grauer, Y. (20 de abril de 2016). 5 Reasons You Should Stop Shortening URLs. Forbes. www.forbes.com/sites/ygrauer/2016/04/20/five-reasons-you-should-stop-s . Consultado el 12 de abril de 2019.

Créditos

Imagen I: xkcd: Digital Resource Lifespan. Traducido por Jakeukalane. Licencia: CC-BY-NC. Tipografía: xkcd font.

Resto de imágenes: Capturas de pantalla realizadas por Jakeukalane. Licencia: dominio público.