Recuerden que ahora estamos en fernand0.github.io.
.
Los duendes de las estadísticas de WordPress.com prepararon un informe sobre el año 2014 de este blog.
Aquí hay un extracto:
Un teleférico de San Francisco puede contener 60 personas. Este blog fue visto por 2.600 veces en 2014. Si el blog fue un teleférico, se necesitarían alrededor de 43 viajes para llevar tantas personas.
Esta bitácora empezó en el año 2009 como continuación de otras previas, como contábamos en Tercera Etapa. Por algún motivo nunca he terminado de sentirme confortable aquí.
Es tiempo de hacer pruebas nuevas y nos movemos a otro lugar. Copio aquí el post que lo explica en mi nuevo sitio, Cuarta etapa:
Repito aquí una historia ya contada unas cuantas veces, a la que le vamos añadiendo matices y novedades.
Copio de Tercera Etapa:
”
Esta bitácora nació allá por el 2001 en forma de [MiBarrapunto](http://barrapunto.com/articles/01/04/23/2033238.shtml): se trataba de un invento que hicieron los creadores de [BarraPunto](http://www.barrapunto.com/) para permitir a los usuarios tener su propia sección con algunas ideas que ya me gustaría ver en alguna plataforma ahora, pero que no cuajaron por problemas de escalabilidad del programa y falta de recursos en aquel momento para mejorarlo (destacable, la promiscuidad absoluta: cualquiera podía tomar una entrada cualquiera del sitio -en particular, de otros usuarios- y reformarla o simplemente republicarla en su propia página).Parte de esas ideas se han establecido en [GitHub](http://github.com/), donde el código puede copiarse, transformarse y reenviarse al autor original o a otros con herramientas bastante accesibles.
”Con ese espíritu empecé a subir los contenidos de algunos de mis sitios a GitHub: Archivo bitácoras fernando para posteriormente descubrir que GitHub permitía publicar Páginas personales y para los proyectos y el sistema que las gestiona, Jekyll, que también permite gestionar un blog: nuestra página estaría albergada en el sistema con las mismas características de gestión del código fuente de los programas: fork permitido, copiar, pegar, modificar y reutilizar. Todavía no es tan fácil como era en la época de BarraPunto, pero aquí lo tenemos. Y aquí estamos.
No creo que la mayoría de la gente vaya a utilizar esto, y tampoco creo que nadie vaya a reutilizar estos contenidos. Pero siento que encaja bien con mi forma de trabajar y publicar (editar en local, subir al sitio y publicar) así que vamos a probar. Desde este momento, la bitácora anterior queda congelada y seguimos por aquí.
Bienvenidos a la cuarta etapa. Proximamente algo más de información sobre cómo gestionar un sitio aquí e ir resolviendo las carencia que aún tenemos (ya hay RSS, las categorías y las etiquetas no funcionan aún).
Les espero en fernand0.github.io.
Leía hace unos días el artículo algorithmic complexity attacks and libc qsort() donde se hace un análisis del Quick Sort, lo que pueden costar algunas de sus implementaciones y fantasea con la posiblidad de utilizarlo para algún tipo de ataque de denegación de servicio (o al menos ralentización).
Son de esas cosas que nos trae el software libre e internet.
En why I don’t touch crypto explican un par de buenas razones para no tratar de inventar nada relacionado con la criptografía. Un buen recordatorio:
La generación de números (seudo)aleatorios es un problema difícil y hablan
de un fallo:
Last week’s issue in the random number generator in Cryptocat is a very good example.
The bug was an off-by-one error in their random number generator. The output of the function was still random numbers, looking at the output would clearly show random numbers. Given that fact, the natural bias for seeing code as being correct is only reinforced.
Comprender los conceptos no es suficiente, es muy fácil equivocarse:
I’m just plain not good enough. Crypto is a world where understanding the concepts, understanding the math and writing tests just isn’t good enough.
Un interesante análisis en Why mobile web apps are slow de los diferentes parámetros que afectan al comportamiento de aplicaciones web en el teléfono móvil.
Después del parón del verano volvemos con un proyecto pequeñito. Después de añadir movimiento (Añadiendo movimiento: servos) descubrimos que podemos orientar la cámara en una habitación (Una cámara móvil), pero casi nunca vemos nada interesante (es difícil encontrar el momento adecuado).
Sentía curiosidad por ver cómo funcionaría un sensor de movimiento y decidí comprar un par de HC-SR04, que funcionan con ultrasonidos.
El objetivo es disparar una fotografía cuando alguien pase por delante de la cámara: para ello medimos la distancia al obstáculo que haya enfrente del sensor y cuando cambie tenemos que suponer que hay alguien o algo en la trayectoria.
Tras unas primeras pruebas con la Raspi el resultado no era satisfactorio: se obtienen medidas aproximadas (y relativamente sencillas de filtrar, eliminando los valores desvidados) pero que no resultaban apropiados para lo que teníamos pensado.
Se puede ver, por ejemplo, un tutorial en HC-SR04 Ultrasonic Range Sensor on the Raspberry Pi.
La conexión del sensor a nuestra raspi.
Parece que el problema de precisión tiene que ver con la medición del tiempo (que es lo que se usa para medir la distancia con este tipo de sensores: el tiempo que tarda en ir y volver hasta el obstáculo un frente de ondas sonoras), que no es muy preciso en la Raspberry con su GNU/Linux.
Afortunamdamente, teníamos a mano un Arduino y decidimos probar si era más adecuado. Esto nos permitiría:
– Medir distancias de manera más precisa.
– Aprender a comunicar la Raspberry y el Arduino.
Y, seguramente, abrir la puerta a nuevos proyectos.
El arduino conectado al sensor:
Siguiendo las pistas de HC-SR04 Ultrasonic Sensor fue fácil preparar el programita (sketch) de arduino y hacer las conexiones (se puede ver en sketch.ino en su versión actual, puede haber cambios después).
Efectivamente, la medición era mucho más precisa: de vez en cuando, manteniendo fijo el sistema hay una variación de un centímetro o dos. Pero eso no es un problema cuando tratamos de detectar la presencia de un objeto más o menos grande (como una persona) en la trayectoria porque debería haber una modificación de más de 20 cm.
Ahora había que comunicar el arduino con la Raspberry (para reaprovechar código existente y no tener que empezar de cero en el nuevo aparatito).
Parece que hay varias formas de comunicarlos: mediante un puerto serie sobre USB (Connect Raspberry Pi and Arduino with Serial USB Cable), mediante I2C (Raspberry Pi and Arduino Connected Using I2C) y mediante GPIO (Raspberry Pi and Arduino Connected Over Serial GPIO).
Elegí la primera porque me pareció la más sencilla de poner en funcionamiento (aunque no descarto probar las otras).
Lo que envía el arduino se puede leer fácilmente en la Raspberry como una entrada de texto y sólo tenemos que procesar adecuadamente:
distAnt=0 ... while 1: distAnt = dist dist = int(ser.readline().strip().strip()) if abs(distAnt-dist)>10: print "Alert!!"
Esto es: conservamos la medición anterior (distAnt), obtenemos una nueva (dist = …) y si la diferencia es mayor que diez, lanzamos una alerta.
Como lo que queríamos hacer era una fotografía justo en ese momento, hemos reutilizado código de Una cámara en la Raspberry Pi y, siguiendo viejas costumbres, la envíamos por correo (Enviar una imagen por correo en Python).
El código puede verse en serialPicture.py.
Por la forma de enviar el mensaje esto dejaba el sistema inutilizado mucho tiempo: no podemos evitar el tiempo que consume la cámara (que no es despreciable tampoco) porque no queremos poner más de una; pero sí que podemos evitar la espera de la conexión al servidor de correo, y el envío de la imagen.
Esto lo conseguimos mediante la creación de un subproceso (ver multiprocessing) que se ocupa del envío.
camera(name,cam) p = Process(target=mail, args=(name,who)) p.start()
Esto es, tomamos la foto y lanzamos un proceso hijo que se ocupa del envío.
No tenía experiencia con esta parte de Python y no estoy seguro de si hace falta terminar el proceso de alguna forma, pero como no hay que hacer sincronizaciones ni esperar a que termine para hacer otras cosas, parece que funciona razonablemente.
Para terminar: ninguno de los procesos es muy rápido; que nadie espere poder utilizar esto como ‘trampa’ para capturar el paso de un ave volando (o incluso un niño corriendo).
¿Qué podemos hacer ahora?
Podríamos embarcar el sensor de distancia en uno de nuestros motores (como en Una cámara móvil) y con ello hacer un ‘mapa’ de la habitación: se me ocurre que serviría para detectar cambios de otra forma diferente.
Otra cosa que se me ocurre es que, una vez que alguien o algo ha cruzado la ‘barrera’ podríamos hacer un barrido con la cámara móvil y tomar varias imágenes (o incluso grabar un vídeo; me está dando pereza, pero es algo que hay que probar).
Y, por supuesto, escuchar ideas de quien lea esto o buscarlas por ahí.
Todavía hay otro problema y es que el sensor funciona aunque no haya luz; tal vez podríamos añadir un sensor de luminosidad para evitar el disparo cuando sabemos que no se va a poder tomar una imagen (o, tal vez, iluminar la escena de alguna forma).
En Arabesque estuvieron escribiendo una interesante serie sobre diversos aspectos de seguridad para el usuario en Linux (el índice en http://blog.sanctum.geek.nz/linux-crypto-introduction/”).
Tal vez volvamos sobre ella pero hoy me gustaría traer aquí el tema de las contraseñas: Linux Crypto: Passwords donde nos habla de pass como utilidad para gestionar las claves que utilizamos habitualmente.
Para los aficionados a los programas con interfaz textual puede ser una buena alternativa a otros métodos publicitados frecuentemente.
Ya hace mucho tiempo de aquellos tiempos en los que se hablaba de lo simple que era Firefox (Mozilla en aquel momento) frente a la complejidad del navegador de Microsoft (recuerden Software Complexity: Open Source vs Microsoft.
Por eso es interesante echarle un vistazo a How maintainable is the Firefox codebase? donde se mostraban varias medidas habituales. Se ve que no está mal del todo, aunque algunos módulos se estarían volviendo más y más complejos.
Aunque la entrada que yo guardé en su día era otra, en Security Headers on the Top 1,000,000 Websites: March 2014 Report se puede encontrar justamente eso: el resumen de un estudio sober el primer millón de sitios más importantes en la web (según Alexa) y las cabeceras relacionadas con la seguridad que envían desde sus páginas web.
Normalmente estas entradas nos pueden servir para bajar un poco los pies a la tierra sobre lo que realmente se está utilizando en la industria y también para echarle un vistazo a todas las cabeceras en las que deberíamos pensar si somos nosotros los que tenemos que tomar la decisión de cuáles enviar.
Si miramos la serie a lo largo de tiempo también pueden ser útiles para ver cómo van cambiando los usos y costumbres.
Finalmente, me gustan porque permiten ver todo lo que se puede saber en la red, con unas pocas herramientas y ganas de hacer los programitas adecuados.
Veo que también han publicado:
Security Headers on the Top 1,000,000 Websites: November 2013 Report.
Security Headers on the Top 1,000,000 Websites: March 2013 Report.
Security Headers on the Top 1,000,000 Websites (noviembre 2012).
En Top 10 Proactive Web Application Security Measures.
– Content-Security-Policy
– X-Frame-Options
– anti-CSRF cryptographic nonces
– DAL (data/database access layer)
– Unwritable file system
– Forensically secure logging
– Secure credential/passwd/secret questions and answers storage
– SSL, cookies with secure flags, cookies with httponly and STS
– Security frameworks
– autocomplete=”off” and strong passwords
