La historia del estándar para la exclusión de robots: Sí, robots.txt

El 30 de junio de 1994, un grupo de aficionados y profesionales llegaron a un consenso para tratar de regular el desarrollo de los robots web (o arañas, o rastreadores), que cada vez recorrían, con mayor frecuencia, una Internet en ciernes. Esta es la historia del desarrollo del estándar para la exclusión de robots, conocido popularmente como robots.txt.

📌 Antes de que empieces a leer: esta es la historia de robots.txt. No vas a encontrar un tutorial de cómo funciona. Para eso podés ir acá.

Traté de resistir, sin evidente éxito, la tentación de comenzar este artículo contando la «simpática» historia de cómo una acción involuntaria de un escritor de ciencia ficción británico, que en su empeño por aprender Perl para hacer más llevadero su trabajo en un ambiente corporativo opresivo, terminó ocasionando la creación del estándar para la exclusión de robots web.

Esta historia la encontré mientras buscaba información para armar esto. Particularmente, se hace una breve mención en la entrada de Wikipedia sobre robots.txt, y Josh, del equipo de Mojeek, la utiliza como introducción en su articulo sobre cómo funciona la indexación en los motores de búsqueda.

El protagonista de la historia es Charles Stross. Stross tiene un sitio web. No tuve una mejor idea que contactarlo directamente para preguntarle si esta historia de él siendo el disparador del estándar, es verdadera o es un mito urbano que terminó propagándose por Internet. Y le mandé el mensaje, pero… me arrepiento 👇

Haciendo una sencilla búsqueda en Mojeek (site:www.antipope.org "robots.txt"), pude encontrar la historia completa en su sitio web.

Me siento mal por hacerle perder el tiempo. Él mismo expone claramente una serie de condiciones que se tienen que cumplir para enviarle un correo. Son condiciones razonables, y aunque me hicieron dudar, se ve que no me amedrentaron lo suficiente y terminé presionando Submit. 

En fin. Voy a dejar que sea el mismo Stross quien te cuente cómo sucedió todo:

« Durante uno de mis períodos de agotamiento decidí aprender Perl por mi cuenta. Así que comencé intentando escribir una araña web, un robot que recorría en profundidad la web para recuperar (y eventualmente indexar) lo que encontraba, o simplemente para descargar páginas (con wget o curl). En aquel entonces no había muchos recursos para los escritores de robots; Internet en el Reino Unido también era bastante embrionario. (SCO EMEA tenía una línea arrendada de 64K en aquellos días, compartida entre 200 personas). Estaba probando mi araña y, distraídamente, le di una URL de inicio cableada. De lo que no me di cuenta fue que había elegido un maldito lugar estúpido para comenzar mis recorridos de prueba; un sitio web sobre arañas, gestionado desde un servidor propiedad de una empresa muy pequeña, a través de una línea alquilada de 14,4K. ¡Supongo que sin querer inventé el ataque de denegación de servicio! Martijn, el tipo que administraba el servidor web, se puso en contacto y quedó muy disgustado. Primero, me dijo que dejara de criticar su sistema, consejo que cumplí apresuradamente. Luego inventó un procedimiento estándar: cuando visite un nuevo sistema, busque un archivo llamado "robots.txt", analícelo y evite cualquier directorio o archivo que enumere. Creo que pude haber escrito la primera araña que obedece el protocolo robots.txt; Ciertamente soy el tonto que necesitaba su invención. (Se puede encontrar la evidencia aquí (busque websnarf).) »

Stross: si se da el improbable caso de que leas esto, perdón por mandarte ese correo sin antes buscar en tu página. 

El lejano oeste

Al principio de la década de los 90, del siglo XX, Internet era utilizado por unos pocos, que tenían el privilegio de acceder a los recursos necesarios para poder consumir y compartir documentos.

Inicialmente, la W(orld)W(ide)W(eb) estaba dominada por los académicos; pero, poco a poco, Internet fue dando paso a empresas y aficionados que también buscaban, por diferentes motivos, tener participación en una red que crecía rápidamente.

No solo las personas e instituciones comenzaban a ser ciudadanos virtuales, también lo hicieron los robots web (actualmente conocidos como bots).

A medida que más servidores se sumaron a Internet, para algunos se hizo evidente la necesidad de contar con sistemas automatizados que pudieran navegar, indexar y organizar la vasta cantidad de información disponible (la verdadera Biblioteca de Babel).

Estamos en el 1994, no hay motores de búsquedas consolidados, solo algunos experimentos de poco alcance, que permiten hacer búsquedas primitivas en un conjunto acotado de servidores.

Es en este contexto, en donde se comenzaron a desarrollar programas informáticos que fueran capaz de recorrer, sin intervención humana, la mayor parte de la red. ¿El objetivo? Ir conformando un índice de todos los sitios / documentos existentes.

La idea no es mala, y así lo demuestran los índices que fueron construidos a lo largo de los años por diferentes bots. Hoy constituyen la base de los motores de búsqueda modernos. Sin embargo, la infraestructura disponible en los primeros años de Internet, no era la ideal para enfrentar los problemas que ocasionaban los robots.

En el documento inicial, publicado en el año 1994, que describe el estándar («A Standard for Robot Exclusion»), Martijn Koster, el CREADOR, dice lo siguiente:

«En 1993 y 1994 hubo ocasiones en las que los robots visitaron servidores WWW, donde no eran bienvenidos por diversas razones. A veces, estos motivos eran específicos del robot, por ejemplo: ciertos robots inundaron los servidores con solicitudes rápidas o recuperaron los mismos archivos repetidamente. En otras situaciones, los robots atravesaron partes de los servidores WWW que no eran adecuadas, por ejemplo: árboles virtuales muy profundos, información duplicada, información temporal o scripts cgi con efectos secundarios (como votaciones). Estos incidentes indicaron la necesidad de mecanismos establecidos para que los servidores WWW indiquen a los robots a qué partes de su servidor no se debe acceder.»

Carga en los servidores

Los servidores noventeros tenían capacidades limitadas. El acceso frecuente y no regulado de los robots de búsqueda podía causar una carga «mortal» en estos servidores, ocasionando el ralentizando de los sitios web para los usuarios humanos, o incluso provocando caídas temporales del servicio.

Acceso a todo el contenido

Cuando surgieron los bots, no había un método estándar para evitar que indexaran contenido específico dentro de un sitio web. Esto implicaba que cualquier información publicada en línea podía ser fácilmente indexada y encontrada a través de los primeros motores de búsqueda, incluyendo aquella que los webmasters preferirían mantener privada o accesible solo para ciertos usuarios.

Desarrollo desregulado (o cómo cada uno hace lo que quiere)

Cada bot podía seguir sus propias reglas para rastrear e indexar sitios web, lo que dejaba a los propietarios de los sitios con poco control sobre cómo se accedía a su contenido y cómo se presentaba en los resultados de búsqueda. Esto podía llevar a problemas de representación incorrecta o uso no deseado del contenido.

Por otro lado, al no tener una organización que compilara «buenas prácticas» en el comportamiento de los bots, estos podían gastar recursos valiosos rastreando áreas de sitios web que eran irrelevantes o redundantes para los propósitos de indexación, reduciendo así la eficiencia general del proceso de rastreo.

En este panorama de falta de orden y ausencia de reglas claras, que podríamos catalogarlo como «el lejano oeste de los robots web», comienza la construcción de lo que hoy conocemos como el estándar robots.txt.

Relajo, pero con orden

El intercambio de ideas de lo que terminó siendo el estándar definitivo utilizado hasta nuestros días, se dio en una lista de correo (robots-request@nexor.co.uk) en donde participaban los creadores de bots y otros interesados en el tema.

El asunto también se discutió de forma abierta en www-talk@info.cern.ch, discusión a la cual tenemos acceso a través de los archivos públicos de w3.org.

Navegando por los mensajes de aquel entonces, podemos ver la forma embrionaria del estándar, en donde se discutían otras cuestiones relacionadas con el control de acceso y regulación del contenido, como lo demuestra el comentario que hace Ted Hardie:

«Martijn, discutiendo la diferencia entre exclusión de robots y notas de etiquetado:

> El etiquetado que estamos discutiendo es bastante diferente. Hay muchos autores de software cliente, con mucho tiempo de comercialización y deseos de no distribuir hacks (con algunas excepciones :-) ya que se utiliza software antiguo durante siglos. Hay muchas visitas de clientes a muchos servidores, por lo que las recuperaciones de /audience.txt serían considerablemente más notorias. Cuando  se trata de etiquetar contenido según la granularidad propuesta por Kidcode, ya no estamos hablando de unas pocas áreas o unas pocas URL por servidor, y puede tener rápidamente problemas de escala. Así que desaconsejaría proponer un /audience.txt como provisional solución.

Mi sugerencia de usar un encabezado HTTP KidCode no provocó muchas respuestas, aunque creo que tiene algunas ventajas: el usuario obtiene la elección, se escala, se puede agregar fácilmente al código existente, se escala, no requiere una infraestructura de terceros y será bastante fácil establecer como estándar ya que es una simple extensión de http. Él también puede coexistir fácilmente con planes comunitarios.

 > Agradecería algún comentario: ¿es la falta de soporte para protocolos?

¿Aparte de HTTP se percibe como un gran problema? ¿UR[CA] implementar la infraestructura requiere tanto tiempo como agregar un encabezado a código existente? ¿Está justificada la prisa por alcanzar una solución provisional? ¿El encabezado HTTP es una buena idea?

Ciertamente, estoy de acuerdo en que el etiquetado que estamos debatiendo es bastante diferente de establecer un estándar de exclusión de robots, y que el

Los resultados contra un /audience.txt serían extensos. Varias cosas podría hacerse a nivel del navegador para minimizar el impacto (marcando encabezados para cambios antes de recuperar el texto de /audience.txt, por ejemplo). Sin embargo, no importa lo que se haga para acelerar las cosas, no hay. Dudo que agregar este paso adicional ralentice los navegadores, ya que necesitaría hacer una recuperación y analizar el texto antes de obtener información real. Presumiblemente, aquellos que utilizan navegadores para llevar a cabo búsquedas en función de audiencia.txt estarían dispuestos a aguantar el tiempo extra. 

No estoy seguro del impacto real que tendrían las recuperaciones de audiencia.txt. tener en el rendimiento del servidor o en la carga de la red. Los archivos robots.txt que tengo vistos son bastante pequeños; sin duda, el audiencia.txt sería más grande, pero probablemente más pequeño que un gif de un solo botón. Sí, como /robots.txt, solo hay un archivo de audiencia.txt por sitio (y un navegador lo descarga solo una vez por sesión, almacenando en caché el resultado), no veo un problema real con tráfico de red o carga del servidor. Esto plantea, sin embargo, el problema de escala; para un sitio grande con mucha información diferente colecciones, mantener un /audience.txt preciso puede ser difícil (Martijn sin duda recordará mis comentarios en ese sentido sobre robots.txt en el contexto de la cosecha de la NASA; por suerte, es demasiadoel caballero para usarlos en mi contra). Ante esa dificultad, el los problemas que se presentan al utilizar una solución basada en archivos para quienes utilizan servidores basados en bases de datos, y los problemas que Martijn señala con tiempo de comercialización para los autores de navegadores, puede ser mejor evitar el audiencia.txt como solución provisional; Siento que funcionaría mejor que un sistema basado en URL, pero estoy de acuerdo en que es inferior al más largo soluciones a plazo. Lo único que realmente veo para recomendarlo es que es (relativamente) rápido de implementar. 

En cuanto a la idea de un encabezado HTTP, propuse Restricciones: encabezado al grupo de trabajo http hace algún tiempo, para tratar situaciones en las que un navegador necesitaba saber qué restricciones de acceso se colocaron en materiales específicos (esto fue en el contexto de la indexación colecciones, y está destinado a permitir que un navegador/recolector determine si un elemento específico estaba disponible para todos los usuarios antes de indexarlo).

Recibí muchos comentarios en ese momento, muchos de ellos negativos. Para resumir algunos de esa retroalimentación: 

1) Algunos sintieron que sería mejor una variación del encabezado Aceptar:

para que los navegadores presentaran lo que estaban dispuestos a ver, en lugar de servidores que describen lo que había que ver y lo dejan en manos del navegador para luego desechar datos que pasaron y no estaban bien (para evitar esto, el navegador tendría que solicitar el encabezado y luego solicitar el documento o piezas que estaban bien.) 

2) Algunos sintieron que las descripciones del documento pertenecían al

campo de palabras clave, y que las restricciones de acceso eran esencialmente descriptivas. El desacuerdo con esto se centró en la idea de que los navegadores sin acceso el servidor les dio información de acceso, y que el uso de palabras clave Significa utilizar dos métodos diferentes para entregar la misma información. 

3) Muchos, muchos de los que respondieron, vieron la propuesta como invitando a la censura y me disuadió de sugerir Restricciones: encabezado por esos motivos.

 Cerca del final de la discusión, se hizo una sugerencia para adaptar el método pragma (actualmente solo utilizado por los navegadores cuando desean insistir en que se recupere el documento original, incluso cuando esté en línea, los apoderados tienen copias disponibles) para este efecto. Dada la prensa de En otros trabajos, no he seguido esta sugerencia en absoluto.

Saludos, Ted Hardie. NAIC de la NASA»

Este correo electrónico, enviado por Ted Hardie 10 días antes de alcanzar el consenso en el grupo que permitió tener listo el primer borrador, muestra las diferentes opiniones que dieron forma al estándar.

El mensaje de Hardie se centra en dos propuestas principales para gestionar el acceso y la clasificación del contenido: una basada en un archivo denominado /audience.txt y otra a través de un encabezado HTTP llamado «KidCode» o un encabezado similar de «Restrictions».

Hardie señala que el etiquetado de contenido propuesto, por ejemplo, mediante /audience.txt o encabezados HTTP, es fundamentalmente diferente del mecanismo de exclusión de robots utilizado en robots.txt.

Mientras robots.txt sirve para indicar a los bots de búsqueda qué partes del sitio no deben ser indexadas, las propuestas de etiquetado tienen como objetivo clasificar el contenido basándose en su idoneidad para ciertas audiencias, lo cual involucra una escala y complejidad que, ciertamente, escapa del alcance del estándar de robots.txt.

Uno de los problemas que se anticipaban sobre la implementación de /audience.txt, es la cantidad de accesos adicionales requeridos por parte de los navegadores para recuperar y procesar esta información antes de acceder al contenido real.

Respecto a esto, Hardie sugiere que, aunque los impactos en el desempeño podrían ser mitigados en parte por técnicas de caché y verificación de encabezados, la introducción de este paso adicional inevitablemente ralentizaría la navegación.

Otra dificultad identificada, está asociada con mantener un archivo /audience.txt actualizado, especialmente para sitios grandes con múltiples colecciones de información.

Este mensaje es solo uno de los tantos que podemos encontrar en la discusión, que ilustra la complejidad y los desafíos que se enfrentaron al momento de desarrollar el estándar de robots.txt.

De esta fase temprana, podemos ver cómo ya existía la discusión respecto a los mecanismos para abordar la protección de usuarios (especialmente menores) y la autorregulación del contenido, resaltando preocupaciones éticas, técnicas y de implementación.

🗃️ En el siguiente documento podés encontrar el hilo completo de las conversaciónes que se hicieron en el grupo por este tema: Agent-mediated access, kidcode critiques, and community standards.

Primeras menciones de meta tag

Dentro de la discusión que venimos leyendo, encontramos un comentario realizado por Stephen D. Williams, en donde propone lo que hoy conocemos como robots meta tags.

Stephen D. Williams dijo lo siguiente:

«> obstruccionismo.Estamos, en el fondo, discutiendo cómo se entenderá el contenido de la Web y cómo interactuaremos con él en el futuro; Estas son preocupaciones tan importantes como inmediatas.

Exactamente. Tenemos la oportunidad de agregar valor a los datos existentes y futuros a través de metadatos.

> Para aquellos que creen que existe una necesidad inmediata de establecer un sistema de etiquetado voluntario y razonable, Martijn Koster y Ronald Daniel han presentado argumentos muy convincentes sobre la necesidad de mantener separados el control de acceso, el etiquetado y la descripción de temas.

Ronald, estoy de acuerdo, aunque no creo que el mecanismo deba estar separado. Sólo deben diferir los valores de los metadatos y la interpretación.

> La discusión de Daniel sobre la URC indica un grupo de trabajo que está tratando este tema de una manera muy convincente y completa.Para aquellos que necesitan algo más inmediato, el trabajo de Martijn con la exclusión de robots puede proporcionar una solución viable y lista para usar. De acuerdo con el estándar de exclusión de robots, los robots buscan un archivo llamado "robots.txt" en cualquier sitio que atraviesen; enumera el agente de usuario, luego la URL parcial.

Mi opinión es que esto podría tomar inmediatamente la forma de archivos .meta. /.meta para todo el sitio, /.../.meta para subárboles y /.../filename.meta 10 para archivos específicos. Con la capacidad adicional de incrustar los metadatos como etiquetas en formatos compatibles (es decir, HTML). Los archivos .meta se pueden recuperar como archivos simples o agregarse automáticamente a encabezados MIME, etc. El uso de los metadatos puede ser multifacético. Ahora sólo es necesario crear ámbitos y sintaxis generales de metadatos y, si se hace con cuidado, se podrá ampliar para adoptar todos los proyectos actuales y futuros relacionados con metadatos. (URC, OCLC, WWW.org, etc.)»

En su mensaje, Williams hace una conceptualización del uso de archivos denominados meta, que podrían ser una alternativa a robots.txt para la gestión de contenido y el control de acceso.

Si bien esta propuesta implicaba la creación de archivos como una forma inmediata de implementar metadatos, que podrían aplicarse a nivel de sitio (/.meta), a nivel de subárbol (/.../.meta), o a nivel de archivo específico (/.../filename.meta), Williams también menciona la capacidad de incrustar metadatos directamente en formatos compatibles, como HTML, lo cual es coherente con el uso de etiquetas <meta> en la práctica moderna de desarrollo web. 

Aunque su propuesta específica de archivos .meta no se adoptó ampliamente como estándar, muchos de los principios que discutió se han materializado de diferentes maneras a través del desarrollo de tecnologías web, especialmente en el uso de etiquetas <meta> en HTML y en la implementación de esquemas de metadatos estructurados como Schema.org.

La evolución del estándar

Según el sitio oficial del estándar, el último borrador disponible, denominado «A Method for Web Robots Control», fue publicado en el año 1997 por Martijn Koster, a través de la organización «Internet Engineering Task Force» (IETF).

Podemos decir que el borrador del año 1997, viene a formalizar el estándar definido en 1994 («A Standard for Robot Exclusion»), profundizando en algunos aspectos, como se puede ver a continuación:

• Criterio: Enfoque y Estructura
  • Versión 1994: Basado en consenso de la comunidad de robots; solución operativa.
  • Versión 1997: Formalización y estandarización como Internet Draft para IETF; especificación más rígida.
• Criterio: Especificaciones Técnicas
  • Versión 1994: Descripción simple del método y directivas básicas de exclusión.
  • Versión 1997: Introduce sintaxis formal (BNF), líneas de "Allow", y detalla interpretación de directivas.
• Criterio: Consideraciones de Seguridad y Cache
  • Versión 1994: No mencionadas explícitamente.
  • Versión 1997: Incluye consideraciones de seguridad sobre la naturaleza voluntaria y el riesgo de engaño; recomienda manejo de caché con expiración predeterminada.
• Criterio: Propósito y Uso
  • Versión 1994: Enfoque práctico para evitar accesos no deseados por robots.
  • Versión 1997: Enfoque en la estandarización para una adopción más amplia y consistente entre robots y servidores.
• Criterio: Ejemplos y Notas para Implementadores
  • Versión 1994: Ejemplos básicos de configuración del archivo robots.txt.
  • Versión 1997: Expande ejemplos, añade notas para implementadores sobre compatibilidad y interoperabilidad, y subraya la importancia de ser liberal en la aceptación de diferentes formatos de archivo.

El estado actual del estándar

Dentro de las preguntas frecuentes que se encuentran en el sitio oficial https://www.robotstxt.org, se menciona que no hay organismos de estándares técnicos como el IETF o el W3C que se encuentren trabajando en robots.txt. Sin embargo, si da cuenta de la intervención de terceros, como ser: Yahoo, Google y Microsoft.

Respecto a la participación de Google. En julio de 2019, la empresa anunció que había trabajado con el equipo original que creó el protocolo de exclusión de robots y con otros motores de búsqueda para documentar cómo el archivo robots.txt debe ser analizado e interpretado por los rastreadores web. 

La participación de Google tenía como objetivo formalizar el estándar para el archivo robots.txt a través de la IETF. ¿El resultado? Un borrador titulado «Robots Exclusion Protocol», también conocido como «draft-rep-wg-topic-00».

En este documento, se propone un estándar formal, incluyendo las reglas para el formato del archivo robots.txt, cómo los rastreadores web deben interpretar las directivas encontradas dentro del archivo, y cómo se deben manejar situaciones como URLs con caracteres codificados o la presencia de sitemaps dentro del archivo.

La última actualización del documento, al momento de escribir este artículo, fue realizada el 6 de julio de 2022. 

Los aportes de Google al estándar

Hice que ChatGPT comparara ambos estándares (1997 vs 2022), y este es el resultado:

• Aspecto: Estado del Documento
  • Versión 1997: Internet-Draft destinado a recopilar comentarios de la comunidad de IETF.
  • Versión 2022: Internet-Draft con el estado intencionado para convertirse en un estándar oficial.
• Aspecto: Sintaxis Formal
  • Versión 1997: Presenta una descripción BNF-like para el formato del archivo robots.txt.
  • Versión 2022: Introduce una descripción Augmented Backus-Naur Form (ABNF) más detallada, buscando estandarizar aún más la sintaxis.
• Aspecto: Caracteres Especiales
  • Versión 1997: Menos detalle sobre el manejo de caracteres especiales y codificación.
  • Versión 2022: Incorpora reglas específicas sobre caracteres especiales, incluyendo el manejo de codificación porcentual y caracteres reservados según RFC 3986.
• Aspecto: Consideraciones de Seguridad
  • Versión 1997: Discute los riesgos asociados al uso del archivo robots.txt y enfatiza su naturaleza voluntaria.
  • Versión 2022: Expande las consideraciones de seguridad, advirtiendo que Robots Exclusion Protocol no debe usarse como una medida de seguridad para controlar el acceso a recursos.
• Aspecto: Manejo de Caché
  • Versión 1997: Recomienda que los robots implementen mecanismos de caché para el archivo robots.txt pero no especifica detalles.
  • Versión 2022: Proporciona directrices específicas para el caché, recomendando no usar una versión en caché del archivo robots.txt por más de 24 horas.
• Aspecto: Consideraciones IANA
  • Versión 1997: No aplicable o no mencionado explícitamente.
  • Versión 2022: Se incluye una sección "IANA Considerations" sin acciones específicas requeridas.
• Aspecto: Extensiones y Registros Personalizados
  • Versión 1997: Abre la posibilidad de extensiones futuras pero sin mucha especificación.
  • Versión 2022: Clarifica cómo manejar registros no especificados directamente por el protocolo, permitiendo cierta flexibilidad para futuras expansiones.

Curiosamente, esta última participación de Google, no está documentada en el sitio oficial de robots.txt. La referencia registrada tiene 11 años menos, y está relacionada con un artículo publicado en el blog de developers de Google, en el año 2008. 

Esto me hace pensar que el sitio oficial de robots.txt, se mantiene activo más por motivos históricos que prácticos, así como también para recaudar algún que otro $ a través de la publicidad que se ofrece a través del sitio; y esto te lo deja bien claro la página de política de privacidad:

«Nuestros socios publicitarios cuidadosamente seleccionados utilizan análisis de rendimiento, técnicas de focalización y estrategias antifraude estándar de la industria. Es decir, no sabemos realmente qué hacen, pero probablemente implique la configuración y el seguimiento de cookies. Si esto le molesta, ejecute AdBlock, desactive JavaScript, desactive las cookies y utilice un proxy anónimo.»

La persona detrás de robots.txt

Si eres un lector habitual de este blog, (avísame porque son  pocos), sabrás qué procuro hacer, aunque sea breve, una mención a o los autores que están detrás de los temas que desarrollo. En este caso, el impulsor y creador del estándar de exclusión de los robots, es el ingeniero holandés, Martijn Koster.

Koster se presenta de la siguiente manera en su sitio web personal:

«Soy desarrollador de software e ingeniero de operaciones y trabajo principalmente en servicios backend de Linux, redes, tecnologías en la nube, Docker y automatización de compilación, lanzamiento e implementación.

 Actualmente trabajo en Apple. Anteriormente dirigí Stalworthy Computing Ltd durante 9 años, con clientes como Lucidworks. Antes de eso, trabajé en Microsoft, Danger, Excite, WebCrawler, Nexor y SHAPE. 

Nací y crecí en Holanda, vivo en el sur de Norfolk en el Reino Unido.»

Es un presentación muy escueta, por que ese señor es responsable de uno de los primeros (si no el primero), motores de búsqueda: ALIWEB.

Aparte de no estar contento con el rumbo de Twitter, razón que hizo que dejara la plataforma del ex pajarito azul, Koster es radioaficionado y tiene una magnífica entrada sobre cómo captar imágenes satelitales, un sueño que pudo cumplir. También es el responsable de un canal de Youtube, con más suscriptores que vídeos publicados.

Gracias Koster. Gracias Stross. Gracias.

Llegaste al final. 

/ Súmate al boletín. No es gran cosa, pero es gratis 👇 /