Un programador indio, Aditya Ravi Shankar, (¿este es un nombre común hindú o tendrá que algo que ver con el célebre músico virtuoso del sitar’) ha logrado la modesta hazaña a través de Javascript y HTML5. De momento sólo el primer nivel del legendario RTS, pero eso si, completamente jugable.

Lo hizo en el plazo de tres semanas, una de ellas en pleno proceso febril. Cómo el mio en estos momentos, pero mejor aprovechado, que duda cabe. Dicen que durante esos momentos de enfermedad, sudor y fiebre suelen surgir ideas geniales. ¿Que os gustaría programar a vosotros?

Link: HTML5 runs Command and Conquer, is now relevant (Dvice)

Este aviso se dió a partir del análisis realizado al panel de control de la vulnerabilidad Blackhole donde 16,144 computadoras fueron atacadas y desconectadas. F-Secure recomendó a quienes usen servicios bancarios en línea o una aplicación Intranet que dejen Java en su sistema operativo pero desinstalen el plugin del navegador o consideren otra alternativa para ser usada específicamente con ese fin.

Para F-Secure, las vulnerabilidades de Java no afectan a Google Chrome, porque no utiliza plugins de terceros (como Adobe Reader para visualizar archivos PDF).

Toma en cuenta que los programas siempre tendrán problemas de seguridad y en el caso de Java toman tiempo en actualizarse, por lo que si no quieres desinstalarlo lo mejor es tenerlo actualizarlo en todo momento y así evitas dolores de cabezas innecesarios.

Link: Java Considered Harmful (F-Secure Weblog vía Geek.com)

La nueva herramienta, llamada #RefRef, usará JavaScript y SQL para atacar sitios y aprovechar un tipo de vulnerabilidad en los servidores para usar su propio poder de procesamiento contra ellos mismos. RefRef podrá ser usado desde cualquier dispositivo que soporte Javascript, incluyendo teléfonos, o al menos ese es el plan.

El impacto de un ataque de RefRef es mucho más alto que el de LOIC: Anonymous probó esta herramienta contra PasteBin: un test de 17 segundos botó al sitio por 42 minutos.

Las vulnerabilidades que la herramienta ataca podrían llegar a ser parchadas (aunque según Anonymous se trata de problemas bastante generalizados que requerirían mucho trabajo de las empresas). También el colectivo recordó que Sony fue “pillada” con la seguridad por el suelo, y que serán así las compañías “irresponsables” las que serán vulnerables a su herramienta.

Lo malo es que RefRef tampoco hace mucho trabajo para esconder al atacante. Anonymous espera que quienes lo usen intenten tomar medidas para esconderse antes de usarlo. Anonymous supuestamente lanzaría la nueva herramienta en septiembre.

Link: Anonymous testing LOIC replacements – new tool uses server exploits (TechHerald)

Abrir archivos PDF en internet siempre ha sido un problema. Si bien la herramienta estándar para verlos, el Adobe Reader, ha ido evolucionando, la experiencia de abrir uno de estos archivos en internet sigue siendo lenta.

Ante esto, varias empresas han intentado dar solución al problema. Por ejemplo, Google desarrolló su propio lector de PDFs, que viene incluído en las últimas versiones de Chrome. Ahora es el turno de Mozilla, que está desarrollando un sistema llamado “pdf.js”.

La idea de Mozilla es crear un sistema que renderea los archivos PDF en el mismo navegador, sin usar otro software. Por ahora se está pensando que sea una extensión para Firefox, aunque no descartan incluirlo por defecto en las próximas versiones del browser.

Pdf.js funciona, como su nombre lo dice, a través de Javascript. Andreas Gal, uno de los desarrolladores detrás del proyecto, lleva años trabajando en una manera de mejorar la velocidad de funcionamiento de Javascript en Firefox, por lo que el uso de ese lenguaje para este nuevo proyecto parecía obvio.

Pero además, pdf.js usa otras tecnologías como, por ejemplo, HTML5 Canvas. Si bien esta herramienta permite renderear los archivos de manera muy rápida, tiene algunos problemas, como hacer muy complicado el seleccionar texto dentro del archivo o la incapacidad de generar impresiones en papel de buena calidad. Para saltarse estos problemas, también se va a trabajar con gráficos vectoriales. Lo que hará pdf.js es renderear una primera copia del archivo en HTML5 y después reemplazarla por una versión que usa las SVG.

Los próximos pasos para el equipo detrás de esta herramienta son terminar de implementar los formatos de archivos PDF más comunes, para que así se pueda abrir todo tipo de archivos con ella (lo que se hará en aproximadamente 3 meses), y después lanzar la primera versión de la extensión para Firefox. Para probarlo, los desarrolladores publicaron un link que lleva a una versión web de un PDF publicado el 2009.

Link: Mozilla eyes hassle-free PDFs on the Web (CNET News)

Google finalmente liberó una versión previa para desarrolladores de su estándar WebRTC, un nuevo proyecto abierto que dota a los desarrolladores de sitios web de una herramienta para que puedan implementar una interfaz de comunicación con audio y video en tiempo real sobre un navegador compatible.

En concreto WebRTC se basa en HTML5 y APIs de Javascript para que los desarrolladores puedan crear aplicaciones de comunicación en tiempo real (RTC) sin que sea necesario la instalación de un plugins de un tercero o algún cliente.

Toda la arquitectura en la que se basa WebRTC y sus códecs son libres (de hecho utiliza el códec de voz iSAC y VP8 para el video), al igual que su código fuente que ha sido publicado bajo licencia BSD.

En su desarrollo Google trabajó en conjunto con Mozilla y algunas organizaciones como la IETF y la W3C, incorporándose ahora último Opera Software.

Link: WebRTC (Vía The Next Web)



El desarrollador Alon Zakai utilizó la herramienta Emscripten, un compilador LLVM a JavaScript. El sistema funciona en Firefox y Safari – en Chrome se queda pegado. Si estás interesado en los detalles técnicos, están disponibles aquí, mientras el código fuente está acá.

Ya hace un año, Google había hecho una demostración similar corriendo Quake II en Chrome usando WebGL, demostrando las capacidades de las herramientas que están cada vez más disponibles en internet. ¿Qué será lo que vendrá ahora?

Link: Doom on the Web (Mozilla Developers)

Fabrice Bellard es un programador independiente francés quien consiguió hacer funcionar el kernel de Linux dentro de un navegador web gracias al uso de JavaScript.

Para lograrlo, lo que hizo Bellard fue crear una especie de emulador compatible tanto con Firefox 4 como con Chrome 11, que es capaz de ejecutar el Kernel de Linux en su versión 2.6.20.

Bellard señaló que creó esto “porque es divertido. Los nuevos motores de JavaScript son lo suficientemente rápidos para hacer cosas complicadas”.

Según el programador francés, su emulador corre dos veces más lento con el motor JavaScript V8 de Chrome, comparado con el motor Jaeger Monkey de Firefox. Su desarrollo ya fue probado por Brendan Eich, programador de Mozilla y creador de JavaScript, y Bellard cree que se puede usar como un sistema de prueba (un benchmark) para los motores de JavaScript.

Links:
- Sitio de Fabrice Bellard(Vía The Register)
- Emulador

(cc) NASA

Poniendo cosas sin sentido en los formularios que aparecen en las webs. Ese es el método que emplea el informático experto en áreas de seguridad Alonso Vidales para detectar vulnerabilidades en las diferentes páginas. Un curioso método que le ha servido para encontrar una brecha en el sitio de la mismísima NASA:

El pasado mes de septiembre descubrí un ‘bug’ del que informé a la NASA, y que han ‘parcheado’ de forma bastante cutre en los comentarios, pero que persiste en la página. Si se mete un ‘tag stript’ en lugar del nombre y los apellidos en la página, en lugar de mostrar la cuenta de este nombre se mostrará el ‘tag script’ con lo que se permitirá inyectar código JavaScript desde cualquier otra página”, dice Vidales.

Ese fue el descubrimiento de Vidales, que identifica el error como un fallo causado por la posibilidad de introducir y ejecutar algún tipo de código (JavasScript, por ejemplo) a través de diferentes partes de la web, como los citados formularios. Una vulnerabilidad denominada XSS (de Cross Site Scripting).

Pero la agencia espacial estadounidense parece no aprender del error:

Para evitar que esta vulnerabilidad fuese crítica, en un primer momento dejaron de mostrar estos datos en los lugares en los que eran públicos -comentarios a fotografías, noticias y demás-; actualmente solicitan el nombre cada vez que comentas algo, verifican mediante JavaScript si no hay inyección (algo que considero estúpido), y luego el comentario pasa una verificación, que supongo será humana”.

Medidas que el experto español considera inefectivas y que demuestra cambiando el logo de la NASA por otra imagen albergada en el propio servidor de la agencia espacial. ¿Cómo actúan los norteamericanos cuando son advertidos de un fallo de este tipo, como el reportado por Alonso hace ya varios meses?

Cuando avisas de un fallo de seguridad lo normal es que te den la callada como respuesta, y excepcionalmente te dan las gracias; lo normal es que traten de arreglar la vulnerabilidad con un parche y ya”.

Esperemos que sean más cuidadosos con la seguridad de sus naves y astronautas.

Link: Un experto español alerta de errores en la web de la NASA (El Mundo)

(nitot)

La buena salud de su versión beta (al menos lo que indica su nivel de descarga) se verá refrendada durante el próximo mes con la llegada Firefox 4.

Al menos así lo ha sugerido Mozilla en un e-mail a sus grupos de desarrollo, donde el director de ingeniería informática de la organización, Damon Sicore, señala que “hemos trabajado tremendamente duro en Firefox 4, y es tiempo de lanzarlo”.

La esperada nueva versión del navegador de Mozilla deberá pasar eso sí antes por ese paso previo que es la fase Release Candidate y arreglar los diferentes bugs localizados por los usuarios en pruebas.

En Mozilla son optimistas: “Debemos lanzar el mejor producto posible que podamos… Firefox 4 va a estar genial”, declaró Sicore.

En la última versión beta lanzada había mejoras más que evidentes en diferentes aspectos tales como la velocidad (de momento el ascendente Google Chrome parece llevarse la palma en este sentido), optimizada por el uso del compilador de JavaScript JägerMonke.

Si todo va bien, a finales de febrero tendríamos la nueva versión de Mozilla Firefox, navegador que recordemos hace poco ha superado a Internet Explorer como el más empleado en Europa.

Link: Mozilla Firefox 4 release expected in February (InformationWeek)

Hotmail sigue intentando evolucionar aunque ya haya perdido mucho terreno contra Gmail. Su último anuncio es uno bien interesante: desde ahora se podrá ejecutar Javascript en los mensajes de correos, convirtiéndolos en mensajes dinámicos y actualizados.

Según Microsoft, es un problema que cuando abres un mensaje viejo tenga información vieja (lo que, si lo piensan, es obvio). Además, muchas veces los correos necesitan que hagas algo (responder, llenar un formulario, etc.) y gran parte del tiempo tienes que hacer esa acción en otra ventana, por lo que usualmente no te dan ganas de hacerlo por el tiempo que requiere.

Pensando en esto, Microsoft pensó que es hora el siguiente pasó en la evolución del correo de un texto plano a un mensaje dinámico. Primero fue la incorporación de HTML en el mail, ahora es el turno de Javascript. A través de su plataforma “Active Views”, Hotmail permitirá que el emisor mande correos con Javascript lo que permitiría que se mantengan actualizados y que se puedan realizar diversas acciones desde el mismo correo.

¿Por qué no ha había hecho antes? Porque, según Microsoft, ejecutar Javascript tan abiertamente en un correo era peligroso para la seguridad del computador, pero con su plataforma nueva no habría problema. Por ahora sólo algunas empresas podrán mandar correos, aunque se supone que después se abriría a más gente.

Link: Hotmail introduces interactive email using Active Views (Inside Windows Live)

Microsoft publicó una nueva batería de pruebas basados en el último build de Internet Explorer 9 (Platform Preview 7), el que si bien no incorpora nuevas características si promete convertirse en el más rápido a la hora de enfrentarlo al test WebKit SunSpider, imponiéndose con una marca de 234,6 milisegundos.

Al parecer los ingenieros de Microsoft han logrado dar en el clavo respecto al rendimiento de su motor Chakra, logrando un incremento en el rendimiento de esta build que supera en más de un 300% al primer Platform Preview.

Claro que estos impresionantes números generaron serias dudas en los desarrolladores de los navegadores rivales, siendo específicamente un ingeniero de Mozilla el primero en levantar la voz respecto a los resultados mostrados por Microsoft.

En concreto Rob Sayre se enfocó principalmente en una prueba específica en donde el navegador de Microsoft superaba hasta en diez veces a sus principales contrincantes, lo que le pareció bastante extraño y lo motivó a realizar una serie de pruebas que, según sus conclusiones, ponen un manto de duda respecto a la validez de las pruebas realizadas por Microsoft.

Según Sayre el impresionante resultado obtenido por IE9 en el test SunSpider podría ser consecuencia de una de las siguientes opciones:

• Un bug inesperado en el motor JavaScript
• Que el motor JavaScript estaba especialmente adaptado para dicho test
• Una optimización inesperada del motor JavaScript

El bueno de Sayre no quiso dudar de la honorabilidad de los ingenieros de Microsoft, por lo que no dudó en reportar como un bug del motor JavaScript este “aparente” extraordinario resultado obtenido por IE9 en dicho test.

Link: Microsoft IE9 SunSpider JavaScript results raise questions (ZDNet)

(cc) greenasian

Cuando muchos pensaban que la magnitud del caos e histeria que generó ayer la aparición de un gusano propagado por Twitter a través de RTs involuntarios y la aparición de pop-ups con páginas porno, sería obra de experimentados hackers que lograron vulnerar la seguridad de la red social, resultó que no; todo fue gestado por un joven australiano de 17 años llamado Pearce Delphin.

Según AFP, el adolescente identificó la falla que permitía incorporar código JavaScript en los mensajes y lo publicó, tardando poco en ser recogido por verdaderos hackers que se encargaron de darle el toque malicioso que tuvo a los programadores de Twitter de cabeza intentando extinguir el incendio desatado en la web y que duró por cerca de cinco horas.

“Lo hice solamente para ver si es que podía hacerse… que realmente pudiera ejecutarse JavaScript contenido en un tweet”, explicó el joven a la agencia de noticias. “Cuando escribí el tweet, no tenía idea de que agarraría el vuelo que tomó. Simplemente ni lo consideré”, agregó.

“Descubrí una vulnerabilidad, no creé un gusano que se multiplique automáticamente”, se defendió Delphin. “Hasta donde sé, eso no es técnicamente ilegal. Espero no meterme en problemas”, culminó el muchacho.

Link: Twitter worm was unleashed by 17-year-old Australian (The Guardian)

Lo primero que hace mi navegador (Chrome) es abrir Google, que está por comodidad por defecto como página de inicio. Como algunos sabrán, estoy de visita en San Francisco, Estados Unidos, y al encender mi PC aquí, el logo de Google esta mañana se había convertido en unas pelotas saltarinas.

Al parecer sólo está funcionando a este lado del planeta, pero básicamente se trata de una animación (en realidad, un simulador de movimiento de partículas basado en JavaScript y HTML5) con la que puedes interactuar usando tu mouse. Cuando pasas la flecha por encima, el logo estalla, se mueve, rebota, etc.

Hasta el momento no está claro de qué se trata esto de las pelotas saltarinas, aunque algunos han supuesto que se trata de una celebración del aniversario de Google, que se convirtió en una Inc el 7 de septiembre de 1998.

Otros han indicado que se trata de una celebración a JavaScript, que fue liberado en septiembre de 1995 bajo el nombre de LiveScript como parte de Netscape Navigator 2. Como sea, hasta ahora es sólo especulación.

Google ha jugado pocas veces con los logos interactivos, como las manzanas de Newton y notablemente el Google-Pacman.

Link: What’s up with Google’s bouncy ball logo? (PCWorld)

Kamkar atrae a la víctima a un sitio web que utiliza PHP + JavaScript [PPT] para extraer la MAC Adress del router. Una vez que tuvo esta información, la buscó en los datos de Google Street View para ver dónde se registró esa MAC, obteniendo así las coordenadas de posición del router. Esto demuestra lo fácil que es identificar el domicilio de una persona con una precisión casi exacta, utilizando los datos recogidos por los vehículos de Google.

Este tipo de bases de datos “MAC-to-Location” empleadas por servicios como Google Street View y Skyhook pueden utilizarse para acosar o atacar a personas, poniendo en tela de juicio la responsabilidad de estas empresas con los datos “privados” que recolectan.

Mientras tanto Apple se lava las manos y desde iOS 3.2 utiliza sus propias bases de datos para ofrecer servicios basados en la ubicación – que antes mantenía con Google y Skyhook Wireless (“Skyhook”).  Recientemente manifestó que siempre ha tenido cuidado en proteger la privacidad de sus clientes.

Link: Web attack knows where you live (BBC – gracias Nobita81)

En algún momento de esta jornada Microsoft liberará el tercer preview técnico de Internet Explorer 9 (no es un beta sino un pre-beta), y es de esperar que vuelvan a hacer un benchmark contra todos los  browsers populares de la industria por lo que será “tarde de guerra santa”.

Lo de la guerra santa es mitad broma mitad verdad. Cuando el fabricante de un navegador publica los resultados de un benchmark, éste suele salir misteriosamente bien parado. Eso no quiere decir que los resultados sean manipulados sino que se eligen los benchmarks que destacan particularmente las fortalezas del navegador. Lo importante es que proveen de materia a los fanboys de cada browser (al menos de los 5 más importantes) para defender al suyo en los hilos de comentarios.

Pero volvamos a IE9. Entre los adelantos, sabemos que Explorer 9 usará en parte el GPU o procesador de la tarjeta gráfica para hacer el render de las páginas. Los diseñadores y desarrolladores podrán hacer uso de este poder latente y tantas veces desperdiciado usando sencillamente CSS, DHTML y Javascript. Respecto a esto último, así como Chrome tiene el motor V8 y Firefox el motor TraceMonkey que en ocasiones son más famosos que el mismo browser que los contiene, Internet Explorer trae el suyo propio, nombre clave Chakra. Espero que sea más parecido al Chakra Sahasrara que al Muladhara.

En cuanto a la interfaz de usuario, IE9 contará con una versión mejorada de la tecnología QuickTabs de la versión actual. Esto se desprende de una patente inscrita por la empresa de Redmond en la cual se describe “un sistema de manejo de pestañas”. Estas patentes son muy difusas en su descripción, pero sería contradictorio patentar ahora algo  igual a lo que ya existe en IE8 por lo que es razonable pensar que mejora la versión actual.

Como dijimos antes, se espera que con IE9 Microsoft se convierta en la antítesis de la fama que se hijo  IE6 entre los diseñadores (mal que mal, el 9 es un 6 invertido) , al abrazar casi de lleno los estándares de la W3C en lo que respecta a HTML5 (incluyendo el tag de video) , gráficos vectoriales SVG 1.1 segunda edición, CSS3 incluyendo querys, bordes, fondos y selectores, manejo del DOM (Document Object Model) de nivel 3 incluyendo la base y los eventos, y DOM nivel 2 en lo que respecta a los estilos.

En conclusión: a esperar este tercer pre-beta y a preparar la artillería.

Link:
IE9 Platform Preview 3 with HTML5 video support due today (NeoWin)
Microsoft ready to deliver another IE 9 developer preview (ZDNet)

Cuando Opera Software anunció la llegada de la versión 10.5 de su navegador, dejó muy en claro que este estaría enfocado principalmente en la velocidad. Para ello se utilizó un nuevo motor de JavaScript llamado Carakan, se actualizó el motor de renderizado Presto a la versión 2.5 y se incorporó una nueva librería de gráficos, con soporte para aceleración por hardware (Vega).

Una pincelada de lo que sería esta nueva versión del navegador la recibimos con el lanzamiento de su versión pre-alpha, en la que quedó demostrado que la unión de todas estas nuevas tecnologías efectivamente convertían a Opera en uno de los navegadores más rápidos del mercado.

Ahora con la llegada de la primera beta de Opera 10.5 tenemos la posibilidad de disfrutar del excelente trabajo realizado por los programadores de la compañía, la que nuevamente ha bautizado a su navegador como el más rápido de la Tierra.

Link: Opera 10.5 beta (Opera Software)

Una filtración de una patente presentada por Microsoft nos daría algunas luces de lo que veríamos en la nueva versión del navegador de la compañía, que sigue perdiendo participación de mercado y se mantiene en el ojo del huracán debido a los recientes ataques informáticos en los que se aprovechó una vulnerabilidad del navegador.

En primer lugar se habla de importantes mejoras en todo lo relacionado con la navegación por pestañas, específicamente en la función QuickTabs que actualmente utiliza IE8 y que afectaría a la forma como se reorganizan las pestañas (arrastrar y soltar), el aumento en su tamaño cuando pasamos el cursor sobre ellas y para facilitar su búsqueda cuando tenemos varias pestañas abiertas.

Pero eso no es todo porque también se esta trabajando en un nuevo motor de JavaScript y de renderizado, el que ahora podría trabajar en conjunto con la GPU para acelerar el funcionamiento general del navegador.

Se espera que un adelanto del nuevo IE9 sea presentado durante la próxima MIX 2010, la que se realizará en Marzo de este año en la ciudad de Las Vegas.

Link: Internet Explorer 9 to enhance tabbed browsing (Neowin)

(cc) por Dmitry Baranovskiy

Brendan Eich, creador del lenguaje JavaScript, líder de Mozilla Foundation y CTO de Mozilla Corporation declaró que las implementaciones de JavaScript son cada vez más rápidas, y que esto ha ayudado a que los desarrolladores lo usen en nuevos tipos de aplicaciones.

Eich cree que muchas de  las aplicaciones que hoy se hacen en Flash se podrán hacer perfectamente en JavaScript en el futuro. Por ejemplo, con los nuevos estándares se podrán ver juegos 3D escritos en JavaScript, algo que era impensado hasta hace poco.

Un factor clave para que JavaScript llegue a ese punto es que Microsoft agregue en Internet Explorer las mejoras que se están haciendo al lenguaje y otras tecnologías relacionadas, o que al menos ésta pueda ser agregada por medios alternativos.

Hace tiempo que JavaScript dejó de ser percibido como el hermano chico de Java, donde este último se veía como un lenguaje de programación real en comparación. Aunque hay gente que puede no estar de acuerdo, para Eich Java está prácticamente muerto en el lado cliente de las aplicaciones web, mientras que JavaScript está en todos lados.

Caída y surgimiento de JavaScript

JavaScript es un lenguaje de programación interpretado y suficientemente simple para que cualquier programador con experiencia en lenguajes como Java y C/C++ pueda lograr resultados rápidamente. Inicialmente fue creado para ser usado en aplicaciones web, ejecutándose en el navegador, pero también se utiliza en otros ambientes, como por ejemplo para escribir scripts dinámicos e integrarlo con otras aplicaciones.

Hasta hace poco los desarrolladores evitaban a JavaScript por la complejidad de lidiar con las diferencias de implementación que existían en los distintos navegadores y la poca utilidad que aportaba, pero con el surgimiento de AJAX y frameworks especializados, JavaScript tuvo un renacimiento y se convirtió en un componente crítico de las aplicaciones actuales.

Es tanto así que optimizar el rendimiento de JavaScript se transformó en algo crucial para los navegadores, ya que las aplicaciones web modernas lo usan intensivamente.  Un claro ejemplo es el navegador Google Chrome, en donde se publicaron las primeras optimizaciones fuertes a JavaScript debido al interés de Google en tener una plataforma potente para su nueva generación de aplicaciones.

Otro ejemplo es Google Web Toolkit, un framework para generar código JavaScript a partir de código en Java, y que ha sido usado en la implementación de Google Wave.  GWT  permite desarrollar aplicaciones que corren en el browser en forma rápida y productiva, gracias a que los desarrolladores pueden usar los conocimientos y herramientas de programación en Java que ya manejan, para construir aplicaciones que posteriormente correrán en cualquier browser a través de JavaScript.

Link: JavaScript getting faster, could displace Flash (InfoWorld – gracias, Keichi)

(cc) nojhan - Flickr

Todos sabemos que Wikipedia tiene su fortaleza en la cantidad y su flanco más criticado en la calidad, un prejuicio que muchas veces es injustificado y alimentado por las publicaciones tradicionales o los competidores virtuales, pero que en otros lamentables casos es cierto: hay gente inescrupulosa que no trepida en usar un proyecto tan vasto y que a todos beneficia para jugar bromas pesadas o llevar agua a su molino, sea metiendo links a sus propios sitios, cambiando las versiones oficiales a su conveniencia o difamando personas hacia las cuales albergan algún resentimiento, por nombrar algunos vicios.

El problema ha sido mitigado estableciendo control editorial, pero comprenderán que es un poco difícil monitorear 10 millones de artículos. Hoy supimos que la fundación Wikimedia ha dado con un método adicional para ayudar a reforzar la credibilidad de su contenido.

El proyecto se llama WikiTrust y consiste en desplegar una coloración para el trasfondo del texto, la cual es de un color naranja intenso para las ediciones más recientes y/o de autores menos confiables, y se va tornando más claro hasta llegar a ser blanco para aportes que por antigüedad o reputación de sus autores se considera absolutamente fidedigno. La reputación, por cierto, se calcula tomando en cuenta la cantidad y antigüedad de los aportes de un mismo usuario.

Por ahora, el funcionamiento puede probarse en el mismo sitio de Wikitrust, en donde pinchando sobre check text encenderán la coloración. A mi parecer le falta un poco de trabajo a nivel de forma, porque el paso de versión normal a coloreada podría hacerse modificando el CSS via Javascript para no tener que recargar la página.

Link: Wikipedia to Color Code Untrustworthy Text (Wired)

Un ingeniero que trabaja en la compañía responsable del navegador Opera, cuenta una anécdota en su blog que explica cómo una simple línea de JavaScript le salió muy cara a una compañía que vende servidores.

La historia se remonta al tiempo cuando Opera planificó la compra de una cantidad importante de servidores, debido al crecimiento que tendría el uso de Opera Mini, la implementación de Opera Link y al crecimiento del servicio My Opera.

Como sucede en estos casos la compañía se puso en contacto con diversas empresas que ofrecen estas máquinas, quienes les enviaron equipos de prueba para evaluar si cumplían con las necesidades de la compañía.

Cuando uno de los administradores de sistemas de Opera inició un servidor perteneciente a una de las compañías más importantes del mundo -cuyo nombre no quiso revelar- con el objeto de probar su interfaz web de administración, se sorprendió al ver que era redirigido de forma inmediata a una página de error. Luego de revisar el código JavaScript detrás de la interfaz se encontró con las siguientes líneas:

if (is.opera)
(
window.location.href = “config / error.htm”;
)

Claramente la venta de los servidores de esta importante compañía no se materializó.

Link: Most expensive javascript ever? (Vía Slashdot)

Una importante vulnerabilidad de Firefox 3.5 salió a la luz antes que la gente de Mozilla publicara un parche. Se trata de una vulnerabilidad que se aprovecha de una nueva característica incorporada en Firefox 3.5, gracias a la cual se acelera el ritmo de ejecución de JavaScript, pero que a su vez es vulnerable a ataques.

Los atacantes pueden crear una página web que incluya código malicioso que se aproveche de la vulnerabilidad, por lo que se recomienda la desactivación de JIT (Just-In-Time) en el motor de Java siguiendo estos pasos:

• Escribir about:config en la barra del navegador
• Escribir jit en la caja del filtro en la parte superior del editor de configuración
• Hacer doble clic en la línea que contiene javascript.options.jit.content, para establecer el valor false

Hay que tener en cuenta que al deshabilitar JIT hacemos que el rendimiento de JavaScript disminuya, por lo que sólo se recomienda como una medida de seguridad temporal.

Una vez que se publique el respectivo parche para resolver el problema, se recomienda habilitar nuevamente JIT siguiendo los mismos pasos descritos anteriormente.

Link: Critical JavaScript vulnerability in Firefox 3.5 (Gracias Thomas)

Se ha descubierto una nueva vulnerabilidad que afecta a Adobe Reader en sus versiones 8.1 y 9.1 (para Windows, Mac y Linux).

El problema estaría radicado en la función ”getAnnots()”, la que por un error podría permitir que se ejecutara código remoto en el computador afectado.

Por el momento la compañía se encuentra analizando el problema, pero ha recomendado a los usuarios desactivar JavaScript en Adobe Reader.

Link: Potential Adobe Reader Issue (Vía CNET)

Click aqui para ver el video.

El mismo día que Microsoft lanza la versión definitiva de Internet Explorer 8 (que al parecer no ha superado la prueba del Acid Test 3), Google no se queda atrás y muestra el desempeño de Javascript en su navegador Chrome mediante un sitio llamado Chrome Experiments que tiene 35 interesantes juegos animados y widgets que ponen a prueba el navegador.

Dos de estos interesantes experimentos es Google Gravity, donde vemos caer los elementos de este buscador con el efecto de gravedad y aún así realizar una búsqueda. Browser Ball es un experimento donde rebota una pelota a través de las ventanas de Chrome.

En algunas pruebas que realicé, noté que estos experimentos funcionan mejor con navegadores basados en los motores de renderizado Gecko y Webkit, mientras que en IE8 solo funcionaban unos pocos.

Link: Google’s Amazing Browser Experiments (Slashdot)

(CC) 120linux.com

El lenguaje JavaScript por mucho tiempo fue relegado a operaciones simples.  Su uso consistía básicamente en funciones cortas para validar si un número estaba dentro de un rango, si la dirección de correo estaba bien formada, si se habían ingresado los campos obligatorios, para cambiar imágenes sin recargar la página y otros usos de poca monta.

Cuando surge el concepto de AJAX y aplicaciones como GMail, Google Docs y Facebook, el web browser ya no es un tonto cliente liviano que sólo muestra lo que le dice el servidor, sino que se transforma en un cliente pesado que actúa por si mismo y por lo tanto necesita ejecutar una gran cantidad de código JavaScript.

Es en este contexto cuando el rendimiento de JavaScript se convierte en un factor relevante de la experiencia del usuario al usar la web como la conocemos hoy en día.

El Benchmark de TuxRadar

Los muchachos de TuxRadar hicieron un benchmark para comparar el rendimiento del motor de JavaScript de Mozilla 3.0 entre Windows y en Linux y los números son poco favorables a Linux

La prueba fue realizada entre Windows XP SP3 y Fedora 10, ambos corriendo en 32 bits sobre un Intel Core 2 Quad a 2.66Ghz, con 4GB en RAM y 1.5TB de disco (estos últimos dos datos son irrelevantes para estas pruebas, pero los incluyo por si hay dudas).

El rendering no es parte de las pruebas, eso aisla el motor de JavaScript de factores externos como puede ser un driver de video o un método de rendering de bajo nivel, sería bueno algún día contar con ese tipo de pruebas para ver qué cosas se pueden mejorar.

Las pruebas aplicadas fueron SunSpider (WebKit.org), V8 Benchmark Suite (Google) y Dromaeo (Dromaeo.com / Mozilla).  Estas pruebas ejecutan operaciones típicas de JavaScript que se usan en frameworks como Dojo, GWT y JQuery, por lo tanto son representativas de lo que podemos esperar de una aplicación del mundo real.

Las tres pruebas arrojaron resultados desfavorables para Mozilla corriendo sobre Linux. Afírmense los Linux fanboys porque aqui está el resumen de las pruebas:

• SunSpider : Windows es 11% más rápido que Linux
• V8 Benchmark Suite : Windows es un 32% más rápido que Linux
• Dromaeo : Windows es un 36% más rápido que Linux

Análisis de los resultados

Estos números no deberían asustar.  Como toda operación de análisis está sujeta a re-análisis.  Por ejemplo en los resultados se calcula el total de cada prueba considerando que todas las pruebas específicas son equivalentes, no es un total ponderado.  Esto quiere decir que para efectos de las pruebas, calcular una transformación 3D vale lo mismo que calcular operaciones sobre arrays, cuando en realidad es poco probable que el rendimiento de la transformación 3D influya en una aplicación tradicional.

Con esto no estoy diciendo que la prueba sea inválida, incluso ponderando los resultados serían desfavorables pero en otra proporción.

Una de las gracias de estas pruebas es que son de una gran ayuda para evaluar mejoras en un motor de JavaScript, pero no hay que olvidar que los números se deben interpretar y no simplemente recibir.

Perspectivas

La prueba realizada por TuxRadar mide el estado actual de lo que está al alcance de cualquier usuario, pero este escenario está pronto a cambiar.   Google Chrome incluye el nuevo motor de JavaScript V8 en donde se hizo un trabajo fuerte para mejorar el rendimiento, astuto movimiento considerando que Google depende fuertemente de ese factor para llevar adelante su tecnología.  Mozilla por su parte está trabajando también en un nuevo motor de JavaScript que incorpora los mismos conceptos aplicados en V8 y pronto comenzaremos a verlo en todos los escritorios.

Es poco probable que a estas alturas se hagan mejoras en el motor JavaScript de Mozilla, considerando que le queda poco tiempo de vida.  Sólo queda esperar que se acorte esta brecha entre ambas plataformas, pero al menos sabemos que será mucho mejor lo que tenemos hoy.

Update: Han sacado los resultados de nuevas pruebas en donde se confirma que el problema no está en la plataforma, sino que en el port.  Firefox sobre WINE en Linux es más rápido que Firefox nativo en Linux

Link: Benchmarked: Firefox Javascript on Linux and Windows – and it’s not pretty (TuxRadar)

Los ingenieros detrás del navegador noruego Opera, se encuentran trabajando en el desarrollo de un nuevo motor JavaScript (al que han denominado Carakan), que sería el motor más rápido del mercado.

Según las pruebas realizadas por los ingenieros, el nuevo motor es 2,5 veces más rápido que el motor que utiliza la versión 10 del navegador (Futhark).

Se espera que este nuevo motor sea integrado en cuanto se encuentre listo, aunque aún no pueden dar una fecha para su lanzamiento, ni tampoco qué versión del navegador lo incluiría.

Tendremos que esperar para ver efectivamente qué tan bien anda este nuevo motor, sobre todo comparándolo con los que utilizan el resto de los navegadores.

Link: Carakan (Opera Core Concerns)

Según un estudio publicado en CNET las últimas revisiones de los navegadores que más han dado que hablar en el último tiempo (Firefox y Chrome) les vuelan la raja superan ampliamente a los navegadores tradicionales; aunque para ser honestos llama la atención el desempeño de IE8 Beta 2 (que no siempre anda bien con JavaScript).

En las pruebas de SunSpider Firefox 3.1 Beta 1, con el motor JavaScript TraceMonkey activo, es bastante más rápido que el resto de los navegadores evaluados.

Las mejoras también se notan en Chrome, que supera a Firefox 3.1 Beta 1 sin el motor TraceMonkey activo.

Ahora si comparamos el test JavaScript de Google el ganador lógicamente es Chrome, pero se espera que la distancias se vayan acortando en la medida que se vayan depurando ambas betas.

¿Y qué pasa con el resto de los navegadores?

Tanto Safari 3.1.2 como Internet Explorer 8 Beta 2 quedan bastante rezagados a la hora de evaluar el tratamiento de JavaScript, por lo que ambos bandos deberán trabajar duro para no seguir relegados y perder la carrera.

Me gustaría ver a Opera metido en el baile también.

Link: Newer Chrome, Firefox show speed improvements (CNET)

Cuando fue anunciado, SquirrelFish prometió ser hasta cuatro veces más rápido que el motor JavaScript usado por Safari 3. Apenas tres meses de desarrollo después, SquirrelFish ha sido sepultado por SquirrelFish Extreme, una versión un 50% más rápida que su predecesora, que comparativamente es 10 veces más rápida que Webkit 3.0, pero que de paso supera también a TraceMonkey, el motor tras Firefox 3.1 y a V8, su equivalente para Google Chrome.

Link: Introducing SquirrelFish Extreme (Vía Arstechnica)