Archivo de la categoría ‘Artículos’

Feliz Navidad, Feliz año 2014

Black3

Es hermoso ver que la inmensa mayoría de este mundo, con independencia de religiones o razas, de clases, de géneros… todos celebramos estos días. Por desgracia no todos lo viviremos del mismo modo, con las mismas posibilidades, con las mismas comodidades, con la misma igualdad. Para algunos serán unas navidades más, para otros unas navidades menos. Quizás esa será siempre la mancha negra que adornarán las navidades. Como decía Silvio Rodriguez en su canción de Navidad, mientras unos celebrarán sus millones, otros no conocen que es brindar. No hay que ahogarse en ello, son días para reencontrarse, días para compartir, días para disfrutar… tan solo recordar, al menos, que no todos nacimos con las mismas condiciones.

 Dicho todo esto, tan solo espero que este año que también se termina haya sido al menos tan generoso como lo fue conmigo. Espero que las lágrimas que se quedaron en él hayan podido ser sepultadas por risas, brindis, por muchos te quiero. Si bien usamos la tecnología cada día para perder el tiempo, no pasa nada por usarla al menos un día para decidle de un modo más especial a aquellas personas que nos importan, que nos importan, que gracias por estar ahí y, que por supuesto, gracias por aguantarnos un año más

Por último, gracias a vosotros, cientos e incluso miles de lectores cada día pasan por estas páginas aun no sé bien por qué, leyendo textos que parecen no tener fin de una mente a veces pienso que perturbada. Creerme cuando os digo que soy el primero que aprendo de todos, sin olvidar por supuesto a conocidos e incluso amigos que nacieron precisamente de esos correos que a lo largo de los meses y los años llegan a la bandeja de entrada preguntando algo o sencillamente queriendo saber un poco más. Gracias por compartir un año más este viaje con esta Alma Oscura.

Feliz navidad, os deseo unas felices fiestas, una feliz noche buena, y por descontado un Feliz Año Nuevo.

Nos vemos pronto amigos, paz y amor
Theliel

PD: Os dejo el vídeo del año pasado… creo que merece la pena recordarlo

WhatsApp (Android): Como volver a tener la opción de “Descarga automática de imágenes”, para poder deshabilitarla (Actualizado)

Actualizado: A fecha de de 2 de Junio, las versiones a partir de la 2.10.509 (aun no disponibles en Play Store pero deberían de estarlo dentro de poco tiempo) disponen de opciones personalizadas para permitir o denegar la descarga automática de imágenes, vídeos o audio dependiendo de si estemos por WIFI, por datos o en Roaming. Gracias por replantearse la política de empresa al respecto.

 

Lo cierto es que ha sido un amigo el que me ha dicho esta mañana que la opción para permitir o denegar la descarga automática de imágenes le había desaparecido con la última actualización. En realidad no se trata de la última actualización, es un cambio que hace ya muchos meses efectuó WhatsApp, lo único que sucede es que para que la aplicación no falle por tener activadas ciertas opciones (y no tener que “resetearlas”), todos aquellos que tenían dicha opción deshabilitada han mantenido teniendo dicha opción dentro de los ajustes de su WhatsApp. En cambio, todo aquel que instalase de nuevas la aplicación o tuviese que eliminar los datos de ella por cualquier motivo, no tiene acceso a ella. Por suerte para todos, la aplicación continúa manteniendo exactamente el mismo comportamiento, simplemente oculta la opción para que no pueda modificarse… y es ahí donde entramos nosotros.

Sinceramente no entiendo cual ha sido la razón por la que WhatsApp a quitado la opción, me parece genial que por defecto la mantuviese activada, pero siempre con la opción de quitarla. Del FAQ de su web nos dicen lo siguiente:

“As part of a product decision, we have removed the ability to turn off auto-download images from recent versions of WhatsApp. If your friends still see this feature on their phones, they most likely have an older version of the app.

We understand your concern for data usage; however, images on WhatsApp are down-sized, resulting in a typical image size and data usage of approximately 40-50KB per image. In comparison, the average web page on the internet is 1 MB (1000 KB).

Keep in mind this applies only to image files and not to videos or audio notes, since videos and audio files are significantly larger.

Therefore, even if your WhatsApp contacts send you 100 images every day for an entire month (30 days), that would total to 135MB of data usage. Of course, that’s an extreme case and more often the average WhatsApp user receives 19 images per month; this is equivalent to 855KB, or 0.83MB per month. Rest assured, this amount is covered by even the smallest data plans.

You can also check your actual data usage within WhatsApp by going to Settings > Account Info > Network Usage

You can see the exact media data usage under “Media bytes received.”

In order to stop the WhatsApp images from appearing in your gallery, we recommend that you create a .nomedia file or folder inside of your WhatsApp images folder. You can do this using a file explorer, or by hiding the folder in Quickpic.”

Sinceramente me parece una explicación bastante mala. Traduciendo y resumiendo, la única explicación que dan de dicho cambio es que las imágenes transferidas por WhatsApp ocupan muy poco (aparentemente), y pro tanto no hay razón por no descargarlas automáticamente. Y para aquellos que puedan pensar: “Ya no se trata de lo que ocupen, también una cuestión de privacidad porque CUALQUIERA puede enviarte cualquier imagen, y si por defecto se autoacepta esta va a la galería.” WhatsApp termina respondiendo que si no se quiere que aparezcan que se cree un archiv ollamado “.nomedia” en la carpeta raiz de WhatsApp para inhibir que aparezca en la galería.

Es cierto que Android permite ese “truco” para inhibir que una carpeta sea listada en la galería o en el reproductor de medios, pero sigo sin entender porqué pasamos de tener una opción que TOODOS podían activar o desactivar a voluntad sin mayores problemas, a tener que fastidiarnos y tener que hacer “trucos” molestos si queremos apalear solo algunos de los problemas que implica tener dicha opción activada.

En el artículo de WhatsApp: Lo que todo buen bromista debería de conocer, creo que dí motivos más que suficiente del peligro que implica tener esta opción marcada, ahora marcada o sí o también:

a) Cualquier puede enviarnos una imagen, eso implica que conozcamos al usuario o no puede mandarnos el tipo de imagen que queramos y el móvil la recibirá sin problema. Esto significa que si un desconocido nos manda a nuestro teléfono la imagen de un muchacho haciendo guarrerías con cualquier animal, esa imagen va directamente a nuestra galería.

b) Por mucho que diga WhatsApp, es un gran consumo de ancho de banda, y si estamos dentro de grupos numersos en los que se suelen compartir imágenes, el ancho de banda puede incrementarse considerablemente. Por otro lado es mentira que la media de los datos usados sean de 40-50KB por imagen, si hago media de lo que tengo ahora mismo en mi galería, me da 80KB, una horquilla entre 70-130KB, dependiendo de las imágenes. Eso significa que esas 100 imágenes al día que dice WhatsApps tendría un consimo de ) serían entorno a los 380MB, SOLO en imágenes de WhatsApp.

c) Como ya expliqué en el artículo anteriormente citado, puedo crear en un momento una imagen de 1GB si quiero, y dado que el usuario no tiene forma humana de deshabilitar la descarga automática de la imagen, su dispositivo empezará a descargar dicha imagen de 1GB me conozca o no me conozca, y en todo caso podrá cancelar la descarga (si es que puede) una vez se de cuenta de lo que está pasando, lo cual es también relativo porque se le puede engañar al sistema para que el usuario crea que la imagen ocupa tan solo 10KB. dicho de otro modo, forzando al usuario a dicha opción, lo condena a quedarse sin datos si cualquiera que tenga su número le gusta ser un bromista pesado. Y si dicha imagen la manda en un grupo de 20 personas, seguramente ni siquiera se daran cuenta de lo que ha pasado, hasta que estén bien jodidos.

 

Visto esto, solo nos quedan tres soluciones… cuatro. La primera pasa por empezar a usar en la medida de lo posible HangOut, que aunque no sustituye todas las funciones de WhatsApp, es mucho mejor, pero eso ya entra dentro de lo personal de cada cual.

La segunda y posiblemente casi cualquiera pueda realizarla, pasa por instalar una versión antigua de WhatsApp que permitiese aun tener dicha opción, posiblemente alguna versión 2.8.xxx, estoy seguro que por google pueden encontrase. La idea por tanto sería sencilla, desinstalar WhatsApp, instalar la versión vieja, desmarcar la opción de descarga automática, actualizar a la versión más actual y listo. Cualquiera podría realizar este proceso, siempre y cuando WhatsApp no haya bloqueado ya las versiones viejas.

La tercera opción e igualmente sencilla, aunque tan solo temporal de nuevo, radica en editar el archivo de configuración de WhatsApp y añadirle la opción que deseamos. Como he dicho, Whatspp al iniciarse chequea si ya existía dicha opción en el archivo de configuración. Si existe la deja, si no existe (porque sea una instalación limpia o cualquier otro motivo, la opción no existe. El problema de este método es que necesitamos tener el dispositivo Rooteado, porque necesitamos editar el archivo de configuración de WhatsApp que se encuentra en la partición /data, exactamente en la ruta “/data/data/com.whatsapp/shared_prefs/com.whatsapp_preferences.xml”. Al encontrarse en la carpeta data de la aplicación, implica que dicho archivo tan solo lo puede editar la misma aplicación o un usuario con permisos superiores, es decir root.

Suponiendo que tengamos el dispositivo rooteado, tan solo hay que editar dicho archivo y añadir en la lista de opciones:

Para evitar que la aplicación tenga acceso a él mediante lo hacemos, podemos detener la aplicación por completo en el administrador de aplicaciones de Android, realizar la modificación y lanzar de nuevo la aplicación. Como si por arte de magia fuese la opción vuelve a aparecer (y con la opción desactivada por defecto). El único inconveniente es que no sabemos cuando WhatsApp eliminará por completo dicha opción, o que tendremos que repetir el proceso si realizamos una instalación limpia o se borran los datos de la aplicación.

La cuarta opción es la más útil, pero la más “complicada”, ya que de nuevo se trata de modificar el código de la aplicación. En este caso la modificación es muy muy sencilla, porque el código de WhatsApp ya permite dicha opción. Si lo que hace WhatsApp es chequear si la opción está o no está presente en el archivo de configuración, traducido a código lo que buscamos es un salto condicional, un sencillo “if”: Si la opción existe mostrar lo siguiente… Si sabemos encontrar ese pedazo de código, bastaría simplemente con eliminar la condición, con lo que la opción aparecería SIEMPRE, con independencia de que sea una instalación nueva o vieja. La complejidad de nuevo radica en que hay que:

a) Decompilar la aplicación
b) Encontrar el archivo y el lugar exacto de la edición
c) Saber que editar/añadir/eliminar
d)Saber recompilar la aplicación
e) Firmar la aplicación de nuevo (si queremos que Android la acepte perfectamente, pero al iniciarla tendremos q restaurar una copia de seguridad porque detectará que se ha modificada) o dejarle los certificados antiguos para que no de error al verificar la cuenta (pero entonces tendremos que tener parcheada la verificación de certificados). Personalmente me gusta más siempre la primera opción, pero cada cual escoge su sistema favorito, en el caso de WhatsApp se podría terminar de modificar la aplicación para que tampoco se quejase en la verificación de los certificados, pero sería más edición.

Todos los demás puntos los hemos visto aquí varias veces, así que tan solo voy a ayudar d enuevo con el punto b y el punto c.

En este pequeño cambio, solo hay un archivo implicado, una sencilla búsqueda con findstr en Windows o grep en linux rápidamente nos pondría en la pista de lo que estamos buscando. Es muy sencillo, sabemos como se llama la opción, así qeu si buscamos por “autodownload” llegaremos al id en hexadecimal de la etiqueta, y si buscamos por dicho id, llegaremos al archivo implicado y a la sección de este. Si miramos un poquito más arriba de donde encontramos el id de la etiqueta, tenemos la condición que se ejecuta, con lo que tan solo habría que eliminar la instrucción if que lo precede. Esto en lenguaje de alto nivel sería trivial, en Dalvik es un poquito más engorroso porque hay que saber que borrar o que no borrar, no leemos un sencillo if… sino toda una estructura basada en registros que va cargando los valores necesarios para invocar la condición. Es un bloque pequeño de todos modos, y tampoco es complicado verlo ni eliminarlo

Una vez terminada la edición, se guardan los cambios, se recompila, se firma, se vuelve a colocar la aplicación y aquí no ha pasado nada, volveremos a tener nuestra nuestro WhatsApp con la opción deseada. Claro que si actualizamos perderemos el cambio y tendríamos que volver a realizarlo, lo cual puede ser un poco engorroso para muchos. De ahí a que llega un momento en que es más sencillo crearte tus propias herramientas que automatizan todo el proceso por tí. En cualquier caso, de nuevo se trata de ser didáctico, y de paso decirle a los chicos de WhatsApp que no tiene ningún sentido el cambio que han realizado, lo cual evidentemente nos dice que tienen otros motivos que no están contándonos 😉

whats

Como inhibir el “Ultima vez conectado” de WhatsApp y otros comportamientos: Ingeniería Inversa en Android

Estoy seguro que la mayoría que tenga WhatsApp le gustaría que sus contactos no supiesen cuando estás conectado a él, no son pocos los que envían un mensaje y para saber si lo han leído o no abren de cuando en cuando WhatsApp y ven el estado de conexión del otro para ver cuando fue la última vez que se conectó. Personalmente me da exactamente igual que lo vean o no, pero seguro que la mayoría piensa de otro modo.

Como con la gran mayoría de todos los experimentos, este me llegó después de que un amigo me dijese que su hermano había comprado una aplicación de Android para impedir que sus contactos pudiesen conocer la última vez que estuvo conectado al WhatsApp. Bueno en Android ya sabemos que técnicamente el Ultima vez conectado no es propiamente eso, sino cuando fue la última vez que el usuario tenía en primer plano la aplicación WhatsApp, puesto que en realidad el usuario está siempre conectado. Sabemos que los usuarios de iPhone tienen una opción para deshabilitar esto, los conocemos bien porque son aquellos contactos en los que cuando vemos su estado simplemente no aparece ninguna fecha. En Android no tenemos esta opción, pero eso no quiere decir que no pueda modificarse la aplicación para crear un comportamiento parecido, o incluso mejor.

En realidad este pequeño experimento es solo un ejemplo de la gran utilidad que tiene la Ingeniería Inversa. Pese lo que puedan pensar muchos programadores o defensores a ultranza del código propietario, la Ingeniería Inversa permite conocer mejor el software, descubrir problemas de seguridad para evitarlos, crear Software de mejor calidad… no es una lacra ni un problema, todo lo contrario, es una gran herramienta.

Volviendo al tema de hoy, cuando me dijo este amigo mío sobre dicha aplicación en Play Store sinceramente me extrañó, por la simple razón de que si es un comportamiento de la aplicación en sí, la única forma de eludirlo sería con una modificación de la misma aplicación… a menos que se tratase de un simple truco. Efectivamente, lo que hacen este tipo de aplicaciones no es más que un truco para provocar un efecto similar que puede realmente funcionar bastante bien, aunque tiene muchos problemas asociados sin duda alguna. Para saber en que se basan estas aplicaciones para esconder el estado de conexión de nuestro terminal hay que conocer antes como maneja WhatsApp dicho estado, no hay que profundizar mucho, en realidad es muy sencillo:

La primera cosa que hay que tener clara de nuevo es que en Android las aplicaciones se minimizan, no se cierran (pueden cerrarse también, pero vamos a simplificarlo), esto es debido a que Android es multitarea. Aunque WhatsApp no esté en primer plano continua en ejecución, lo que quiere decir que cualquier mensaje que nos manden, imagen… la recibimos perfectamente en nuestro terminal en ese mismo momento, el que volvamos a poner a WhastApp al primer plano no cambia nada. Teniendo esto en mente, cuando el usuario abre la aplicación o la coloca en primer plano estando minimizada, WhatsApp envía a los servidores de estos un mensaje sobre su estado de forma peródica y constante. Cuando el usuario minimiza la aplicación, este desactiva este comportamiento, con lo que de cara a cualquier otro usuario nuestro estado de conexión cambiará de “En línea” a “Últ. Vez”.  Conocer esto no requiere realmente ser un experto en nada, estoy seguro que muchos que se hayan planteado el “como funcionará…” habrá echo sus propios experimentos de cuando cambia el estado y otras cosas.

Sabiendo por tanto como es el comportamiento de WhatsApp, cualquiera podría imaginar como engañar a WhatsApp, repito, simplemente conociendo como funciona el cambio de estado. Se trataría simplemente de evitar que WhastApp comenzase a enviar esos mensajes a su servidor, y lo cierto es que tenemos una solución muy sencilla a esto, no tener conexión. El no tener conexión (ni WIFI ni datos) impediría evidentemente que WhatsAppe comenzase a enviar los mensajes de estado, pero evidentemente también impediría que WhatsApp pudiese mandar cualquier cosa a otro contacto o recibir mensajes o cualquier otra cosa, pero como ya hemos dicho WhatsApp aun estando minimizado se está ejecutando, y sabemos que el cambio de estado solo sucede cuando tenemos la aplicación en primer plano, es decir la maximizamos. Aplicando la lógica común, nos bastaría tan solo con deshabilitar datos/wifi cuando queremos volver al WhatsApp para escribir un mensaje o leer alguno ya recibido, y volver a conectar los datos/wifi cuando la minimizásemos de nuevo. Estando minimizada y con conexión, recibiría perfectamente mensajes o imágenes o cualquier otra cosa, así como también enviaría nuestros mensajes escritos a nuestros contactos, pues estarían a la espera de conexión.

Esto que he explicado puede hacerlo cualquiera en su casa en cualquier momento, y de echo funciona perfectamente, aunque por supuesto tiene muchos problemas. Las aplicaciones que están en Play Store simplemente automatizan este proceso, pero hacen exactamente lo que he indicado. Hacen que cuando se maximiza (se cambia a primer plano) WhatsApp, se deshabilitan datos y wifi, y se invierte cuando se minimiza WhatsApp. Muchos pueden pensar que es la solución perfecta, pero no solo no es perfecta puesto que no funcionaría siempre, sino que además el usuario perdería mucha funcionalidad en el WhatsApp. Por ejemplo, para mantener una conversación con alguien tendría que estar minimizando y maximizando constantemente puesto que de lo contrario sus mensajes no se enviarían ni el podría recibir nuevos mensajes! Para un mensaje ocasional funcionaría, pero si esa persona quisiese mantener una conversación mínima con cualquiera, tendría que mandar mensaje, minimizar, esperar que el otro respondiese, maximizar, escribir, minimizar.. es evidente que no es práctico de ninguna de las maneras, sin contar que lo único que el usuario podría descargar serían imágenes si tuviese activado el autoaceptar, el resto de contenido no podría descargarlo nunca.

¿Es posible dar con una solución más eficaz? Sí, ingeniería inversa. En el artículo que menciono justo abajo explico mejor que es la Ingeniería inversa para quien no lo conozca, pero digamos que en el software es básicamente el proceso de obtener información sobre como funciona una aplicación de forma interna sin disponer su código fuente original, lo que nos permite incluso modificar la aplicación misma. Recordar que en algunos países la ingeniería inversa es ilegal, aquí en España es legal siempre y cuando no se distribuya su código o cualquier modificación realizada. Es por eso que aunque puedan pedirlo algunos, no puedo colgar ningún WhatsApp modificado lo siento, cada cual que experimente si así lo desea, además la razón de este blog ha sido siempre para enseñar, no para dar.

 

 Muchos de los pasos realizados aquí, los encontramos también en otro artículo que publiqué hace ya meses. En Android, cualquier proceso de Ingeniería inversa tendría los mismos pasos a seguir:

  1. Obtener la aplicación APK (y el paquete odex en caso de ser una aplicación interna de algunos terminales)
  2. Decompilar la aplicación para obtener el código Dalvik equivalente.
  3. Realizar las modificaciones pertinentes.
  4. Recompilar la aplicación, firmarla y alinearla (optimizarla).

Con excepción al paso 3º, el resto son siempre los mismos, existiendo tan solo pequeñas modificaciones entre diferentes casos, pero nada importante. Como tales procesos están explicados en el artículo mencionado, simplemente voy a presuponer que se saben realizar. Existen herramientas incluso que nos permiten obtener un código en JAVA relativamente fidedigno desde la aplicación APK, que aunque no pueda ser recompilado, al menos será mas inteligible para la mayoría de las personas que lo es el código en Dalvik

Obtener por tanto un código que podamos modificar es simple una vez se decompila la aplicación, por ejemplo con apktool. Así que vamos a presuponer que disponemos del código ya decompilado en la carpeta “whats”, y con eso completaríamos los pasos 1 y 2.

El tercer paso sería el más tedioso, puesto que de cientos de archivos que disponemos hay que saber que se quiere modificar, donde hacerlo y como hacerlo. En realidad es lo complicado del caso. En nuestro caso ya sabemos que queremos modificar, queremos suprimir el estado de conexión de nuestro WhatsApp, pero seamos coherentes, tenemos una carpeta con el código decompilado que pesa más de 40MB y contiene más de 4000 archivos. Evidentemente tenemos que acotar nuestra búsqueda, o podríamos tardar años. A este problema se le suma el echo de que inevitablemente tenemos que conocer algo de programación en Android y de como funciona Dalvik, de lo contrario es imposible que pudiésemos encontrar el lugar (o lugares) en el que se implementa dicho comportamiento o como se tendría que modificar. Por suerte para nosotros, el código Dalvik resultante de la compilación es bastante más legible que el código ensamblador de la arquitectura x86. Dalvik es una máquina virtual basada en registros, y en el mismo código podemos ver por suerte la llamada a las funciones que son usadas, así como los parámetros pasados. Esto es una ayuda infinita sin duda, ya que simplemente con conocer a grandes rasgos el SDK de Android, podemos empezar a buscar lo que deseamos.

En nuestro caso concreto, presuponiendo que tan solo tenemos la idea que mencioné al principio de como/cuando se actualiza el estado de conexión, tendríamos que comenzar por ahí. Lo primero que sabemos es que nuestro estado cambia al volver WhatsApp al primer plano, es decir, en el código tiene que existir algún disparador que se acciona al realizar este cambio de estado en la aplicación. Cualquiera que le guste la programación en Android o simplemente haga un poco de investigación, antes o después encontraría esta imagen en la documentación oficial de Android:

actividad

 

Por supuesto existe documentación extensa sobre todo ello en el portal oficial, pero esta imagen es suficiente. Lo que nos dice esta imagen es que existen funciones concretas que son disparadas cuando nuestra aplicación cambia de estado, ya sea al iniciar la aplicación, al empezar a ejecutarse, al “resumirse”, al pausarse, al pararse, cerrarse, reiniciarse… lo cierto es que tenemos unas cuantas opciones. Si fuésemos un poco curiosos, también sabríamos que la función exacta que se dispara cuando una aplicación pasa de segundo plano a primer plano (maximizarse) se llama OnResume(), y la función que se aplica al pasar de primer plano al segundo es onPause(). Estos nombres pueden causar un poco de confusión ya que en realidad una aplicación en Android no se pausa propiamente dicho, pero obviemos esto.

Es evidente que una aplicación puede tener otros sistemas para detectar si la aplicación se encuentra en primer plano o no, pero siempre hay que partir de presunciones y ver a donde nos llevan, si son un callejón sin salida hay que volver y replantarse el problema para optar por otras opciones. Pero si WhatsApp está usando realmente onResume() para la actualización de nuestro estado, al menos podríamos ser capaces de realizar una gran criba. Así pues, si nos basamos en esta teoría, podríamos usar el comando findstr (en windows) o grep (en linux) para buscar dicha función dentro del código Dalvik, puesto como he dicho el nombre de las funciones se encuentran en él:

E:\Android\Proyectos\Whats>findstr /S /I /M onResume *.*
smali\com\whatsapp\AccountInfoActivity.smali
smali\com\whatsapp\BlockList.smali
smali\com\whatsapp\ContactInfo.smali
smali\com\whatsapp\ContactPicker.smali
smali\com\whatsapp\Conversation.smali
smali\com\whatsapp\Conversations.smali
smali\com\whatsapp\DeleteAccount.smali
smali\com\whatsapp\DeleteAccountConfirmation.smali
smali\com\whatsapp\DescribeProblemActivity.smali
smali\com\whatsapp\DialogToastActivity.smali
smali\com\whatsapp\DialogToastListActivity.smali
smali\com\whatsapp\EULA.smali
smali\com\whatsapp\GroupChatMap.smali
smali\com\whatsapp\LocationPicker.smali
smali\com\whatsapp\MediaGallery.smali
smali\com\whatsapp\MultipleContactPicker.smali
smali\com\whatsapp\OverlayAlert.smali
smali\com\whatsapp\RegisterName.smali
smali\com\whatsapp\RegisterPhone.smali
smali\com\whatsapp\Settings.smali
smali\com\whatsapp\VerifyNumber.smali
smali\com\whatsapp\VerifySms.smali
smali\com\whatsapp\ViewSharedContactActivity.smali
smali\com\whatsapp\wallpaper\CropImage.smali
smali\com\whatsapp\wallpaper\WallpaperPicker.smali

Simplemente con esto, si realmente WhatsApp usa dicha función para el cambio de estado, estaríamos restringiendo la búsqueda de más de 4000 archivos a 25 posibles lugares, en los cuales puede ser por supuesto más de uno. 25 es un número suficientemente manejable como para ir buscando en cada archivo manualmente, pero no soy un sádico y vamos a acotarlo aun un poco más. Con poco de inglés que sepamos y aplicando un poco la lógica común, podríamos cribar estos 25 resultados desechando aquellos que parecen no tener absolutamente nada que ver con la actualización del estado, ya que el listado anterior simplemente nos dice donde se está usando dicha función, pero evidentemente dicha función se usa para muchas cosas, no solo modificar supuestamente el estado:

smali\com\whatsapp\AccountInfoActivity.smali
smali\com\whatsapp\DialogToastActivity.smali
smali\com\whatsapp\DialogToastListActivity.smali
smali\com\whatsapp\ViewSharedContactActivity.smali

La razón por la que he suprimido los anteriores no está basado en que evidentemente antes de escribir estas letras ya sé que modificar o buscar, sino en el sentido común. Si tengo un archivo llamado WallPapperPicker, es de suponer que el punto exacto que estoy buscando no se encuentra en él. Por supuesto, de nuevo se está simplemente presuponiendo, esta aseveración podría ser errónea y llevar a un camino sin salida, con lo que de nuevo tendríamos que dar marcha atrás, aumentar el campo de búsqueda y ver si hay mas suerte.

Por experiencia y por el nombre de los archivos, automáticamente habría optado de los 4 archivos mencionados por el segundo y el tercero, DialogToastActivity y DialogToastListActivity, puesto que precisamente lo que quiero es inhibir el estado de conexión, el cual se refleja en lo que en ingles podría llamarse “toast”. Si esos dos archivos no me diesen la solución que busco, buscaría en los otros dos. En este caso concreto, lo que se busca está exactamente en el archivo DialogToastListActivity.

Este archivo podemos editarlo con cualquier editor de texto, y por suerte es un archivo pequeño, unas 670 líneas. Si buscamos por onResume, vemos que nos lleva a la línea 600 aproximadamente, y vemos que comienza un pequeño bloque de unas 25 líneas en Dalvik, algo sinceramente bastante pequeño. Llegado a este punto llegaría la segunda parte complicada, que punto modificar y como, a lo mejor basta con eliminar, a lo mejor se requiere modificar o quizás es añadir. Esto ya es más complejo porque implica tener conocimientos de Dalvik, que aunque es bastante sencillo hay que entenderlo. En este caso concreto podemos hacer alguna chapuza rápida que funcione relativamente bien, para no tener que entrar en muchos detalles.

Si leemos el bloque, vemos que en un momento dado se llama a la función onResume, y después de ello la siguiente función que se invoca de forma clara es sendEmpyMessageDelayed. Posiblemente la mayoría de programadores de Android conocen dicha función, y quien no la conozca puede buscar información al respecto, pero básicamente lo que hace esa función es enviar un mensaje cada X milisegundos, y aquí la palabra mensaje adquiere un amplio significado.

El pedazo de código que nos interesa sería por tanto:

    .line 8
    iget-object v0, p0, Lcom/whatsapp/DialogToastListActivity;->d:Lcom/whatsapp/jd;
    const/4 v1, 0x0
    const-wide/16 v2, 0xbb8
    invoke-virtual {v0, v1, v2, v3}, Lcom/whatsapp/jd;->sendEmptyMessageDelayed(IJ)Z
    .line 2
    const/4 v0, 0x1

En java, todo ello equivaldría más o menos a:

d.sendEmptyMessageDelayed(0, 3000L)

En Android sería algo así como enviar el mensaje ‘0’ cada 3 segundos desde que la aplicación se resuma. Si estamos en lo cierto y todas las presunciones son ciertas, que pasaría por tanto si elimino dicho bloque?? En realidad en Dalvik hay que tener mucho cuidado porque es un lenguaje basado en registros, con lo que no suele ser bueno eliminar asignaciones a registros, puesto que quizás la línea que esté más abajo use el mismo registro para otra cosa, y si la asignación se elimina tendremos problemas. Por tanto podríamos limiter la eliminación a la línea:

invoke-virtual {v0, v1, v2, v3}, Lcom/whatsapp/jd;->sendEmptyMessageDelayed(IJ)Z

Si eliminamos esa simple línea, y todo lo que hemos dicho se cumple, al resumir la aplicación nunca se comenzaría a enviar el mensaje de actualización de cambio de estado (o lo que sea que contenga en ese punto los mensajes ‘0’). La pregunta es si realmente ese es el punto exacto, o si dicha modificación posee efectos no deseados. Pero para eso la única opción posible es recompilar la aplicación con el cambio realizado y probarlos.

 

En este caso concreto, veríamos que efectivamente simplemente por eliminar dicha línea y recompilando el código, funcionaría perfectamente. No obstante tendría dos efectos secundarios no deseables, aunque serían “mínimos”. Realizando dicho cambio nunca veríamos si el contacto con el que hablamos está o no conectado en ese mismo momento, así como que tampoco nos aparecería el “Está escribiendo…”, pero nada más, todo lo demás funcionaría perfectamente. Este problema es debido a que el mensaje ‘0’ que se envía cada 3 segundos no solo contiene nuestro estado de conexión. Por supuesto que esto puede ser perfeccionado y mejorado para suprimir tan solo nuestro estado de conexión.

Otra aplicación práctica de todo ello sería por ejemplo suprimir el envío de “Está escribiendo…” de forma que el contacto con el que hablamos nunca pueda saber si estamos escribiendo o no, lo cual implicaría por ejemplo eliminar un par de líneas en el archivo App.smali sin ningun otro efecto secundario. Podría aplicarse también para producir el efecto opuesto, aparentar estar siempre en línea, o incluso crear en las opciones un botón para habilitar o deshabilitar la actualización de estado a voluntad. En realidad no hay límites, simplemente hay que pensar que deseamos hacer e implementarlo.

conexion

Esa imagen está tomada desde otro WhatsApp el día 9 de febrero mientras ambos mantenían una conversación, en el estado vemos perfectamente que la última vez de conexión de Theliel (Alma Oscura) fue el 30 de Enero, contacto con el que además se estaba hablando en ese mismo momento, con lo que tendría que poner en línea de echo.

 

 Un saludo, y disfrutar de la invisibilidad de WhatsApp.

 

Niantic Project – Ingress

El lector habitual, sabe que no suelo hacer publicidad ni demagogia barata a nadie, y que rara vez publico un producto, sino que generalmente son ideas. No puedo definir Niantic como producto… tampoco como idea.  Definir de forma sencilla que es el “Proyecto Niantic” sería complicado, e incluso algunos me criticarían si dijese que el “Proyecto Niantic” fue sacado de los laboratorios de Google (como el propio Brandon Badger dijo), y más aun si especulase siquiera que se trata de un “juego”. Sin embargo es todo eso y algo más. Pero lo cierto es que de algún modo sería conveniente definirlo.

Un pequeño resumen para quien ande perdido. Hace más o menos un mes (El 1 de Noviembre) apareció una web un tanto enigmática llamada “Niantic Project“. Al principio nada se supo ni se tenía siquiera idea de lo que se estaba cociendo, la web tan solo mostraba lo que parecía ser un tablón de corcho típico donde se colocan papeles y otros, y un tal P.A.C hacía una pequeña introducción con este vídeo:

  

 

Aunque el “Proyecto Niantic” lleva casi un mes puesto en marcha de forma pública, no ha sido sino hace unos 10-15 días cuando ha empezado a atraer las miradas de medio mundo por enlazar su historia con Ingress, aunque de eso hablaremos más adelante. Como digo, todo empezó con ese 1 de noviembre en el que se veía un tablón casi desnudo en la web citada. Cada día transcurrido, la web se actualiza añadiendo al tablón un día más, en el que se cuelgan nuevos enigmas en forma de vídeos, acertijos, pistas, informes… desgranando muy poco a poco y solo para los que son capaces de entender los galimatías no solo que es el Proyecto Niantic, sino toda una trama de conspiraciones, pseudociencia, experimentos… que hay detrás de ello.

Así pues, el Proyecto Niantic nace a primera vista como una web que intenta seducirnos para que descubramos los enigmas que van publicando con un trasfondo sencillamente impresionante. Los Enigmas y la trama son lo suficientemente complicadas que no se ha creado para trabajar individualmente, sino que a día de hoy Google+, IRC, Facebook… en todos los medios es fácil encontrar respuesta para la mayoría de los secretos que se han ido desvelando por ahora, y por supuesto nadie quita que aun queden muchos por descubrir, sin contar que los días siguen pasando… y el tablón continúa publicando puntualmente actualizaciones. Cuando hablo de enigmas y de conocer todo el trasfondo y la historia, solo diré que en los días que llevamos (29 ya) hemos tenido que lidiar con Morse, Braille, Ruso, conocimiento básico de HTML, diferentes cifrados desde simples a muy complejos, análisis de imágenes…

La grandeza del proyecto no obstante, desde mi punto de vista, no radica ya siquiera en que pueda o no tener los laboratorios del proyecto Niantic en Google, sino que TODO el material que encontramos podría pasar por real. Hablamos de decenas de imágenes, transcripciones de audio, grabaciones de voz, vídeos supuestamente amateurs sobre Niantic Project, supuestos documentos secretos… Y eso sin contar con la gran comunidad que se ha formado alrededor de ello en la que encontramos ya cientos y miles de imágenes artísticas de todo tipo, conspiraciones de todo tipo… y por supuesto el gran interés de todos: Poder entrar en “esa otra parte” llamada Ingress

 

 

 

Siento el secretismo con todo ello, pero hay que entender que aquel lector que no haya oído hablar absolutamente de todo esto, quizás podría interesarle realmente como a tantos otros, y desgranar más información sería sencillamente una equivocación y se arrepentirían de haber leído este pequeño artículo. Pero volviendo al tema… ¿que es Ingress?

Oficialmente, Ingress es una aplicación para Android que encontramos en Play Store que cualquier usuario de Android puede instalar. Pero antes de correr a hacerlo hay que entender que tan solo se puede acceder a ella (una vez instalada) por medio de una invitación. A esto se le llama beta privada… aunque todo aquel que siga el Proyecto Niantic podría encontrar que tal vez no es solo una cuestión de ser una beta privada.

Ingress se perfila en principio como una aplicación de realidad aumentada en la que interaccionamos en el mundo real gracias a nuestros dispositivos, que lo único que requieren es tener GPS, tener deshabilitado las ubicaciones falsas y una conexión a datos. Por supuesto son muchos que ya aseguran que es el primer juego de realidad aumentada con calado mundial, otros en cambio más en la línea de Niantic Project preferimos referirnos a Ingress como una herramienta. Su conexión con Niantic Project es directa, aunque eso tan solo podrán conocerlo bien quien siga dicho proyecto. Eso no quiere decir que cualquiera que quiera en el presente o futuro probar Ingress deba de pasar por entender siquiera que es Niantic, nada más lejos!! Puede/podrá hacer uso de una de las aplicaciones más adictivas y mejor pensadas de los últimos años (sin duda alguna), con la única excepción que habrá veces que no comprenda el trasfondo de todo ello o el significado de algunos documentos.

¿Que podemos decir de Ingress? Bueno esto es más fácil para que todos lo entiendan. Nada más ingresar el código, recibiremos en la misma aplicación unos mensajes que empezarán a explicarnos algunas cosas, así como ofrecernos un pequeño tutorial para conocer las funciones principales de la aplicación y de como usarla. En cualquier caso se nos solicitará un Nick por el cual seremos conocidos dentro de Ingress, y tendremos que escoger a que facción pertenecer. Iba a cometer el error de decir eso de “Los buenos y los malos”, puesto que en realidad nadie es bueno y nadie es malo, es más una concepción de como cada cual ve las cosas. Lo que está claro es que o te unes a la causa de “The Enlightenment” (Los iluminados) o “The Resistence” (La resistencia). Escogido esto, para dicha persona, empezara a formar parte de lo que posiblemente sea la primera “Guerra” virtual a nivel mundial, solo que aquí no disparamos, no matamos, la guerra que se desata es (siempre dentro de Niantic e Ingress) por el “adoctrinamiento” del resto de la humanidad. Para ello será necesario la captura de Portales situados en lugares de “poder” o “únicos”, establecer defensas, enlazar unos con otros, interactuar dentro de la misma facción unos con otros si es necesario, establecer estrategias, avanzar…

 

No es tan complejo como cabría de esperar, sino la facilidad con la que cualquier persona del mundo puede adentrarse en este mundo y aportar su grano de arena a la causa, ya sea la de los Iluminados o la de la Resistencia. ¿Tienes un portal cerca? Si no lo sabes es porque aun no tienese una invitación, y para eso tan solo la suerte puede ayudarte ahora mismo, lo mejor es acudir a las vías ordinarias en Ingress y Niantic Project para solicitar tu invitación, y mientras que llega tu oportunidad o no, intenta desentrañar los secretos del Proyecto Niantic, para el cual no hace falta acceder a Ingress. ¿Y que pasa si no tienes uno cerca? No desistas, busca, colabora buscando y enviando nuevos sitios, es posible que en cualquier momento encuentres no uno… sino decenas de ellos.

Y si lo tienes… espero que hayas tomado ya el control sobre él y esté bien protegido, o de lo contrario no durará mucho en tu facción.

Un saludo.

 

 

 

Comparativa Navegadores 2012/Q2: Internet Explorer 10, Firefox 20.0, Chrome 25.0, Safari 6, Opera 12.12

Índice

  • Navegadores
  • Condiciones de las pruebas
  • Benchmarks
  • Conclusiones

 

Versiones de los navegadores

 

Navegadores:

 

Aunque hayan pasado más de 6 meses, no podía faltar una nueva entrega, sobre todo teniendo en cuenta que no hace mucho Windows 8 fue oficialmente lanzado, y con él por tanto la versión final de Internet Explorer 10. La razón por la cual siempre hago mis comparativas con las versiones aun en desarrollo la he dicho siempre y siguen siendo las mismas, y me limito a hacer prácticamente un Copy/Paste de la comparativa anterior:

a) Chrome y Firefox poseen ciclos de actualizaciones muy rápidos, haciendo por tanto que estos siempre tengan ventajas ante otro tipo de comparativas que los enfrenten ante navegadores con ciclos de actualizaciones más largos como Opera, IE o Safari, ya que estos últimos tan solo lanzan versiones oficiales cada bastante más tiempo. Comparar las últimas versiones en desarrollo de cada navegador nos permite ser más imparciales. Incluso Microsoft está empezando a lanzar cada cierto tiempo versiones preview.

b) Los amantes del software (geeks y nerds entre otros) siempre deseamos probar y tener a mano lo último que se está cociendo, cambios que verán la luz de forma oficial para todo el público dentro de quizás unas semanas, unos meses o incluso un año. Por tanto es también una buena oportunidad para probar no lo que hay sino lo que tendremos.

 

Por tanto como es costumbre, tanto Firefox como Chrome se han tomando sus respectivas versiones Nighly. Opera no lanza versiones Nighly, pero sí prácticamente  todas las semanas, al igual que Safari. Las versiones de todos ellos se han especificado anteriormente. Para Internet Explorer se ha usado la versión más actual a la que tenemos acceso, que aunque no es una versión en desarrollo, no olvidemos que su lanzamiento oficial conjuntamente a Windows 8 hace tan solo unos días, puesto que por desgracia no tenemos acceso a versiones betas o alpha.

Como siempre, las versiones de 64 bits de Opera, Internet Explorer y Firefox NO CONTARÁN en el tanteo final, y tan solo tendrán un valor presencial en las comparaciones pertinentes, exceptuando en las de compatibilidades con estándares puesto sus resultados serían supuestamente los mismos. Esto es necesario debido a que lamentablemente aun no tenemos disponible versiones de 64 bits de Chrome o de Safari. Hay que anotar que aunque Windows 8 x64 incorpora tanto una versión de 32bits como de 64bits, el navegador siempre ejecutará una instancia en 64bits que tomará el rol de la interfaz, mientras que ejecutará el contenido de las pestañas en instancias separadas, de 32bits si se ejecuta en modo estándar Internet Explorer, o en el modo “puro” de 64 bits si se habilita las funciones de “Modo protegido Avanzado”. En las pruebas de 32 bits se usa el modo mixto (la interfaz siempre se ejecuta con instancias de 64 bits), en las de 64 bits se activa el modo protegido avanzado y todo se ejecuta en 64bits.

Por quinta (y posiblemente última vez), la versión de Safari instalada está exenta de QuickTime como ya se ha explicado otras veces, esto hace que pierda muchos aspectos de compatibilidad. Las razones son las que he dado siempre, QT actúa de plugin para Safari para dotarlo de mayores prestaciones, y la idea es probar siempre los navegadores, no sus complementos. De lo contrario, por esa regla de tres, podríamos instalar diferentes plugins o extensiones a otros navegadores para dotarlos de más características o mejoras. Sería evidentemente injusto. Apple es la que no debería de asociar un reproductor multimedia a su navegador.

Por otro lado, posiblemente esta sea la última vez que veamos Safari en estas comparativas. Es muy simple. Aunque Apple no ha hecho hasta la fecha ningún comunicado al respecto, lo cierto es que desde hace ya meses Apple ha eliminado de su web todo comentario, enlace, propaganda… hacia Safari para Windows. Esto no es algo a extrañar realmente, si tenemos en cuenta que el índice de mercado que posee Safari en Windows es prácticamente nulo, e incluso en MAC OS ha dejado de ser la opción predominante. Actualmente se siguen generando no obstante Nighlys casi a diario de Safari para Windows desde el proyecto WebKit, lo cual por tanto no debería de ser un problema continuar dando soporte a este navegador en mis comparativas, pero lo cierto es que estas Build no funcionan de forma totalmente independiente, sino que dependen básicamente de toda la interfaz de Safari y otros. Sin el debido soporte de Safari para Windows, estas versiones serán posiblemente cada vez más inestables, y será cuestión de tiempo que dejen siquiera de generarse. En esta ocasión no han existido mayores problemas, y aunque la build se referencia como Safari 5.2 no hay que engañarse, y os aseguro que se ha usado el código más reciente que posee Safari. Por tanto aunque a efectos teóricos se base sobre Safari 5.2, se estará probando Safari 6+

Por último, respondiendo a algunos comentarios y sugerencias de otras veces, la razón por la cual no se incluyen en la comparativa otros sistemas operativos es muy simple. Si quieres hacer una comparativa que sea mínimamente rigurosa tienes que intentar eliminar todas las variables que sean externas a los navegadores. En una comparativa puedes medir al mismo tiempo una sola variable, no dos. Si introdujésemos en esta comparativa resultados provenientes de Linux por ejemplo, además de tener disponibles menos navegadores no podríamos comparar los resultados obtenidos en Windows con los obtenidos en Linux, no tendrían validez alguna puesto que el sistema operativo sería siempre una variable constante. Es como si queremos comparar el rendimiento de una CPU, y para ello tenemos dos equipos totalmente iguales en el que en uno ejecutamos el programa A y en el otro el programa B para medir el rendimiento. Evidentemente ese test no tiene sentido alguno ya que se está midiendo algo de dos formas diferentes. Siempre que sea posible hay que hacer el esfuerzo de no alterar las condiciones, y es por ello que es necesario realizarlo tan solo sobre un solo OS. Sí, se podría hacer la misma comparativa sobre Linux y ver los resultados, y podríamos llegar a conclusiones similares incluso, pero serían solo válidas para ese OS. Dado que Windows posee una cuota de mercado que roza el 90%, es evidente el motivo de por qué se usa este Sistema Operativo.

 

 

Condiciones de las Pruebas

 

Sistema:

  • OS: Windows 8 Enterprise x64
  • CPU: Intel Core i7 920
  • RAM: 12GB DDR3 Triple canal
  • Video: nVidia GTX460 (Driver 310.61)
  • Resolución: 1920 x 1080 (navegador siempre maximizado)
  • Flash Player: 11.5.502 (Firefox, Opera y Safari), 11.3.376.12 (Internet Explorer 7), 11.5.31.106 (Chrome)

 

Como es costumbre, todos los navegadores son instalados de forma limpia en el mismo equipo, usando para ellos como es de esperar perfiles nuevos, tocando mínimamente las opciones de configuración de los navegadores, como pueda ser la página de inicio, la deshabilitación de la carga selectiva progresiva de pestañas, la activación de aceleración por Hardware y WebGL en Opera y poco más. Esto último es debido a que Opera aun no está entregando su navegador con dicho soporte activado, aunque pueda parecer algo de “trampas” se tomará en cuenta también a la hora de evaluar el navegador.

Tan solo se ha instalado como complementos Adobe Flash Player en todos los navegadores y el complemento para WebM de Internet Explorer. El uso de Flash Player es evidente, necesario para algunos test en los que se desea probar el rendimiento Flash en diferentes navegadores y circunstancias, pero también para compararlo con las funciones nativas de vídeo en HTML5. La instalación por otro lado de WebM en Internet Explorer 10 tiene también su lógica. El futuro HTML5 especifica que los navegadores puedan reproducir vídeo sin necesidad de complementos, pero no estandariza que codecs para hacerlo. Opera, Firefox o Chrome soportan todos ellos el estándar propuesto por Google WebM, mientras que Microsoft y Apple apuestan (al menos por ahora) tan solo por H264. Guerras a parte, la idea no es comparar H264 frente a WebM, sino medir el rendimiento de la tecnología de vídeo para HTML5 y compararla a la tecnología de vídeo de Flash. Todos ellos (excepto Safari) soportan de un modo u otro esta tecnología sin ningún tipo de complemento, por tanto el requerimiento mínimo lo cumplen. Ahora bien, como deseamos medir el rendimiento es necesario que TODOS usen la misma tecnología. Por suerte además, existe un complemento oficial del proyecto WebM para IE, con lo que de este modo podemos hacer uso de la tecnología de vídeo WebM de HTML5 en todos los navegadores por igual, excepto como digo Safari, que queda fuera por la sencilla razón que ni siquiera (fuera de la caja) es compatible sin QuickTime. Si Safari fuese compatible al menos con WebM o HTML5 sin necesidad de QuickTime aun podríamos pensar en incluirlo, pero de lo contrario debe de quedar fuera.

 

Cada test se ejecuta 10 veces en cada navegador. Dado que hay test que son muy dependientes a las condiciones externas (y por tanto capaces de generar resultados extraños), el valor final de cada prueba se ha obtenido calculando la media aritmética de los valores registrados un UNA VEZ han sido descartados los valores “extraños” estadísticamente (por medio de la “Distribución Normal”). De este modo se intenta que los datos obtenidos sean lo más fiables posible, sobre todo como he dicho en aquellos test en los que simplemente una pequeña interferencia en el PC como un acceso a disco por algún proceso de fondo, es suficiente para modificar por completo un resultado.

Cada prueba puntúa de 1 a 5 (1 el peor resultado, 5 el mejor), reservando el cero para aquellas pruebas en las que el navegador no pueda realizarse por carencias de este o simplemente produzca un fallo del navegador y sea incapaz de terminar la prueba. En caso de que dos navegadores obtengan el mismo resultado, a los dos se le asignará la misma puntuación, dejando la puntuación restante simplemente sin asignar. Dado que son versiones inestables (al menos algunas ellas) se creará un último “test” que recogerá a modo de resultado la estabilidad del navegador frente a las diferentes pruebas.

 

 

Benchmarks

En esta ocasión no ha habido grandes cambios en los test usados. Si cabe destacar que de momento se ha eliminado de forma temporal el test de PeaceKeeper. La última actualización que hicieron provocó que fuese imposible acceder de forma simple a los resultados parciales, así como no ha sido actualizado algunos de los test que ejecuta a los últimos estándares, con lo que los resultados no son para nada exactos. En cuanto los solucionen, se volverá a incluir.

Las Webs usadas para el consumo de RAM en este caso, así como los tiempos de inicio en frío/caliente y cierre serán las siguientes:

Bandeja de Gmail, Bandeja de Mail Live (Outlook), La página personal de Facebook, La página personal de Google+, YouTube (http://www.youtube.com/watch?v=KEIdACFBhGE en 360p), Portada de “MARCA”, Portada de “El País”, Google Play Store, Wikipedia (https://en.wikipedia.org/wiki/History_of_the_web_browser), eBay (http://www.ebay.com/fashion/womens-clothing). Para los test de 20 pestañas, simplemente se han duplicado las 10 anteriores.

 

Test:

  • Rendimiento
    • Tiempo de Inicio en frío (1, 10 y 20 pestañas)
    • Tiempo de Inicio en caliente (1, 10 y 20 pestañas)
    • Tiempo de Cierre (20 pestañas)
    • Velocidad de carga de Webs con/sin Caché
    • RAM (10 y 20 páginas)
    • CPU/GPU reproduciendo contenido 1080p (Flash y WebM)

 

 

 

 

 

 

 

 

Tiempo de Inicio en Frío y en Caliente

Comenzamos con los tiempos de inicio del navegador para 1, 10 y 20 pestañas, siempre a caché vacío. Fundamentalmente, no se trata de medir la velocidad de carga de las páginas (que se verá más adelante), sino el tiempo de arranque y carga del navegador ante los 3 supuestos anteriores. Inicio en fío significa que el PC no tiene cacheado en RAM nada, generalmente se realiza ejecutando el navegador una vez el arranque del sistema se estabiliza y se ejecuta pro primera vez este, restaurando la sesión de forma automática (de 1, 10 o 20 pestañas). En esta ocasión no se ha recurrido al sistema de siempre de reiniciar el equipo para vaciar la RAM, sino una aproximación similar más consistente y más rápida. El inicio en Frío se hace para asegurarnos que no hay datos en RAM que puedan agilizar la carga del navegador, pero el propio sistema operativo hace esto de forma automática nada más arrancar, cacheando en RAM librerías y otros de programas que ejecutamos de forma habitual para que después se ejecuten estos de forma más veloz. A esto Microsoft lo llama por ejemplo “Superfetch”. Es decir, que los tiempos de inicio en frío de los navegadores en Windows dependen completamente de esta tecnología. Para evitar esto en lo posible se podría deshabilitar Superfetch (que desestabilizará en parte el sistema) u optar por una opción más simple y eficaz: Llenar la RAM.

El sistema después de un arranque en frío empieza a cachear algunos datos. Si además abrimos cualquier aplicación y la cerramos, una gran parte de la memoria se va llenando con datos antiguos que pueden ser usados a posteriori, esta es la razón por la cual abrir una aplicación la primera vez después de arrancar es más lenta que la segunda. Esto lo hace el sistema pero siempre que existan RAM para hacerlo, a fin de cuentas si el sistema posee RAM que no está usando de forma activa, ¿por qué no usarla para cachear datos? Una forma rápida y totalmente eficaz de inducir a un navegador o cualquier aplicación a un inicio en frío es simplemente colapsando la propia RAM del sistema, obligando a este a consumir todo ese espacio que se había reservado para el caché de las aplicaciones. Esto es fácil, tan solo hay que escribir una pequeña aplicación que nos permita reservar la cantidad de RAM que especifiquemos. Si dispongo de 6GB de RAM libres, de los cuales se usan 2 para caché (y contienen datos), si ejecuto mi aplicación y digo que reserve 6GB más, los 2GB reservados son consumidos, puesto que tiene preferencia la aplicación activa. Crear una aplicación para esto es muy simple, y gracias la propio administrador de tareas de Windows 8 podemos ver en todo momento no solo la RAM libre/consumida, sino también la RAM usada en cada momento en el cacheo de aplicaciones/procesos.

Resumiendo, Inicio en frio en esta ocasión se ha realizado consumiendo toda la RAM del sistema asignada para caché, liberando toda la RAM asignada a la aplicación de consumo (lo que asegura que no hay cacheado nada importante) y ejecutando el navegador. Después de comprar este sistema con el inicio en frío (reiniciar) de toda la vida, los resultados son bastantes consistentes, más exactos y además no requiere reiniciar el sistema.

Inicio en caliente implica por el contrario que el sistema ya ha abierto anteriormente el navegador y ha estado trabajando con él, y por tanto mantiene en RAM mucha de la carga anterior. El tiempo es medido desde que se ejecuta el navegador hasta que todas las pestañas han terminado de cargarse (que no quiere decir que todo el contenido en ellas se haya descargado):

 

[singlepic id=36 w=350 h=228 float=left][singlepic id=35 w=350 h=228 float=center]

  • Chrome: Falló en la carga de algunas pestañas, siendo necesario refrescarlas posteriormente (no se contabilizó ese tiempo extra)
  • Internet Explorer: Múltiples bloqueos y cierres en la carga

 

Tiempo de Cierre

Se ha medido el tiempo de respuesta del navegador a cerrar. En teoría podríamos pensar que estos tiempos son prácticamente inmediatos, pero no lo son. En muchas ocasiones el navegador se mantiene como proceso de fondo durante un largo período de tiempo, lo cual evidentemente no es deseable, sin contar con el consumo de RAM que mantiene. Los tiempos medidos son con 20 pestañas cargadas en los navegadores, contabilizando desde el momento en el que se envía la señal kill al proceso padre, hasta que el árbol de procesos de este es totalmente finalizado, incluyendo el proceso padre evidentemente. Es importante al hablar de proceso “padre” si tenemos en cuenta que navegadores como Chrome o Internet Explorer son multiprocesos, y cada proceso padre ejecuta uno o varios procesos hijos:

[singlepic id=31 w=700 h=456 float=center]

  • Internet Explorer: Grandes irregularidades al cerrearse, diferencias de tiempo…

 

Velocidad de Carga de la Web con y sin caché

Este test posee un doble propósito. Por un lado medir la velocidad con la que los navegadores son capaces de descargar por completo la Web desde los servidores externos, y por otro lado medir la eficiencia del Caché de estos, realizando el test con el caché del navegador activado y deshabilitado. Hay que tener en cuenta que lo que se mide no es el tiempo que tarda el navegador en comenzar a mostrar las páginas o cargarlas por completo, sino el tiempo que tarda el navegador en descargar y preparar TODOS los recursos de las web solicitadas. Es de esperar por tanto que los tiempos en las páginas con el contenido cacheado sea mucho menor. Cada Web (La de Facebook, la d PlayStore, la de Wikipedia y la de eBay) fue abierta de forma aislada y se sumaron los tiempos de todas ellas. Como medida y para la consistencia de los datos, se seguro que el tamaño total de la web era aproximadamente siempre el mismo, y las webs tomadas eran las que presentaban un menor contenido dinámico (invariante):

[singlepic id=30 w=700 h=456 float=center]

 

Consumo de RAM

A día de hoy la gran mayoría de los sistemas actuales cuentan con cantidades más que suficientes de RAM, pero no por ello hay que malgastarlo. Además, hay que entender que cada dato que es cargado en RAM o procede del mismo proceso que lo genera o ha sido cargado desde el disco duro anteriormente, y los discos duros (ya sean SSD o convencionales) siguen siendo con diferencia el elemento más lento del equipo, con lo que esto es de vital importancia. El problema se acrecenta en dispositivos portátiles donde la RAM a veces no es tan “sobrante”, o cuando se está trabajando con otras aplicaciones más pesadas. Los datos mostrados corresponden a la memoria Privada usada por el/los procesos, eso quiere decir que no es exactamente el 100% de la memoria RAM ocupada, ya que no se incluyen pequeños “pedazos” adicionales como por ejemplo el mapeo de archivos adicionales como puedan ser las fuentes, archivos de configuración… No obstante, esta “Memoria Privada” supone una precisión de más del 95%, haciendo que sea más que suficiente para nuestros propósitos:

[singlepic id=42 w=700 h=456 float=center]

  • Safari: Múltiples cierres
  • Opera: Picos entorno al 16-20% de uso del procesador
  • Internet Explorer: Picos entorno al 40-50% dele procesador

 

Reproducción a 1080p

Es evidente que la reproducción de vídeo es crucial en los tiempos que corren en la web, un mundo que busca cada vez más el máximo rendimiento con el mínimo consumo posible, lo que alarga las baterías de los dispositivos portátiles también si tenemos en cuenta que la la reproducción de Vídeo continúa a día de hoy siendo uno de los mayores “comecome” de baterías… sin contar con que la gran mayoría del tráfico producido en inet es por estos. La comparativa es doble, ya que no solo compararemos la eficiencia en la reproducción de un vídeo Full HD a través de Flash, sino que también a través del estándar HTML5 vídeo, usando como sistema WebM. Así podremos comparar a grandes rasgos la eficiencia de un sistema o de otro. Internet Explorer reproducirá WebM a través de un complemento como ya dijimos, más que nada porque IE10 oficialmente posee soporte para el estándar de vídeo de HTML5, lo único que ellos ofrecen de base tan solo el uso de H264 y no WebM. El vídeo reproducido en este caso es el mismo tanto en Flash a 1080 como en WebM a 1080 también, el trailer de “El Hobbit“, lo bueno de este vídeo es que está disponible en Full HD tanto en Flash, en WebM como en H264 (aunque este último no lo vamos a testear)

[singlepic id=50 w=700 h=456 float=center]

  • Opera: Saltos tanto en WebM como en Flash, posiblemente algún tipo de FrameSkip

 

SunSpider, V8 y Kraken

Son los 3 benchmarks más utilizados para medir el rendimiento de los motores JavaScript de los navegadores. En los últimos meses Google ha lanzado otro test nuevo a fin de sustituir básicamente V8, llamado Octane. Me parecería injusto usar los dos de Google, por tanto he optado por usar por última vez V8, y en la siguiente será sustituido por Optane. No obstante, aunque los resultados no los publique, son muy similares a los obtenidos por V8, quedando todos los navegadores más o menos en la misa posición parcial.

Como ya he dicho en muchas ocasiones no soy fan de test sintéticos de ningún tipo, y mucho menos tests que han sido optimizados al máximo por todos los navegadores para obtener buenas puntuaciones. Estos 3 test se toman como estándar por todos los navegadores, lo que quiere decir que puedo asegurar que TODOS los navegadores hacen trampas en estos test según les convenga. No quiere decir que sean totalmente inútiles, ya que muchas optimizaciones son llevadas después a los entornos reales, pero por regla general no son demasiado fiables. Así es previsible que Google obtenga un resultado favorable además en V8, Firefox en Kraken y Safari en SunSpider, más que nada porque los test son suyos.

Más adelante veremos que el rendimiento JS en entornos reales (aplicaciones, código…) que a fin de cuenta son muy dependientes de JavaScript, los resultados son muchas veces totalmente dispares a los test sintéticos:

[singlepic id=46 w=350 h=228 float=left][singlepic id=49 w=350 h=228 float=center]

[singlepic id=37 w=350 h=228 float=center]

 

Normal Mapped, Canvas Performance, VII y Asteroids

HTML5 permite integrar dentro del navegador de forma simple contenidos complejos a través de canvas. Básicamente Canvas define un marco de ejecución de cierto contenido (generado principalmente por JavaScript). Es por ello que en realidad podría verse Canvas como la aplicación práctica del uso pesado de JavaScript. Esto ha permitido suprimir la necesidad de complementos para un gran sin fin de necesidades, con lo que tan solo con disponer de un navegador compatible podemos hacer correr la aplicación sin importar nada más… siempre que por supuesto el navegador sea capaz de ejecutar en tiempo real la aplicación correspondiente, lo cual como digo se fundamenta en JavaScript

Normal Mapped es un test que aunque es claramente gráfico posee una carga de está mínima, siendo el mayor aporte JS, y por ello queda relegado a este grupo de test. Por otro lado, Canvas Performance, es un benchmark muy interesante de cara a que trata de medir el rendimiento no de JavaScript en realidad, sino del contenido ejecutado en Canvas de forma sintética, al más puro estilo de los test sintéticos JavaScript. VII es una demo de un juego creado a modo de test para los navegadores que hace un uso bastante extenso no solo de JavaScript, en este caso de CSS, SVG y de la composición de capas. Asteroids por otro lado es un test ya conocido, con fuerte dependencia JavaScript:

[singlepic id=39 w=350 h=228 float=left][singlepic id=29 w=350 h=228 float=center]

[singlepic id=51 w=359 h=235 float=left][singlepic id=28 w=359 h=235 float=center]

  • Opera: En Canvas usa algún tipo de FrameSkip, lo cualmejora la puntuación pero produce saltos constantes

 

Tanque de peces (3.000 peces), Pecera (2.000 Peces)

Lo bueno de los peces, es que solo tenemos que añadir más al tanque o a la pecera para aumentar la complejidad. Se han mantenido los 3000 peces en el tanque y los 2000 en la pecera, aunque en esta última ya se ha alcanzado el tope por dos de los navegadores (se incrementará en la próxima). Dos Test similares pero diferentes, orientados ambos al rendimiento gráfico de Canvas puro y duro. Los dos fueron diseñados para aprovecharse de la aceleración hardware de contenido, por lo que es de esperar que Safari fracase estrepitosamente.

Todos los test con fuerte contenido gráfico acompañan igualmente la carga en la CPU y en la GPU, lo cual servirá además para comparar el consumo energético de cada navegador

[singlepic id=48 w=350 h=228 float=left][singlepic id=40 w=350 h=228 float=center]

 

“Come-Cocos” (Browse Hunt)

Un test bastante exigente en todos los aspectos, aunque está en la categoría de gráficos hace un uso extensivo de JS y SVG.  sin duda caprichoso y que prácticamente ningún navegador logra ejecutar de forma correcta, después de muchos meses ninguno es capaz de llegar a los 60 fps.

[singlepic id=32 w=700 h=456 float=center]

 

“Letras” (SpeedReading)

Uno de los mejores test para comprender la importancia de la aceleración gráfica dentro de los navegadores. Pasamos de los 6 segundos en finalizar el test a más de 2500 en el caso de Safari. Posiblemente sea también la última vez que lo veamos en acción, puesto que exceptuando Safari el resto de los navegadores logran “Pasarlo” correctamente, de 6 a 7 segundos no es algo que podamos… “valorar” en demasía.

[singlepic id=44 w=700 h=456 float=center]

 

Psicodélico

Otro test que se ha hecho muy extendido y famoso en toda la red por demostrar el potencial gráfico actual de los navegadores. Existen varias versiones de este test, pero al final siempre es lo mismo: Una imagen que gira sobre si misma a la máxima velocidad posible. A diferencia que el test anterior, es uno de los mejores test para ir comprobando la evolución y el perfeccionamiento del potencial gráfico del navegador:

[singlepic id=41 w=700 h=456 float=center]

 

Webvizbench

Aunque no deja de ser un benchmark, es uno de los mejores ejemplos de canvas compuesto, con una alta carga JavaScript, gráfica, CSS… explota al máximo desde transiciones, composición de capas, animaciones… es de los test más completos que veremos por aqui, y orientado siempre a aplicaciones prácticas que podrían/pueden crearse y que antes eran totalmente impensables. Uno de mis test favoritos:

[singlepic id=53 w=700 h=456 float=center]

 

Tanque de Peces (50.000) y Sistema Solar (4000 planetas), ambos para WebGL

De nuevo, dado que todos los navegadores exceptuando inexplicablemente Internet Explorer 10 y (previsiblemente) Safari soportan WebGL, es ya de obligado cumplimiento su testeo. En realidad Safari si cuenta en esencia con soporte para WebGL, pero este soporte es tan solo para MACOS, por tanto queda exlucído a última posición junto a IE10.

El caso de Microsoft de no dar soporte para WebGL fue explicado hace tiempo por ellos mismos, personalmente no comparto su visión pero es respetable. El problema nace de que puede ser “peligroso” que el navegador pueda tener acceso directo o indirecto al hardware del equipo, como es en este caso el adaptador de vídeo para poder hacer uso de webGL. Navegadores como Chrome, Firefox u Opera no es que no tengan en cuenta este tipo de “problemas de seguridad potenciales”, todo lo contrario, simplemente se centraron en solucionar esas deficiencias. Han pasado ya muchos meses desde que comenzamos a ver WebGL en los navegadores y sabemos por los reportes de seguridad que las primeras versiones que implementaban los navegadores eran como digo potencialmente peligrosas, ya que podría descubrirse (siempre hipotéticamente hablando) un exploit a través de WebGL que a su vez pudiese interactuar con el Driver de vídeo y por ende ejecutar código malicioso en modo Kernel (muy peligroso). Esto se ha ido solucionando con el tiempo, y a día de hoy se usan incluso extensiones de OpenGL específicas como pueda serlo GL_ARB_robustness para protegerse de este tipo de posibles problemas potenciales.

Esto no elimina totalmente el potencial peligro de WebGL, y técnicamente podría encontrarse alguna combinación de shaders,  texturas, geometrías… que desestabilizasen el sistema. En realidad no por un problema del navegador en sí, sino por el propio Driver de vídeo del sistema o una mezcla de ambas cosas. Es un riesgo mínimo y hay sistemas como digo para evitarlo (para empezar unos Drivers actualizados siempre ayuda). Por otro lado hay que destacar que aunque GL_ARB_robustness es una solución muy eficaz (y realmente funciona), es una extensión de OpenGL 3.2, lo que deja fuera prácticamente por diseño a cualquier navegador bajo MAC OS (el soporte de OpenGL bajo MACOS es de muy deficiente a pésimo) y a muchos adaptadores (sino todos) de AMD. Tan solo nVidia y bajo Windows se salvan en gran medida, con lo que se puede comprender en parte el miedo de Microsoft. Repito… hablamos hipotéticamente.

 Es interesante no obstante como los chicos de Mozilla tomaron el test original de Microsoft del tanque de peces (usado anteriormente con 3000 peces) y lo adaptaron a WebGL. Comprobamos como tenemos que elevar a la friolera de 50.000 peces para no alcanzar los 60 fps de tope. Si bajo la aceleración por Hardware por contenido y capas 3.000 peces parecían ser el tope por ahora, el rendimiento por WebGL frente al test anterior es sorprendente:

[singlepic id=47 w=350 h=228 float=left][singlepic id=43 w=350 h=228 float=center]

  • Opera: No es capaz de representar los “planetas” en Sistema Solar

 

Spinnig Balls

Cualquier programa informático generalmente requiere un buen gestor de memoria que esté de forma asidua buscando y liberando cualquier trozo de RAM que ya no use. Esto es útil por dos razones principalmente: Primero porque de lo contrario el consumo de RAM subiría constantemente y terminaría con consumir toda la existente, y segundo porque la ejecución del programa sería cada vez más lenta y los datos en RAM más fraccionados. Esto como digo se evita “reciclando” la RAM cada cortos períodos de tiempo, función que es llevada acabo por lo que llamamos un Garbage Collector (recolector de basura en sentido literal). Los navegadores no son una excepción a esto, y pueden producir en cortos períodos de tiempo muchos objetos nuevos debido a código JavaScript o DOM, los cuales muchos de ellos incluso son destruidos con la misma rapidez. Esto genera constantemente muchos trozos de RAM “basura” que es bueno… es necesario ir liberando. La alternativa de no usar GC (Garbage Collection) no es viable en ninguna circunstancia, sin esto el navegador no tardaría en colapsarse y agotar la RAM del sistema.

El problema de los recicladores es que son funciones/subrutinas que tienen que ser ejecutadas como es natural dentro de los propios procesos, y dependiendo del sistema GC que estén usando pueden incluso detener la ejecución del proceso por completo hasta que el reciclado se ha terminado. Esto en un navegador se traduce por ejemplo como una extrañas pausas en un momento dado, un salto en u juego, un drop de FPS momentáneo… cuestiones que realmente no implican que el proceso se ejecute más rápido o menos rápido, sino que se ejecute de forma fluida o no. Esto lo hemos visto en muchos test en los que algunos navegadores no es que obtengan bajos FPS, sino que aplicaciones que aun obteniendo altos FPS son totalmente imposibles de manejar dada las continuadas pausas.

Cualquiera que haya jugado a cualquier juego online conoce los efectos del “lag”, pues bien esto sería algo similar, donde da igual cuan potente sea el equipo, puesto si el lag es alto puedes darte por muerto. La eficiencia o no de cada modelo de GC varía. En algunos programas puede ser mejor un modelo, en otros otro. Por ejemplo se podría hacer un GC simple que cada 2 segundos ejecutase una subrutina para hacer el reciclado, pero el tiempo invertido en ese “limpiado” también variará en función de la última vez que se realizó. Podríamos ejecutar GC cada X segundos, pero cada esos X segundos casi con toda seguridad se notaría una micro pausa. Si no se ejecutase ya sabríamos que pasaría y si se  hiciese cada medio segundo a lo mejor se estaría tb produciendo una latencia y lag por el número de veces que se ejecuta el recolector… es decir, no es nada fácil dar con el mejor sistema, puesto que el mejor sistema depende de cada momento.

Este test mide este comportamiento. Genera muchos objetos a gran velocidad constantemente, y mide las pausas que se registran. Este test es muy muy sensible a cualquier otro proceso que se esté ejecutando, incluso puede afectar el movimiento del propio ratón, así que ojo. Cada pausa que registra el programa la anota, y la mejor puntuación es para aquel navegador que realiza menos pausas o pausas más cortas. Es decir que un navegador que a lo mejor tienen 10 pausas de 5 ms y otro que posee 5 de 10 ms, el primero obtendrá mejor resultado ya que la implicación es menor y la ejecución mucho más fluida.

[singlepic id=45 w=700 h=456 float=center]

 

Test de compatibilidad HTML5 de Niels

A día de hoy un buen navegador no solo es aquel que es el más rápido, sino que también está en continuo desarrollo para adaptarse a los nuevos tiempos y a los nuevos estándares. El test de Niels es uno de los mejores identificativos para medir la compatibilidad con el futuro estándar HTML5. En las últimas actualizaciones se le ha añadido también algunas otras características ajenas a HTML5 de todos modos. Hay que tener en cuenta que este test al margen de algunos otros añadidos y HTML5 no testea otros estándares igualmente importantes, como puedan ser WebGL, CSS, SVG…

[singlepic id=38 w=700 h=456 float=center]

  • El test de Niels se basa actualmente sobre 500 puntos máximos.

 

Test de compatibilidad WebGL de Khronos

Exactamente igual que testeamos poco a poco las especificaciones HTML5 que van formándose, hacemos lo mismo con las especificaciones de WebGL. WebGL es un estándar para permitir que el navegador pueda ejecutar gráficos avanzados en él, es llevar la API OpenGL a los navegadores. Dos navegadores pueden ser compatibles con WebGL, pero si uno no es compatible en algunas cuestiones de WebGL el resultado puede ser simplemente que el contenido no se visualice o se visualice mal. Mientras buscaba algunos test WebGL interesantes, en muchos casos no todos los navegadores con soporte WebGL podrían ejecutarlos correctamente

[singlepic id=52 w=700 h=456 float=center]

  • Internet Explorer y Safari: No son compatibles
  • Opera: Aunque es compatible, múltiples test provocan cierres constantes

 

IE Center Testing

Microsoft posee desde hace ya tiempo un site con una tabla que muestra la compatibilidad de los diferentes navegadores frente a los nuevos estándares. Los test que se han usado aquí son exactamente los mismos, solo que yo los aplico a mis versiones de los navegadores, y no a las que aplica MS.

Hay que entender que aunque la suite de test que expone Microsoft es bastante completa (siendo a mi gusto el test de compatibilidad mas completo que hay), es totalmente parcial y engañosa. La suite de test creados por Microsoft para probar la compatibilidad de los navegadores se basa en exponer TODAS las compatibilidades que Microsoft sabe que Internet Explorer 10 es compatible, con lo que cabe esperar que Internet Explorer 10 obtenga un 100% en todos los test. En cambio, para muchas otras especificaciones y partes de especificaciones en las que Internet Explorer no es capaz de estar a la altura, Microsoft simplemente no crea test para ellos. Es el caso de muchas especificaciones de HTML5 (que es mucho mejor identificativo el test de niels) o para WebGL. A esto habría que sumarle además errores de los propios tests que conscientemente o inconscientemente Microsoft comete, haciendo que IE 10 sea capaz de pasar dichos test y la competencia no. Esto no es tan extraño, pensar que muchas cuestiones de las especificaciones son totalmente interpretativas, y así por ejemplo Mozilla puede entenderlas de un modo y Microsoft de otro. Otras veces simplemente se deja abierto a elección de cada cual como hacerlo… Supongo que la mejor forma de saber quien de ellos tiene razón es mirando simplemente las implementaciones de cada uno, y si 3 lo hacen de un modo y solo es uno quien la interpreta de otro, posiblemente esos 3 tengan razón. De todos modos aquí nos basamos tan solo en los test de Microsoft tal como ellos los concibieron.

Todo esto se resume con que esta suite es crucial a día de hoy y un excelente trabajo por parte de Microsoft sin duda, pero que quizás tan solo cubre un 60% de un todo, siendo el 60% que cubre el que precisamente interesa a Microsoft por ser compatible con su navegador. Aun así el soporte para CSS, SVG, JavaScript…  es bastante bueno. Quizás la mejor forma de interpretar estos resultados sería eliminando a Internet Explorer de este test, lo que nos daría posibilidad de comparar realmente otros navegadores entre ellos, no contra otro que evidentemente sabemos que va a ganar (se hizo para ello).

[singlepic id=34 w=700 h=456 float=center]

  • Test realizados con la última versión del IE Center de Microsoft, actualizada a 25/10/2012

 

  Test de W3C para CSS 2.1

 Pese al bombo que se le ha dado a las futuras especificaciones de HTML5, posiblemente CSS sean especificaciones mucho más importante que los nuevos añadidos que pueda implementar HTML5. Esto es simple, CSS es usado a día de hoy prácticamente en todas las web del mundo, y cada vez se hace un uso más intensivo de este, tanto para aplicar simples estilos, a crear auténticos efectos de todo tipo.

CSS permite básicamente aplicar estilos, formatos… a cualquier parte de una web, elemento o conjunto de ella de forma que sea simple reutilizar su código, modificarlo… y como cualquier otro estándar ha estado en continuo cambio y evolución. Las especificaciones CSS 2.1 son a día de hoy ya un estándar en uso, no es como HTML5 un estándar en desarrollo, sino que esta por decirlo de algún modo publicado. Es cierto por supuesto que se continúan revisando sus especificaciones añadiendo… pero básicamente está terminado. La evolución de este sería CSS 3.0, que se encontraría en el mismo estado más o menos que HTML5, en pleno desarrollo.

En este caso, me gustaría tener tiempo material para poder lanzar un análisis exhaustivo sobre los navegadores y CSS 2.1 gracias a la suite de W3C, el problema es que hablamos de miles de test y no son automatizados, requieren una constante vigilancia. Es por ello que en esta ocasión he de optar por tomar los datos oficiales de W3C sobre estos datos, y lo que voy a exponer aquí no son pruebas personales y locales, sino los datos del último reporte de W3C. 

Los datos son simples de interpretar, existe un porcentaje de test cubiertos y otro de test cubiertos pasados. Como es porcentual, y teniendo en cuenta que la mayoría de los navegadores tienen cerca del 100% de test cubiertos, podemos usar de resultado final el porcentaje de test pasados cubiertos. Por supuesto este tendrá una pequeña desviación de error, que es menor en tanto y cuanto el porcentaje de test cubiertos sea mayor.

En el futuro intentaré poder pasar manualmente todos los test a cada navegador, puesto que los resultados del W3c no son aplicados a un navegador en particular, sino que se aplican a cada Engine del navegador, y además son acumulativos. Es decir que Safari o Chrome se le asigna el mismo valor (cuando por descontado las puntuaciones serían diferente), y por otro lado no se aplican tan solo a cada versión del navegador en particular, sino en el conjunto de todas ellas. Pese a todo, es interesante tener una visión globgal de la compatibilidad de los navegadores frente a CSS 2.1

Sobre CSS3, el test de Microsoft ya cubre parte de estas especificaciones, y en el futuro incluiré también la suite oficial de W3C de test para CSS3 (muchos de los cuales son los que usa Microsoft)

 [singlepic id=33 w=700 h=456 float=center]

 

 

 

Conclusiones

Si valoramos cada navegador como se dijo al comienzo, los resultados serían por tanto los siguientes:

Resultados Firefox 20 x86 Chrome 25
IE 10 x86
Opera 12.12
Safari 6
Rendimiento 62 41 32 24 35
JavaScript 12 13 11 5 4
Canvas 13 17 14 11 5
Gráficos 28 16 23 20 7
WebGL 10 7 0 7 0
Otros 5 4 1 3 2
Compatibilidad 17 15 12 9 4
Estabilidad 5 4 2 1 4
           
Total 152 117 95 80 61

 

  • Rendimiento

    El rendimiento de un navegador no sólo se resume en lo rápido que pueda ejecutar un código en JavaScript o los fps que sea capaz de mostrar en cualquier aplicación/juego. De echo, desde mi punto de vista posee un peso más que importante a la hora de escoger uno u otro. ¿Cuantas horas a la semana pasamos delante de un PC/dispositivo con el navegador abierto? Cada vez disponemos de dispositivos más potentes, pero las páginas Web, las aplicaciones Web… cada vez son más complejas igualmente y requieren de esa potencia extra. Por tanto es de extrema importancia que el navegador no solo sea capaz de ejecutar una tarea lo más rápida posible, sino que el propio navegador se comporte de forma ágil y veloz en el sistema. Eso implica que tenga excelentes gestores de memorias propios, que pueda gestionar inteligentemente la carga de nuevos contenidos, reducir en la medida de lo posible los accesos a disco, innovar en nuevos sistemas de almacenaje de datos para su rápido acceso, reducir la sobrecarga del propio OS… y sinceramente esto es una tarea muy complicada.

    En cuanto a tiempos de inicio se refiere, en este caso es Firefox quien prevalece sobre el resto casi en todas las pruebas. Esto posee una mayor importancia si recordamos que Firefox no es un navegador multiprocesado como es Chrome, lo que significa que los chicos de Mozilla están aunando un esfuerzo increíble en mejorar la respuesta general del Navegador. Chrome e Internet Explorer aunque son multiprocesados (que no quiere decir multihilos, que lo son todos) no son capaces de optimizar lo suficiente el código para estar a la par, pero exceptuando Opera que posee problemas en este caso, no tienen un rendimiento que sea muy alejado.

    El principal problema de abrir múltiples pestañas a la par es la sobrecarga en el navegador, independientemente de la velocidad con la que se carguen después en el navegador. En los navegadores no multiprocesados como Firefox, Opera o Safari la apertura múltiple de muchas pestañas podría provocar al usuario la sensación de paralización/congelación de este hasta que prácticamente todas las pestañas estuviesen cargadas, ya que desde el punto de vista del navegador tan solo estaría llevando a cabo una misma tarea. Para Internet Explorer o Chrome este problema no lo tienen, cada pestaña tiene su propio espacio y sería el propio sistema operativo quien gestionaría por medio de su planificador (Scheduler). Para tratar con ello, tanto Opera como Firefox usan por defecto la carga selectiva de pestañas, es decir, por defecto cuando se abren múltiples pestañas a la par tan solo se cargan aquella que esté en primer plano. El efecto es inmediato, de poder tener el navegador paralizado durante múltiples segundos la navegación es instantánea, y mientras se pueden ir cargando de fondo el resto de las pestañas. Por supuesto a la hora de medir los tiempos, este comportamiento se deshabilitó para que todos los navegadores estuviesen en igualdad de condiciones, como es natural.

    Todo tiene pros y contras, y que una aplicación sea multiprocesos implica inevitablemente otros efectos secundarios cuando no se cuidan demasiado, y que se evidencia en una sobrecarga adicional en la memoria RAM y en el tiempo necesario para finalizar por completo la aplicación. En esta ocasión Chrome ha mejorado en mucho el cierre del navegador, mientras que IE continúa con tiempos muy altos y muy inestables. De cualquier modo, se puede apreciar perfectamente como precisamente Chrome e IE poseen con diferencia el mayor consumo de RAM, mientras que el resto de los navegadores poseen un consumo mucho más amortiguado, llegando hasta las increíbles cifras de FIrefox. Uso increíbles porque si las comparamos con Chrome, para 10 y 20 pestañas Chrome casi duplica el consumo de RAM frente a Firefox. Tanto Opera como Safari poseen un consumo medio no obstante.

    Respecto a la carga de contenido cacheado y sin este, vemos que de nuevo Firefox vence, aunque prácticamente con unos resultados iguales a Chrome, siendo las diferencias complicadas de apreciar. Safari tampoco queda muy lejos de Chrome, e incluso IE no obtuvo unos resultados demasiado malos, sino fuese por algún que otro problema cuando no cachea el contenido.

    Por último, hay que destacar el rendimiento en la reproducción de contenido en 1080p de los navegadores y de la mitificación que otrora intentó Steve Jobs en que Flash es la lacra para el rendimiento, la seguridad, la batería y el pasado. 6 meses después, volvemos a demostrar que flash sigue siendo la opción más viable, más rápida, con menor consumo energético, con mayor rendimiento para la reproducción de contenido audiovisual. Si miramos los recursos usados por el equipo en la reproducción de contenidos en Flash y contenidos en WebM, vemos que las diferencias son notables, aunque en esta ocasión vemos que los resultados son más moderados, lo cual nos dice que posiblemente nVidia al menos habría aplicado algún tipo de aceleración hardware a sus drivers para WebM, y esto se nota. Aun así vemos que es mucho más eficiente Flash, mientras que reproducir en el equipo de pruebas un vídeo 1080p en flash consumía en el peor de los navegadores un 13% de la CPU (menos de un 1% en los mejores casos) y un 11% la GPU (en el peor de los casos), WebM llegó a necesitar en el peor de los escenarios un 13% CPU/20% GPU. sin duda alguna es una gran evolución desde la última comparativa, pero aun así Flash continúa siendo lider.

    Por supuesto, se podría usar otros codec como H264 para la reproducción de vídeo por HTML5, y este poseería mejor soporte para aceleración por hardware que WebM (y mayor calidad), pero h264 está fuertemente patentado y ya explicamos el por qué de usar WebM.

    Estoy convencido que en el futuro se podrá estandarizar el uso de codecs en los navegadores y que la reproducción por medio de HTML5 será tan eficaz como con Flash, pero eso será el futuro, continúa estando lejos. El proyecto WebM no será posible mientras que el soporte para este sea el que estamos viendo.

     

  • JavaScript

    Los test sintéticos JavaScript que ya conocen todos siguen siendo punto de referencia para muchos. Como ya he dicho tantas veces, me parece que son test tramposos que tan solo buscan la buena prensa de los medios. Seamos sensatos, cualquiera que eche un vistazo a los números y luego a los entornos reales ve que existen diferencias cuanto menos graciosas. Así por ejemplo supuestamente Internet Explorer mantiene la primera posición en SunSpider, pero si miramos en Kraken que es un derivado de SunSpider queda lejos de esa posición.

    No hay que ser un genio para darse cuenta que todos los navegadores (sin excepción) optimizan partes de su código a sabiendas de estos test, con la inclusión de Fast Path y otros. Por supuesto que muchas de estas optimizaciones pueden ser llevadas a entornos reales, pero es evidente que la mayoría no, la mayoría tan solo tienen utilidad en estos test, y por tanto su fiabilidad es más que dudosa.

    De nuevo no quiere decir que sean totalmente inútiles este tipo de test, y se aprende mucho de los motores JS de cada navegador, se pueden detectar puntos calientes en ellos, mejorar… eso por supuesto!! pero estos test tienen sentido realmente cuando se comparan no navegadores Vs navegadores de la competencia, sino en todo caso las mejoras existentes en JavaScript entre las diversas versiones del mismo navegador.

 

  • Canvas

    He querido separar este apartado del de JavaScript, aunque en realidad están muy relacionados uno con otros. Canvas es una de la infinidad de especificaciones que poseerá el estándar HTML5 y que se están empezando a usar muy poco a poco. Como ya he dicho, Canvas define algo así como un espacio de trabajo en el que se ejecutará un código principalmente en JavaScript, CSS… con lo que es posible la creación de aplicaciones Web complejas, y por supuesto juegos como Angry Bird y tantos otros. El rendimiento de estos “marcos” está ligado íntimamente con JavaScript, pero como veremos en el apartado gráfico también de otros muchos factores.

    Es complicado medir este apartado dado que se puede crear un Canvas con el contenido más vario pinto posible, y es más que posible que en algunas aplicaciones domine un navegador y en otras domine otro. Si vemos los resultados son muy variados, no hay un claro ganador porque como digo es muy dependiente del contenido del canvas. Quizás podamos afirmar que cuando Canvas posee un fuerte componente Javascript, el ganador es Opera o Chrome, mientras que si posee un componente gráfico es Firefox.

 

  • Gráficos

    Hay que tener en cuenta antes de empezar, que aunque esta sección se llame “gráficos” no tiene nada que ver con la elavoración de gráficos complejos 3D ni nada por el estilo, sino test que pueden sacar un provecho enorme de la aceleración hardware. Así por ejemplo tenemos el test de SpeedReading que tan solo se vasa en un marcador veloz de letras, o psicodélico, que no deja de ser una imagen girando sobre sí misma.

    Opera continúa por defecto con esta característica deshabilitada, aunque en esta ocasión ha logrado rebajar de forma considerable el uso de GPU que tenía anteriormente. Internet Explorer o Firefox continuan siendo lideres indiscutibles, siendo muy eficaces tanto en uso de GPU como en rendimiento general.

    Tanto Internet Explorer como Firefox usan el mismo Backend usado de forma muy similar, aunque Firefox lo usa por regla general algo mejor (no demasiado). Chrome por su parte hace algo similar que Opera, usando un backend de OpenGL Safari por contrapartida parece haber abandonado el soporte para Windows, con lo que es más que posible que jamás lo tenga. En la versión de MAC OS posee cierto tipo de aceleración, pero recordemos que MAC OS no posee ninguna API Decente de aceleración hardware 2D, con lo que estos test en MAC OS darían igualmente a Safari la última posición.

    Por último decir que la ventaja de que Opera o Chrome usen OpenGL de backend, es que en teoría debería de ser totalmente compatible con cualquier OS compatible con OpenGL (Linux, Windows XP, MAC OS), mientras que el camino tomado ahora mismo por Firefox e Internet Explorer requieren de DirectX 9+ (recomendando DirectX 10) y Windows Vista/7.

    El futuro parece más o menos evidente. Firefox no solo tiene creado el backend de Direct2D/DirectDraw, sino que posee también un Backend OpenGL para Linux/MAC OS e incluso Windows si se fuerza. Así mismo con el tiempo Mozilla abandonará Direc2D/DirecDraw e implementará un Backend en Windows basado en Direc3D, con lo que se obtendrá no solo un rendimiento superior, sino que será más compatible dentro de los diferentes adaptadores de vídeo y versiones de Windows.

 

  • WebGL

    Opera se sumó hace tiempo al carro de WebGL aunque aun no habilitado por defecto.

    Aunque en el apartado anterior se ha hablado de forma extensa sobre la aceleración de hardware y de contenido gráfico, hay que saber diferenciar totalmente WebGL de ello. En el apartado anterior se mostraba la capacidad de los navegadores para acelerar gran parte del contenido en muchas aplicaciones Web y juegos a través de diferentes APIs, como por ejemplo una imagen girando velozmente sobre ella misma, transiciones rápidas… aplicaciones o juegos que podemos encontrar cada vez más en cualquier lado. No hablamos de apartado gráfico anteriormente porque manejásemos gráficos complejos, sino para especificar que son test que hacen uso extensivo del adaptador de vídeo.

    Pero WebGL es totalmente diferente, con WebGL sí asumimos que vamos a trabajar (o al menos que podemos trabajar) con gráficos complejos. WebGL se crea como iniciativa de poder renderizar en Canvas contenido 2D/3D complejo a través de OpenGL. De prosperar y ser realmente eficiente (que es discutible dado la gran sobrecarga de JavaScript) podríamos encontrar a medio plazo juegos con bastante potencial gráfico ejecutado directamente en nuestro navegador. Como lado negativo se encuentra en que WebGL se basa evidentemente en JavaScript, y la sobrecarga de este lenguajes es muy alta. No podremos por tanto comparar jamás una aplicación/juego programada en C++ y OpenGL que programada en JavaScript y WebGL. Esta tecnología jamás será un sustituto ojo, WebGL no llega para desbancar nada, sino para añadir algo que antes era imposible.

    Gracias a WebGL vimos el increíble trabajo por parte de Google y Zigote con “Body Browser”, que es una aplicación totalmente práctica, útil y funcional. Realizar algo así sin WebGL sería imposible a día de hoy, se debería de instalar algún complemento en el navegador. Aun así, se ha demostrado que WebGL aun está muy lejos de alcanzar el rendimiento que se obtiene con una aplicación nativa en OpenGL.

    Soy defensor de OpenGL, sobre todo por su facilidad a la hora de programar con él, pero la API DirectX es sencillamente mejor y más rápida. Incluso con ANGLE (implementación de OpenGL sobre DirectX) que tiene que hacer de “traductor”, el rendimiento a través de este es superior. En Firefox existe la posibilidad no obstante de usar el soporte nativo OpenGL, pero cuando se opta por este modo, el rendimiento es algo inferior.

    Aun así, no se usa ANGLE por su rendimiento, ya que al final cuando se optimizase WebGL y el soporte nativo es de esperar que el rendimiento de este fuese superior. Se usa ANGLE porque el soporte para OpenGL varía mucho entre diferentes fabricantes. Así por ejemplo, nVidia ofrece el mejor soporte para OpenGL disponible, siendo compatible desde su serie GX 400 con OpenGL 4.3.0. Pero este escenario es totalmente desastroso cuando miramos adaptadores de vídeo Intel, que poseen un soporte para OpenGL mucho más pobre. ANGLE es una solución muy eficaz ya que asegura que sea cual sea el fabricante o el adaptador de vídeo que se tenga instalado, mientras que este sea compatible con DirectX 9.0c podrá ejecutar a la perfección contenido WebGL, y en muchos casos como vemos con un rendimiento superior. Por suerte, Intel está empezando a aplicarse el cuento y entregando controladores decentes para OpenGL en la actualidad, ahora mismo creo que ya soporta en Windows 8 hasta OpenGL 3.0. Recordar que estamos hablando en todo momento de Windows, en Linux o MAC OS no es posible bajo ningún pretexto el uso de la API DirectX, y OpenGL forma parte intrínseca de él. En el caso de Linux es posible usar OpenGL 4.3.0 (la especificación más alta actualmente) siempre y cuando el adaptador de vídeo lo permita, en el caso de MAC OS, este tan solo soporta OpenGL 3.0 y con muchas carencias.

    El test que más nos llama la atención es inmediatamente el tanque de 50.000 peces. Recordemos que realizamos el mismo test bajo HTML5 con 3000 peces, obteniendo Opera en el mejor de los casos cerca de 50 fps. En este caso tenemos el mismo tanque pero usando WebGL, y vemos que es necesario elevar a 50.000 peces para que Firefox no alcance los 60fps. Cualquiera podría decir que si disponemos de WebGL que sentido tiene el test anterior en el que el navegador no podía con 3000. Y volvemos a lo mismo, las peras se parecen a las manzanas en que las dos son frutas, pero nada más. Es más que evidente que si cualquier test html5 se puede pasar a WebGL (con lo que debe de tener un fuerte componente gráfico evidentemente) su rendimiento será infinitamente superior.

 

  • Estándares

    Actualmente parece que existen dos grandes frentes abiertos a la prensa. Si uno es el rendimiento en los test sintéticos, el otro es el proclamar que su navegador es compatible con HTML5, o mejor dicho, pelearse por cual es más compatible en este campo. HTML5 es muy importante en el futuro, pero de nuevo no es el único estándar emergente estos días. Es más, actualmente es infinitamente más usado CSS 3.0 como estándar emergente que HTML5. Tan importante es lo uno como lo otro.

    De nuevo y como era de esperar, todos los navegadores han mejorado su compatibilidad con los estándares existentes, sobre todo en HTML5 como podemos ver en el test de Niels (no podemos compararlo con la comparativa anterior dado que el test de Niels está en constante cambio). Aun así, y pese que Microsoft asegura que en sus test Internet Explorer 10 es el más compatible de cara a HTML5, es Chrome quien posee cierto liderazgo aquí. El problema de Chrome es que aunque es cierto que es más compatible a efectos generales en HTML5 que el resto de los navegadores, no a efectos concretos. Es decir, Chrome implementa la mayoría de funciones de HTML, pero de una forma básica, y lo mismo le pasa con CSS y otras tecnologías. Opera en contrapartida se centra en menos variedad pero de una forma mucho más profunda, intentando cumplir a rajatabla todas las especificaciones de cada sección. Esto hace que en test generalistas como el de Niels Chrome obtenga muy buenos resultados y en otros más específicos como la suite de IE obtenga resultados algo inferiores.

    Sobre la Suite de Microsoft poco podemos añadir, evidentemente es una suite totalmente engañosa para mostrar que Internet Explorer es el navegador más compatible, y en cambio en el test de niels el resultado es deprimente. No obstante Microsoft sigue avanzando a pasos agigantados en cuanto a compatibilidad se refiere, su eterna lacra desde luego… aun a día de hoy muchos webmaster necesitamos crear código redundante y hacer “trampas” para que las web se visualicen correctamente en Internet Explorer, precisamente por no ceñirse a los estándares.

    Sobre WebGL, tanto Firefox como Chrome continúan aumentando su compatibilidad. Opera se ha subido al carro y no ha empezado con mal pie desde luego, aunque en las últimas versiones no es demasiado estable.

    Microsoft optó al final por desgracia de no implementar por ahora WebGL, parece más o menos claro que antes o después lo implementará. Microsoft ya dijo hace tiempo que su postura era dudosa dado a los posibles problemas de seguridad que podrían derivar de WebGL, en cambio como ya explicamos esto es relativo y existen sistemas para evitar estos problemas de seguridad.

 

  • Compilaciones x64

    Internet Explorer 10 ejecuta su interfaz siempre en 64 bits, siendo su chrome en 32bits o 64 bits dependiendo de si se ha habilitado el modo de seguridad avanzada, pero aun cuando habilitamos el modo nativo 64bits vemos que por fin MS se decidió a añadir sus mejoras de rendimiento a la versión de 64bits.

    Firefox continúa ofreciendo versiones diarias de 64 bits con un rendimiento muy similar a las versionese de 32 bits, manteniendo la estabilidad. Por desgracia recientemente se ha anunciado que durante un tiempo deshabilitarán las versiones de 64 bits problemas a la hora de detectar los fallos de su navegador, pero han asegurado que estarán disponibles para el año próximo.

    Opera continúa con sus versiones de 64 bits, y son bastante decentes.

    Sobre Chrome y Safari por otro lado no hay indicio alguno de que una versión de 64 bits pueda ver la luz a corto plazo… habrá que esperar. Es de suponer que eventualmente Chrome sacará una, pero…

 

  • Consumo energético

    ¿Como puede influir un navegador en el consumo energético de un dispositivo? Pues es fácil, dependiendo en gran medida de los recursos que tenga que hacer uso de él. Para ello tan solo tenemos q observar la carga en la CPU/GPU del sistema para hacernos una idea.

    Cuanto menor sea la carga en ambos menor es el consumo, es evidente, pero no está tan claro cuando tenemos que pensar si es la GPU o la CPU quien prima sobre el consumo. Es decir, es mejor tener un consumo de un 10% CPU y 2% GPU o un 2 CPU y 7% GPU. Sería muy complicado llegar a una decisión unánime sin acudir a un tester de potencia y medirlo directamente, pero si más o menos imaginarlo.

    Mirando las gráficas, parece claro que el navegador más eficiente energéticamente hablando dependería del contenido. En un escenario normal, el mejor resultado sería para Internet Explorer o Firefox, en cambio cuando se entrase en test más complejos el ganador sería Safari (por la sencilla razón de que no usaría la GPU y que no sería capaz de ejecutar correctamente el test). Opera en cambio obtendría el peor consumo de forma general por un exceso en el uso de la GPU, y Chrome tampoco quedaría en muy buen lugar, con cargas de CPU/GPU considerables.

    Quizás en un equipo de sobremesa el consumo energético es lo de menos, pero como siempre pensemos en portátiles.

Volver a arriba

Sobre Mí

Alma Oscura por Theliel is licensed under a Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0 Unported License.
Política de Privacidad.
Para otros permisos que puedan exceder el ámbito de esta licencia, contactar en blog.theliel.es/about/contactar.