Spanish | English

Description:

Animal Captcha is a PHP program created for web developers who need a secure spam control for HTML forms. It displays a random image picked from a list of animals which only humans can recognize.

• Try the example! (in English and Spanish)

Advantages:

• Nice look: better than an ugly alphanumeric string.
• Fast: users can identify an animal faster than several mixed letters.
• Effective: less wrong answers.
• Secure: the main reason. Some alphanumeric captchas you can find on the Internet are really difficult to be recognized by a bot, but with an animal it’s almost impossible!
• Multi-language: available in some languages, multiple valid names for each animal.

Español | Inglés

He aquí la primera versión pública del captcha gráfico que desarrollé para el formulario de registro de Blogs Teoriza.

• Prueba online! [en Español (de España) e Inglés]

Introducción:

Cuando me enfrenté al gran desarrollo del sistema de usuarios quise destacar de los demás formularios. Ante todo quería que fuese usable, sencillo y al grano. En definitiva minimalista, fiel a mi tendencia evidente.

Por supuesto el formulario de registro debe tener un control captcha, es decir, un obstáculo que solo es capaz de sortear un humano. Solo así puede estar protegido un formulario en Internet. Y aquí entra en juego este programa que hoy tengo el placer hacer público, muy fácil de implementar.

Descripción:

Animal Captcha es un pequeño programa en lenguaje PHP, orientado para su uso en páginas web, que permite adjuntar a un formulario una imagen aleatoria de un animal que cualquier humano conoce, y sin embargo un robot es incapaz de identificar.

Ventajas:

• Belleza: es más agradable ver una foto de un animal que un código alfanumérico.
• Rapidez: los usuarios ahorran tiempo, ya que se tarda mucho menos en identificar y escribir un animal conocido que un código aleatorio de 5 cifras, por ejemplo.
• Efectividad: los usuarios aciertan con más probabilidad, aportando una excelente experiencia.
• Seguridad: esta es la razón principal, en Internet hay desarrollos que consiguen resolver algunos captchas de códigos alfanuméricos, con cierto éxito. Sin embargo, ojalá pudiese una máquina identificar a un animal! Es imposible teóricamente. Aunque la aleatorizacion de imágenes, para que sean únicas, puede no ser firme.
• Multi-lenguaje: permite responder en varios idiomas, incluso varios nombres para un mismo animal (ejemplo: halcón y águila son equivalentes).

Desde hace años compro habitualmente en Internet. Con el tiempo he tenido que aprender a identificar un sitio web, instintivamente, para saber si es fiable o hay un riesgo en la compra.

En estos años he tenido experiencias de todo tipo: tiendas online que envían productos a contrareembolso sin más verificación, pago por transferencia bancaria/internacional(IBAN)/Paypal, devoluciones de dinero, paquetes perdidos, artículos estropeados, reparaciones en garantía… y hace unos días, el timador de eBay.

Como en todas las primeras veces, uno siente el riesgo de que le hayan timado y vaya a perder el dinero (más bien el artículo que se necesita). Ese miedo aparece en cualquier paso del proceso, por simple que sea, ya que muchas veces no se tiene una fuente de referencia o experiencia a la que agarrarse.

He de decir que mi experiencia en general ha sido excelente. Nunca he perdido ni un euro, y puedo decir que he conseguido ofertas notables, a veces abismales respecto a los precios del MundoReal. Pero esto ya es otro tema, para otro día.

Hace unos días tuve un accidente con un timador de eBay. Encontré una buena oferta de un ordenador portátil, y gané la puja a un precio excelente, demasiado barato, sobre todo para un particular.

Desde el primer instante tuve desconfianza con esta transacción.

Los indicios fueron los siguientes:

1. El usuario tenia 0 votos, registrado hacia menos de 30 días.
2. Precio demasiado pequeño para ser un particular.
3. Producto nuevo, con garantía.
4. La especificaciones estaban traducidas automáticamente (ponía cosas como Dual-Corazón de procesador, jeje).
5. Había vendido unos 4 artículos, al mismo tiempo, todos de alto valor (entre 400€ y 1500€).
6. Las pujas eran atípicamente bajas, denotando una desconfianza generalizada por parte de los demás compradores.
7. Sus respuestas las envió desde su correo personal, no desde el sistema de eBay.

Ahora me estoy dando cuenta de que no debí seguir adelante con esta compra. Era evidente. Aún así decidí que iba a llegar hasta el final de este embrollo.

Gané la puja y procedí con la petición del total a ingresar. Pero hice unas cuantas preguntas al vendedor. ¿Tiene la tecla ñ? ¿Está en su embalaje original?

Rápidamente me respondió a las preguntas, afirmativamente. Aquí es cuando mis sospechas empezaron a consolidarse, demasiado bonito.

Le respondí que de acuerdo, pero antes le pedí una prueba. Siempre con amabilidad, le pedí un par de fotos del portatil en los que apareciese el también, sin la necesidad que aparezca su rostro, tan solo para darme confianza.

Pensé que aquí el posible timador se rendiría mostrando su verdadera cara, pero no. Me envió 5 fotografías (como la adjunta). En ellas se ve el portátil y su mano supuestamente. Pero ahora, pensándolo mejor, parecen ser fotos de una secuencia de un vídeo promocional de ese portátil.

En definitiva, me vi en una encrucijada. Por una parte muchos indicios indicaban un fraude inminente pero por otro lado, nunca me habían timado, suele haber buen rollo y el personaje parece responderme con normalidad, incluso aportando fotos… y porqué no, tenia ansias de tener ese portátil.

Siendo sincero, estuve a punto de pagar. Una vez pagas, has perdido el dinero, el timador gana y se esfuma. (si lo haces por PayPal se supone que te devolverían el dinero).

La solución:

Pero a Mia se le ocurrió una genial idea, la solución definitiva a casos de timos en eBay.

Resolverlo es tan sencillo como decirle que quieres que envíe el producto a contra-reembolso y que tu (el comprador) se hace cargo del coste adicional de este servicio.

Así lo hicimos y el timador se esfumó de la faz de la Tierra.

Segunda parte de una serie de artículos divulgativos sobre una de mis aficiones de mi trabajo, optimizar la carga web.

Parte II: Gzip estático

El único problema que tiene la compresión con Gzip (explicado en la Parte I) es que sacrifica consumo de CPU a cambio de obtener archivos 4 o 9 veces mas pequeños. En mi opinion realmente ahorra CPU, sin embargo existe esa delgada linea de rendimiento.

La solución que he desarrollado soluciona por completo este problema.

Ventajas:

1. Elimina la necesidad de comprimir Gzip on-the-flight (en cada petición). Solo se hará una sola vez, cuando se genere una caché del archivo.
2. Ahorra de 4 a 9 veces espacio en disco, ya que reduce el tamaño de los archivos. Para una caché es magnifico, como explicaré en el ejemplo práctico.
3. Permite activar el nivel más potente de compresión (9) sin ningún miedo a colapso, ahorrando un poco más de espacio en disco, CPU por transferir más rápido y tiempo de carga.
4. Además conserva todas las ventajas del Gzip (explicadas extensamente en la Parte I)

En qué consiste:

Consiste en guardar una copia pre-comprimida del archivo a transferir. El concepto es sencillo, evita la necesidad de comprimirlo al vuelo (on-the-flight) cada vez que se pide ese archivo de texto plano como ocurriría con Gzip normal.

Esto alivia radicalmente el consumo de CPU conservando, incluso aumentando la ventaja de comprimir a más nivel.

Ejemplo práctico:

La herramienta más usada de Blogs Teoriza es el Caché Web. Para el que no lo conozca es una sencilla aplicación web que genera una copia en texto plano de una pagina web dada.

Ahora funciona con este nuevo método. Con ello doy un paso de gigante en cuanto a rendimiento, uno más ya que conseguí desarrollarlo sin uso de MySQL y con apenas 10 lineas para presentar cada caché. Sin embargo permanecia la poca ventaja del gasto de CPU al comprimir las paginas.

Ahora las comprime una sola vez, cuando genera cada caché. Sirviendolas sin apenas procesar. Ligerísimo.

Antes aseguraba que aguantaba cualquier avalancha de visitas extremas… ahora ya doy por sentado que jamás conseguirán colapsarlo.

Ejemplo del resultado:

• Caché de este mismo post, como puede verse perfectamente aquí.
• Corresponde a este archivo Gzipeado que probablemente no verás bien porque esta comprimido.

Donde aplicarlo:

Recomiendo usar esta metodología para los siguientes casos:

• Cachés de cualquier tipo. (especialmente útil al ahorrar también tremendo espacio en disco)
• CSS y javascript: en la mayoría de los casos estos archivos son totalmente estáticos y rara vez son modificados. Por lo tanto son candidatos perfectos a ser pre-gzipeados y ahorrar así enormes gastos de CPU.
• Cualquier archivo en general que cumpla estas tres condiciones:
  • Texto plano. (html, css, javascript…)
    
  • Contenido estático (cuando no tiene variables, cuidado con formularios).
  • Pocas modificaciones.

Cómo aplicarlo:

La clave del asunto es la función gzencode($datos, 9) para PHP.

Usándola de la siguiente manera se crea una copia de un archivo con terminación .gz y comprimido con Gzip al máximo en el disco duro del servidor.

<?php
if ($_GET[”archivo”]) {
$file = $_GET[”archivo”];
$data = implode(”", file($file));
$gzdata = gzencode($data, 9);
$fp = fopen($file . “.gz”, “w”);
fwrite($fp, $gzdata);
fclose($fp);
}
?>

[Aviso: este código es una herramienta sencillísima de ejemplo para generar archivos pre-gzipeados.]

Pegando este código en un archivo PHP, por ejemplo gziper.php y dando los permisos de escritura (777) correspondientes vía FTP podrémos crear versiones Gzipeadas de cualquier archivo que se encuentre en ese directorio ejecutandolo de la siguiente forma:

http://www.tuweb!.es/gziper.php?archivo=style.css

Con esto obtendremos la creación de un nuevo archivo style.css.gz pre-comprimido con Gzip.

Una vez creado el archivo, recomiendo enmascararlo con .htaccess. También se puede mejorar un poco la cosa, detectando si el navegador acepta Gzip para descomprimir el archivo en su defecto.

Otro punto a tener en cuenta es que hay que modificar la cabecera del archivo. Se resuelve desde .htaccess o fácilmente añadiendo esta linea PHP al principio del código:

header(”Content-Encoding: gzip”);

@include(”style.css.gz”);

Y eso es todo para una interesante Parte II, espero que sirva a la comunidad.

Este es el primer artículo de una serie de métodos que he conseguido implementar con éxito ahorrando CPU y transferencia, haciendo que mis servicios web soporten más lectores online, sirviendo más rápido y con menos hardware.

Parte I: Compresión Gzip

Este método ya es bastante familiar, casi todo el mundo que lo necesita realmente lo utiliza, pero no lo aprovecha al máximo.

La compresión Gzip hace que el servidor comprime los archivos de texto antes de transferirlos, reduciendo su tamaño entre 5 y 9 veces el original. Como por arte de magia consigue que la información que envía el servidor hacia el cliente sea notablemente menor.

Por ejemplo, un archivo que pesa 68 Kb gzipeado se queda en 9 Kb ahorrando mas de 7 veces el tamaño

Conseguimos de un plumazo tres enormes ventajas:

1. Mayor capacidad de carga: ahorrando tiempo en transferir archivos se minimiza la carga de CPU y RAM del servidor.
2. Mejor velocidad de carga: al transferir menos información las paginas cargarán bastante más rápido, la experiencia de tus usuarios será mejor y evade la necesidad de que el server esté en el país objetivo.
3. Considerable ahorro de dinero: el gasto elemental de un servidor web es la transferencia mensual, esta se mide en Gb/mes. Comprimiendo con Gzip el ahorro será tremendo.

[Curiosidad: existe una supuesta delgada linea de eficiencia, algunos dicen que activando Gzip on-the-flight se gasta más CPU que en modo normal. Por mi experiencia pienso que se ahorra CPU, sin embargo en la Parte II explicaré un método muy interesante para hace Gzip estáticamente (mas magia)]

Puede parecer trivial, ya que mucha gente lo conoce y lo aplica. Sin embargo mi truco “avanzado” es que recomiendo activar Gzip en TODOS los archivos planos y no solo a las páginas HTML como veo en la mayoría de webs. Cualquier archivo plano se debe gzipear, me refiero especialmente a archivos html, estilos css y archivos javascript. El ahorro triple será más significativo aún.

Distintos métodos para implementar Gzip:

• Con Wordpress: es fácil, Opciones > Lectura > Marcar opción Gzip (abajo). Sin embargo el error común es olvidarse aquí del tema, un error porque con esta opción solo consigues comprimir las páginas html olvidandote del archivo css y posibles javascripts.
• Con PHP: para comprimir una página html donde puedes ejecutar PHP has de añadir estas lineas de código al principio de cualquier proceso:
  

  <?php ob_start(”ob_gzhandler”); ?>

  Al final de cualquier código:

  <?php ob_end_flush(); ?>

• Para CSS y javascript (recomendado)
  En .htaccess

  AddHandler application/x-httpd-php .css .js
  php_value auto_prepend_file /home/… RUTA LOCAL …/public_html/gzip-start.php
  php_value auto_append_file /home/… RUTA LOCAL …/public_html/gzip-end.php
  

  En gzip-start.php

  <?php ob_start(”ob_gzhandler”); ?>
  

  En gzip-end.php

  <?php ob_end_flush(); ?>

• Combinando htaccess + PHP: poner en .htaccess:
  

  php_flag zlib.output_compression on
  #Con el numero se controla el nivel de compresion donde 0 es null y 9 el maximo
  php_value zlib.output_compression_level 5
  AddHandler application/x-httpd-php .css .js
  #Poner una ruta local cualquiera hacia un archivo php
  php_value auto_prepend_file /home/…/public_html/gzip-head.php

  Crear el archivo gzip-head.php con el siguiente contenido:

  <?php
  $pathinfo = pathinfo($PHP_SELF);
  $extension = $pathinfo[”extension”];
  if ($extension == “css”) {header(”Content-type: text/css”);}
  if ($extension == “js”) {header(”Content-type: text/javascript”);}
  ?>

Y esto es todo…

En la Parte II explico un interesantísimo metodo para comprimir con Gzip estáticamente, en vez de on-the-flight gastando 0 CPU en comprimir cada pagina, completando el circulo de eficiencia perfecta.

En Marzo de 2005, en mi época de IRC. Enredando en este tipo de chat (hoy en declive) perdía el tiempo aprendiendo a programar un lenguaje de puertas cerradas llamado scripting de mIRC (es similar a C, sin compilación, solo ejecutable en mIRC, que por cierto es emulable en Linux con Wine).

Una de tantas aventuras fue la idea de crear un captcha en IRC, obviamente en texto plano. Entonces los captchas eran algo desconocido, empezaban a usarse en las webs, en cambio hoy te los puedes encontrar hasta para comentar.

Un captcha es una prueba que hace el servidor a un usuario para determinar si es un humano o no. Esto es fundamental en IRC por ejemplo para frenar y defender una red de ataques de clones (tan frecuente como el spam).

Mi captcha conseguía renderizar un numero aleatorio a una especie de gráfico con caracteres. Ademas lo ofusca con diversas tecnicas como fuentes de numeros distintos que varían aleatoriamente.

Aquí una muestra:

Hola, si eres humano teclea este número por favor.
#############################
#############################
#############################
#############################
#############################
#############################
#############################

Esta tecnica es muy segura, en mi opinion es casi imposible que se consiga hacer un anti-captcha que se salte esta tecnica… porque con un minimo esfuerzo se pueden añadir nuevas fuentes de numeros (se podrían hacer infinitos numeros distintos, para entender esto ver fuentes.ini). Simplemente añadiendo una nueva fuente obligaria al que intente cazar este sistema a analizar de 0 los captchas para detectar todos los nuevos numeros y reprogramarlo. Un infierno…

Además se puede complicar más añadiendo cuadrados aleatorios en medio del numero, lo cual dificultaria su lectura un poco pero aumentaría exponencialmente su seguridad.

Me habría encantado implementarlo en el IRC-Hispano, pero pasaron de mi idea. La verdad es que hubiese sido divertido asegurar una red entera liberandola de bots de spam y clones de ataque, pero me di cuenta de que a esta gente le interesa que hayan clones, porque inflan sus estadísticas y así sus anunciantes les pagan más.

Como ando muy agradecido e involucrado con el Software Libre, voy a liberar este programa a todo el mundo que quiera echarle un vistazo, probarlo, utilizarlo, mejorarlo, rehacerlo… lo que queráis siempre que se respete razonablemente mi autoría.

Archivos (3):

• captcha-IRC.mrc 1.0 [3kb] - El código fuente, crea un evento y el alias /validar.
• fuentes.ini [2kb] - Las fuentes de números con distinto tamaño y forma, se pueden añadir cuanto se quiera.
• validaciones.ini [0kb] - Log (vacio) para guardar quien consigue pasar el captcha y quien no, a partir de esto se pueden crear muchas aplicaciones.

Cómo instalarlo y usarlo en mIRC:

1. Descargar los 3 archivos de arriba (abriendo uno a uno haciendo: Guardar como…)
2. Guardarlos en el raíz de tu mIRC (ejemplo: c:/mIRC/)
3. Ejecutar en mIRC: /load -rs captcha-IRC.mrc
4. Ya está.
   Lo puedes probar con el comando /validar NICK esto enviará a ese nick una consulta captcha, notificará su acierto o error y lo registrará en validaciones.ini.

Para desinstalar: /unload captcha.IRC.mrc

Surfeando por Internet, como quien dice, he descubierto algo que me parece increíble y de haberlo descubierto de niño me habría alucinado completamente.

Resulta que hay una comunidad de radioaficionados a los satélites, pudiéndose utilizar algunos satélites para intercambiar comunicaciones.

Explicaré los conceptos que he aprendido. Quiero aclarar que no he tenido la suerte de comprobar todo esto de forma práctica, pero he leído suficientes teorías como para hacer esta pequeña introducción superficial.

Los satélites de radioaficionado permiten a cualquiera enviar y recibir voz o información (fonía o packets). Para un radioaficionado un satélite es como un espejo o una antena repetidora terrestre. Este recibe y vuelve a emitir hacia la Tierra. Solo hay un canal donde se realizan todas las comunicaciones entre los aficionados que estén escuchando.

La cobertura de los satélites tiene grandes limitaciones. Para empezar no hay ninguno geoestacionario (confirmado), todos se mueven en órbita alrededor de la Tierra. Esto significa que no siempre están disponibles, ni mucho menos. Es más, dado que normalmente giran 5 o 6 veces la Tierra cada día el periodo de cobertura sobre España, por ejemplo, puede ser de entre 10 y 30 minutos por ejemplo. Los que hacen órbitas elípticas permiten ampliar este tiempo un poco más, pero su frecuencia es menor.

Por supuesto los satélites no se pueden dirigir ni nada parecido, eso es un mito de las películas. Los geoestacionarios están inmóviles porque se han colocado (y empujado) con precisión girando al unísono con la Tierra, es el caso del los satélites de la tele. Las parabólicas apuntan siempre hacia el ecuador, en el caso de los radioaficionados tendrían que moverse constantemente.

El equipo necesario para realizar comunicaciones con satélites es sorprendentemente, solo hace falta un equipo VHF/UHF y una antena larga direccional, con el mayor numero de elementos para dar la mayor ganancia posible. También se necesita una licencia que se obtiene previo pago más un pequeño examen.

El punto clave importantísimo (a parte de conocer las pautas de comunicación y las frecuencias) es saber donde se encuentran los satélites de radioaficionado en tiempo real. Esto lo podemos hacer cualquiera gracias a programas como el WXtrack (mi preferido) o SatScape y por supuesto a los keplerianos.

Simplificando: los keplerianos son parámetros (en texto plano) que indican con dos vectores temporales la dirección, posición y altitud de un satélite en el tiempo. Esto significa que teniendo los keplerianos de un satélite y el programa adecuado podrás saber donde se encuentra en cualquier momento! (aunque hay que mantener estos elementos keplerianos actualizados una vez al mes para evitar sorpresas).

Un ejemplo de elementos keplerianos, en concreto de la estación Espacial Internacional (ISS, tripulada permanentemente) que curiosamente tiene un repetidor para radioaficionados funcionando actualmente en 145.825 MHz:

ISS
1 25544U 98067A 07262.51637699 .00020000 00000-0 20000-3 0 9002
2 25544 51.6353 337.1650 0009650 22.0216 338.1362 15.76879361 25661

El resultado es el siguiente:

Esta captura muestra mi recopilación de todos los keplerianos que he podido encontrar, introducidos en el WXtrack y visualizados en tiempo real. Resulta evidente que los que están en linea son los geoestacionarios, como los Meteosat.

Tal es la fascinación con los satélites (me alegra descubrir que no soy el único) que se pueden avisar algunos satélites a simple vista si se sabe hacia donde mirar y se tienen las condiciones adecuadas.

Enlaces interesantes:

• Estatus de satélites de radioaficionado junto con sus datos técnicos.
• La biblia de las introducciones a los satélites radioaficionados.
• WXtrack. (necesité instalar esta librería para que funcionase en mi XP)
• SatSpace. Otro tracker de satélites, parece muy vistoso pero no me gusta su interfaz.
• Información técnica sobre adaptación de antenas para uso con satélites.

[Nota: Dado que no soy un aficionado de la materia, simplemente un curioso ocasional, seguiré cualquier comentario que se haga en este post, haciendo las pertinentes correcciones. Si ves algún error avísame!]

Los discos duros tienen los días contados. Serán sustituidos por una nueva generación de dispositivos de almacenamiento basados en la tecnología SSD (Discos de estado solido). Funcionan de forma similar a una memoria RAM, no tienen mecanismos ni platos magnéticos girando a toda velocidad.

Veo un gran avance en la tecnología SSD especialmente en un par de cualidades (en adelante explico) en las que creo que puede provocar un salto en cuanto a rendimiento del hardware.

Siempre he soñado con desarrollar un Buscador de Internet, empezando en mi propio garaje y todo eso (y nunca pararé hasta conseguirlo). Sin embargo, hoy en día no es posible. Haría falta una millonaria inversión para solo intentar alcanzar a Google, y luego habría que intentar ser mejor que ellos con menos recursos, lo cual veo improbable.

Sin embargo en los discos SSD hay una oportunidad para alcanzar al gigante de la información.

Actualmente Google funciona gracias a cientos de miles de ordenadores. Estos almacenan y procesan la información para devolver las búsquedas web. El punto clave para conseguir una buena experiencia de búsqueda y resistir tanta demanda es la rapidez de respuesta (a parte de repartir datacenters espejo por todo el mundo).

Esta rapidez se consigue distribuyendo el trabajo de cada búsqueda que hacemos en decenas de miles de ordenadores que procesarán simultáneamente para confeccionar el resultado. Si, cada vez que se hace una simple búsqueda estas activando alrededor de 10.000 servidores (salvo que la búsqueda esté cacheada, tendrías que hacer una búsqueda peculiar para activar toda la maquinaria, se nota en el tiempo de respuesta).

Esta rapidez se consigue gracias a que gran parte de la información se almacena en la memoria RAM de todos esos servidores (suman decenas de terabytes fácilmente), reduciendo al mínimo el acceso al disco duro magnético que es lento y torpe.

Y aquí llega el punto clave de la cuestión. Los nuevos SSD tienen una bajísima latencia, su tiempo de respuesta es 100 veces más veloz que un disco duro magnético resultando tan veloz como una SDRAM. El acceso a la información es tan solo de 0,01 milisegundos.

Para rematar la jugada, la velocidad de lectura de datos aleatoria es tan rápida como una lectura continua. En este punto los discos duros son muy lentos porque deben mover la aguja hasta el lugar determinado de lectura. Para realizar búsquedas este punto es importantísimo ya que permitiría ampliar 100 veces (teóricamente) la capacidad de almacenaje y búsqueda de cada servidor.

Por lo tanto mi teoría es que dentro de poco habrá una oportunidad estratégica para crear un datacenter más potente que el de Google con 100 veces menos servidores. Con lo cual la necesidad de ser rico sera menor y quien sabe… habrá que ahorrar.

[Nota: actualmente los discos SSD son carísimos y tienen una duración de vida extremadamente corta lo que obliga a usar un sistema de archivos especial que evita que se gasten rápido. Doy por hecho que en el futuro se superarán estos problemas técnicos y que pronto esta tecnología estará lista para usarse a un precio competitivo.]

[Nota2: por cierto, equivocado o acertado, en un futuro cercano el formatear se va a acabar. Los discos SSD pueden borrar toda su información instantáneamente.]