Cappuccino y la Web que se viene

Uno de los muy interesantes punteros que me dejó la conferencia tiene que ver con las keynotes[1][2], y la existencia por un lado de la aplicación web 280Slides y por el otro del framework en el cual se basa, Cappuccino. Sugiero pegarle una mirada, más que nada a las demos (para los faltos de tiempo como yo); me parece que es sencillamente genial, hay mucha influencia del OS X acá, y se nota. Es una aplicación donde la línea entre lo desktop y web se esfuma, literal y definitivamente. Lástima que hay que aprender oootro lenguaje nuevo, Objective-J.

Y esto parece que no se va a detener, tal como dijo Jacob. Más si nos enteramos que hay desarrollos bastante avanzados para integrar contextos canvas 3D en los navegadores, y leemos algunas características futuras de HTML5. En resumen, él plantea que toda la toolchain web actualmente apesta, incluso Python, y propone algunas líneas de solución para que Python sea el lenguaje web del 2020, cuando HTML 5 sea el estándar y el navegador web sea el nuevo Sistema Operativo. Ya había escrito algo de esto.

Código más rápido, código más optimizado: LLVM

De la segunda plenaria, me quedó claro que al fin surgió un contendiente de relativa importancia al venerable GCC, y se llama LLVM. Acá tengo más todavía para investigar, pero básicamente el branch performante de Python llamado Unladen Swallow implementará (entre varias cosas más) un JIT para CPython implementado por medio de LLVM; algo así como V8 o TraceMonkey son para Javascript. Una de las cosas en las que Collin afirmó varias veces fue que “no pretendemos ser originales, queremos robar ideas de cualquier paper, de donde sea, con tal de hacer Python más rápido” . Lo malo es que al parecer, y si bien era una de las ideas iniciales del proyecto, eliminar el GIL no será tan fácil (de paso y relacionado, ¡excelente charla la de Multiprocesamiento en Python!).

LLVM está haciendo muchos méritos para ser considerado, como por ejemplo que Apple está apostando muy fuertemente por él, incluso tiene la idea de reemplazarlo definitivamente dejando atrás a GCC. En Snow Leopard (OS X 10.6), ya mismo se ofrece una interfaz compatible con GCC para LLVM además de toda la toolchain para compilar software desde los fuentes con él. FreeBSD también está trabajando para migrar a él. Y si bien todavía le falta bastante camino por recorrer (tiene escaso soporte para C++, o que no compila el kernel de Linux, por ejemplo), ya se pueden ver algunas muestras de su potencial, y personalmente encontré varios comentarios de que es mucho más sencillo contribuir y entender el código del proyecto comparado con GCC.

En fin, repetí en ambos párrafos, en asuntos totalmente diferentes, la palabra toolchain, que significa literalmente “cadena de herramientas”, y está relacionado generalmente al uso de varias herramientas como un conjunto en las diferentes etapas de la creación de aplicaciones. Evidentemente, tanto en el mundo de las aplicaciones web, como en el de los lenguajes de programación, se está yendo hacia la optimización de los recursos que tenemos. ¡Buenísimo!

[1] Snakes on the Web – Jacob Kaplan-Moss
[2] Unladen Swallow – Collin Winter

¡Gracias a PyAr por una excelente PyCon!
Saludos

No puedo agregar mucho más a lo que Manuel Benet escribe, analiza y explica en su post, salvo que tengan mucho cuidado con las fotos e información que suben.

En fin, en caso de usarlo, subir sólo lo básico, muy impersonal y nada más; nunca se sabe qué vulnerabilidades se descubren y permiten manipular la información de todos.

Saludos,
Marcelo

Veamos, las que me parecen más interesantes son:

• Soporte para los nuevos tags audio y video del futuro (y en borrador todavía) HTML 5 incluído. Lo interesante es que no sólo permite controlar la reproducción por Javascript (algo relativamente lógico), sino que también permite que Javascript procese y manipule la imagen mediante canvas. ¡Muy bueno! Un detalle es que por ahora soporta el formato WAV y OGG únicamente.
• Soporte para descargar “al vuelo” una fuente True Type u Open Type para ver una página exactamente igual a como el diseñador lo quiso. Esta funcionalidad respetará la nueva política de Control de Acceso para sitios con nombre diferente al de origen (ver más abajo).
• ¡Multithreading en Javascript mismo! Los navegadores están cada vez más cerca de convertirse en un Sistema Operativo… ahora vamos a tener un manejador de eventos para notificar de las cosas que nuestros hilos (workers) hagan, y sólo se puede acceder al DOM desde el “proceso” principal, tal como los toolkits gráficos para interfaces de escritorios de hoy en día.
  Lo bueno (?) es que son hilos reales, al nivel del Sistema Operativo (o al menos eso dice), no son hilos “emulados” (green threads).
• Unas cuantas mejoras en CSS: soporte de estilos para diferentes medios de entrada/salida (por ejemplo, según el tipo de dispositivo de entrada y cantidad de colores, resolución y relación de aspecto del medio de salida, etc.), transformaciones.
• Corrección de color ICC habilitada por defecto.
• Posibilidad de hacer prefetching de DNS desde el mismo HTML que está siendo renderizado. Esto (usado en forma medida), puede hacer que al hacer click en un link de la página que estamos viendo, Firefox ya haya resuelto de antemano vía DNS la IP del servidor de la nueva página, logrando que los tiempos de “saltos” entre links se acorten.
• Mejoras en el “Gran Objeto AJAX” (XmlHttpRequest), como la posibilidad de saber cuánto falta para finalizar la transferencia; y además, un relax en la política del “mismo origen” para Javascript, permitiendo hacer requests a otros servidores con dominio diferente al de origen, siguiendo las directivas de un nuevo Control de Acceso (que por lo que leí muy brevemente trabaja a nivel de encabezados HTTP).

Bueno, son bastantes cambios, esto sumado a TraceMonkey seguramente va a hacer que Firefox esté preparado para las aplicaciones web de acá a unos años; aunque pensándolo bien, yo iría tachando la palabra “web” de la frase anterior, dejando “aplicaciones” a secas…

¡Saludos!
Marcelo

Su objetivo es detectar el protocolo de aplicación (no basado en el número puerto, sino que lo hace interpretándolo realmente), y extraer la información relevante (el stream de datos), mostrarla y darle a uno la posibilidad de guardarla aparte para abrirla con un software que pueda reproducir dicho formato. Por ejemplo, puede detectar el formato SIP (utilizado comúnmente en llamadas telefónicas de VoIP) en una serie de paquetes capturados y guardarlo aparte para poder escuchar la llamada telefónica.

De todas maneras, su página de estado del proyecto nos dice que le falta soporte de varios protocolos más (por ahora soporta decentemente HTTP, SMTP, IMAP, POP, FTP, IPP, PJL y SIP, entre otros) pero insisto que es un proyecto muy interesante, con muchos usos y muy útiles. Además, sería un lindo como add-on para Wireshark, IMHO.

Vean las capturas de pantalla.

Saludos
Marcelo
[1]: Es “disecar”, no “disectar”; es la primera acepción de esta palabra. La segunda acepción es la conocida.

Son un montón de diapositivas (101!), unas cuantas las pasé por alto, pero son útiles; a modo de resumen, enumero los “highlights“:

• Vulnerabilidad DNS: Análisis exhaustivo del problema, demostración del ataque. Es útil porque empieza desde el principio, comenta la impresionante (awesome) reacción de las “software factories” de DNS con un lindo grafiquito, y tiene interesantes conclusiones para los desarrolladores de software en general (ver los Takeaway a lo largo de toda la presentación). También explica porqué atacar DNS: ¡es el MiTM perfecto!.
• Lo que viene: Bienvenidos a la tercera era del hacking. Ya se explotaron vulnerabilidades en los servidores y en los navegadores. Lo que sigue es aprovecharse del resto del software, que está íntimamente ligado a la red también; a modo de ejemplo cita esta vulnerabilidad del Sidebar de Windows Vista. Incluye a los juegos en red, y a las formas “seguras” de actualizar desde el software que se usa a diario.
• Cuidado con SSL: Destaca muchos problemas a futuro, tanto técnicos como del usuario: falta de escalabilidad y de difusión, problemas con los virtual hosts, los usuarios no prestan atención a los mensajes de advertencia, el uso de MD5 para su firma, etc. “No es la panacea que pareciera ser”.
• Autenticación – el Bug principal de 2008: elabora una lista las últimas vulnerabilidades importantes conocidas, todas tienen que ver con este punto crucial en la interacción de sistemas.
• En resumen, la infraestructura y servicios (¡todos ellos!) de Internet y las Intranets dependen del servicio de DNS. Hay que mejorar la infraestructura; esta vez tuvimos suerte, la próxima vez puede que no sea tan “suave” el problema. DNS no debería haber sido capaz de provocar este daño: entonces, ¿Por qué lo fue?

Además, mientras tuve algo de tiempo, también estuve mirando:

The Internet is Broken: Beyond Document.Cookie – Extreme Client Side Exploitation. Presenta una serie de vulnerabilidades en varios componentes de software comunes estos días, provocado por el abuso de confianza en el nombre de dominio (está claramente relacionado con lo que decía Kaminsky, pero bien práctico); en Java, los servidores Web locales de ciertas aplicaciones, etc.

Disclosing Secret Algorithms from Hardware: Confieso que no sé mucho de electrónica, pero así y todo entiendo que esta charla estuvo interesantísima: ¡los tipos hacen ingeniería reversa de algoritmos en hardware! Muestran cómo se hace, en forma muy gráfica, y explican qué herramientas utilizan. Me asombra que digan “acá hay un NAND, así y así…” Y ya que están, agarran un chip RFID de MiFare a modo de (mal) ejemplo para determinar el algoritmo de encriptación (cerrado), como ya lo hicieron anteriormente (aunque la ley impidió la presentación en sí). Nobleza obliga, debo agregar que la compañía relativiza esta cuestión y hace pública su posición al respecto.

Bueno, espero que tengan un feliz año!

Saludos
Marcelo

FairSoftware se encarga de la gestión (virtual) de los ingresos y los pagos (electrónicos), de permitir la búsqueda de colaboradores para ciertas tareas, y de figurar “legales” ante el fisco estadounidense. No se mete con el copyright del desarrollo en sí ni con la gestión técnica del proyecto, y lógicamente un usuario puede colaborar en varios proyectos (lo cual pienso que puede servir de “propaganda personal” también).

Lo bueno de todo esto es que FairSoftware evita que la persona que tiene una idea (más los colaboradores de antemano, por qué no) tenga que lidiar con contratos, abogados, el ponerse de acuerdo en ciertas cuestiones con el equipo, etc., además de permitir que cualquier persona del globo contribuya. El “contrato” que existe entre los miembros de un equipo es lo que llaman el Bill Of Rights, que si bien no lo leí, entiendo que muchos equipos ya lo utilizan; propone la igualdad de derechos, el manejo abierto del proyecto, compartir ganancias, etc.

Claro que este servicio tiene un costo: el 9,9% de los ingresos, que incluye el pago electrónico vía PayPal y/o tarjetas de crédito y la declaración de impuestos frente al gobierno de EEUU.

En fin, es una idea muy interesante. De todas maneras, aún está en “beta”, por lo tanto no tiene forma (visible, al menos) de buscar startups a las cuales unirse.

Saludos
Marcelo

http://blog.buanzo.com.ar/2007/09/informe-de-puertos-proxeados-fibertel.html

Con lo cual, después de una breve consulta en Google, me encontré con este excelente documento:

http://hcsw.org/nmap/QSCAN

Básicamente, los tipos de escaneos QScan se basan en comparar las medias (mediante la distribución T de Student) de los RTTs de una cantidad N (la muestra) de paquetes enviados a distintos puertos de un mismo (o diferentes) hosts. Además, para sacar más el jugo a la técnica, uno puede configurar el intervalo de confianza, la cantidad de muestras y la demora N entre paquete y paquete enviado (que para hacer la prueba estadísticamente más ‘fuerte’, el parche hace un random que tiene como punto medio al N configurado). El objetivo es saber si el host que recibe los paquetes (el ‘target’ del escaneo) hace tratamientos diferentes de los paquetes de acuerdo a al puerto destino.

Por ejemplo, si un host tarda ~600 ms. en responder a los paquetes enviados por nmap al puerto 80 y ~250 ms. en responder a los paquetes enviados al puerto 22, y la comparación de las medias por T de Student da como resultado que son diferentes, se puede inferir que los paquetes enviados al puerto 80 son reenviados por el host a otro host (que no lo veo!), a diferencia de los paquetes que van al puerto 22.

Recomiendo muchísimo la lectura del artículo. Me parece un tipo de escaneo bastante útil para hacer detección de infraestructura de DMZs, reglas de firewall, etc. Hasta lo recomiendo porque es un tipo de escaneo muy sencillo e interesante por sus resultados.

Para los que tuvimos el gusto de asistir a sus clases (yo en la UNLu), es imposible no acordarse de Daniel Villa y sus clases de estadística leyendo este artículo!

Lástima que este QScan no está disponible en la versión estándar de NMap (hay que recompilarlo).

Sitio oficial del parche: http://www.hcsw.org/nmap/

Insisto, me alegré mucho personalmente por entender la aplicación de tanto sentido común (y con herramientas que uno conoce) sobre algo que no se me hubiera ocurrido.

Saludos
Marcelo

Andá bárbaro!!! Pruébenlo.

Me imagino que no es el primero en existir, pero sinceramente me sorprendió el equipo de Banshee (un reproductor de música desarrollado en Mono). Claro que está en desarrollo, pero parece que pronto reemplazo al Amarok (esperemos, pero si no tiene Crossfading no me cambio nada eh!).

En este post hay más detalles al respecto (el sonido viene por un plugin Flash y es controlado con Javascript).

Salutes
Marcelo

Me parece muy útil el tema del agregado de indicadores de Cookies “no legibles” por scripts, cosa que sólo tiene el IE (qué raro, je) y también la aparición de un tag que indica un recurso “off-line”, para que Firefox la “cachee” para uso posterior.

Esto último, bien utilizado, puede permitir el laburo desconectado de aplicaciones web.
http://ejohn.org/blog/javascript-updates-in-firefox-30a3/

Acá está el resumen oficial para developers de Mozilla:
http://developer.mozilla.org/en/docs/Firefox_3_for_developers

Marcelo

De curioso la bajé, y está muy buena, más que nada al nivel del famoso “Usuario Final” y en español, además de ser extensa: tiene 334 páginas. Documenta la mayoría de los programas Linux de uso general*: Entorno Gnome y sus aplicaciones, OpenOffice.org, Firefox, Evolution, Gaim, Ekiga, Nvu, Gthumb, Inkscape, Gimp, Totem, la Configuración del Sistema y sus Herramientas de Administración.

Acá está el enlace de su versión online:

http://www.molinux.info/downloads/documents/manual-usuario-molinux/

Y acá está el enlace al pdf (ojo, son 109 MB!):

manual-usuario-molinux-rocinante.pdf

Es pesado pero vale la pena. Probablemente la distribuyamos en el FLISOL 2007, el que hacemos en Luján (podríamos armar un CD con documentación para incluír en el “escritorio” de las compus instaladas…)

Parece buena idea, no?

Marcelo
(*) Orientado al escritorio Gnome, claro está.