La fiabilidad de las encuestas, votaciones… realizadas en la red, y lo fácil que puede resultar manipularlas

 

 

Inicio Fin (10 minutos después)
Opción 1º: 43.6%  20.7%
Opción 2º: 10.1%  4.8%
Opción 3º: 17.4%  8.2%
Opción 4º: 17.5%  8.3%
Opción 5º: 11.4%  58.1%
Número de Votos: 2506  5462

 

Raro es el día que nada más abrir Thunderbird no recibo en las suscripciones RSS algún resultado nuevo de alguna encuesta, votación o gráfica basada en las supuestas respuestas de los cientos y miles de usuarios que supuestamente votan en ellas para dejar su opinión: Cuestiones políticas, preferencias de consumo, concursos, sondeos… raro es el periódico o site más o menos conocido que no tiene una encuesta o recoge datos semanalmente, para luego exhibirlos igualmente en los periódicos, o en publicaciones de toda índole.

La pregunta que uno debería de hacerse es simple: ¿Como de fiables son estos datos? Y la respuesta es aun más simple: No lo son, y eso es lo gracioso. Esto no quiere decir que cualquier gráfica, resultado de encuentras o votaciones sea mentira o los datos no seas ciertos, significa que a día de hoy tomar por cierto esos datos simplemente porque cualquiera los exponga sería poco inteligente.

En este caso me he cebado/centrado en particular con un servicio de encuestas llamado tusencuestas.com que usan no pocas webs, que usan simplemente para plasmar unos resultados, confeccionar estadísticas y otros. Al igual que este sistema, existen muchos similares, algunos más seguros, otros menos. Esto no quiere decir que TODOS los sistemas sean susceptibles de manipular, aunque tampoco quiere decir lo contrario. Primero un poco de literatura y después veamos el caso práctico… quien quiera saltarse el bla bla bla puede irse más abajo directamente y ver lo que sucedió con tusencuestas.com

 

Lo peor de todo, además, es que detrás de esos datos muchas veces se puede encontrar no solo una duda sobre su fiabilidad, sino que son múltiples las cuestiones que nos pueden llegar a pensar que eso datos dictan mucho de ser ciertos. Hay que tener cuidado cuando se habla de manipulación de datos, dado que muchas veces no son manipulados directamente, pero hay muchas formas de manipular la información. Veamos algunos ejemplos:

 -”Lugar” en que se recogen los datos: Esto es simple, si por ejemplo aparece una encuesta o una gráfica aparece en un diario con fuertes tendencias políticas, los datos recogidos serán en su inmensa mayoría provenientes de lectores con la misma ideología política, y por tanto los resultados serían evidentes. Si la misma encuesta o los mismos datos fuesen recogidos en otro diario con fuerte tendencia política contraria, los resultados serían totalmente opuestos. Este sistema se usa de forma extensiva todos los días.  Personalmente, creo que cualquier encuesta o recogida de datos realizada por cualquier medio partidista o a fin a cualquier tipo ideología (religiosa, política, clase social…) carece totalmente de valor por lo mismo. Extrapolado a la tecnología sucede exactamente lo mismo, si entras en un foro a fin a Microsoft y pusieses una encuesta sobre lo bueno o malo que es Windows saldría que es bueno por una amplia mayoría, si lo haces en un site fin a Apple dirá que MAC OS.

-Confianza en el autor de dichos datos: Más simple aun, damos por echo que dicha recogida de datos tiene detrás a una persona de la cual hay que fiarse, que no haya modificado los datos ni vaya a hacerlo. Por supuesto no digo que lo haga, digo que podría hacerlo.

-Manipulación por parte de los propios usuarios: Incluso cuando se pongan las mejores intenciones en la fiabilidad de dichos datos, si no se usa un sistema decente para la recogida de dichos datos estos de nuevo no pueden tener ningún tipo de validez, y esto es culpa tanto de los propios usuarios como quien está detrás de todo ello.

 

Aquí no podemos señalar con el dedo o asegurar sin pruebas quienes inventan resultados o los manipulan, pero sí podemos ver lo simple que puede resultar para un usuario la modificación de estos, y si cualquier usuario muchas veces puede hacerlo, prueba irrefutable de la validez cero de este tipo de sistemas, sobretodo repito cuando no se es nada riguroso.

El principal problema, quitando por supuesto la honradez del equipo/persona que esté detrás de esa recogida de datos, son los sistemas usados para tales recogidas de datos. Muchas veces los propios equipos/personas encargadas en esa recogida de datos usan métodos consabidamente “manipulables” a fin de que los resultados sean aun más impactantes cuando son mostrados. Y es gracioso, puesto que lo único que debe de hacer un buen sistema de recogida de datos de este tipo es: Un solo submit/voto/estadística/comentario… por persona física. Y señores, uno es uno, no son dos ni tres, es uno ¿Es que acaso en las elecciones generales nos permiten votar más de una vez?

El mundo de la informática está sujeto de la picaresca humana, y seamos franco, en España tenemos mucha de esa. Y es que he llegado a encontrar encuestas incluso en periódicos (en sus ediciones digitales evidentemente) de primera línea en las que con tan solo seleccionar la opción indicada y darle a enviar se contabilizaba automáticamente un voto, sin importar cuantas veces lo hicieses. Es decir, un solo usuario podría en 3 minutos realizar cuantas… 100 votaciones? 300? Y eso sucede (al menos ha sucedido) como digo en medios principales de nuestro país, que días más tarde salen en portadas, noticiarios, radio… jactándose unos y otros de los resultados tan dispares que aparecen.

Existen muy variados sistemas para impedir este comportamiento por parte del usuario (impedir hacer trampas):

-Uso del DNI-e: Sería un sistema viable, seguro y riguroso, casi totalmente imposible de manipular. El problema es que el usuario tendría que molestarse más de lo debido para enviar la información (tener el DNI-e, un lector…)

-Introducción del DNI: Podríamos sortearlo introduciendo un DNI falso, en el mejor de los casos el site verifica el número frente a la letra, y para ello tan solo tendríamos que introducir cualquier número de 8 cifras y calcular la letra de este. Este sistema no sirve.

-El uso de Cookies: La mayoría sabemos que es una Cookie en el navegador, una práctica muy habitual es marcar el equipo del usuario con una cookie que registra la introducción de los datos e impide volver a repetirlo… el problema es que una cookie se puede borrar en lo que se tarda contar 3 misisipis. Este sistema es inútil.

-El registro de la IP: Muchos otros usan la premisa que si tenemos asignada una IP por nuestro ISP, si se registra esta IP se lograría un solo “voto por persona”. El problema es que detrás de un dispositivo NAT (un router por ejemplo) puede existir desde una familia ha una empresa con muchos empleados, y este sistema estaría denegando el acceso a dichos usuarios desde ese lugar, sin contar por supuesto que sería posible saltarse el sistema poxeando o tuneleando la conexión sin mayores problemas. Incluso es relativamente simple el uso de programas o scripts para automatizar el proceso para ir saltando de proxy en proxy constantemente. Este sistema es inútil.

-El registro del User-Agent: Todos los navegadores tienen por así decirlo un identificador propio y único en teoría que los identifica. Muchos sitios usan la combinación entre User-Agent+IP+Coockie para de este modo permitir tan solo “un voto por persona”, permitiendo solo desde la misma IP múltiples accesos siempre que fuesen con diferentes User-Agent, de este modo en teoría se estaría permitiendo a otro usuario diferente detrás de la misma IP pública poder realizar su aportación. El problema es que si cambiar la IP momentaneamente es fácil, modificar el User Agent es aun más simple. En Firefox es tan simple como cambiar la opción: “general.useragent.override”, o por supuesto por medio de scripts y wget en linux.Evidentemente este sistema es inútil.

 

Dado que el único sistema viable y seguro es molestar al usuario, esto no es viable, por tanto es lógico usar un sistema alternativo, que aunque sea posible de saltarse al menos sea lo suficientemente “lento” o farragoso para un usuario mal intencionado de sortear. Y ante esto hay dos aproximaciones que he visto de forma extensa: Los que usan JavaScript para realizar las comprobaciones pertinentes y lanzar o no así las peticiones, y los que usan PHP para lo mismo. JavaScript es un lenguaje que se ejecuta en los equipos de los usuarios, PHP se ejecuta en los servidores… por tanto cualquier programador que use JavaScript para este tipo de cuestiones, y sin ánimo de ofender a nadie, es idiota. Si se ejecuta en el equipo del cliente, el cliente puede modificar el código como quiera, y por tanto puede evitar prácticamente cualquier medida preventiva que hubiese añadido, por no decir que tendría acceso al código JavaScript y ver por donde pillarlo. Con PHP por otro lado no es posible saber que se está realizando en el otro lado, ese código no nos llega, tan solo podemos saber que datos enviamos nosotros, pero no como se tratarán esos datos.

En este caso concreto de tusencuestas.com, ni que decir queda que usan JavaScript para sus sistemas, algo realmente absurdo por lo simple que resultará como veremos modificar cualquier votación/encuesta que usa su plataforma en unos pocos minutos.

Tomemos de ejemplo una web cualquiera que use este servicio, en este caso concreto he tomado la web de un programa televisivo bastante conocido en España, y que por deferencia a ellos me abstengo de decir. En este portal aparecen encuestan semanales cuyos resultados son al final presentados en el propio programa de televisión. La votación semanal en esta ocasión cuenta con 5 opciones posible, que por motivos obvios no pongo que se vota ni cuales son las opciones… de lo contrario cualquiera podría saber a que estábamos refiriendo. Actualmente la distribución es la siguiente:

1º Opción: 43.6%
2º Opción: 10.1%
3º Opción: 17.4%
4º Opción: 17.5%
5º Opción: 11.4%

Con un total de 2506 votos.

El problema reside como he dicho en que este proveedor de encuestas/votaciones, tusencuestas.com, usa JavaScript para registrar las votaciones, y para peor males tan solo prohíbe la votación por una simple verificación de Cookie. Aun así, como veremos más adelante, el echo de usar una cookie o no para verificar si el usuario ya votó o no es totalmente irrelevante. 

Lo primero es echar un vistazo al código HTML del formulario de envío de la votación:.

<div id=”tusencuestas_identificador”><div width=”100%”><div width=”100%”>Nombre de la Encuesta</div><div width=”100%”>
<input type=”radio” value=”287603″ name=”tusencuestas_respuesta_resultados_name”> Opcion 1º<br>
<input type=”radio” value=”287604″ name=”tusencuestas_respuesta_resultados_name”> Opcion 2º<br>
<input type=”radio” value=”287605″ name=”tusencuestas_respuesta_resultados_name”> Opcion 3º<br>
<input type=”radio” value=”287606″ name=”tusencuestas_respuesta_resultados_name”> Opcion 4º<br>
<input type=”radio” value=”287607″ name=”tusencuestas_respuesta_resultados_name”> Opcion 5º<br>
</div><div width=”100%”><span align=”center”>
<input type=”button” onclick=”tusencuestas_votar();” value=”Votar”></span><br>
</div></div></div>

 Por comodidad he eliminado algunos hash que continuaban a cada propiedad name. El caso es que se trata de un formulario muy simple, 5 opciones posibles a las que se asigna dependiendo de cual esté seleccionada un valor diferente. Cando el usuario quiere enviar su voto tan solo tiene que presionar el botón “Votar” que aparece en la encuesta, en cuyo caso el formulario invoca la función “tusencuestas_votar()”.

Del mismo modo, podemos echar un ojo al código JS de la web dicha función:

function tusencuestas_votar()

{
if (cookieHabilitada())
{
var accion_argumento = tusencuestas_recogeValor();
tusencuestas_accion(2, accion_argumento);
if (accion_argumento != “-1″)
{
var expira = new Date();
expira.setSeconds(expira.getSeconds() + 604800);
setCookie(“P_Id” + P_Id_hash, “1″, expira, “/”);
}
else
alert(‘��Escoge  una opcion!!’);
}
else
alert(‘No puedes votar porque no tienes las cookies habilitadas’);
}
 En realidad antes de pasar a esta función, si nuestro navegador envía una Cookie anteriormente seteada, el sistema no nos permitirá realizar la votación, y en vez de eso nos mostrará el resultado que pusimos anteriormente. La función mostrada tan solo tendremos acceso a ella si nuestro navegador no posee aun la cookie en cuestión. La función es bien simple. Si tenemos las cookies habilitadas, recoge el valor de nuestra opción marcada y lo almacena en la variable accion_argumento, y después invoca otra función que supuestamente será la que registre la votación. El resto de la función simplemente setea la cookie para que el sistema detecte al visitante que ya ha votado o muestre uan advertencia si tenemos las cookies deshabilitadas.
 
En otras circunstancias más complejas tendríamos que continuar con un seguimiento de las funciones que se van llamando, así como verificar efectivamente que la funcion recogeValor efectivamente captura el valor de la opción marcada (mostrado anteriormente en el código HTML). Pero lo cierto es que los amigos de tusencuestas.com lo han dejado francamente sencillo. Simplemente usando la consola del navegador (Ctr+Shift+k en Firefox) podemos introducir insitu el código JS que deseemos inyectar en la web que queramos, a fin de cuenta como hemos dicho el código JS es ejecutado en nuestro equipo. Así pues, podemos de forma directa introducir la función que suponemos es relevante para el caso:
 
tusencuestas_accion(2, 287607);
 
El valor 287607 no es arbitrario evidentemente, corresponde a la opción 5º del código HTML anteriormente tomado. Es decir, si todo es correcto simplemente invocando esa función en dicha web, se estaría enviado un voto a la 5º opción, sin preocuparse nadie ni nada de cookies o historias. siempre quedaría la opción de que el servidor denegar multiples conexiones desde la misma IP, pero este no es el caso.
 
Interesantemente, el servidor al introducir esa función por consola nos responde con:
 
GET http://www.tusencuestas.com/acciones/tusencuestas.aspx?44905… [HTTP/1.1 200 OK 1231ms]
Está acortado por comodidad, es a fin de cuenta una URL compuesta entre otras cosas con el ID de la encuesta (que he suprimido desde el comienzo, el valor de la opción y algunos datos más.
 
Llegados a este punto, cada vez que introducimos la función por la consola y le damos a enter, automáticamente si lo comprobamos el sistema registra un voto!! Simplemente presionando cursor arriba y enter introducimos en el sistema un nuevo voto… 10, 100, 1000… pero seamos sinceros, eso un poco farragoso y un trabajo manual de narices si deseamos por ejemplo darle la vuelta a la encuesta, o suponer en una encuesta que hayan miles o decenas de miles de votos… nos llevaría un ratito. Por suerte el voto se registra simplemente con una petición GET al servidor, como vemos en la propia consola. De echo si copiamos la URL y la pegamos directamente en la barra de dirección se registra también el voto. Por tanto, nada más sencillo que automatizar el proceso:
#!/bin/sh
X=0
while [ $X=0 ]
do
wget -O- –timeout=1 “http://www.tusencuestas.com/acciones/tusencuestas.aspx?44905…”
done
exit 0
Un simple script que realiza de forma indefinida peticiones HTTP que registrarán el voto por medio de wget, especificando que no se desea un arcivo de salida y un timeout de 1 segundo (ahora mismo lo necesito por cuestiones de retrasos de la línea en la que estoy). Y con eso el negocio quedaría terminado.
 
Para ver si funciona tan solo hay que invocar el script y ver que pasa al cabo de un ratito, pongamos 10 minutos:
 
 1º Opción: 20.7%
2º Opción: 4.8%
3º Opción: 8.2%
4º Opción: 8.3%
5º Opción: 58.1%

Con un total de 5462 votos.

 
En realidad, poca importancia tendría que tener esto, a fin de cuenta que importancia puede tener si en un periódico hacen una encuesta sobre cual es político mejor valorado o el peor… No porque la encuesta o la votación en sí carezca de sentido, sino que se usan la mayoría de las veces con fines demagogos. La importancia radica de nuevo, como en la mayoría de las veces, en lo que el usuario cree o quiere creer, dejándose casi siempre influenciar por lo que leen/escriben otros, sin pensar generalmente un poco por ellos mismos. ¿Cuantas gráficas vemos con datos tan contradictorios a lo largo de la semana? Si accedes a cierto tipo de sitios las estadísticas son unas, si entras en otros las estadísticas son diferentes… a veces explican con pelos y señales las condiciones en las que los datos fueron recogidos, otras veces son tan absurdas que comparan manzanas con platanos tan solo para que los defensores salten a la red en cualquier lugar: Blog, foros… defendiendo a ultranza a veces con total fanatismo ideas de otros con datos tergiversados y muchas veces manipulados.
 
Ahí queda eso señores. Solo espero que aquel que lea estas letras, la próxima vez que vea una encuesta, votación, gráfica… se pregunte aunque solo sea por un segundo de donde salieron esos datos, que sistemas usaron y que intereses o no puede existir detrás.
 
Un saludo.

Entradas relacionadas:

  1. Seguridad: Encriptación y Autentificación. Capítulo Segundo -> Cifrado de Datos
  2. Seguridad: Encriptación y Autentificación. Capítulo Quinto -> Ataques y Vulnerabilidades contra la Criptografía
  3. Seguridad: Sniffing. Capítulo Cuarto -> Analizadores/Capturadores de Paquetes
  4. Comparativa Navegadores 2011: IE9, Firefox 4, Chrome 10, Safari 5, Opera 11
  5. Comparativa Navegadores 2012/Q1: Internet Explorer 10, Firefox 14.0, Chrome 19.0, Safari 5.2, Opera 12

Comparativa Navegadores 2012/Q1: Internet Explorer 10, Firefox 14.0, Chrome 19.0, Safari 5.2, Opera 12

Índice

  • Navegadores
  • Condiciones de las pruebas
  • Benchmarks (Nuevo: Inicio en caliente, Tiempo de cierre, Consumo, Caché…)
  • Conclusiones

 

Versiones de los navegadores

 

Navegadores:

 

Continuando con la tónica de las otras dos comparativas, y teniendo en cuenta que durante estos 6 meses ningún fabricante ha modificado de forma sustancial sus ciclos de actualizaciones, hoy volvemos de nuevo a la mesa de pruebas para enfrentar de nuevo a los navegadores que aun están por llegar. En alguna ocasión me han preguntado el motivo por el cual suelo hacer comparativas de navegadores que aun se encuentran en fase de desarrollo en vez de hacer comparaciones de las versiones oficiales. Esto lo he explicado en alguna otra ocasión, y son varias las razones:

a) Debido a los ciclos rápidos de Chrome y de Firefox, estos siempre tendrían grandes ventajas sobre Opera, IE o Safari, ya que estos últimos tan solo lanzan versiones oficiales cada bastante más tiempo. Comparar las últimas builds de cada navegador nos permite ser más imparciales (exceptuando Internet Explorer, ya que Microsoft no da acceso a las nightly Builds.

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.

Tanto para Firefox como para Safari se han tomado sus respectivas versiones nightly, ambos publican versiones nightly diadiamente. Para Chrome se ha tomado Chrome Canary, que aunque no se actualizan todos todos los días, sí prácticamente todos. Opera no publica versiones nightly tampoco, pero su versión de Opera en desarrollo es actualizado cada muy pocos días.

Internet Explorer no obstante es el único que se queda un poco atrás, ya que no podemos obtener versiones diarias ni muy actualizadas del desarrollo de Internet Explorer 10, y nos tenemos que conformar con la última versión de IE 10 que Microsoft sacó para Windows 7. Hay que tener en cuenta que esta versión de IE 10 no es un navegador completo, y por tanto los resultados obtenidos por él son cuanto menos discutibles. Esto hace además que no sea  posible realizar algunos test sobre él, por lo que se ha usado junto a él Internet Explorer 9. Cuando IE 10 no pueda ser usado en las pruebas, será usado IE9 y así quedará indicado.

Como en otras ocasiones, las versiones de 64 bits NO CONTARÁN en el tanteo final en modo alguno, y tan solo tendrán un valor presencial para comparar, puesto que ni todos los navegadores poseen versiones de 64 bits, ni ningún navegador posee una versión de 64 bits que real0mente funcione bien. No obstante, tenemos que añadir en esta ocasión Opera a los navegadores de 64 bits, siendo tan solo Safari y chrome los que por ahora no han abrazado esta arquitectura.

 Por cuarta vez, , la versión de Safari instalada está exenta de QuickTime como ya se ha explicado otras veces. En esta ocasión Apple no obliga instalarlo (un buen paso por su parte). Las razones son las de siempre, QT actúa de plugin para Safari para dotarlo de mayores prestaciones, y la idea es probar los navegadores no sus complementos. Sería igualmente injusto si no, instalar extensiones a otros navegadores para obtener mejores resultados.

Fue necesario deshabilitar DEP (en Windows) para los 3 procesos implicados en Safari, de lo contrario el navegador era bloqueado por este por motivos de seguridad.

 

Condiciones de las Pruebas

 

Sistema:

  • OS: Windows 7 Ultimate x64 SP1
  • CPU: Intel Core i7 920
  • RAM: 12GB DDR3 Triple canal
  • Video: nVidia GTX460 (Driver 296.10)
  • Resolución: 1920 x 1080 (navegador siempre maximizado)
  • Flash Player: 11,2,300,130 y 11,2,202,197

 

 Todos los navegadores son instalados de forma limpia en el mismo equipo, usando perfiles nuevos para todos ellos. El único complemento de partida que se instaló en todos los navegadores fue Adobe Flash Player, y en uno de los test para Firefox se instaló Firebug (para medir con precisión tiempos de carga, el resto usaron sus herramientas nativas).

Cada prueba en esta ocasión se ha ejecutado 5 veces en cada navegador, despreciando de ellos el mejor y el peor ciclo y haciendo media de los otros 3 resultantes. Esto se ha convertido en algo esencial debido a que muchos de los test son muy sensibles a cualquier cambio del equipo, desde un lectura en el disco duro o a algún proceso en segundo plano que pudiese interferir. Suprimiendo la mejor y la peor vuelta, se intenta evitar en lo posible estas deficiencias, sobre todo como digo en los test más sensibles.

Cada prueba puntuará de 1 a 5 (1 el peor resultado, 5 el mejor), reservando el cero para aquellas pruebas en las que el navegador no pueda realizarlas por deficiencias 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. Como última prueba se hará simplemente una pequeña tabla a modo de “prueba de estabilidad” con los problemas experimentados con los navegadores a lo largo de las pruebas, y se puntuará cada navegador en función a esa estabilidad.

 

 Benchmarks

He reestructurado un poco mejor todos los test, se han modificado, añadido y eliminado otros. Hay que tener en cuenta que incluso muchos de los test que repiten, no pueden compararse con otras comparativas ni siquiera para ver las mejoras de una versión a otra, dado que los propios test sufren modificaciones por sus creadores, las web que se cargan cambian… etc etc etc.

Para ampliar cualquier imagen hacer clic en cualquiera de ellas.

Las Webs usadas para el consumo de RAM , así como los tiempos de inicio en frío/caliente y cierre son: Bandeja de Gmail, Bandeja de Mail Live (Hotmail), Muro de Facebook, YouTube (“http://www.youtube.com/watch?v=nAHyGbOXoF4″ en 360p), “MARCA”, portada de “El País”, la NASA, DevianArt, Play Store, Wikipedia (https://en.wikipedia.org/wiki/History_of_the_web_browser). 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) – Mejorado
    • Tiempo de Inicio en caliente (1, 10 y 20 pestañas – Nuevo
    • Tiempo de Cierre (20 pestañas) – Nuevo
    • Velocidad de carga de Webs con/sin Caché – Nuevo
    • RAM (10 y 20 páginas)
    • CPU/GPU reproduciendo contenido 1080p (Flash y WebM) – Mejorado

 

 

 

 

 

 

 

 

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. 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, el equipo es reiniciado por completo, se esperan 3 minutos para que se estabilice el sistema entero y se abre el navegador pertinente, restaurando la sesión de forma automática (de 1, 10 o 20 pestañas). Inicio en caliente implica 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):

  Inicio en Frío Inicio en Caliente

  • Opera: Falló en la carga de algunas pestañas, siendo necesario refrescarlas posteriormente (no se contabilizó ese tiempo extra)
  • Safari: Muy inestable, constantes cierres del espacio de trabajo del navegador (proceso webkit2webprocess.exe).
  • Safari: Picos constantes de la CPU de hasta 30%

 

Tiempo de Cierre

En esta ocasión se ha medido también 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 incluso, lo cual evidentemente no es deseable. 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. Esto es importante sobre todo en Chrome o Internet Explorer, que al ser navegadores multiprocesos tienen unas dependencias mucho mayores al resto:

Tiempo de Cierre

 

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 la caché del navegador activada y deshabilitada. 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 fue abierta de forma aislada y se sumaron los tiempos de todas ellas:

Velocidad de descarga

  • Internet Explorer 10: Los resultados que aparecen con caché pertenecen a IE9, la Preview 2 de IE 10 parece tener la caché deshabilitada

 

Consumo de RAM

Aunque a día de hoy la gran mayoría de los sistemas actuales cuentan con cantidades más que suficientes de RAM, continúa siendo un recuro que siempre hay que vigilar y que optimizar al máximo. Además, hay que entender que cada dato que es cargado en la RAM o procede del mismo proceso que lo genera o ha sido cargado desde el disco duro anteriormente, y teniendo en cuenta que el disco duro continúa siendo a día de hoy el elemento más lento del equipo, es algo a tener en cuenta. 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:

Consumo de RAM

  • Safari: Como ya se ha dicho, el proceso “webkit2webprocess.exe” produce una carga de la CPU de un 30% aproximadamente
  • Opera: No logró “estabilizar” (dentro de lo normal) la RAM ocupada, provocando un crecimiento lineal en el consumo de esta mientras transcurría el tiempo. Sin duda alguna un leak de memoria ocasionado por alguna de las pestañas abiertas.

 

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). La reproducción de Vídeo continúa a día de hoy siendo uno de los mayores “comecome” de baterías. De nuevo, en esta ocasión 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 haremos lo mismo a través de WebM gracias a HTML5, así podremos comparar a grandes rasgos la eficiencia de un sistema o de otro. En la comparativa de hace seis meses los únicos navegadores con soporte WebM eran Chrome y Firefox, en cambio a día de hoy tanto Opera como Internet Explorer (por medio de un complemento) soportan también WebM, con lo que sí me parece correcto comenzar a medir cada navegador frente a WebM, y como ya he dicho este ante Flash. El vídeo reproducido es el mismo que el de hace seis mese: “We Are The World – Haiti”

Reproducción de Vídeo

  • Internet Explorer: Permite la reproducción de WebM gracias a un complemento externo. Se pone por referencia, pero a efectos de conteo general se tratará como un “no soportado”
  • Un error por mi parte en el código de colores. Cada columna de cada navegador representa (en orden) lo que muestra la leyenda, aunque los colores para representar WebM sean los mismos que  para Flash

 

SunSpider, V8 y Kraken

Posiblemente los 3 benchmarks más utilizados para medir el rendimiento de los motores JavaScript de los navegadores. Como ya he dicho en muchas ocasiones no soy fan de test sintéticos, y mucho menos tests que han sido optimizados al máximo por todos los navegadores para obtener buenas puntuaciones. Quiero decir que TODOS los navegadores hacen algo así como “trampas” para aparentar ser veloces, cuando a lo mejor no lo son tantos. 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. Esto lo veremos más adelante cuando analicemos el rendimiento en Canvas, que a fin de cuenta son muy dependientes de JavaScript, y veremos como los resultados obtenidos aquí no siempre ejemplifican aplicaciones web con alta carga JavaScript:

Sunspider V8

Kraken

 

 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.

Normal Mapped es un test que aunque es claramente gráfico posee una carga gráfica 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 y gráfica:

Normal Map Canvas Performance Test

VII Asteroids

  • Opera:Graves problemas cuando VII superpone diferentes capas de texto, el framerate baja a la mitad de golpe

 

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

En esta entrega los peces vuelven al ataque, pero gracias a Opera ha sido necesario incrementar el número de Peces en ellos, ya que en ambos test Opera era capaz de llegar al tope de los 60 fps. Dos Test similares pero diferentes, orientados ambos al rendimiento gráfico de Canvas puro y duro. Los dos fueron diseñados para aprovecharse al máximo de la aceleración hardware de contenido, y es por ello que Chrome y Safari fracasan estrepitosamente. Anteriormente vimos como Opera no disponía de esta cualidad, que ahora ha implementando con sus pros (gran rendimiento) y contras (uso extensivo de la GPU y el consiguiente consumo energético), los cuales veremos en las conclusiones en detalle.

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

Tanque de 3000 peces Pecera de 2000 peces

  • Safari: No posee Aceleración por Hardware
  • Chrome: Google tiene implementada a medio gas la aceleración por Hardware, pero además de ser muy inestable aun, es necesario activarla por medio de about:flags actualmente, con lo que en esta ocasión queda fuera.

 

“Come-Cocos” (Browse Hunt)

Una vez más, este test creado por Microsoft logra poner los pelos de punta al resto de los navegadores, siendo 6 meses después imposible de acercarse a los 60 fps que logra Internet Explorer. Aun siendo un test fuertemente gráfico, tanto Firefox como Opera estan lejos de alcanzarlo:

Come-Cocos

 

“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:

SpeedReading

 

 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:

Psicodélico

 

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 sin duda:

Webviz Benchmark

 

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

Aunque en la entrega anterior WebGL no llegó a puntuar realmente, en esta ocasión dado que Opera da soporte de forma oficial también, es coherente añadirlo. Aun se quedan fuera tanto Internet Explorer como Safari. Microsoft no está claro que vaya a implementarlo por ahora, no obstante para Safari es posible activarlo de forma experimental y tan solo en MAC OS. Ambos obtendrán por tanto un “no soportado”.

Es interesante 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:

Tanque de 50000 peces (WebGL) Sistema Solar

 

Peacekeeper

Test sintético que mezcla varios elementos para medir el rendimiento de los navegadores. Personalmente me gustaba más la versión anterior pero ya no es posible hacerla andar. Mezcla parte JS, trabajo con cadenas, gráficos… y sobre todo objetos DOM. Como ya dijimos también, ha sido un test muy criticado por explotar con fines mediáticos la fortaleza y debilidades de los navegadores, un test muy parcial. Pero de nuevo, no deja de ser un buen indicador, muchas veces es necesario conocer los puntos fuertes y débiles de cada navegador para poder mejorarlos. Lo único que no queda claro del todo es si el echo de que el navegador pase o no pase más test puntúa más. Más que nada porque el test en un momento dado intenta reproducir vídeo en diferentes codec por medio de html5, y si no lo logra no lo puntúa correctamente. Recordemos que el codec usado para el tag <video> de html5 no es una especificación, que eso queda a discreción del navegador. El test de niels pra HTML5 es mucho más riguroso en este tipo de cuestiones, Peacekeeper no tendría incluir en sus test este apartado

Peacekeeper

 

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. Los navegadores pueden producir en cortos períodos de tiempo muchos objetos nuevos que se destruyen igualmente rápidos alguno de ellos, lo cual genera constantemente muchos trozos de RAM “basura” que es bueno ir liberando. La alternativa de no usar GC (Garbage Collection) no es viable. El problema de los recicladores es que dependiendo del sistema GC que estén usando pueden detener la ejecución del proceso hasta que el reciclado se ha terminado. Esto en un navegador se traduce por ejemplo con una extraña pausa 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.

Este test mide este comportamiento. Genera muchos objetos constantemente y mide las pausas que se registran. Este test es muy muy sensible a cualquier otro proceso que se esté ejecutando, 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.

Spnning Balls

  • Internet Explorer 9: No es compatible con el test
  • Firefox: El GC actual de Firefox no es todo lo estable que se podría esperar,  aunque cuando funciona correctamente es el mejor de los navegadores.

 

Test de compatibilidad HTML5 de Niels

A día de hoy pun 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 estandard HTML5. Repito, el test de Niels TAN SOLO mide especificaciones HTML5, no mide ningún otro estándar, y son muchos otros los que a día de hoy disponemos:

Niels HTML5

  • 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

WebGL
  • Internet Explorer y Safari: No son compatibles
  • Chrome: Varios test de la suite producían un comportamiento totalmente anómalo de este, obligando a reiniciar Chrome. El resultado mostrado es eliminando los test que impedían su funcionamiento
  • Firefox: Aunque pudo completar el test totalmente, uno de los test en particular (que también afectaba a Chrome) producía paralizaciones de todo el navegador en diferentes momentos. Al final no impidió en cambio terminar con todos los test sin producir un cierre forzado

 

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 son los mismos solo que yo los aplico a mis versiones de los navegadores, mientras que Microsoft la aplica a su navegador en desarrollo y las versiones oficiales de la competencia (lo cual es injusto evidentemente).

También 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. Es decir, 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 será compatible, con lo que cabe esperar que posiblemente Internet Explorer 10 cuando sea oficial 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 dar la talla, 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, es decir que Microsoft interpreta las especificaciones de un modo y la competencia de otro… comportamiento que se ha visto en muchas ocasiones verificado.

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 y otras tecnologías es hasta bonito:

IECenter Test

  • Mis test están actualizados con la última versión del IE Center de Microsoft, actualizada a 29/02/2012

 

 

Conclusiones

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

Resultados Firefox 14 x86 Chrome 19 IE 10/9 x86
Opera 12
Safari 5.1
Rendimiento 56 48 34 19 35
JavaScript 12 12 7 9 5
Canvas 14 17 16 6 7
Gráficos 25 14 24 22 7
WebGL 10 8 0 6 0
Otros 8 9 2 7 4
Compatibilidad 12 11 6 10 3
Estabilidad 5 5 3 2 1
           
Total 134 115 90 74 58

 

  • 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 los accesos a disco, innovar en nuevos sistemas de almacenaje de datos para su rápido acceso… y sinceramente esto es una tarea muy complicada.

    En cuanto a tiempos de inicio se refiere, sin duda alguna Chrome reina sobre la competencia siempre y cuando se estén abriendo al mismo tiempo múltiples pestañas. Este comportamiento evidencia la necesidad de que el navegadores sean poco a poco multiprocesados. Recordemos que aunque todos los navegadores a día de hoy sin multihilos, tan solo Internet Explorer y Chrome son multiprocesos. Esto les otorga entre otras cosas ser (al menos teóricamente hablando) más veloces y eficaces a la hora de manejar múltiples pestañas. El problema es que esto no es tan simple de realizar, sobre todo cuando el proyecto es de grandes proporciones. Eventualmente, Mozilla separará los procesos de las pestañas y llegará a ser una realidad el proyecto Electrolysis. Igualmente, antes o después Opera y Safari tomarán caminos similares.

    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 cargue 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.

    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. De esta forma, efectivamente tanto Chrome como Internet Explorer son los que poseen un tiempo sensiblemente superior en cuanto a tiempo de cierre, siendo sus consumos de RAM significamente superiores que si los comparamos con el consumo de RAM de Firefox. Safari por su lado mostró un comportamiento más intermedio y como sorpresa, Opera mostró un resultado terrible.

    En otro orden de cosas encontraríamos sorpresivamente que Firefox es el mejor navegador a la hora de descargar una web no cacheada, y el segundo cuando sí la tiene. Chrome le rozaría los pies de cualquier modo siendo las diferencias mínimas, e Internet Explorer mostró un comportamiento bastante decente.

    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 y el pasado. Para empezar Flash es mucho más que un simple reproductor de vídeos, y para terminar es evidente que a día de hoy es de lejos la mejor opción a la hora de reproducir cualquier contenido en HD. 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 sorprendentes. Evidentemente estas grandes diferencias son principalmente por la aceleración por Hardware con la que cuenta Flash y no WebM, pero es una cuestión de números. 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 8% la GPU (en el peor de los casos), WebM llegó a a necesitar en el mejor de los escenarios un 8% CPU/18% GPU, elevando la carga de la CPU en el caso de Opera hasta el 21% (y un 16% la GPU). Sea como sea a día de hoy la mejor opción para la reproducción de vídeos es Flash gracias al gran soporte que esta tecnología posee en cuanto a aceleración de hardware se refiere.

    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. Aun así, el rendimiento sería inferior al mostrado por Flash.

    No estoy diciendo que el futuro del vídeo sea Flash, el que los navegadores posean capacidad para reproducir vídeo y audio a través de ellos mismos es algo importantísimo y una herramienta muy potente. Pero todo requiere tiempo… a veces mucho tiempo. El proyecto WebM no será posible mientras que el soporte para este sea el que estamos viendo. Por otro lado, la imposición de h264 como codec  de vídeo junto a AAC como codec de audio tampoco parece ser una respuesta a corto plazo, aunque personalmente desearía que esta última opción fuese la que se impusiese con el tiempo y que la MPEG LA abriese el codec para su uso en la Web. Seamos sensatos, soy defensor de los formatos libres y abiertos, pero el codec de vídeo VP8 (el usado en WebM)  no es rival de h264, y además este último posee mucho mejor soporte Hardware. Veremos en el futuro como termina la cosa… mientras tanto podemos más que conformarnos y ser felices por el extraordinario rendimiento de Flash.

     

  • JavaScript

    Los test sintéticos JavaScript que ya conocen todos siguen siendo punto de referencia para muchos. Como ya dije 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 el liderazgo en SunSpider, y en cambio posee la peor puntuación en los otros dos benchmarks!! cuando además se supone que Kraken es un derivado de SunSpider. O al revés, mientras que Chrome obtiene una puntuación totalmente disparatada en su propio test V8 (el de Google), obtiene la penúltima posición en SunSpider.

    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.

    Respecto a la comparativa anterior, los resultados para SunSpider y Kraken son muy similares, pequeños cambios. En cuanto a V8 si hay cambios más significativos, pero hay que tener en cuenta que V8 fue actualizado a su versión 7, mientras que el test anterior era la V6.

 

  • Canvas

    He querido separar este apartado del de JavaScript, aunque en realidad están muy relacionados uno con otros. En la comparativa anterior se usaban dos juegos de ejemplo que en esta ocasión han sido sustituidos por otros dos test. 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. No obstante, cuando valoramos de forma general todos ellos (y siempre que no hagamos un uso relativamente extensivo gráfico), Chrome e Internet Explorer son los líderes, estando Firefox relegado a una tercera posición. Más sorprendente es el caso de Opera, que aun cuando exhibe un buen comportamiento JavaScript (y como veremos más adelante gráfico) obtuvo la peor calificación. Esto nos hace ver que un entorno real como una aplicación o un juego HTML5 no es un test sintético, y que un buen competidor como Opera que sobrepasaba tanto a Internet Explorer como a Safari en JavaScript y a Chrome y Safari en el apartado gráfico, fracasa estrepitosamente aquí. Safari por su parte logra a duras penas quedar por encima de Opera.

 

  • 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.

    En la comparativa anterior, el soporte de Chrome para aceleración de vídeo estaba habilitado por defecto, y ya antes era inestable. En esta ocasión vemos que estando deshabilitado (que es como está por defecto) Chrome cae a posiciones inferiores. Aun así, aun de estar habilitado habría obtenido la misma puntuación casi con toda seguridad, ya que en esta ocasión ha sido Opera quien por fin ha activado de forma oficial el soporte hardware de este. El otro gran avance que hay que citar es sin duda alguna los Drivers del sistema de nVidia y las actualizaciones de Microsoft de DirectWrite y Direct2D, los cuales han hecho que de forma generalizada se haya experimentado un incremento sustancial en el rendimiento.

    Ha sido muy interesante comprobar el rendimiento de Opera en esta comparativa gráficamente hablando. Dado el comportamiento que mostró tanto en el test del Tanque de 3000 peces como en la pecera con 1500 peces, fue necesario incrementar el número de peces de estos para que Opera no fuese capaz de llegar a los 60 fps. Aunque al final terminase en la tercera posición, en realidad en los test en los que estuvo por debajo de Firefox o Internet Explorer no fue por demasiado.

    Opera sin duda alguna ha hecho un gran trabajo con el soporte hardware de su navegador, pero su visión fue totalmente diferente a la de Internet Explorer o Firefox. Tanto Internet Explorer como Firefox usan la API DirectWrite y Direct2D para la aceleración hardware de contenido y de capas, mientras que Opera usa OpenGL para ambos. Como ya hemos dicho todo tiene sus pros y sus contras, y esto lo vemos muy bien reflejado además en los consumos de CPU/GPU de dichos test.

    El adaptador de vídeo no se comporta igual si está ejecutando código en DirectWrite que código en OpenGL. Evidentemente (y como veremos más adelante en WebGL) OpenGL está clasificado como una API completa de alto nivel, como pueda ser Direct3D, mientras que DirectWrite y Direct2D es una API 2D tan solo. orientada al bajo consumo y eficiencia. Esto tiene una repercusión directa en el adaptador de vídeo, y es que este junto a los Drivers otorgan siempre más recursos a contenido que supuestamente es 3D. Es decir, la API DirectWrite/Direct2D está diseñada precisamente para sobrecargar en lo menos posible al adaptador de vídeo, ya que se supone que el contenido que se va a visualizar o tratar es en 2D, y por tanto no requiere de unos recursos demasiado altos!! esta asunción es totalmente sensata y es lógica: “Si se requiere de unos recursos muy elevados será porque se estará manejando gráficos complejos en 3D, de lo contrario podemos trabajar a medio gas porque el contenido 2D es infinitamente menos exigente. Y si requerimos contenido 3D complejo para ello tenemos OpenGL/Direct3D”

    Todo ello se resume en que Opera, que usa OpenGL como Backend, obtenga resultados superiores en algunos test, a expensas siempre de un consumo bastante superior tanto de CPU como especialmente de GPU. Así en el test del tanque de 3000 peces la GPU eleva su uso al 61% en Opera, mientras que Firefox con la segunda mejor marca alcanza el 38%. Mucho más exagerado lo vemos en el test de la Pecera con 2000 peces!! Opera logra la friolera de 52 fps, a expensas de requerir un 20% de CPU y poner a trabajar el adaptador de vídeo al máximo, a un 97%!! Firefox de nuevo con la segunda mejor marca logra los 31 fps, pero usando “tan solo” un 41% de la GPU.

    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 con el soporte experimental hace algo similar que Opera (y todos esperamos ver dentro de 6 meses que ya se encuentra activado). Safari por contrapartida se desconoce si en algún momento incorporará soporte hardware en su navegador… cosa dudosa teniendo en cuenta la mala imagen que podría dar en la prensa que el navegador Safari tuviese un rendimiento superior en Windows que en MAC OS.

    Por último decir que la ventaja de que Opera use 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. 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

    Dado que Opera se ha sumado por fin al carro de WebGL y que Safari posee en MAC OS soporte experimental para ello, me parece sensato comenzar a puntuar también WebGL.

    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.

    No obstante aquí encontramos un escenario muy interesante si comparamos los datos obtenidos. Opera que obtenía unos resultados increíbles en algunos test anteriores, cuando se trata de usar WebGL no es capaz de alcanzar ni a Firefox ni a Chrome. Esto parece tener clara la explicación: Opera usa OpenGL como backend también en WebGL, pero tanto Firefox como Chrome usan ANGLE. ANGLE es un proyecto impulsado/creado/mantenido por Chrome que básicamente es una capa de software encima de DirectX 9.0c que traduce OpenGL 2.0. Dicho de otro modo, cuando Firefox o Chrome usan ANGLE todo el código ejecutado en OpenGL a través de WebGL es transformado a llamadas en Directx 9.0c.

    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 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.2.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 OpenGLen la actualidad, ahora mismo creo que ya soporta en Windows 7 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.2.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 2.0 y con algunas 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. En parte es la misma explicación por el cual Opera obtenía tan buenos resultados anteriormente. En este caso Firefox y Chrome no hacen uso de Direc2D o DirectDraw, sino de Direct3D (recordemos que usa ANGLE). Aun cuando usasen OpenGL puro y duro, el rendimiento sería muy superior. Pero es lógico, son APIs totalmente diferentes orientadas a funciones totalmente diferentes. Direct2D/DirectDraw no están pensadas para proporcionar un rendimiento de vértigo exprimiendo la GPU.

 

  • 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. Señores, 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 cumplri 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 muchso 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, aunque desde que Khronos publicase la nueva versión de sus test, ambos han tenido algunos problemas con algunos de ellos. Opera se ha subido al carro y no ha empezado con mal pie desde luego, es agradable ver como poco a poco los navegadores van sumándose a los estándares y apoyando lo que sin duda alguna podrá ser de muchísima utilidad en el futuro. Y es evidente, hasta que no hay en el mercado un buen soporte los programadores y diseñadores no pueden pillarse los dedos creando maravillas en la web que tan solo podrán ver dos o tres personas porque sus navegadores no son compatibles. Las cosas tienen que llegar poco a poco por las dos partes..

    Aun se desconoce de forma clara si Microsoft implementará WebGL, parece más o menos claro que antes o después lo implementará, pero cada día que pasa se duda más de que Internet Explorer 10 salga a la luz con soporte para ello. 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 hemos visto en Firefox o Chrome ambos fueron actualizados con las últimas especificaciones para evitar este tipo de problemas y hasta la fecha no se ha detectado ningún fallo de seguridad producido por ello. Sería bueno ver que al final Internet Explorer 10 viese la luz con WebGL, y de echo estoy totalmente seguro que los chicos de Microsoft disponen en sus laboratorio versiones de Internet Explorer 10 con soporte para WebGL. Apple por su parte mantiene la misma política, las últimas builds de WebKit poseen soporte, pero experimenta, deshabilitado por defecto y tan solo compatible con  MAC OS.

 

  • Compilaciones x64

    Sobre Internet Explorer 10 no podemos decir nada ya que aun no está disponible ninguna versión para Windows 7 nativa en 64 bits, aunque es evidente que cuando Internet Explorer 10 salga a la luz estará disponible tanto para Windows 7 como para Windows 8, tanto en 32 como en 64 bits. Esperemos que Microsoft por fin pueda habilitar sus mejoras en su motor JS en la versión de 64 bits, que como hemos visto siempre en Internet Explorer 9, está muy por atrás del resto.

    Firefox continúa ofreciendo versiones diarias de 64 bits con un rendimiento muy similar a las versionese de 32 bits, manteniendo la estabilidad. De echo si miramos todos los test realizados, la versión de 32bits y la de 64 bits de Firefox están casi siempre cara a cara. Aun así la versión de 64 bits no es oficial aun, y no parece que lo vaya a ser a corto plazo. Esto no quiere decir que no sea una versión totalmente funcional, en la que muchas veces su rendimiento es superior a las versiones de 32 bits, y más seguras.

    Opera irrumpe con su versión de 64 bits. En el caso de Opera no son tan estables como las versiones de 64 bits de Firefox y están menos optimizadas, pero parten desde una buena posición. Sin duda alguna Opera ha dado un gran salto en esta ocasión en muchos aspectos, desde la salida de su versión de 64 bits, soporte para aceleración hardware, soporte para WebGL… no está mal en estos 6 meses desde luego, y aunque no es capaz de alcanzar a Chrome, Firefox o Internet Explorer, sin duda alguna están haciendo un gran trabajo.

    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 delos 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 dependiendo 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, aunque puede obtener unos resultados increíbles, elevar al 97% el uso de la GPU en el test de la pecera es demasiado.

Entradas relacionadas:

  1. Comparativa Navegadores 2011: IE9, Firefox 4, Chrome 10, Safari 5, Opera 11
  2. Comparativa Navegadores 2011/2: IE9, Firefox 9.0, Chrome 15.0, Safari 5.1, Opera 12
  3. Comparativa Navegadores: IE9, Firefox 4, Chrome 6, Safari 5, Opera 10
  4. Pwn2Own 2012: Chrome averguenza, IE y Firefox KO
  5. Firefox 3.7: Aceleración por Hardware y una de Navegadores

Pwn2Own 2012: Chrome averguenza, IE y Firefox KO

Para quien no lo sepa, el Pwn2Own es un concurso anual sobre seguridad informática en el que se ponen a prueba los navegadores Web y los sistemas operativos más comunes. El concurso, no solo supone cuantiosos premios en metálico para los concursantes, sino que además está orientado a mejorar la seguridad de los navegadores y los SO en cuestión, ya que los concursantes están obligados a compartir con los programadores de los respectivos productos TODA la información relevante sobre los métodos usados, las vulnerabilidades encontradas y cualquier otro por menor.

Cada año, las bases del concurso suelen ser ligeramente diferente, los objetivos suelen variar a sí como los premios percibidos. Si bien el año pasado participaron en el concurso navegadores y sistemas operativos de terminales portátiles, este año se han quedado fuera. Las normas de este año son muy simples:

-Navegadores Usados: Mozilla Firefox 10, Microsoft Internet Explorer 9, Google Chrome 17 y  Apple Safari

-Sistemas Operativos: Windows 7 y MAC OS Lion

-Objetivo: Lograr un exploit de ejecución remota haciendo que cualquiera de los navegadores instalados en cualquiera de los sistemas visite un enlace proporcionado por el concursante. El código arbitrario invocado será siempre la ejecución de la calculadora del sistema.

 

Existen dos categorías:

-Exploit Zero-Day: Es decir, el concursante tiene que ser capaz de realizar una ejecución remota en uno de los sistemas TOTALMENTE parcheado y actualizado hasta la fecha del comienzo del concurso.

-Exploits publicados: En esta categoría, se han preparado sistemas XP (para Chrome, Firefox e Internet Explorer 8) y MAC OS Snow Leopard (para Safari)  dejando 2 vulnerabilidades de cada navegador abiertas (sin parchear), es decir se han dejado “abiertas” dos vulnerabilidades de Firefox, de Chrome/Safari (los dos usan el mismo motor) y de Internet Explorer. La idea en este caso es ser capaz de crear el exploit en el tiempo que dure el evento para esas vulnerabilidades en esos sistemas.

Para la primera categoría, se asignarán 32 puntos por cada éxito que se obtenga sin importar el día en el que se logre, para la segunda 10 puntos si se realiza en el primer día, 9 en el segundo y 8 si se realiza el último día.

 

Hay que tener en cuenta algo igual de importante, y es de nuevo la preparación o no preparación que los fabricantes acuden al concurso. En el concurso se entregan sistemas totalmente parcheados hasta el mismo día en el que comienzan. Es decir que los fabricantes de software (Mozilla, Google, Apple o Microsoft) tienen en teoría hasta ese mismo día para parchear sus sistemas. Esto es de suma importancia dado que un concursante podría llevar semanas preparando un exploit y el fabricante aprovechar el último día para tapar el agujero de seguridad. Luego es justo ver que es lo que ha hecho cada desarrllador con sus productos en estas últimas semanas en tanto a actualización de vulnerabilidades se refiere:

Mozilla Firefox Apple Safari Microsoft Internet Explorer Google Chrome Apple MAC OS X Microsoft Windows 7
2 2 4 34 49 7

 

Mozilla Firefox:

En lo que vamos de año, Mozilla tan solo ha tenido que enfrentarse a dos vulnerabilidades, parcheadas en dos entregas diferentes, el 13 y el 17 de Febrero. Ambas fueron subsanadas prácticamente al momento de conocerse. Desde entonces no ha sacado ningún otro parche de seguridad. El año pasado días antes del Pwn2Own sí respondió con la corrección de varios fallos de seguridad, este año tan solo lleva en su cuenta dos boletines, y por ello le damos la corona de oro en esta ocasión. Podemos decir que este año ha participado sin hacer “trampas”

 

Apple Safari:

En lo que lleva de año tan solo han sido publicado dos boletines de seguridad (todo un record para Safari), no obstante Apple de nuevo ha sido un chico malo, y aprovechó hasta el último minuto de que comenzase el concurso para publicarlos, el 7 de Marzo, es decir el mismo día que comenzó el concurso. Este mismo comportamiento lo vimos realizar el año pasado a gran escala, de nuevo apuró hasta el último momento para lanzar una macro actualización. De cara a Safari no ha sido mucho, pero sin duda han aprovechado hasta el último momento. Aun así no ha sido el peor parado ni mucho menos, este año como hemos dicho Safari se ha comportado.

 

Microsoft Internet Explorer:

Microsoft ha continuado con la tónica del año anterior. Cada fabricante tiene su propia política de actualizaciones, así por ejemplo Google y Mozilla suelen tener respuestas casi inmediatas, Apple responde de manera muy muy tardía, y Microsoft desde hace años y años como ya hemos dicho publica mensualmente (si no se detecta un error grave) el segundo martes de cada mes sus boletines y actualizaciones. Si miramos lo que ha hecho Microsoft en lo que llevamos de año con Internet Explorer, coincide a la perfección, y es que Microsoft pese a todo tan solo ha tenido que lidiar con 4 Boletines de seguridad, todos ellos publicados en su ciclo estándar de febrero, el día 14.

 

 Google Chrome:

Google es hoy nuestra primera oveja negra y se llevará el primer tirón fuerte de orejas. Ya el año pasado recompensó con fuertes sumas de dinero a cualquiera que lograse encontrar fallos de seguridad en su navegador (curiosamente justo antes del Pwn2Own), con la idea evidente de intentar por todos los medios que su navegador no fuese asaltado en el Pwn2Own de 2011. Además, aprovechó hasta el último minuto para actualizar su navegador al igual que hizo Apple. Este año ha realizado exactamente lo mismo. Durante unas semanas Google ha estado pagando a cualquiera que lograse descubrir fallos de seguridad en su navegador. Esta medida me parece sinceramente respetable y muy inteligente, pero recordemos que no por ello no es jugar con “trampas” en un concurso. Podríamos pensar que Google lo hace en post de la seguridad pero en cambio lo hace justo antes del Pwn2Own por segundo año consecutivo… ergo le importa más la mala prensa que la seguridad en sí. Además, no hay que olvidar ni obviar que Chrome ha cerrado lo que llevamos el año con la friolera de 34 boletines de seguridad!! Y tiene aun más delito si vemos que Google ha realizado al entrega de sus actualizaciones en dos entregas: La primera y más pequeña el 16 de febrero, y la más gorda hace exactamente 4 días, dos días antes de que comenzase curiosamente el Pwn2Own. Google… eres un tramposo.

 

Microsoft Windows 7:

Después de analizar los navegadores hay que analizar los parches de seguridad que se han aplicado a los sistemas, ya que para lograr un acceso remoto la primera barrera a superar es el navegador pero la segunda es el sistema operativo. Microsoft se salta una cuenta total de 7 vulnerabilidades en lo que va de año, entregadas de forma rigurosa con sus ciclos estándar al igual que las actualizaciones de Internet explorer. En este caso fueron dos entregas, una en el ciclo de enero (el martes 10 de Enero) y la segunda en el ciclo de febrero (el 14 de febrero). En términos generales le daría la medalla de plata en cuanto a navegadores y la de oro en cuanto a sistema operativo. Este año de nuevo participa con las manos limpias y con un historial bastante decente en cuanto a vulnerabilidades se refiere.

 

Apple MAC OS X:

Apple es la segunda oveja negra del día, pero contra todo pronóstico este año no lo es por Safari, sino por MAC OS. Apple este año no ha aprovechado en actualizar MAC OS hasta el último minuto como si hizo el año pasado o este año con Safari, pero sí que lanzó una macro actualización con la friolera de 49 fallos de seguridad, todos ellos entregados tan solo en una misma entrega el 3 de Febrero. No esperó hasta el último momento así que no podemos decir que su comportamiento fue el mismo que el de Google ni mucho menos, pero tan solo un mes antes parchear hasta 49 fallos (recordemos que Windows 7 tan solo ha tenido que hacer frente a 7) no es que sea jugar tampoco muy limpio, por no decir la inseguridad hacia sus usuarios. Es decir, lo de Google no tiene nombre pero al menos actúa con prontitud, al igual que Mozilla con Firefox. Microsoft posee ciclos totalmente regulares y es muy fial a ellos, pero Apple simplemente publica cuando cree que tiene que hacerlo.

 

Una vez que sabemos las condiciones del concurso y las condiciones en las que cada compañía acudió al concurso, sí podemos decir ya los resultados de este año:

 

Chrome

Después de todos los esfuerzos de Google, fue en vano. Vupen logró destrozar por completo Chrome en MAC OS X por medio de un Zero-Day exploit (la máxima pena para un navegador/sistema), dejando en bastante evidencia a Google. Hay que entender algo, cuando juegas limpio y pierdes, al menos puedes retirarte con la cabeza alta y entender que han sido unos buenos concursantes… pero en el caso de Google ver como Chrome sucumbía después de estar durante semanas pagando a expertos de seguridad e incluso lanzando grandes parches de seguridad hasta dos días antes…  eso señores es cuanto menos humillante, según mi modo de ver las cosas por supuesto. Eso sí, hay que destacar que Google ya ha parcheado Chrome y corregido el meritoso éxito de Vupen.

 

Internet Explorer

Despúes de que Vupen pulverizase Chrome, cambió de objetivo, y si su desayuno fue Chrome, su comida fue Internet Explorer. De nuevo imponiendo el máximo castigo con un otro exploit Zero-Day logró sacar la calculadora de Windows en este caso. Sin duda alguna otros merecidos 32 puntos en su cuenta.

Internet Explorer no solo cayó con la pena máxima, sino que Vupen fue capaz también de crear dos exploits más para cada una de las vulnerabilidades que se habían dejado abiertas en IE para tal efecto, y dado que todo fue el primer día, logro otros 20 puntos adicionales (10 por cada vulnerabilidad explotada)

Más tarde, la pareja Willen y Vincenzo lograrían también explotar una de las vulnerabilidades abiertas, los que les daría sus primeros 10 puntos.

 

Safari

Vupen no ha dejado títere con cabeza, y asaltó con éxito también las dos vulnerabilidades dejadas abiertas en Webkit, logrando otros 20 puntos por Safari. Lo mismo para el equipo formado por Willen y Vincenzo, que fueron capaces de realizar exactamente lo mismo.

Pese a todo no se ha logrado un exploit Zero-Day en Safari

 

Firefox

En esta ocasión fue el equipo de Willen y Vicenzo quienes lograron tumbar después de bastante sudor Firefox con un exploit Zero-Day en MAC OS Lion, cosa que no se logró el año pasado (asaltar Firefox), Para terminar, vulpen logró también con Firefox su éxito frente a las 2 vulnerabilidades abiertas, robando otros 20 puntos más. Willen y Vincenzo lograrían explotar tan solo una de ellas.

 

 

En esta ocasión es Google quien a defraudado, no porque haya caído, sino por jugar un tanto “sucio” y aun así caer pese al ingente número de vulnerabilidades parcheadas en el último momento. Por otro lado Apple se ha salvado en esta ocasión por pelos con Safari, aunque no con MAC OS, pese al macro parche de seguridad que lanzó en Febrero. Mozilla este año calló en el último momento pese a quedar invicto el año pasado, pero no será hasta la semana que viene en la que se darán a conocer todos los datos. Por último Microsoft, que junto con Mozilla son los dos únicos que pueden irse con la cabeza bien alta por acudir al concurso sin “trampas” algunas y sin cambiar sus ciclos de actualizaciones….

Un saludo amigos.

Entradas relacionadas:

  1. Comparativa Navegadores 2011: IE9, Firefox 4, Chrome 10, Safari 5, Opera 11
  2. Comparativa Navegadores 2011/2: IE9, Firefox 9.0, Chrome 15.0, Safari 5.1, Opera 12
  3. Un poco de todo: Google, iPad, JB permanente, Ley “Sinde”, pwn2own…
  4. Comparativa Navegadores: IE9, Firefox 4, Chrome 6, Safari 5, Opera 10
  5. Pwn2Own: Resultados 2011

Google Play

 

Hace unos días comenzó a circular rumores sobre los motivos por los cuales Google había comenzando a registrar dominios y hacer referencia a “Play” o Google Play. Sin hacer ruedas de prensas espectaculares o comunicados en los medios, Google cambia de forma bastante cotundente el concepto de Store que tenía anteriormente. De este modo Google abandona el viejo Android Market que se creó exclusivamente para sus aplicaciones y lo renueva con un Store mucho más lógico y sencillo.

Tendríamos que remontarnos a cuando Google decidió abrir su Android Market. Pronto se llenaría de aplicaciones, pero no dejaba de ser eso… un store de aplicaciónes. No obstante, con el tiempo Google lanzó Google Music, un servicio en nube que permite almacenar hasta 20.000 canciones. Tiempo después de nuevo (hace unos meses) Google lanzó dentro del propio Android Market su servicio de venta y alquiler de películas y de libros. Android Market no se creó realmente para todos esos servicios, y la cosa se complicó aun más cuando Google lanzó de forma oficial la venta de música y su integración con Google Music.

Estaba claro que el viejo Market no era precisamente el mejor punto de encuentro para todo ello, y eso es Google Play. De este modo desaparece el viejo Android Market y se traslada absolutamente todo:

 

http://play.google.com

https://play.google.com/about/features/

 

Google Music <-> Google Play Music

Cambia el logotipo, el nombre… y las últimas versiones del gestor de Google Play Music para el PC permite descargar en nuestro equipo no solo la música comprada, sino que también nuestra biblioteca subida anteriormente.

Para quienes tengamos cuenta podemos usar Google Play Music, pero la venta de discos tan solo está disponible por ahora en EEUU

 

Google Movies <-> Google Play Movies

Al igual que con Google Play Music, tan solo en EEUU se puede por ahora acceder a las películas

 

 

Google Books <-> Google Play Books

 

 

 

Al margen de hacerles un lavado de cara generalizado, todo se ha integrado mucho mejor, se han cambiado prácticamente todos los logos y nombres de los productos asociados. Se han implementando mejoras que iremos conociendo a lo largo de los días y es muy posible que aun estén por ver otras tantas sorpresas.

 

De cara a Android Market <-> Google Play Store

Al igual que con Google Play Music, ya están disponibles las dos aplicaciones actualizadas para Android. En el caso del Play Store también se ha mejorado la navegación y el acceso tanto a la tienda de aplicaciones como a nuestras propias aplicaciones. Como ya he dicho, todo centralizado.

 

 

Para quien no tenga Play Store actualizado (el viejo market), dejo aquí el apk, en conjunto con el apk de Play Music, que como sabemos aunque podamos acceder no podemos descargar la aplicación de forma oficial:

Google Play Store

Google Play Music

 

Personalmente me ha gustado la fusión, sobre todo para los que hacemos un uso extenso de los diferentes servicios de Google

Entradas relacionadas:

  1. Google I/O
  2. Google Music
  3. Google+
  4. Un poco de todo: Google, iPad, JB permanente, Ley “Sinde”, pwn2own…
  5. Android: Llamadas de audio/video con Google Talk

Angry Bird en Facebook: Como matar el tiempo “Hackeándolo”… y por supuesto aniquilando a esos malditos cerdos verdes

Sé que tengo la bandeja de borradores con muchos proyectos que terminar, pero entre unos y otros siempre hay que sacar algo de tiempo para la diversión, y que mejor manera que jugando un poco… a modificar juegecillos de Facebook, lo cual se ha ido convirtiendo con el tiempo en algo habitual con lo que suelo entretenerme.

Esta es una de muchas historias que empezaron y terminaron igual. En este caso concreto todo empezó matando cerdos… todo terminó con un marcador lleno de ceros (a la derecha) en el servidor de Rovio (por supuesto a modo de ejemplo, y como es costumbre informaré a los desarrolladores, Rovio en este caso, sobre ello)

La noche de hace un par de días fue un tanto larga… (algunos problemillas febriles sin mucha importancia). Entonces vi el anuncio de que por fin Rovio (la empresa del más que famoso “Angry Bird”) había lanzado el juego en Facebook. Aquí hay que decir que soy un gran fan de los pájaros enojados, y que ambos hemos pasado bastante horas matando el tiempo en lugares en los que tenía simplemente que esperar. Así que aunque no soy proclive a juegos en las redes sociales no pude resistirme a tirar del tirachinas unas cuantas de veces. Aunque parezca un poco curioso, mi cabeza cuando mira una pantalla a veces empieza a pensar un poco más allá y cuando me doy cuenta estoy intentando conocer los secretos más recónditos de lo que estoy mirando. No pude resistirme, y entre tanto matar cerdos comencé de nuevo a lanzarme esas preguntas de siempre: “Habrán hecho bien los deberes el equipo de Rovio encargado de Facebook?” “Será relativamente seguro o por otro lado será otro coladero de fallos de seguridad como tantos otros de Facebook?”. Antes de darme cuenta ya estaba jugando con editores de memoria RAM y buscando la aplicación Flash en ella.

Unos se divierten jugando, otros intentando ser simplemente los mejores en esos juegos, otros simplemente son felices por poder hacer trampas en ellos!! Yo por mi parte soy de los que se divierte jugando sin más y encontrando problemas en el código que hacen que sea inseguro o que facilitan el trampearlos. Es bonito ver como, una vez más, aplicando simplemente teoría, imaginación y tiempo todo es posible. Por supuesto no tiene nada de especial ni demasiada complejidad para muchos ser capaz de hacer “trampas” en juego Flash, la importancia es que esto tan solo es un juego, pero pone de manifiesto que cualquier aplicación tenga detrás el equipo que tenga está siempre expuesta a todo tipo de asaltos!! Y ningún sistema es impenetrable si se ponen los medios necesarios, un poco de cabeza, ingenio y tiempo. Las limitaciones generalmente tan solo existen en las ideas de las personas. Si tienes una idea y esta es buena, más del 50% estará terminado, el otro 50% será ponerla en práctica. Y por supuesto si todo falla, volver atrás,. replantearse de nuevo el problema y atacarlo por otro costado, y de nuevo volver a empezar tantas veces haga falta hasta lograrlo.

 

Los chicos de Rovio sin duda alguna pusieron las cosas relativamente complicadas en muchos aspectos, no obstante en otros se dejaron llevar quizás por el descuido o por la desgana o incluso por creer que ciertas medidas eran suficiente. Veamos con lo que me encontré:

 

-Búsqueda simple de valores

La primera idea aunque sea lo más simple y rápido de hacer, sin contar que disponemos de programas tipo CheatEngine que hace que sea trivial, no deja de ser lo primero que hay que hacer, a fin de cuenta igual funciona, y sino tal vez modificando el proceso un poco es posible. En este caso concreto, Rovio ha cerrado bien esta posibilidad, y tiene bien protegido el marcador de puntos frente a modificaciones puntuales en RAM de los valores. Sí, es posible encontrar los puntos y modificarlos, pero rápidamente cualquiera vería que es una vía muerta en principio, estos vuelven a restablecerse de inmediato.

La segunda idea consta de echarle algo de más imaginación al asunto y tratar de buscar otros posibles valores igualmente importante que puedan ser relativamente simples de encontrar/buscar y que Rovio hubiese podido pasar por alto, por ejemplo los puntos que da el destrozar un cerdo, un muro… el problema de este sistema es que encontrar el valor es algo más fatigoso dado que no es un valor dinámico como los puntos del jugador, sino que es un valor fijo, y con que existiese en la memoria Virtual del proceso unas cientos de ocurrencias de dicho valor seria casi imposible conocer cual es el que está fijando los puntos de aquello que queremos modificar… y eso siempre sin contar con que pueden ser valores “protegidos”. De cualquier modo, tampoco fue algo exitoso, los valores no fueron muy complicados de encontrar, pero igualmente inservibles, con algún tipo de doble protección para impedir su modificación.

 

-Decompilación de la aplicación Flash

Una de las formas más eficaces es echar mano de nuevo a los decompiladores de Flash. Obtener la aplicación Flash es fácil, aunque esta está partida en varios trozos: El juego principal, el entorno (compras, contactos…), el sonido, otra de sonido y los créditos. En particular podríamos comenzar por lo que sería el juego principal:

http://angrybirds-facebook.appspot.com/20120216-1322/flash/AngryBirdsFacebook.swf

 Evidentemente si accedemos directamente desde un navegador no podremos alcanzar dicho archivo puesto que está diseñado para ser cargado de otro modo. No obstante, si podemos utilizar dicho enlace en cualquier gestor de descargas, o en el mismo Firefox deshabilitando la ejecución automática de contenido Flash.

A este punto los chicos de Rovio cometieron dos errores. El primero es no proteger mejor la aplicación principal, como vimos en Towner es posible y una práctica muy aconsejable el cifrar el flash totalmente, y que sea un loader el que llama directamente el archivo flash (cifrado) y se encarga de su descifrado antes de cargarlo en RAM. En el caso de Towner el problema estaba que para el cifrado usaron una simple función XOR con un valor preestablecido que era inmediato adivinar. Es cierto que el contenido flash se sirve comprimido, pero actualmente existen multitud de herramientas para convertir un flash CWS (comprimido) a uno FWS (sin comprimir)

El segundo error es usar texto plano inteligible en la propia aplicación Flash una vez descargada, sin necesidad siquiera de decompilar. Esto hace que aplicaciones como Flasm sean muy útiles en estos casos.

Independientemente de las dos fallas bastante importantes de Rovio, estas podrían haber sido de todos modos sorteadas, como por ejemplo accediendo a RAM directamente y sacando de ella la imagen de la aplicación Flash descomprimida y descifrada, pero desde luego sería una capa de seguridad bastante importante. No se trata de crear a fin de cuenta el sistema invulnerable (que es imposible), sino de hacerlo lo más complicado que se pueda… sin repercutir por supuesto en usabilidad o rendimiento

Una alternativa efectiva y casi definitiva sería decompilar la aplicación Flash, modificarla a nuestro antojo, recompilarla, y usar apache en nuestro equipo para redireccionar las peticiones de la aplicaicón a nuestro equipo, de este modo estaríamos “inyectando” la aplicación modificada por así decirlo cada vez que la usásemos. Los servidores de Rovio no notarían nada extraño y casi con toda seguridad los datos se validarían correctamente.

En esta ocasión no llegué a realizar dicha práctica, no me hizo falta.

 

-Realizar un Spoof de los datos enviados de vuelta al servidor

Por desgracia para Facebook y para muchos usuarios, este no obliga de forma rotunda el uso de TLS/SSL a través de toda su plataforma, tanto de sus propias páginas como de las aplicaciones que se hospedan. A día de hoy debería de ser una obligación y no una alternativa, sobre todo cuando lo que están circulando de un lado a otro son nuestros datos. En cualquier caso, es posible ejecutar la aplicación a través de conexiones no seguras, y por tanto es fácil ver todo lo que pasa de una red a otra. Esto no quiere decir que sea posible modificar las peticiones de la aplicación hacia sus servidores ojo, pero si es una opción que puede meditarse, y tampoco pasa nada por tenerlo en cuenta.

En este caso concreto tampoco fue algo a lo que me ceñí, pero siempre es un buen punto de partida

 

-Traceado del código

En el último lugar de la lista de opciones viables (que sean confesables), siempre está el tracear el código que se está ejecutando en RAM. A fin de cuenta un contenido flash no es más que una aplicación que se ejecuta a través de una máquina virtual, a la cual puede adherirse un debugger. Una vez que tenemos una aplicación conectada a un depurador, podemos si queremos ver que instrucciones, posiciones de memoria y otros se están ejecutando. ¿Que sentido tiene este método?

Los datos pueden cifrarse o camuflarse, pueden usarse funciones que enmascaren sus valores o implementar rutinas para proteger las partes más sensibles del código. Pero del mismo modo si conocemos donde están estos datos podemos realizar un traceado inverso para saber que funciones o que operaciones se están realizando sobre esos datos. Si tenemos el código desensamblado Flash por otro lado mejor que mejor por supuesto, puesto que tendremos una visión mucho más amplia.

Es decir, con programas tipo CheatEngine o cualquier otro monitor de RAM es fácil encontrar valores concretos, pero no le uso que se le dan. En este caso concreto, es fácil encontrar ciertas posiciones de memoria (10 creo que eran) donde se almacenan los puntos en teoría, pero como comprobamos anteriormente no tenían efecto el modificaros. Pues bien. podemos partir de ello y realizar un traceado inverso, averiguando que instrucción o instrucciones están accediendo a dichas posiciones de memoria para escribir en ellas esos datos. Este procedimiento realizándolo un par de veces, rápidamente nos hace encontrar dos o tres instrucciones en ensamblador que modificándolas al aire resulta en un completo éxito.

Imaginad que las posiciones de memoria en las que se almacenan los puntos fuesen la 0×00-0x0A. Si vigilamos dicha posición de memoria y analizamos que instrucciones tienen acceso a ellas, nos damos la sorpresa que tan solo un par de instrucciones son las que escriben en ellas. Si no podemos controlar el valor que se escribe porque no es un valor “real” pro así decirlo, si podemos controlar la instrucción que da la orden de escritura en dichas posiciones. Modificando simplemente un registro llegado dicha instrucción se obtiene lo deseado. Por supuesto tenemos una gran colección de depuradores al alcance de cualquiera, desde Windbg, como Ollydbg, IDA… el propio CheatEngine puede usarse en parte para este tipo de cosas también.

Otra opción realmente interesante sería el simplemente deshabilitar rutinas/funciones de protección que se usan para enmascarar los datos. Esto es muy sencillo dado qeu muchas veces tan solo hay que sobreescribir la instrucción en ensamblador por operaciones NOP: 0×90. De echo, esto mismo es lo que se hace muchas veces en parches típicos de programas para “activarlos”. Imaginar que toda la rutina de verificación de una aplicación se rellenase con operaciones NOP, la rutina simplemente dejaría de tener utilidad. Normalmente si si se puede puede producirse lo mismo modificando la condición de un salto condicional (que se aplica del mismo modo a la aplicación flash en cuestión.

Este fue el primer sistema con éxito que probé, que fue el el segundo en poner en práctica (el primero fue la búsqueda de valores por supuseto). Lo bueno de este método es que si se comprende bien puede aplicarse prácticamente a cualquier otra aplicación existente, ya sea Flash o de escritorio. Lo malo del proceso es que no es algo tan intuitivo, y hay que saber un poco más sobre el funcionamiento interno de nuestros equipos. Además, no pueden evitarse de forma simple. Y aunque Rovio implementa algunos sistemas de protección para ello, con los cuales por cierto me topé unas cuantas veces: “Opps, error con el servidor refresque la página”, fue posible circunvalarlos.

La única opción para evitar este tipo de técnicas por parte de Rovio implicaría el uso de detectores de Debuggers en el propio código de la aplicación, rutinas cebo y de trampa para engañar al usuario y cosillas varias. Y siempre por supuesto protegiendo antes toda la aplicación Flash a una eventual decompilación, dado que esta podría darnos código directamente escrito en Action Script, bastante más simple de comprender que código en ensamblador. Con todo el código Action Script por delante es posible crear aplicaciones pequeñas como vimos con Towner para modificar lo que quisiésemos.

 

No obstante en este caso concreto es posible realizar un sistema aun más simple y fácil de los expuestos para obtener éxito en la tarea de modificar lo que deseemos, por ejemplo el marcador de un nivel. Este “sistema” es más ingenioso que técnico y la verdad se me ocurrió más tarde de todo lo anterior… cuando en realidad es más simple. Precisamente por su simpleza prefiero no exponerlo públicamente y evitar que cualquier lector le pique más las ganas de hacer trampas que de investigar y aprender, y ya sabéis que se trata de aprender y de tirar de las orejas y poner un poco colorados a los responsables, Rovio en este caso.

En cualquier caso tengo que decir como ya he dicho que soy fiel a la matanza de cerdos a pajarrazo, un juego adictivo y original. Por no decir que cuando terminé de “hackear” (nunca me ha gustado dicha palabra) el juego, las siguientes par de horas fueron dedicadas a conseguir todas las estrellas de los niveles abiertos actualmente, eso sí, sin trampas… bueno, exceptuando aquellos niveles en los que estaba probando todo lo comentado anteriormente, como me sucedió por ejemplo en el primer nivel de todos… en el que sinceramente se me fue un poco la mano… es lo que tiene muchas veces modificar sin estar seguro al 100%… el resultado a veces es… inesperado, y sí,el servidor aceptó por buena la puntuación (por supuesto he eliminado de la imagen las caras de los perfiles, y sí, es 1 millón y pico, siendo la segunda mejor puntuación de algo más de 30.000):

 

Un saludo amigos

Entradas relacionadas:

  1. Proyecto. Towner: Destrozando otro juego Flash (Facebook y Tuenti)
  2. FaceBook: Te reto a ver esta pagina… -> NO, Engaño, Suplantación…
  3. Pasando el tiempo… el día a día
  4. Steve Jobs: Google quiere matar al iPhone
  5. Apple renueva la gama de sus MacBook. Echemos un vistazo!! y por supuesto algunas mentiras

Elvira Lindo: “Lo que no queremos ver”

Leyendo el periódico hace un rato me he topado con un interesante artículo de opinión que sinceramente me ha hecho reflexionar y me ha puesto los pelos de gallina, puesto que debo de reconocer que es cierto. En este caso, se usa de ejemplo a Apple por las noticias (nada nuevas) de la explotación en china de sus trabajadores, pero por supuesto y por desgracia tampoco son los únicos (aunque si el caso más sangrante por la explotación que se sufre). La pregunta incómoda que se lanza es tajante:

¿Vivimos mejor a costa no solo de la explotación de otros sino también de su salud? ¿Usamos la tecnología realmente en pos de una vida mejor y más cómoda o somos esclavos de ella? Cada cual que se mire a si mismo, pero por desgracia lo que expone Elvira Lindo es totalmente cierto. Lo que sucede es que generalmente cerramos los ojos y nos olvidamos de que es así por puro egoísmo.

 

“Dickens vive. De la misma forma que sobrevive Charles, el niño de 12 años que entró a trabajar en una fábrica de betún en 1824 mientras su padre cumplía condena en la cárcel por no poder hacer frente a sus deudas. Sobrevivió esa desdichada criatura en muchas de las novelas con las que el escritor se convirtió en uno de los primeros fenómenos populares de la literatura. El escritor la tuvo presente en Oliver Twist, en Cuento de Navidad, en Casa desolada, en David Copperfield. Toda la obra de este grande del que se cumple dentro de unos días el bicentenario está impregnada del sentimiento de humillación que padeció de niño, cuando despojado de la protección paterna, se vio trabajando de sol a sol en una fábrica infestada de ratas: “Rememoro con tristeza aquella época de mi vida, y muchas veces me olvido de que tengo una mujer y unos hijos, incluso de que soy un hombre”. Su niñez explica un sentido de la justicia tan imperioso que estoy convencida de que influía en la resolución de sus argumentos: tras someter a los personajes a múltiples penurias, siempre hay alguien, un tercero, que restablece la verdad y devuelve al miserable la buena vida que le fue arrebatada. Tal vez eso explique la cabezonería con la que peleó en Estados Unidos unos derechos de autor que le habían sido negados por el mero hecho de no ser americano. Lo que la prensa interpretó como codicia él lo reclamó como derecho puesto que, aunque dicen que el público lector esperaba con impaciencia la llegada del barco en el que traería el último capítulo de una novela que seguían por entregas, él no disfrutó de los beneficios de su tremenda popularidad en el país de los yanquis. Dickens vive. Vive más que nunca, aunque los niños o los jóvenes no lo lean (que yo sepa) tanto como lo leímos nosotros, a los que nos creó una conciencia social en estado puro, sin el consabido envoltorio ideológico que vendría luego. Dickens, su espíritu, está latiendo poderosamente en esta época en la que la codicia de los ricos ha vaciado los bolsillos de los pobres y lleva camino de vaciar los de la clase media.

Cierto es que la explotación infantil no sucede ante nuestros ojos pero, de vez en cuando, por una noticia o una imagen que reclama solidaridad, sabemos que la ignominia no ha dejado de ocurrir, aunque tenga lugar en un país tan lejano que el espectáculo de esa miseria no nos azote a diario. Durante unos días, el periódico The New York Times ha publicado unos valientes reportajes sobre las condiciones de los trabajadores en las fábricas proveedoras de componentes a las grandes empresas tecnológicas. Si empleo la palabra valiente es porque no deja en muy buen lugar a empresas americanas que, aprovechándose de la baratura del empleo en las célebres tierras lejanas y descargando toda la responsabilidad en la falta de derechos de aquellos países, niegan que su presión a la hora de marcar los tiempos de entrega tenga algo que ver con que, por ejemplo, en el pulido del cristal de un iPhone, en vez de usar alcohol, que tiene un secado lento, opten por una sustancia altamente tóxica. Si califico el reportaje de valiente, repito, es porque, según las encuestas, un 57% de los americanos no le ven a los productos Apple ninguna peguita, y se entregan a ellos como quien se entrega a una imagen religiosa que les comunica directamente con san Steve Jobs, que ya está en los cielos.

Este tipo de noticias pueden provocar un mal rato a ese batallón de sensibles corazones que piensan que las creaciones de Jobs han servido solo para mejorar el mundo. Lástima que para sofisticar la calidad de nuestras comunicaciones haya personas que vivan hacinadas en un cuarto, sin derecho a la intimidad, que trabajen 60 horas a la semana, que pongan su salud en peligro, que se dejen la piel literalmente en ello. No es demagogia, como tampoco lo eran las narraciones dickensianas. Hace falta que uno de esos jóvenes trabajadores que pulen cristales convierta su humillación en novela o reportaje y cuente aquello que solemos olvidar: cómo se fabrican las cosas. Habría que esquivar, eso sí, la censura de su país, por la que al parecer estamos muy preocupados. No estaría de más que nos llegara esa historia por escrito. La leeríamos, no podría ser de otra manera, como un acto de solidaridad. En un libro de papel. No, mejor en un iPad, que le daría al acto de la lectura un carácter simbólico. O no, mejor todavía, descargada gratuitamente de la Red, porque ni la cultura ni la solidaridad han de tener fronteras. Se ha hablado mucho de la explotación a las mujeres del sector textil o de la inmoralidad de lucir abrigos que provienen de un cruel sacrificio animal, pero el terreno de lo tecnológico sigue envuelto por una especie de manto santificado que protege al usuario de las malas noticias. Qué guay. Levantamos el puño con furia para reivindicar nuestro derecho a meter en un aparatito tres mil libros, cien mil canciones, dos mil películas. Esto nos debe estar haciendo brillantes y cultivados, aunque de momento no se vean señales de ello, y aunque no sintamos la obligación de sacar la cara por aquel que produjo estos pequeños tesoros sin los cuales muchos afirman que ya no sabrían vivir.” [Elvira Lindo]

Entradas relacionadas:

No hay entradas relacionadas con esta.

Vulnerabilidades en 2011: Windows 7, MAC OS Snow Leopard/Lion, SmartPhones y Navegadores

Ha terminado el año, y por curiosidad me he dado una vuelta por los boletines de vulnerabilidades CVE de este año pasado para ver como se habían comportado las principales empresas de Software en cuanto a fallos de seguridad se refiere en sus productos estrella. Para quien no lo sepa, CVE es digamos un Identificador que se le asigna a cada vulnerabilidad descubierta en cualquier software para que esta quede totalmente identificada y catalogada. No todas las vulnerabilidades son etiquetadas con CVE, pero podemos afirmar que más del 95% de todas las vulnerabilidades conocidas o documentadas lo están. Es por ello que es una forma muy eficaz de poder contabilizar de forma bastante rigurosa los fallos de seguridad de software de un producto.

Todos los datos están extraídos por tanto tanto desde del Instituto Nacional de Estándares de Tecnología (NIST) que son los que se encargan de CVE, como Secunia, posiblemente la empresa más importante de índole mundial en el seguimiento de vulnerabilidades.

En cuanto a sistemas operativos de escritorio se refiere he tomado por un lado Windows 7 (que ha estado presente con nosotros los 365 días del año pasado) y por el otro lado MAC OS X. En el caso de MAC OS X, dado que Lion apareció a mitad de año, he contabilizado en la gráfica principal todas las vulnerabilidades registradas en boletines CVE hasta la fecha para Snow Leopard, y a partir de esa fechas las vulnerabilidades de Lion hasta final de año.

En cuanto a SmartPhones se refiere, tendremos un poco todos los implicados: Android, iOS, BlackBerry OS, Windows Mobile (me parecía totalmente despreciable el porcentaje de usuarios actualmente con otros OS).

Por último los Navegadores como siempre: IE8/9, Firefox 3.6-9.x, Chrome 8-16, Safari 5, Opera 11. Evidentemente algunos navegadores participan con múltiples versiones porque en todo el 2011 han cambiado varias veces.

 

 

  

 

Sobra decir que cuantas más vulnerabilidades es peor. De nuevo se desmitifica el mito que dice que MAC OS es más seguro que Windows. Incluso teniendo en cuenta la gran desproporción de usuarios que existe entre un OS y el otro (existen infinitamente más usuarios en Windows 7 que en Snow Leopard o Lion), MAC OS en 2011 ha tenido una tasa de fallos de seguridad que duplica la de Windows!! Pensar que cuando se habla de CVE no importa si los fallos de seguridad han sido parcheados o no, simplemente que existe una vulnerabilidad que ha podido (o no) ser corregida por su fabricante.

También he optado en esta ocasión por mostrar una gráfica que representa por versión de OS esa tasa de fallos de seguridad. Los resultados son más o menos igual de interesantes, Lion llegó al mercado a finales de Junio y se empezará a distribuir masivamente sobre Julio-Agosto. En teoría habría sido muy lógico pensar que al ser una revisión más actual habría sido mucho más sólido que Snow Leopard, en cambio ha sufrido prácticamente el mismo porcentaje de vulnerabilidades (teniendo en cuenta que entró algo despues de medio año de forma masiva). ¿Quien continúa afirmando que Apple es sinónimo de seguridad?

Por supuesto no es tan solo importante el número de vulnerabilidades encontradas, sino la rapidez con la que los fabricantes las parchean. En el caso de Microsoft, los ciclos son regulares, al menos una publicación mensual si se han encontrado fallos de seguridad, y se publican actualizaciones inmediatas de existir un fallo grave. A lo largo de todo 2011 Microsoft habría parcheado el 100% de todas las vulnerabilidades CVE en unos 15-17 entregeas repartidas por todo el año.

Por el contrario en el caso de MAC OS, Apple no tiene ciclos concretos de actualizaciones. En su caso, las 208 vulnerabilidades fueron corregidas tan solo en 8 tandas repartidas a lo largo del año, en las que ahora mismo no se han parcheado el 100% de ellas. Este es incluso un peligro aun mayor al de tener un gran número de ellas, el no tener políticas de publicaciones periódicas cada poco tiempo. Apple lo que hace es que cada mucho tiempo actualiza el sistema y le da una versión diferente: 10.7.0 a 10.7.1 por ejemplo, cuando el 99% del código cambiado es por fallos de seguridad.

 

 

Actualmente aunque no tenga a mano los datos, el mercado de los Smartphones se encuentra dominado totalmente por Android, que apararía ahora mismo más del 50% de este. Más alejado se encontraría iOS con un 30 aproximadamente y el resto se lo repartirían BlackBerry, Windows Mobile, Symbian… En esta ocasión no puedo sino quedarme con la boca abierta de lo que me topé cuando terminé de extraer los datos… y no se trata de ninguna errata. Windows Phone lograba superar el año sin existir aparentemente ninguna vulnerabilidad CVE registrada, lo cual hace que sea el ganador de la noche!! BlackBerry con muchos más usuarios que Windows Phone nos decía que en todo el año tan solo 4 CVE habían sido asignadas. Android en tercer lugar y copando la gran mayoría de usuarios con tan solo 8 vulnerabilidades. Aquí uso “tan solo” no porque 8 me parezcan pocas, dado que tan solo una vulnerabilidad puede ser suficiente para que se apoderen totalmente de tu terminal!! Digo “tan solo” porque iOS 4/5 ha alcanzado en el año 2011 la friolera de 164 vulnerabilidades. Aquí no hay trampas ni trucos, cualquiera puede ir a revisar los datos del NIST o de Secunia, y ojo!! Tan solo están contadas las de iOS 4/5 referente a los iPhone/iPod Touch, no se incluyen siquiera las que tan solo afectan a iPad/iPad 2

De nuevo, es importante la actuación inmediata por parte de los fabricantes ante cualquier vulnerabilidad. En el caso de BlackBerry se sabe que siempre ha reaccionado de forma tardía. En el caso de Android se sabe que Google siempre ha actuado de forma inmediata y en el caso de iOS Apple siempre ha esperado hasta el final o hasta que ha trascendido a los medios para lanzar actualizaciones.

 

 

 

Por último y no menos importante tenemos los navegadores, y no exentos de sorpresas. De nuevo desmitificando mitos, Internet Explorer se encontraría como el menos vulnerable en el transcurso del año con tan solo 33 fallos descubiertos. Opera le seguiría de cerca con 43, una cifra nada desdeñable, aunque teniendo en cuenta el poco mercado que copa este es relativamente preocupante. En tercer lugar casi doblando a Internet Explorer encontraríamos a Firefox con 66 fallos de seguridad, que ya son bastantes!! Si bien es cierto que hay que tener en cuenta que cualquier software de código abierto poseerá o debería de poseer significativamente un número de CVE superior, puesto que es más fácil detectar fallos de seguridad por parte de expertos en la materia por poder mirar directamente al código fuente de este.

Que safari posea un índice que casi triplica el de Firefox no es es de extrañar a muchos dado que Apple no es que brille jamás por su seguridad y era previsible que íbamos a ver un resultado similar, pero que Chrome haya alcanzado la friolera de 318 CVE es cuanto menos de sorpresa. Sí, evidentemente Chrome es también junto con Firefox los dos navegadores de código abierto que disponemos, y sí… Google posee infinidad de empleados trabajando a tiempo completo en él y por ello es normal descubrir también más vulnerabilidades… ¿pero tantas?

Por suerte para los usuarios de Chrome, pueden estar más o menos tranquilos porque los ciclos de actualizaciones de este son muy cortas, y tanto Google con Chrome como Mozilla con Firefox actúan de manera casi inmediata en el momento en el que se descubre un fallo de seguridad en sus navegadores. Microsoft suene tener un tiempo de reacción inferior a estos últimos, y dependiendo del fallo de seguridad puede posponerse hasta el siguiente ciclo estandar de actualizaciones (el segundo martes de cada mes). Opera actúa un poco de forma arbitraria y bien puede subsanarlo de forma inmediata que tardar bastante tiempo en reaccionar. Por último Apple ya hemos dicho como actúa ante los fallos de seguridad, primero niega, después le echa las culpas a Adobe por Flash y al cabo de un año con suerte saca una actualización sin darle ningún bombo para corregir 9 meses de fallos de seguridad acumulados.

 

 

La valoración final es clara. Increíblemente Microsoft se lleva la medalla de oro en tanto la seguridad de sus productos, en todos ellos!! Es sorprendente como el peor visto por el pueblo por ello es el mejor en ello, y como el más alabado por su seguridad es en cambio el peor. Google ha hecho un gran trabajo en Android, pero Chrome necesita aun pulir muchísimo su código, es incomprensible que haya podido llegar a tal cantidad de CVE, aun cuando todas estén totalmente parcheadas!! Es signo de que existen otras tantas que no lo están. Por parte de Apple el tirón de orejas de costumbre, tanto en iOS como en MAC OS una cantidad descomunal de fallos de seguridad en comparación con la competencia y lo peor: Actuación muy muy lenta. Para RIM poco hay que decir, teniendo en cuenta la afluencia de usuarios que aun controlan no ha salido mal parada del todo y Opera como siempre es ese pequeño incomprendido, siempre estando entre medio de las tablas pero jamás sin sobresalir ni en lo bueno ni en lo malo.

Entradas relacionadas:

  1. Interesantes palabras: Snow Leopard Menos seguro que Windows
  2. pwn2own: Comienza el concurso de Hackers contra los navegadores. Primero en caer? Safari + MAC OS Snow Leopard
  3. MAC OS Lion = MAC OS Leopard SP2. iOS 5 = iOS 4 + Copiado de las funciones de la competencia -> Decepcionante en ambos casos
  4. Bug “crítico” en Snow Leopard
  5. Seguridad: Vulnerabilidades. Capítulo Primero -> Introducción al mundo de las Vulnerabilidades

iPoo: Un retrete que cuesta el doble, sí, pero con estilo

 

Entre muchos de los logros que sin duda alguna nos dejó Steve Jobs en su vida, el “seguidismo” incondicional fue sin duda alguna algo que marcó totalmente la filosofía de los productos de la manzana. Si bien es cierto que el tecnicismo “Fanboy” puede aplicarse a cualquier persona que posee un fanatismo descontrolado hacia algún producto o marca en particular, este ha sido conocido y usado sobre todo en el mundo Apple precisamente por este seguidismo que siempre logró el señor Jobs. El problema es que cuando creas una corriente hacia un lado, creas al mismo tiempo una corriente hacia el otro. Cuanto más fanboys logres captar, mayor será la oposición que encontrarás por el otro lado.

Esta mañana perdido entre noticias tecnológicas me encontré de pronto en la web de Milos Paripovic en la que jocosamente nos mostraba su “iPoo”. Como era de esperar, no han sido pocos los sites pro Apple los que han corrido a quejarse o a mostrar su descontento ante este “iPoo”. De todo el “iPoo” sin embargo, lo que más me ha gustado es la “presentación” que hace Milos sobre ello, escenificando perfectamente el sentimiento (el mío incluido) generalizado que produce Apple para los que están fuera de esa “secta blanca” que en su día supo escenificar el Vídeo de presentación de la Motorola Xoom.

El texto completo lo tenéis en la web de Milos, pero voy a traducir alguna de sus frases de más calado que muestran totalmente la realidad actual de Apple: Pagar el doble por lo mismo, menor compatibilidad, fanatismo, políticas de empresas abusivas, marketing desproporcionado…  Por supuesto, Milos, para evitar cualquier tipo de argumentaciones legales explica al inicio de su web que en todo momento se trata de hacer uso de la sátira y su libertad de expresión (sino, faltaría tiempo que Apple intentase demandarlos por daños a su imagen):

 

“Some people may think it looks like Apple logo, but I disagree. If you see Apple logo everywhere maybe you should see a psychiatrist and take a look at a few Rorschach inkblot cards”

“Algunas personas podrían pensar que se parece al logo de Apple, pero yo disiento. Si ves el logo de Apple en algún lado deberías de ir a ver a un Psiquiatra y realizar algunos tests de Rorschach”

(Nota: Los test de Rorschach todos los hemos visto en películas, en las que el psicólogo muestra algunas cartulinas con dibujos abstractos para conocer que es lo que ven los pacientes en ellos)

 

“Unlike some Apple products, this toilet fully supports Flush”

“Al contrario que algunos productos de Apple, este inodoro es totalmente compatible con la evacuación”

(Nota:En realidad es un juego de palabras en inglés, “Flush” <-> “Flash”, alegando que iOS no es compatible con la tecnología Flash, que como recordaremos según Steve Jobs debería de a ver muerto hace 1 año atrás… en cambio se sigue usando tanto o más que antes)

 

“This toilet has exactly the same function as any other toilet and costs only twice as much for the same performance; but you will agree it is all about style and taste, and you will look a lot cooler in your friends’ eyes when you say you use the iPoo Toilet instead of…”

“Este inodoro tiene exactamente las mismas funciones que cualquier otro y cuesta tan solo el doble, obteniendo el mismo rendimiento; pero estará de acuerdo si le digo que es debido al diseño, y que así parecerá usted más “Cool” a los ojos de sus amigos cuando diga que ha usado un inodoro iPoo en vez de usar…”

 

“Many of our power users were intimidated with standard 2 buttons, and even have had bladder shyness. So our top UX designers came up with this: a button”

“La mayoría de nuestros usuarios avanzados estaban intimidados por el estándar de inodoros de dos botones provocando incluso incontinencias, así que nuestros mejores ingenieros han venido con esto: Un solo botón!!”

(Nota: Una sátira cuanto menos graciosa al hincapié que siempre intenta hacernos creer Apple de que el usuario final es estúpido, y que tienes que ser un experto para usar los productos de la competencia)

 

“We have invented the toilet, and have patented hole in the toilet, water in a hole and seating! Other manufacturers shamelessly stole our ideas!”

“Hemos reinventado el inodoro, hemos patentado el agujero de este, el agua en el agujero y el asiento!! Otros fabricantes sin vergüenzas robaron nuestras ideas!”

(Nota: De nuevo un guiño sobre el mata mata de estar diciendo todo el tiempo que ellos lo han inventado todo porque simplemente el sistema de patentes Americano es cuanto menos absurdo. Guiño a la guerra de patentes que mantiene en ciernes ahora mismo Apple contra todos los demás simplemente porque es incapaz de sacar ellos mismos un buen producto. No nos engañemos, las patentes por las que denuncian a HTC, Samsung y otros no son patentes tecnologías de primer nivel, son patentes tan absurdas como la posición en la que se encuentra un conector e historias similares la gran mayoría, que no todas. El propio congreso de EEUU se está replanteando por fin si el modelo actual de patentes es o no convenientes)

 

“Please help promoting iPoo Toilet with poster above and a link to this website, since we can not yet afford financing appearance in movies featuring famous actors using our toilet…”

“Por favor, promueve nuestro inodoro iPoo enlazando nuestra web, dado que nosotros no podemos afrontar la financiación de este para su aparición en películas en las que aparezcan actores famosos usando nuestro inodoro..”

(Nota: De nuevo para mofarse del exagerado márketing que hace Apple para colocar todos sus productos en series, películas, spots… no es que en esas series o películas sus personajes queden mejor o peor por estar cerca de un producto de Apple, es que Apple paga millonadas para que sus manzanas aparezcan en los primeros planos de estos. En algunas ocasiones esta publicidad es exagerada a unos niveles hasta molestos, en los que no pasan 3 escenas sin que se vea por un lado o por otro algún producto de ellos).

Hay que reconocer que cuanto menos este Milo es original ;) .

 

Feliz Año nuevo a todos!!

Entradas relacionadas:

  1. iBluetooh: De pago en Cydia, pero al menos implementa OBEX
  2. Nuevos iMac: Paga el doble por tener una manzana pegada o paga lo mismo por tener algo infinitamente inverior. Lo caro no es siempre lo mejor.
  3. Nuevos MacBook Air = Vuelve a pagar el doble por menos

Feliz Navidad y Prospero Año 2012

 

Cuando llegan estas fechas lo primero que no dejo de decirme una y otra vez la suerte que tener una vida en la que puedo vivir con comodidades, con salud, con amigos, familia… poder compartir estos días con esas personas que quiero o incluso cantar desafinadamente algún que otro villancico popular para reírnos un poco. Pero doy las gracias porque por desgracia incluso muchos de los que puedan leerme no cuentan con esa suerte de un modo u otro, somos privilegiados. Por eso, como he dicho otros años, lo único que podría desear de corazón en estos mágicos días es que pudiese compartir con todos aquellos que lo necesitan ese trocito de felicidad o esas palabras amigas para a quienes les faltan… y por encima de todo la salud que nos hace levantarnos cada día de la cama y comenzar un nuevo día.

Por desgracia las Navidades se tienen por fechas para disparar el consumismo, ya sea en caprichos, en grandes comilonas, bebidas… no digo que no sea una forma también de vivir estos días con este tipo de ilusiones!! A todos nos gusta recibir una postal navideña de un lejano amigo, un regalo de nuestra pareja, una buena comida…. Pero siempre hay que ser un poco consecuente, tan malo es no disfrutar (los que puedan) como el consumismo absurdo y desenfrenado que muchos otros exhiben. 

 

Personalmente el año 2011 ha sido de cambios, y he sido feliz afortunadamente. Solo espero que este sentimiento sea compartido por todos vosotros y que el año 2011 os haya dejado un buen sabor de boca, o al menos que hayamos sabido extraer de él todo lo bueno y nos quedemos con ello. Solo espero que este nuevo  año que pronto empieza pueda ser al menos tan grato como lo fue para mí el 2011, que podáis (y pueda por supuesto) cumplir los sueños y expectativas que podamos tener, que podamos aguantar con buena cara y el mejor humor para cualquier complicación que se nos ponga por delante.

 

Sé que he estado alejado de las letras unas semanas, pero prometo retomar todos los proyectos que aun quedan en ese saco (mi cabeza), y estoy seguro que aparecerán otros muchos otros. Sin más, daros mis más sinceras felicitaciones de estas Navidades, desearos feliz Año a todos, daros las gracias a todos!! mis lectores de siempre y también los nuevos. Os dejo con una preciosa canción del gran Silvio Rodríguez.

Nos veremos pronto amigos, paz y amor.

Theliel.

 

 

Entradas relacionadas:

  1. Feliz Nochebuena y Feliz Navidad a todos
  2. Feliz Navidad amigos mío :)
  3. Feliz Navidad amigos mío :)
  4. Feliz Navidad para todos
  5. Navidad: ¿Un sentimiento o una imposición? Y otros.

Samsung Nexus Vs iPhone 4S: Hardware, Software, Medios de comunicación…

Vamos a intentar dejar de lado todas las redencillas actuales sobre lo bueno o malo que son uno y sobre lo bueno y malo que son otros, y vamos a intentar ser totalmente objetivos con los dos modelos más comentados estos días, ya que gracias a las “casualidades” de ambas compañías hace que tanto Apple como Samsung+Google hayan estrenado terminales los mismos días. En realidad el Samsung Nexus se retrasó precisamente por el fallecimiento de Steve Jobs por respeto (o eso dicen). Pero no solo los dos estrenan terminales (supuestamente los más avanzados que disponen), sino que ambos estrenan versión nueva de su sistema operativo (Android 4.0 en caso de Google, iOS 5 en caso de Apple). Así que es perfecto para poner cara a cara el uno contra otro y ver que de verdad o que de mentira hay  en todo lo que los medios nos inunda estos días.

Esencialmente hay tres puntos fundamentales para comparar estos dos productos:

  • Hardware (incluyendo diseño, dimensiones, peso…)
  • Software
  • Marketing

 

Hardware

No es la cara más visible del terminal, pero en cambio es el responsable de todo lo que ocurre con él. Como decía un viejo profesor de la universidad en plan jocoso, el hardware es a fin de cuenta todo aquello que podríamos pisar… claro que en un terminal en el que todo está totalmente integrado sería complicado…

Los terminales actuales son en su arquitectura “simples”. Son algo así como unos mecanos de alta tecnología, en realidad no tan diferente a como funciona un PC: Un procesador principal, un sistema de memoria principal y secundaria, un sistema de entrada y salida. Prácticamente cualquier SmartPhone se compone de los siguientes elementos, que como he dicho se podrían ver como simples piezas de lego:

 

-Un procesador central: Soportará prácticamente la carga completa del sistema operativo que se ejecutará en el terminal, por tanto será a priori (dentro del harware) el máximo responsable de la rapidez del sistema.

-Un procesador de comunicaciones auxiliar: Conocido generalmente como Baseband, es un segundo procesador que está diseñado para soportar el grueso de todas las comunicaciones móviles del terminal. Es decir, podríamos verlo como la pieza que realmente hace que un terminal Android sea un teléfono móvil en sí. Por tanto su importancia es esencial, de el depende por ejemplo cosas tan simples como la cobertura en conjunto con la antena, con los protocolos de comunicación de las redes móviles, con la rapidez con la que podemos navegar por las redes móviles… incluso el enviar un simple SMS depende de este procesador.

-Memoria Principal: Es decir, RAM, es decir, el lugar donde estarán los datos que se estén manejando, ya sean datos que se leen/escriben el propio código que se ejecuta. A más RAM podemos ejecutar potencialmente más aplicaciones a a la vez y trabajar con más cosas y más pesadas

-Memoria Secundaria: Es decir, el almacenamiento masivo, ya sean Discos Duros convencionales, SSDs, SDs…

-Periféricos de Entrada/Salida: Que es lo que permiten comunicar con el exterior, desde la propia pantalla táctil, adaptador WIFI, puertos USB, cámara de fotos, radio, BT, acelerómetros….

 

Con esto en mente, es mucho más simple hacer una comparativa de Hardware, y además, saber exactamente que es lo que se está comparando con qué:

 

-Procesador

Aunque ambos terminales usan un procesador de doble núcleo ARM Cortex-A9 MPCore (El de Apple fabticado por Samsung, Texas Instrument el fabricante del procesador del Samsung Nexus… y sí, es paradógico), el procesador del Samsung Nexus es evidentemente superior. Ambos procesadores usan NEON y otros juegos de instrucciones para hacerlos más eficiente, lo que hace que marque la diferencia a priori la velocidad de su reloj, 800MHz en el caso dele A5 (el procesador de Apple), 1.2GHz en el caso del procesador OMAP4 (el procesador de Samsung). Eso hace una diferencia de hasta 400MHz, la mitad del reloj del A5!! Es cierto que el procesador A5 en el iPad2 está fijado a 1GHz, lo que nos dice que Apple habría disminuido la vleocidad de reloj con el fin de obtener un menor consumo. Lo que sucede es que en el caso del procesador OMAP4460 sucede lo mismo, siendo la frecuencia máxima 1.5GHz. La diferencia es que bajo Android no resultaría complicado hacer que el reloj del OMAP4460 desplegase todo su potencial. ¿Cuanto es necesario? Depende de las aplicaciones que corramos evidentemente.

En el adaptador de video sin duda alguna el ganador sería Apple. Desde hace tiempo Apple ha puesto un gran interés en que sus dispositivos estén preparados/dotados gráficamente más que la competencia. Esto tiene sentido si tenemos en cuenta el uso mayoritario que se le da a estos terminales… Jugar. Gráficamente hablando, el A5 sería más o menos el doble de rápido a la hora de gestionar gráficos!! que no es poco ni muchísimo menos. Personalmente creo que se podría haber usado un procesador OMAP4470 que posee un rendimiento gráfico mejor, pero bueno… tampoco significa que gráficamente el OMAP4460 sea inservible ni mucho menos!! solo quiere decir que en este apartado es bastante inferior.

La RAM… este es un tema delicado que a Apple no le gusta tocar, y la prueba de ello es que mientras que no tiene reparos en decir que ha cambiado el procesador o la velocidad de este, sí que tiene mucho reparo en decir la RAM de sus dispositivos. El Samsung Nexus duplica la RAM que posee el iPhone 4s, el cual sabemos que posee 512 MB porque se ha desmotado y mirado. El tema de la RAM también es incómodo por parte de Apple porque hace que uno se haga preguntas un poco incómoda para ellos. Como siempre la RAM solo beneficia cuando se necesita. Muchos se han preguntado cual es el motivo por el cual Android siempre suele llevar más RAM que iOS, lo cual tiene dos explicaciones muy simples.

la primera explicación es que simplemente iOS se queda corto. Esto lo saben bien aquellos que usaban un iPhone con 256MB, en los cuales tan solo hacía falta abrir 3 pestañas en el navegador para que la RAM quedase frita del todo. 512MB resuelve este problema, pero no permitiría trabajar con agilidad a iOS si fuese multitarea… que es el segundo gran problema de iOS… no es multitarea. Al no ser multitarea los requerimentos de RAM son sensiblemente inferiores en igualdad de condiciones, pero claro… tienes el problema de que no es multitarea. Muchos creen que sí alegando que pueden “minimizar” aplicaciones y ejecutar otras, o que pueden escuchar música u otros servicios simultaneamente. Esto es solo cierto en parte. iOS permite ejecutar simultaneamente ciertos servicios como la geolocalización, música, voIP, notificaciones Push… pero nada más. Cuando un usuario sale de una aplicación, esta se congela, se detiene su ejecución!! En caso de Android no sucede esto, la aplicación diseñada para funcionar de fondo continuará ejecutándose aun cuando no esté en primer plano. Eso es lo que provoca que innumerables aplicaciones de iOS tengan que hacer uso de las notificaciones push, que hacen que el usuario invoque/reanude la aplicación en cuestión, mientras que en Android la aplicación simplemente está ejecutándose todo el tiempo: WhatApps, el tiempo, bolsa, redes sociales… todo trabaja en tiempo real.

 

-Pantalla

Si en algo sobresale con gran diferencia Samsung a toda la competencia es la pantalla… y en este caso no ha sido menos. En este aspecto destroza todas las especificaciones de Apple, exceptuando una diferencia de 11 dpi. La cuestión es que las pantallas son totalmente diferentes. Para empezar, Samsung ha montado una pantalla curva de 4.65 pultadas!! (demasiado desde mi punto de vista), mientras que Apple ha optado por una de 3.5. Evidentemente esto hace que el tamaño del Samsung sea superior. El asunto sobre si es mejor una pantalla más grande o más pequeña es cuestión de gustos. Para mi 4.65” sea quizás excesivo, otros lo verán como una exquisitez. Eso sí, la curvatura de la pantalla es cuanto menos hermosa.

Por otro lado tenemos la resolución, que junto al tamaño de pantalla conforman la densidad de píxeles. Apple siempre ha asegurado y defendido que su pantalla era la mejor por ser una pantalla “retina”, es decir una pantalla con una definición al menos igual a la que puede captar el ojo humano. Apple ya aseguró que este valor era de 300 dpi, y que por tanto cualquier pantalla por encima de este umbral sería una pantalla “retina”. Bueno, técnicamente hablando dicho por científicos y no yo ese umbral sería en realidad 400 dpi y no 300, pero esto en realidad no es algo siquiera interesante. Que tiene que ver la resolución con esto? Para mantener una densidad de píxeles adecuada es necesario aumentar la resolución de la pantalla al aumentar su tamaño, de lo contrario la densidad cae. Este posiblemente es el echo que hace que Apple no haya implementado una pantalla mayor. Es decir, si Apple hubiese optado por una pantalla de por ejemplo 4” y hubiese mantenido la misma resolución, posiblemente no alcanzaría los 300 dpi de los que tanto habla, y por tanto no podría llamarla pantalla “retina”. Además, aun cuando hubiese montado una pantalla mayor aumentando en consecuencia la resolución de la pantalla para conservar sus 326 dpi, habría provocado también un aumento en los requerimentos del sistema, no es lo mismo manejar 614.400 píxeles (los del iPhone 4s) que 921.600 (los del Samsung Nexus)!! es decir, que el Samsung Nexus posee un 50% más de píxeles que el iPhone 4s, y esos píxeles hay que manejarlos. Dicho esto, mientras que el iPhone 4s alcanza una profundidad de 326 dpi (nada despreciables), el Samsung Nexus llega hasta los 315 dpi, luego según el número mágico de Apple también sería una pantalla retina!! sin olvidar ese 50% de píxeles de más que posee.

Algunos dicen que la calidad de la pantalla de este terminal en realidad no es tan alta, y aseguran que aunque posee una gran densidad de píxeles, esto es por usar una matriz PenTile para la organización de los subpíxlees (y con ello la generación de los píxeles en la pantalla). La teoría que hay detrás de esto es que el color de cada píxel en la pantalla en realidad está generado pr un cierto número de subpíxeles más pequeños. En una matriz convencional RGB, lo normal es que un pixel obtenga el color por el mezclado de 3 subpíxeles que posee (Rojo, Verde y Azul). Visto este pixel desde una cierta distancia, la intensidad de los 3 subpíxeles se mezclan para el ojo humano dando color al pixel que es mostrado en la pantalla. Si quisiesemos ver los subpíxeles en realidad sería posible, pero necesitaríamos usar un microscopio posíblemente o una buena lente de aumento. Pues bien, las matrices PenTile optan en realidad por usar dos subpíxeles en vez de tres para obtener el color del pixel. Esto no quiere decir que ahora el pixel no contenga una componente verde roja o azul, sino que el tercer subpixel se obtiene por interpolación del subpixel vecino. Esto hace que sea más sencillo poder tener una densidad de píxeles superior, dado que los subpíxeles que se suprimen (cada pixel pasa de tener 3 subpxel a 2) se usan para añadir nuevos píxeles a la pantalla. Es decir, el patrón para dos píxeles en una matríz RGB sería RGB-RGB, pero par auna pantalla PenTile sería RG-BG, ahorrando dos subpíxeles en cada pixel y obteniendo la tercera componente del pixel siguiente. Es aquí donde entra ahora la batalla sobre si las pantallas PenTile logran o no una gran exactitud del color o no. Es cierto que la precisión del color es menor, pero tb es cierto que en este caso concreto hablamos de poseer un contraste de 100.000:1, lo que hará que por regla general la precisión de color sea infinitamente suprior a la pantalla Retina de Apple. Es decir, el que la pantalla Retina de Apple posea un contraste 800:1 es mucho peor que poseer una matriz PenTile y un contraste de 100.000:1.

Otro aspecto muy interesante y que parece que se olvida muchas veces es el contraste de la pantalla. Muchas veces la gente tan solo se preocupa de la definición de la pantalla, lo pequeño o grande que es el punto en la pantalla a fin de cuentas, pero no la fidelidad con la que el color se expresa. La pantalla renita de Apple posee un contraste de 800:1, mientras que la pantalla HD Super AMOLED de Samsung posee un contraste de 100.00:1. No es una errata, un contrate de más de 100 veces superior. Esto implica que los colores que salgan de dicha pantalla son infinitamente más reales.

Por último, tenemos que citar el tiempo de respuesta de la pantalla. Este valor empezó a tomar interés sobre todo para los gamers y aficionado a deportes de acción rápida como el futbol, carreras… hace unos años este valor se miraba con lupa, buscando siempre pantallas que rondasen los 4 ms. ¿Pero que mide este dato? Simple, la velocidad con la que un pixel en la pantalla se puede apagar y enecnder de nuevo, es decir la rapidez con la que un pixel puede pasar de un color a otro. Y esto es importante? Lo es y mucho, aunque depende sobre todo que veamos en la pantalla. El principal problema que causa un tiempo de respuesta alto es el temido efecto Ghost o efecto fantasma, que hace que cuando se está ante una animación de cierta velocidad se produce una estela que va dejando lo que se va desplazando. Un ejemplo tonto es pensar en una carrera de coches. Pues bien, si el coche pasa a una velocidad alta por delante de una pantalla con un tiempo de respuesta alto puede hacer que a su paso vaya dejando una “estela” similar al desenfoque. Para un gamer, 25 ms sería un tiempo de respuesta totalmente inadmisible, igual que para cualquier gran aficionado a carreras de coches o similar. Evidentemente este efecto no se va a observar al cambiar de ventana, pero sí es cierto que en ciertas aplicaciones, vídeos y juegos se obtiene la impresión de que va lento. Y esto es debido a este tiempo de respuesta. En el caso de Apple es de 25 ms (un valor muy alto), mientras que en el caso del Samsung Nexus es de 0.01 ms (un valor muy bajo), lo que hace de nuevo la pantalla del Samsung Nexus una obra de arte.

 

-Almacenamiento

Llegado a cierto límite, personalmente pienso que no es importante el almacenamiento. Cuanto es este límite? Hombre, depende de cada usuario, para mí con 16GB tengo sobrado para un terminal Android, otros dirían que necesitan 32 GB, otros 64 GB y otros más aun. En cuanto almacenamiento interno se refiere, el iPhone 4s llega en 3 versiones diferentes a elegir, 16, 32 y 64 GB, mientras que Samsung ha optado tan solo por modelos de 16 y 32. Cuando hablamos de este tipo de capacidades, es evidente que no se requieren para aplicaciones del tipo que sea, sino almacenamiento masivo para vídeo, audio, imágenes, documentos…  una vez más, cuanto sea necesario o no tan solo es cuestión del uso que le de cada uno.

Sobre microSD? No está claro del todo si el Samsung Nexus tendrá o no soporte para uSD dado que en la presentación no se conoció este dato. Una ranura uSD siempre es positiva ya no solo para aumentar el almacenamiento del dispositivo (que también), sino porque dota al dispositivo con un elemento más de entrada/salida. Habrá que esperar a la venta del terminal o a unas especificaciones más detalladas para conocer esto, mientras tanto solo podremos teorizar.

 

-Comunicaciones

Tener un teléfono móvil en el que las comunicaciones sea un punto débil sería un tonto ridículo por supuesto. Tanto es esto que en los últimos meses se ha abierto un acalorado debate sobre a que generación pertenece un dispositivo en concreto. La mayoría de usuarios si se les habla de 3G todo saben que es, o al menos se hacen una idea. No obstante 3G se usa a día de hoy de forma minoritaria, y casi el 100% de terminales que se venden a día de hoy son de tecnología 3.5G, es decir, usan redes HSPA. Esto lo sabrán algunos por el icono diferente que muestra nuestro terminal a veces, en el que a veces aparece el viejo GPRS (2G), el clásico 3G (UMTS), el HSPA (3.5G). El problema de estas estas siglas es que par aempezar es fácil mezclarlas unas con otras dado que no existe en realidad un 3.5G o que algunas tecnologías como GPRS puede usarse tanto en 2G como 3G. Y para colmo de males tenemos algo aun peor: El marketing de cada compañía.

Esto hace que cojamos un catálogo de móviles y veamos móviles que ponen sin duda alguna que son 4G por usar la tecnología HSPA+ (un paso por delante de HSPA). El problema es el mismo, HSPA+ es la antesala de 4G, pueden existir terminales HSPA+ que pueden ser considerados 4G y otros que no. Esto es así dado que para usar por ejemplo una red HSPA+ no es necesario cumplir absolutamente todas las características de un modelo 4G real, pero en cambio HSPA+ es usado por supuesto en redes 4G. A estos terminales como los llamaríamos por tanto? Por supuesto el márketing hace que si se puede conectar a una red HSPA+ implica que es 4G.

En esta comparativa vemos claramente este comportamiento. Por un lado el iPhone 4s nos dice que la velocidad máxima que alcanza en redes móviles es de 14.4/5.8 Mbs , aunque se indica que es compatible con HSPA+. El problema es que en realidad el estándar HSPA+ comienza con 21 Mbs para descarga y no 14.4. Esto quiere decir que aunque supuestamente puede conectarse a redes HSPA+ y por tanto posee algunas características de este estándar, no posee otras tantas, y que se comporta a fin de cuenta como si estuviese en una red HSPA.

Al otro lado tenemos el Samsung Nexus, el cual se suministra en dos versiones diferentes. Por un lado la versión HSPA+ que hace que sea un terminal 4G real, alcanzando tasas de descarga de hasta 42 Mbs!!. Y para aquellas redes compatibles, se suministra la versión LTE, una tecnología puramente 4G, con el que el terminal puede obtener unas tasas de 100 Mbs de descarga y 50 Mbs de subida. A esto se refería Google con ser el primer terminal realmente 4G, mientras que el iPhone técnicamente sería un terminal 3.5G, como casi la totalidad de los terminales.

 

-Cámara

Soy de los que opina que si quieres hacer fotos de calidad tengas una reflex, pero es cierto que disponer de una cámara en tu terminal te es infinitamente útil en cualquier momento en el que buscas la foto rápida. Mas aun, en los ultimos meses años se le ha dado un uso infinitamente superior a las cámaras, y no precisamente como meros dispositivos para hacer fotos. Por ejemplo, usamos la cámara para realizar búsquedas según el contenido de la imagen con Google Goggles por ejemplo, o buscamos productos con los escáneres de códigos de barras/QR. Incluso como veremos más adelante, ya podemos usar la cámara hasta para reconocimiento facial. Esto por supuesto no quita el uso principal que es fotos y vídeo, pero si es un modo de usar la cámara para otros propósitos.

En este aspecto ha sorprendido a priori que Samsung implementase una cámara trasera de “solo” 5MP, teniendo en cuenta que prácticamente la totalidad de terminales de última generación usan 8MP, como pueda ser el ejemplo del iPhone 4s. Pero empecemos por la cámara delantera, esa cámara que usaremos principalmente para hacer videoconferencias. Si disponemos de dos cámaras y una de ella diseñada especialmente para video conferencia, como es natural no necesitamos que la cámara frontal sea ni de lejos tan buena como la trasera con ser capaz de captarnos más o menos bien a una resolución aceptable es suficiente (siempre desde mi punto de vista). Aquí Apple hace uso de esta filosofía, una cámara VGA es más que suficiente para esta tarea. Aquí tengo que indicar que me ha sorprendido ver como en algunos lugares se asegura que la cámara es de 0.9MP, es decir que posee una resolución máxima de 1280 x 720. El problema es que las propias especificaciones de Apple rezan “VGA” y por definición VGA es 640 x 480, es decir, 0.3 MP. Samsung por su lado ha optado con una cámara frontal bastante superior, de 1.3 MP (1280 x 1024), capaz por tanto de grabar vídeo en HD ready si fuese necesario o realizar vídeo conferencias en HD, cosa que el iPhone 4s no podría de modo alguno.

La cámara trasera es otro cantar muy diferente. En este aspecto cada compañía ha optado por filosofías diferentes. Evidentemente Samsung podría haber incluído una cámara de 8MP, y posiblemente su coste habría sido inferior que la cámara que al final han optado a montar. Apple aquí ha preferido poder capturar más píxeles, mientras que Samsung ha optado por unas prestaciones superiores. El mejor ejemplo de esto lo tenemos cuando Apple anuncia que su cámara de 8MP será ultra rápida, tardando solo 1.5 segundos en captar la primera fotografía, siendo de 0.5 el tiempo necesario para las siguientes. Estos datos son bastante buenos, pero es aquí donde aparece Samsung para dar una lección anunciando su Zero Shutter lag, es decir, que teóricamente no existe retraso en captar la foto desde que se presiona el botón hasta que se captura. No sé si esto se entiende, en este terminal nada más presionar el disparador de foto la foto se captura e inmediatamente puedes darle otra vez. Esto fue mostrado ante todos los que acudieron a la presentación del terminal y sinceramente fue bastante impactante, ver como el operador realizaba diferentes fotos a gran velocidad, en la que hacía un movimiento rápido y disparaba otra, y otro movimiento rápido y otra y otra… casi con toda posibilidad este comportamiento no habría sido capaz de realizar con una cámara de 8MP. Pensar que cuantos más definición (MP) tenga la cámara, mayor procesado tendrán las imágenes, la electrónica, la transferencia de los datos…

Si pudiese escoger me quedaría con las dos opciones, una gran resolución y un tiempo de respuesta de cero. Pero esto no es posible. Cada cual que opte por lo que prefiera.

Por supuesto, al margen de esa interesante función, ambas cámaras son capaces de grabar en FullHD (1080p) a 30 fps, implementan una mayor sensibilidad para entornos de baja luminosidad y otros.

 

-Sensores

Si bien es cierto que los sensores no son imprescindibles, algunos se han asumido tan naturalmente que en realidad sí lo son. Es el caso del acelerómetro, dispositivo que hace unos años sería imposible siquiera su fabricación en los tamaños actuales. Otros sensores como los de proximidad permiten a nuestros dispositivos por ejemplo apagarse o encenderse dependiendo de la proximidad a nuestro cuerpo (para apagarse cuando lo tenemos en la oreja por ejemplo), otros como el sensor de luminosidad permite establecer el brillo a unos niveles adecuados en función de la luz que exista en el ambiente… Más tarde nos llegó la brújula digital, después el giroscopio, y hace un año Google nos mostró las capacidades potenciales de NFC (Near Field Communications).

En realidad NFC es más un dispositivo de comunicaciones que un sensor, ya que no es más que un dispositivo que permite cambiar datos con otro dispositivo a distancias muy cortas. En principio puede parecer no tener ningún tipo de valor, a fin de cuenta ya disponemos de BT o WIFI. En cambio la filosofía es muy diferente, es un dispositivo que no requiere prácticamente alimentación alguna, y la prácticamente nula distancia para transferir los datos lo hace especialmente útil a la hora de realizar por ejemplo pagos electrónicos insitu o transferir datos a otros dispositivos de forma rápida y sobre todo simple, sin necesidad de emparejamientos ni historias. Google comenzó a implantarlo y soportarlo en Android con la idea en mente de que fuese con los años en el sistema de pago universal que sustituyese en gran parte el dinero de bolsillo, ya que es rápido, cómodo y seguro. No obstante como todas las tecnologías emergnetes requieren años de implantación, y lo que es más importante, que las personas se habitúen a ellos y les sea realtumente útiles. Google ya lo implementó en Nexus S, y Samsung no ha sido menos en el Samsung Nexus. Por el contrario, Apple no hizo lo mismo con su iPhone 4s, porque en palabras del propio Jobs, no era una tecnología muy probada o extendida. Este echo contrasta radicalmente con los comentarios que estamos acostumbrados a escuchar de Apple: “Nosotros innovamos” “Usamos la última tecnología…” Básicamente cuando la competencia innova o son los primeros en usar la tecnología X, los otros tienen que salir diciendo que la tecnología que se está usando no está probada o no es buena. Esto no quiere decir que actualmente vea demasiado futuro en NFC a corto plazo, aunque esto es algo que Google se ha dado cuenta y ya le está dando un uso muy diferente a NFC, que es el de compartir.

Por otro lado tenemos como novedad en el Samsung Nexus un barómetro. Sinceramente no termino de entender bien este sensor. Sí, no hablo de que no sepamos que es un barómetro, sino que la única aplicación prácticas que se me pueda ocurrir ahora mismo sería la de funcionar como altímetro. No digo que sea inútil, ni mucho menos, estoy seguro que para un buen sector el poseer un altímetro en su terminal da lugar a un buen sin fin de posibilidades!! por ejemplo no solo registrar tu ubicacion en 2D, sino en 3D. Un GPS en teoría debería de ser capaz de calcular la altitud, pero un altímetro debería de ser más preciso. Estoy seguro de todos modos que más de uno tiene algunas buenas ideas en mente, no dudo que los ingenieros de Google/Samsung habrán pensado en no pocas aplicaciones prácticas. Eso sí, personalmente no le veo ahora mismo mucha utilidad, quizás cuando vea aplicaciones prácticas cambie de parecer.

De todos modos es evidente, cuantos más sensores tengamos mejor, antes o después pueden hacernos falta, o al menos poder tener más funcionalidades. En el caso de Apple tampoco integra un barómetro evidentemente.

 

-Dimensiones

No podemos comparar anchura y altura dado que son terminales con pantallas de diferentes tamaños, luego es evidente que las dimensiones citadas son mayores en el Samsung y menores en el de Apple. Ya lo he dicho, creo que 4.65 es quizás demasiado, y 3.5 se quedaría corto. Para gustos colores

El grosor y el peso en cambio es otro cantar y una sorpresa agradable, el Samsung Nexus no solo es más fino que el iPhone 4s, sino que además pesa menos. Si tenemos en cuenta que el terminal es bastante superior al de Apple, podemos decir que sencillamente impresiona.

 

-Batería

Sería interesante conocer los datos de la batería del Samsung Nexus, pero pro desgracia este dato es totalmente desconocido por ahora, así que habrá que esperar a tener el terminal en las manos para conocer como de bien o mal se comporta en cuanto a su consumo. Por descontado que una pantalla tan grande debería de tener un consumo sensiblemente superior, pero nunca deberíamos subestimar a los ingenieros de Samsung y lo bien que hayan podido hacer los deberes. Como digo habrá que esperar.

 

 

Software

El hardware es importante sin duda alguna, pero sin un buen software que gestiona cada parte de dicho hardware, haría de este totalmente inservible. Tan importante es el hardware como el software, y siempre deben de ir de la mano. En el momento que uno va adelantado del otro hay problemas. Si el hardware es capaz de más y está limitado por el software estarás desperdiciando recursos y si el hardware es capaz y el software no lo administra como es debido estarás igualmente desperdiciando recursos.

Tanto el iPhone 4s como el Samsung Nexus aparecieron no solo como terminales nuevos, sino como buques insignia de los nuevos sistemas operativos: iOS 5.0 y Android 4.0

Por parte de Apple, iOS 5.0 podrá ser instalado en cualquier iPhone 3GS, iPhone 4 ó iPhone 4S, quedando el iPhone original y el iPhone 3G fuera. Por otro lado, algunas capacidades como SIRI tan solo estarán disponibles para el iPhone 4S. Por parte de Google Android 4.0 no debería de tener limitación estricta de hardware, y cualquier terminal que corra Honeycomb, Gingerbread, o Froyo no debería de tener problemas con hacer correr Ice Sream Sandwich (ICS), aunque sí dependerá más del fabricante de cada dispositivo. Como vemos, en realidad es totalmente falso cuando se esgrime la fragmentación de Android como un punto por debajo de iOS. Por mucho que Apple quiera decir, la misma fragmentación sucede en sus propios dispositivos pero aun con más saña, ya que tecnológicamente hablando, el iPhone 3GS no debería de tener problemas de hacer correr SIRI con total fluidez, o enviar MMS desde un iPhone original, o poder poner fondos de pantalla en un iPhone de 128 MB. En caso de Apple la limitación la ponen ellos, en caso de Android la limitación la suele poner el fabricante de cada terminal, pero a fin de cuentas es igual. Así pues, cuando aparezca a lo mejor el iPhone 5 se deja de soportar en las nuevas actualizaciones al iPhone 3GS simplemente porque sí.

Para comparar iOS con Android haría falta todo un artículo tan solo para ello, y no es sinceramente la idea. Veo más útil comentar las nuevas funcionas que implementan ambos terminales en comparación con sus versiones anteriores y cruzándolas unas con otras, sin pararnos demasiado en ellas puesto que sino sería eterno:

 

Android 4.0

Fragmentación: Con Android 4.0 se pone fin a la fragmentación entre Tablets y móviles, haaciendo que tan solo exista una sola rama de Android, un solo SDK para los programadores. Será el OS el que se adapte perfectamente a uno u otro.

Nueva Fuente Roboto: Android 4.0 cambia la fuente (tipografía del sistema) por una propia llamada Roboto diseñada específicamente para terminales portátiles que sea cómoda de leer y sencilla. Además, es también una buena forma de evitarel uso de cualquier tipografía que pueda estar sujeta a patentes e historias. Yo la he probado (se puede descargar ya que está incluida en el SDK de Android) y la verdad es algo más clara y cómoda de leer que la anterior. Ahora mismo no se cual es la fuente por defecto que usa Apple, y aunque lo supiese es una cuestión meramente estética y dependiente de cada usuario. si es cierto que el usuario de Android tiene la opción de modificar la fuente de forma simple cuando quiera.

Remodelado de las Carpetas: De siempre ha sido posible crear carpetas en Android, pero con Android 4.0 la cosa es bastante más simple y cómodo. Básicamente basta con arrastrar un icono dentro de otro para crear automáticamente una carpeta con el contenido X. Con iOS es posible las carpetas desde la versión iOS 4 si no recuerdo mal, y el sistema usado es más o menos el actual de Android pre 4.0

Multitarea remodelado: Android 4.0 cambia de forma sustancial el manejo de la multitarea y cambio de aplicaciones. De forma simple será posible invocar la lista de aplicaciones en ejecución o suspendidas y alternar de una a otra sin problema alguno, o por supuesto detener cualquiera de las aplicaciones en curso. Esta función por tanto es totalmente ajena a Apple, donde ni siquiera existe una multitarea real.

Notificaciones: Se permitirá la personalización de estas, así como acceder a ellas incluso en la pantalla de bloqueo, lo que quiere decir que será posible desplegar la persiana de notificaciones en bloqueo. Esta función se implementa de forma similar en iOS 5, el cual copia las notificaciones de Android, aunque de forma más cutre. Recordemos que en iOS las notificaciones no las lanzan las propias aplicaciones, sino el servicio push.

Face Unlock: Graciosa cuanto menos es la nueva funcionalidad para poder desbloquear el terminal con una sonrisa. La cámara frontal se podrá usar para desbloquear el terminal al instante, este reconocerá el rostro de su dueño y lo desbloqueará. Un buen sistema sobre todo cuando se requiere de un pin para ello. En iOS no hay nada similar a esto

Navegador: El navegador ha sido rediseñado, permitiendo la navegación por pestaña, el guardado de páginas para visualizarlas offline o el cambio de user-agent de forma rápida y simple. Las pestañas no se mostrarán como pestañas dentro del navegador, sino que será un desplegable el que nos permita seleccionar la pestaña en cuestión, y así maximizar el área de navegación. iOS 5 implementa funciones similares en Safari.

Gmail: La aplicación será remodelada para permitir un mejor control sobre las conversaciones, y otros. Evidentemente no hay equivalencia en iOS.

Calendario: Ha sido mejorado para permitir tanto el zoom como mayor facilidad a la hora de introducir cualquier evento. Pequeñas mejoras que tampoco son demasiado importantes la verdad, aunque cualquier cosa que sea para ir a mejor… Quizás el tema del calendario ha sido mejor hasta ahora en iOS, habrá que ver insitu como responde

Data Usage: Nueva herramienta de Android para controlar, gestionar, pintar… todo el consumo de datos! Personalmente creo que es un añadido casi esencial y útil. Consumo por aplicación, gráficas, límites, restricciones… personalmente indispensable. En iOS no existe nada similar, siempre hablando por supuesto de fábrica.

Cámara y Editor de fotos: Se añade un portentoso editor de fotografías que permite la aplicación de todo tipo filtros, opciones, recortes, ajustes… creación de panorámicas… de todo. Posiblemente incorpore en el propio sistema una de las mejores aplicaciones de retoque que hay en cualquier AppStore o Market. Si a esto le añadimos el Zero Shutter del Samsung Nexus… También se ha añadido la función de Time Lapse, que permite realizar fotografías cada X segundos y después recrear una animación más veloz a estas… lo que vendría a ser la función inversa de una cámara de alta velovidad.

Contactos: Se ha remodelado totalmente los contactos, añadiendo la aplicacion “Personas” que trata de ser un lugar donde centralizar todos los contactos con sus conexiones a las redes sociales. Recordemos que actualmente en Android se asocian a los contactos aquellos de cualquier red social, puese People lleva eso a otro nivel más, pudiendo incluso visualizar las actualizaciones de los propios contactos. En iOS no hay nada similar a esto, la integración de echo entre las aplicaciones del OS con las del AppStore es mínima

Beam: Al “sensor” NFC se le ha añadido la capcidad de ser usado como un sistema rápido de compartir datos. Basta con poner pegados dos dispositivos para compartir lo que sea. Por ejemplo, si un dispositivo está jugando al juego X y se le pega otro Android 4.0 con NFC y se permite Beam, en el segundo dispositivo se abrirá el market con la aplicación que se está ejecutando. Si se hace con un mapa el mapa será “transferido” al otro dispositivo. Si se hace estando abierta una web la web se abrirá en el otro dispositivo… etc etc. La utilidad está en que permite compartir un tipo de información que antes no era posible de forma simple y rápida. En iOS no hay nada similar a esto, ni siquiera soporte para NFC

Aceleración por Hardware de la Interfac: Personalmente una de las funciones que más se esperaba, usar el adaptador de video para acelerar los elementos de la interfaz gráfica. Es decir, ese poquito más de agilidad que parece que le falta siempre con iOS cuando nos desplazamos por los menús, cambiamos de orientación el terminal… a partir de Android 4.0 cualquier terminal tendrá aceleración por hardware de la interfaz. Apple ya implementaba esto desde las primeras versiones en iOS, al igual que también lo hace Windows Mobile.

Teclado/Edición: Se ha mejorado todo el teclado de Android, así como el copiado/pegado de texto. Ahora se puede insertar de forma rápida cualquier parte de texto, la trascripción de audio es prácticamente inmediata y el modo dictado permite ir transcribiendo en tiempo real. iOS permite también la edición de texto, aunque la transcripción a texto por la voz está muy lejos de parecerse a Android

 

 

iOS 5:

Centro de notificaciones: Las notificaciones Push han sido totalmente remodeladas para que sean infinitamente más cómodas de usar, ahora son mucho más similares a lo que son en Android. Por tanto hay que decir que guste más o guste menos, el nuevo centro de notificaciones es una burda copia a las notificacionese de Android, las cuales aun funcionan mejor.

iMessage: Es una aplicación nueva que curiosamente más revuelo a montado en los medios de comunicación en conjunto con SIRI, aludiendo de que iMessage será un SMS Killer. En realidad no me parece una mala aplicación ni mucho menos, es útil para comunicación iPhone <-> iPhone, pero no puede usarse más allá de iPhone, no puede usarse para comunicarse con equipos con Windows o MAC OS siquiera. Guste más o guste menos es una burda copia al Chat de BlackBerry. En android 4.0 (como en otras versiones) se incluye de forma integrada totalmente Gtalk, que permite la comunicación Android <-> Android Android <-> Cualquier dispositivo con Gtalk instalado o por web.  Galk no solo permite la mensajería instantánea, sino que ademas permite videollamadas sin problema alguno. No obstante, Gtalk no está diseñado de base para compartir otro tipo de información como Imágenes, localizaciones, vídeos, documentos… cuestiones que evidentemente han sido copiadas descaradamente de aplicaciones como WhatsApps, que sí es multiplataforma, y es por ello que iMessage carece totalmente de utilidad. si puedes escoger entre comunicarte solo con iPhones o con cualquier dispositivo…

NewsStand: Es algo así como una aplicación para gestionar y administrar suscripciones a noticias, revistas y otros. Básicamente es un expositor para vender suscripciones con los medios con los que Apple tiene acuerdos. Gracioso era el caso del Times (creo recordar que era el Times), que si intentabas acceder desde iOS a su web te decía que te suscribieses, y con usar cualquier otro navegador o user-agent podías ver perfectamente el periódico. En Android puramente no existe una aplicación similar (o yo la desconozco), aunque sí la he visto en el market propio de Samsung.

Recordatorios: Apple en iOS5 mejora el calendario para que sea más simple crear recordatorios. Una función cómoda sin duda alguna, aunque no pasa por más que simplemente citarla. En Android por defecto no existe ningún to-do list, aunque se puede usar el calendario perfectamente para ello. Por supuesto hablamos con el OS sin nada más instalado, por supuesto en el market hay de todo.

Twitter: Esta es una de esas funciones que hacen gracia. En iOS 5 Apple integra Twitter con el sistema, de modo que sea mucho más fácil compartir cualquier cosa con la cuenta de Twitter. Esto no solo no es una novedad sino que cualquier usuario de Android sabe que una de las cosas que hace Android precisamente lo que es, es su capacidad de poder compartir todo del modo más simple posible. En Android esto no solo sucede con Twitter, sino que sucede con Facebook, con Google+, con Flik, con… en cualquier carpeta, viendo cualquier imagen… en cualquier lugar podemos darle a compartir con… y directamente se envía a nuestras cuentas conectadas. Apple ahora lo hace solo posible con Twitter.

Cámara: Apple ha mejorado la cámara añadiendo el botón de cámara a la pantalla de bloqueo y permitiendo si se desea la sincronización con iCloud. iCloud lo explicaremos más tarde, pero de ya digo que no es un servicio en nube, sino un servicio de SINCRONIZACION, que es bien diferente. En Android por descontado se puede poner un botón de cámara de foto en la pantalla de bloqueo (y otros), sino que tampoco es una novedad el poder subir o compartir una foto de forma automática a la par que se hace, ejemplo de ello es Google+ y la función Instant Upload, que además es totalmente configurable para que tan solo se suban las fotos cuando se posee WIFI, que no se compartan, o que se compartan con indiferencia de que se esté en WIFI o redes móviles.

Edición de fotos: En iOS 5 se ha añadido un pequeño editor de imágenes que permite desde redimensionar y recortar la imagen, autoajustar los niveles de color y eliminar los ojos rojos. Por defecto en Android pre 4.0 esto no era posible, no obstante en Android 4.0 como veremos no solo se pueden realizar estos ajustes, sino que está a disposición un sin fin de posibilidades y filtros, desde panorámicas, filtros, recortes, ojos rojos, efectos…

Safari: Safari ha recibido una buena remodelación, permitiendo desde la navegación por pestaña como la posibilidad de guardar páginas para leerlas más tarde. Ambas funciones disponibles en Android 4.0

PC Free: Hasta ahora para poder usar cualquier dispositivo con iOS tenías que usar sí o sí un PC con iTunes instalado. Pues bien, co iOS 5 esto es así también, lo que sucede es que ahora puedes hacer la mayoría de las cosas sin estar conectado físicamente a él. Se permiten actualizaciones OTA y sincronización via WIFI, así como activar el terminal. En contrapartida hay que depender de Bonjour que tan solo trae dolores de cabeza, y tener en el equipo 4-5 procesos totalmente inútiles, y por descontado que no elimina la lacra de tener que usar sí o sí iTunes, posiblemente el peor programa que se ha creado jamás. Esto en Android no hace falta comparar… en el cual las actualizaciones OTA existen desde siempre, jamás se ha necesitado de un programa de forma obligada, y desde siempre ha sido posible la sincronización via WIFI. Es decir, Android si es totalmente PC-Free, pero no solo en cuanto a conectarlo se refiere, sino a que no depende de ningún programa ni limitación a la hora de transferir datos a él. Copiar una sola canción a un iPhone implica abrir iTunes, localizar la canción, añadirla a la biblioteca, sincronizar el dispositivo y por descontado que dicha canción no podrás acceder a ella directamente, solo desde el reproductor. En Android abres el explorador de arcivos, localizas la canción y la copias a la SD o al almacenamiento interno. En tiempo digamos que ahorras el 90%. Pero no solo eso, si te envían una canción por correo electrónico puedes descargarla y tenerla automáticamente en tu reproductor de audio, igual que las imágenes, vídeos, documentos… no es necesario un PC para nada si no se quiere.

 

iCloud

Dediquemos un espacio especial para iCloud. Es supuestamente un servicio en “nube” de Apple para tener tus datos en la nube. Pero realmente no es un servicio en nube, sino un servicio de sincronización masiva que permite compartir entre distintos dispositivos imágenes, documentos, la música de iTunes, calendario/agenda/correo, copias de seguridad, aplicaciones y libros. La idea de Apple es que si haces una foto desde un iPhone esta foto es enviada y descargada automáticamente en los demás dispositivos sincronizados con iCloud. Del mismo modo con la música que se tenga en el equipo en iTunes y tener acceso a ella desde iPhone. El problema de esta sincronización es que genera un ancho de banda enorme!! cosa nada práctica en dispositivos portátiles, los cuales suelen tener planes de precios para los datos dependiendo del consumo mensual, generalmente cortando el servicio de datos o ralentizando su velocidad o cobrando más cuando supera cierto umbral. Por otro lado es totalmente redundante a día de hoy usar ese servicio para correos/calendarios/agendas o las aplicaciones y libros, dado que esto ya era posible hacerlo antes sin necesidad de iCloud, con mucha más seguridad y con más control por parte del usuario… ya que estos datos no se sincronizaban entre dispositivos, sino qeu el dispositivo se sincronizaba con un servicio en nube (este si era en nube) como podía ser Gmail para sincronizar por IMAP o Google Sync el correo el calendario o la agenda. Igual que antes también se podía descargar cualquier aplicación desde el propio terminal. Lo que propone iCloud es que ahora tengamos que enviar primero los datos a nuestro iCloud, ¿y de ahí descargarse a cada uno de nuestros dispositivos? No era más simple que cada dispositivo solicitase sincronización con por ejemplo Gmail? Los datos no se tendrían que subir a ningún lado, simplemente descargarse de los servidores de Google.

Esto hace que iCloud nos deje tan solo de “nuevo” la sincronización de imágenes, copias de seguridad y documentos. Las copias de seguridad no tienen mucho sentido dado que cada dispositivo es diferente y son configuraciones únicas por dispositivo, en todo caso almacenar las diferentes configuraciones de cada dispositivo, lo cual tampoco es algo que sea nuevo, esto ha existido en Android desde siempre. ¿Y sobre imágenes y documentos? La idea no es mala sinceramente, pero tiene el principal problema que he citado: Ancho de banda. Un buen servicio en nube debería de almacenar en todo caso nuestros documentos pero no sincronizar a menos que fuese a petición, y por tanto automáticamente eliminaría el espíritu de iCloud. Imaginar el problema que resultaría en tener activado iCloud en un iPhone e irte de vacaciones a tu País y tienes activado iCloud para las imágenes por ejemplo (a fin de cuenta si crees que iCloud es bueno lo usas, sino evidentemente no lo usas). Haces una foto de 8MP? Subes una foto de 8MP (3264 x 2448) -> Acabas de consumir un ancho de banda de 2MB-3MB (depende de la compresión y calidad). Haces 10 fotos? Te acabas de comer 20MB-30MB en segundos. ¿Cuantas fotos puedes hacer en un viaje de 7 días? 20? 30? 40? Es decir, que es útil si haces una o dos fotos aisladas, si lo usas para hacer fotos estás frito.

¿Pero que decir de la música? Peor aun. En iTunes añades a iCloud un disco nuevo normalillo a 192 kbs? 50 MB. No digo que la idea sea mala, digo que actualmente es algo totalmente inadmisible teniendo en cuenta los planes actuales de datos. Además, no es algo realmente eficiente si tenemos en cuenta los verdaderos servicios en nube, los cuales generalmente se crean o suben una sola vez, servicios que realmente almacenan nuestros datos y se envían a nuestros dispositivos según sea necesario, ya sea una descarga completa del elemento en cuestión o una reproducción en Streaming, haciendo un uso infinitamente más eficiente de la red

 

SIRI

De nuevo algo que se escucha en todos lados, pero que no deja de ser más marketing que otra cosa. SIRI es la apuesta de Apple para luchar contra Google Voice Search. El concepto de SIRI es que teóricamente el terminal te responde de forma inteligente a las preguntas que se le hacen, por ejemplo nos permite realizar llamadas por comandos de voz, establecer una alarma… no está nada mal el sistema, aunque aun tiene muchas carencias. No es ni de lejos lo exacto y preciso que es Google Search Voice, no permite la gran cantidad de acciones que permite este último, tan solo está diposnible para el iPhone 4s (Google Voice Search para casi cualquier terminal Android) y tan solo está disponible para el idioma en ingles. En cambio no es nuevo para cualquier usuario de Android las capacidades de dictado de Android, el uso de la voz para ordenar acciones para llamar, redactar sms, escuchar música, realizar una ruta con el GPS… puede que para olos usuarios de iPHone esto sea algo revolucionario, para los usuarios de Android que llevamos años con ello es de lo más normal.

 

Marketing

Siempre he escuchado eso de que cuando un producto es bueno se vende solo. Cuando un producto intentan metértelo por los ojos yo desconfiaría de ello. Unos dicen que Apple es la mejor compañía del mundo haciendo márketing y promocionando sus productos… yo creo que hay rayas y sistemas que no se pueden tocar nunca.

Cuando Apple saca cualquier producto nuevo se forma un revuelvo mediático enorme, pero esto es fruto a la calidad y exquisitez de sus productos? Generalmente es fruto del márketing que muestra. Esto es muy simple de verlo, tan solo hay que ver en cada uno de los sitios en los que intentan meternos sus productos. Pensemos y tengamos en cuenta que aunque posean una buena tasa de mercado, esta es minoritaria!! Pensar que MAC OS no posee ni un 10% de cuota de mercado, y que hay más terminales Android que iPhone en el mundo!! por cada iPhone que se vende se venden más de 3 Android. Pero si esto es cierto… como es posible que todos hablen de sus productos?

 

-Medios de Comunicación

Podría poner montones de ejemplos de periódicos de tirada nacional y muy importantes en los que cada vez que Apple saca algo nuevo dedican durante una semana artículos tras artículos a dicho producto siendo todos totalmente partidistas y faltos de rigor. En cambio, cuando por ejemplo Google o Samsung saca alguna novedad mucho más importante y de mayor calado le dedican en todo caso un artículo descafeinado. Yo no puedo decir al 100% que estos medios cobren por hacer una publiciad a Apple, pero es más que evidente que cobren o no poseen un interés detrás de ello. Solo hay que ver la falta de rigurosidad total con la que son escritos o la avalancha de artículos que se hacen a raíz de ello. El Fair Play (Juego Limpio) no es algo precisamente que conozcan lso medios de comunicación.

Por qué me parece mal? Me marece mal porque un medio de comunicación tiene la labor de informar. Para dar la opinión ya existen los artículos de opinión, al igual que para la publicidad también existen apartados para tal. Pero escribir un artículo/noticia totalmente desvirtuado, exagerado e incluso engañoso de un producto una vez y otra y otra y otra… ya no es Apple la culpable, sino aquellso que se dejan comprar de modo que sean. Eso es lo que me parece bochornoso. Cuantos artículos se han publico en comparación en un diario como “El País” sobre Android 4.0 ó el Samsung Nexus? Y es porque tenga menos importancia? No, es que simplemente Samsung o Google no se gastan el dinero o lo que sea en ello.

 

-Series y Películas

Desde hace años y años… Apple usa el cine o las series de televisión para hacer una promoción incesante de sus productos. Es de lo más habitual ver en cualquier película en el que aparezca algún cerebrito cualquier producto de Apple. En algunas ocasiones incluso la publicidad es totalmente descarada y faltan dedos en las manos para contar el número de veces que se puede ver una manzana en todo el medio de la pantalla. Digo yo, si en realidad la penetración de MAC OS es tan baja… no es un poco curioso? De echo me planteo otra cosa… si realmente es tan buenos sus productos… porque intentan meterlos hasta en la sopa? Pero al menos esta práctica desde mi punto de vista si cumple las reglas del juego limpio (nada que ver con los medios de comunicación), y es promocionarse al igual que se pueda hacer en un anuncio. Que me parezca a veces totalmente desproporcionado es un hecho, pero al menos no se está mintiendo, tergiversando o rompiendo algunas reglas básicas.

 

-Anuncios

Por supuesto cada lanzamiento lleva consigo anuncios en horarios de máxima audiencia si es necesario en la televisión, en Internet, en la radio, en programas de televisión… en cualquier momento es posible escuchar un anuncio respecto a Apple por algún producto nuevo. Una vez más al menos esta práctica no es jugar sucio y cada cual se gasta el dinero en lo que cree. De nuevo me remito a lo mismo, cuando algo es bueno, simplemente lo es, y la mejor publicidad es la del propio producto.

 

-Acoso y derribo

Otra técnica de Apple, y esta totalmente fuera de juego limpio, se basa en varias técnicas. Primero, desprestigiar a toda aquella persona que no sea un fanático de Apple. O eres un fanático o eres idiota y no entiendes nada. O estás con ellos o contra ellos. Pueden aparecer en cualquier momento para decir cualquier comentario burla a cualquier producto de la competencia, se preocupan más en intentar hacer ver que lo demás es una porquería a que lo suyo es bueno. Si algo no funciona o está mal, la culpa no es de Apple, es del usuario o de la competencia. Y como esto un suma y sigue interminable.

 

Al final, lo gracioso es que al pasar los años uno puede ver realmente que es lo que sucede. Después de un lanzamiento de un iPhone nuevo vemos en las noticias que se han vendido en solo 24 hora millones de terminales y que todo ha sido un éxito… de echo cada año que pasa parece ser un éxito mayor que el anterior de número de terminales vendidos en 24 horas!! En cambio, cuando miramos la evolución del porcentaje de usuarios con iOS vemos que este prácticamente no se mueve!! Es decir, que el porcentaje de mercado que posee iOS permanece prácticamente invariable con los años. ¿Como es esto posible? Es simple, porq la mayoría de los compradores compulsivos son en su mayoría fanáticos de Apple, que posiblemente en su gran mayoría como ya se comprobó disponían de otros terminales iOS, y que simplemente continuaban la rueda que Apple les impone

Es cierto que posiblemente la empresa con más exito en cuanto a márketing quizás sea Apple, pero… ¿a qué precio?

Entradas relacionadas:

  1. Ballmer Vs Jobs Vs los medios de comunicación
  2. Nexus One: iPhone Killer -> Mucho mejor, más bonito y más barato
  3. iPad: Los medios de comunicación II
  4. iPad: Los medios de comunicación
  5. ¿”El iPhone 4 no tiene ningún problema de Antena” = “Despedimos al Ingeniero de Diseño de Hardware del iPhone”?

Volver a arriba

Sobre Mí

Cambiar a la versión para móviles

Alma Oscura por Theliel licenciado bajo Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0 Unported License.
Basado en el trabajo de blog.theliel.es.
Para otros permisos que puedan exceder el ámbito de esta licencia, contactar con el autor.