#7 El proceso de inclusión no tiene coste, pero requiere cumplir diversas medidas estrictas de seguridad. Durante todos estos años, si lees el bug verás como se han ido solicitando estas medidas, certificaciones... etc
No ha sido hasta ahora que se han cumplido todas. Aquí tienes el proceso, y puedes auditarlo ya que se ha hecho en abierto:
#77#78 Sois conscientes que Iceweasel permite plugins que implementan DRM supongo. En dicho caso, deberíais buscar un navegador que no permita instalar plugins propietarios.
#52 Si lees el artículo y los que puse en #31 verás que ni viene por defecto, que hay que activarlo a mano para que se baje (como el plugin de Flash ahora mismo) y estará en un sandbox para que no acceda a datos privados de los usuarios.
El módulo de DRM de Adobe será un añadido externo, sólo los usuarios que lo quieran lo activarán y se bajará, pero no vendrá integrado en Firefox. Lo que se implementa es esta posibilidad de tenerlo quien quiera.
Adicionalmente, #14 el resto de navegadores ya implementa DRM integrado en el propio navegador, no como algo adicional.
Pensad que ahora mismo tenemos lo mismo con el plugin de Flash y Silverlight, añadidos que dan acceso al contenido con DRM. Con la diferencia que esto tiene un envoltorio libre con un sandbox que impedirá acceder a cosas que ahora mismo los plugins pueden acceder (identificadores únicos entre sitios, acceso al disco...)
#27 La cosa es que ahí no puedes comprobar si han metido algo en ese .exe. En el repo está con el md5 y puedes comprobar que generándolo con el código sale el mismo exe.
#19 Aquí no se distribuye ningún binario propietario, es un script que usa un API de acceso, es el usuario el que localmente lo usa, no el desarrollador del script.
#23 Javascript se compila en tiempo real (JIT) para ejecutarse en la mayoría de motores actuales, con muchas optimizaciones sobre funciones habituales, es muuucho más complejo que tu afirmación de "es interpretado":
WebGL es un estándar, y como tal se espera (y se recomienda) que los navegadores lo implementen. Incluso IE11 lo va a a hacer, Opera 12 tiene parte y en la 15 lo tendrá completo:
Una aplicación nativa no te asegura que no habrá agujeros de seguridad, fugas de memoria o cuelgues. Actualmente los navegadores suelen trabajar en sanboxes y procesos separados, los nuevos motores como Servo (Firefox) y Blink (Chrome) usará todo el potencial de varias CPUs.
Como digo más arriba, de momento no se tiene el mismo rendimiento 1x que una aplicación en C++, pero se tiene 2x y se espera reducir a 1,5x muy pronto. Estos datos hacen que la universalidad de poder ejecutarse en todo lugar compense una penalización muy baja de rendimiento que cada día es menor.
Compatibilidad: Todos los navegadores modernos. En cualquier sitio donde tengas uno se ejecutará sin tener que reescribir el código.
Rendimiento: Usando la librería asm.js tienes actualmente entorno a 2x comparado con nativo (c++), y cada día se está reduciendo más, en muchos casos mejor rendimiento que una ejecución en máquina virtual java. Hace unos años estábamos hablando de 7 y 8x.
Ten en cuenta que el código está escrito en c++ y compilado a javascript de una forma muy eficiente.
El terminal ZTE va dirigido a un mercado muy específico, los usuarios que no tienen aún un smartphone y hasta ahora no se lo han podido permitir, el objetivo no es competir con Android o iOS. Puede parecer difícil de entender en un mercado en el que los teléfonos que salen son para ser el tope de gama y barrer el mercado.
#6 Firefox OS no es un "navegador empotrado" es un SO completo creado con tecnologías web y con el motor Gecko, que además implementa nuevas WebAPIs para que se pueda acceder de forma estándar al hardware.
Ah, y la web está ya lista para que se desarrolle alguna cosa más que un minijuego
#6 Telefónica I+D tiene un equipo bastante grande de desarrolladores pagados por ellos que se han integrado con el equipo de Mozilla y están ayudando a desarrollar parte del sistema.
Google tiene un API llamado PPAPI para realizar muchas cosas (no sólo plugins). Mozilla dijo en su momento que no lo iba a implementar porque intenta sustituir muchas cosas que se pueden hacer desde APIs web estándar con sus propios métodos. APIs web estándar como la de geolocalización: dev.w3.org/geo/api/spec-source.html
Google llega a un acuerdo con Adobe por la que haya que usar sí o sí PPAPI para usar el plugin de Flash, intentando obligar así a otros fabricantes a que implementen PPAPI si quieren que flash funcione en sus navegadores.
Traducción de la opinión de Robert O'Callahan sobre Pepper:
"Los navegadores ya ofrecen una plataforma API potente para código "aislado": las APIs web basadas en estándares. Actualmente Pepper ofrece algunas funcionalidades que las Web APIs aún no, pero no veo la razón por la que el código nativo tenga una funcionalidad diferente a las aplicaciones web JS."
Cuando en al actualizad los navegadores se dan tanto la mano en cuestiones técnicas, la pregunta debería ser: ¿Qué navegador se preocupa más por sus usuarios?
¿Cómo es posible que la gente siga repitiendo el mito de que Firefox consume más memoria que otros navegadores? Desde la versión 3, Firefox ha sido el navegador que menos memoria consume y de los que mayor atención ha puesto en que no haya ningún tipo de fuga de memoria añadiendo nuevas características para su control.
No ha sido hasta ahora que se han cumplido todas. Aquí tienes el proceso, y puedes auditarlo ya que se ha hecho en abierto:
www.mozilla.org/en-US/about/governance/policies/security-group/certs/p