Barrapunto

Se podria comentar muchas cosas pero igual hay algo mas interesante.

Si en tu Firefox tienes instalado el DOM Inspector, abre una ventana de "Configurar pagina". Trata de encontrar esa ventana y analizarla con el DOM Inspector. ¿Que se ve?, esa ventana, y otras muchas de firefox, son un interface en XUL, con toda la logica programada en Javascript. Este codigo tiene bastantes privilegios sobre el ordenador, pero no tiene el tipo de control total sobre el ordenador que pueda tener una snip de codigo C. Ademas a este codigo seria posible hacerle la perreria de que cuando quisiera abrir un fichero de texto, tubiera que pedir permiso y se le pudiera denegar. De este modo hemos aislado esta porcion de codigo de la maquina, dando mayor seguridad.

Y SIN EMBARGO, el codigo C de Mozilla es muy complejo, y el problema de mezclar codigo C con estructuras C y codigo en Javascript y su recolector de basura no es un problema trivial, sino todo lo contrario. Es muy facil hacer una referencia circular de modo que la memoria nunca se libere y se cree asi un leak de memoria.

si no prueben ustedes mismos a la velocidad que tiene firefox [celtickane.com]

El único problema es la lentitud. Hará que sea considerablemente más lento pero..., en seguridad ganará fijo.

Para buscar fallas explotables habría que buscar fallas en el motor JavaScript o problemas en las políticas de gestión de permisos de JavaScript.

Lo consideraría un buen paso si... hicieran un intérprete rápido. Me da igual que sea de JavaScript que de Pascal o Cobol: Los intérpretes nunca son tan rápidos (ni por asomo) como el código nativo.

Es eviente que un diseño mal planteado o una mala implementación son culpables de la seguridad del software. Pero aparte de ésto, también hay que tener claro que para dar seguridad a una aplicación, hay que sacrificar rendimiento a medida que el software haga más comprobaciones de seguridad en las operaciones que realiza. Y como es lógico, el código gestionado por máquinas virtuales ofrece mayor grado de seguridad. Por eso sustituir partes de firefox a javascript es una buena medida para reforzar la seguridad de este navegador.
Con los procesadores de hoy en día en PCs, el sacrificio de rendimiento para mejorar la seguridad de firefox no es un problema. Hay que advertir además, que los sitios web cada vez usan más recursos para ser visionados en un navegador web. Por lo que en definitiva, si quieres estar al día, usa un hardware que lo esté.

Pues es un movimiento que tiene un montón de sentido.

Teniendo en cuenta la cantidad de código que se ejecuta en ECMAScript (así no lo confundimos con Java, ¿verdad?) en la actualidad (con XUL, muchas extensiones, etc) no creo que sea un gran problema de velocidad, que siempre se puede mejorar en una aplicación que, básicamente, está sentada sin hacer nada esperando a que el usuario haga alguna cosa, o bien, depende de lo guarripeich que sea el sitio, comprobando que está haciendo el chorras encima de un menú dinámic, etc... (así con todo, buena parte de los componentes por debajo, XPCOM, están programados en C o C++, quizás separando más las responsabilidades se pueda mejorar el rendimiento además de la facilidad de mantenimiento, seguridad , limpieza y esas cosas que sólo son importantes cuando no están).

En cuanto a la elección de JS para el asunto, SpiderMonkey es una implementación realmente buena, y siempre se puede mejorar en ese punto, para que se noten mejoras en todas partes. E JS es uno de los lenguajes de programación más incomprendidos y abusados de la historia de la computación, pobrecito... Con JS nos ahorraremos un montón deproblemas de buffer overrun/flow, cores (o null pointer exceptions, vamos) etc... Es muy potente y soporta muchos paradigmas, para que todos se sientan más cómodos (los de la OO, los otros, los de más allá... ventajas de ser muy potente).

Un comentario en Kriptópolis que me ha causado un arranque de risa (y de tos, pero eso es por el catarro) es el de 'si aún hubiesen escogido un lenguaje de programación funcional!' Entonces, ¿el JS qué es, un lenguaje de programación generacional? ¿puturrudefuá? Los lenguajes funcionales puros tienen sus ventajas, sin duda, pero Haskell y cia. no son para todo el mundo, y JS tiene un potente modelo de programación OO basado en prototipos (similar al de Self) y soporta funciones de primera clase (function() es, efectivamente, igual que lambda(), o \ en Haskell)

Los funcionales "mixtos" funcionan muy bien también, recordemos lo bien que rula el OCaml, ¡o el Lisp!

A los firefoxeros, ¡ánimo! A los que critican, menos palabras y más hechos, valientes, ayudando con código nativo de calidad, tenéis el src de Firefox en los repositorios... ¡Hala, a demostrar lo que valéis con Makefiles, y no con palabrejas que ni compilan ni nada! xD

en fin...

Pero no deben olvidarse de otras cosas como el rendimiento y la velocidad.

La version de Firefox en Linux va (por lo menos a mi) mas lenta que la version de Firefox para windows.

Creo que habira que estudiar y leer un poco mas, antes de intentar dar posiciones catedraticas. Ya que algunas resultan hasta ridiculas.

Y quién decidiría si una página es insegura, ¿un país, una empresa, una organización de países/empresas?

Eso sólo se podría implementar prohibiendo la publicación de cualquier cosa sin permiso previo. Así no funciona Internet --y que sea así por mucho tiempo--.

Internet es la selva, puedes encontrarte cualquier cosa. Tienes que ir provisto de un buen machete por si encuentras alguna sorpresa.

Conclusión: los navegadores deben preocuparse (y mucho) de la seguridad.

Primer problema ¿Cómo descubrir si una página es segura o no? Es muy complicado. Al fin y al cabo las secuencias de comandos javascript, o html son casos un poco especiales. Un hacker podría perfectamente crear una página insegura que parezca una página normal. De hecho se hace.

Adicionalmente esto no eliminaría el problema. También podrían mandartelas por correo. O, por ejemplo, podría usar un php para que sólo muestre el código maligo a las ips de fuera de Estados Unidos o con un user agente determinado.

Luego está el problema político. ¿No hay miles de páginas de Warez? Si la Sgae no consigue evitar que bajarse un disco de Bisbal sea trivial y si un generador de contraseñas de Windows está en cualquier sitio- ¿Pretendes eliminar algo que ni siquiera saebs que aspecto tiene?

Es como decir: los bancos tienen que tener las puertas abiertas y guardar su dinero en cajas de zapatos, lo que hay que hacer es meter en la carcel a todos los ladrones.
Bueno, fuera coña, está claro que si por mí fuera metería el monitor por el culo a todos estos pesados que te envían spam, te intentan colar malware, etc... Pero también hay que hacer seguros los navegadores por otros "enemigos" como podría ser un gobierno como el chino que quiere joderte para ver qué haces con tu ordenador, o una gran empresa que quiere espiar a la competencia.

Aún más? Pues sí, es para dar miedo.

Hay mas navegadores en el mundo aparte de esos tres.
wikipedia Navegador web [wikipedia.org]
wikipedia tabla comparativa navegadores web [wikipedia.org]

Yo pienso que habrá mucha gente a la que no le gustará esa decision y es posible que alguien se plantee hacer un fork.

Bueno eso es relativo , a veces y principalmente en la programación orientada a objetos por comodidad utilizamos ciertas cosas que por supuesto dependiendo de la implementacion degradan la performance.
Ah mi por ejemplo bajo windows y utilizando MFC,por ejemplo tenia métodos en que pasaba las CString por valor ej
void hace_algo(CString argumento) .Un buen día decidi convertir ese mismo programa a una base en C++ mucho mas pequeña y por lo tanto más optimizada y revisada y dejar todo el resto de la lógica a un lenguaje interpretado que en este caso es LUA .
Oh sorpresa , no solo conseguí con esto un programa mas robusto y estable sino que también mucho mas rápido.
Reconozco que el codigo C++ del sistema anterior era más bien malo , pero creo que en sistemas complejos y más esos que no han sido diseñados de principio a fin , sino que han evolucionado con el tiempo , ese "refactoring" puede beneficiar desde muchos aspectos.

¡¿Qué leches saben ellos?! Aquí la gente critica, y critica, y la mitad no sabe ni de lo que está hablando. ¡¿Leer?! Con lo fácil que es escribir sin saber... Si lo pusieran en la tele, a lo mejor.

No les hables de XUL... ni les enseñes las cosas tan chulas que se hacen con él. Ni les expliques que es más seguro ejecutar algo dentro de un navegador, sin permisos para salir, que ejecutarlo desde el navegador, con los mismos permisos que el usuario que lo ejecuta (que, por supuesto, seguirá siendo usuario administrador, hasta el fn de los tiempos).

Y por supuesto no les expliques que Java y Javascript no tienen nada que ver... ¡¿Pero si tienen la palabra Java?! Vaya por dios, y el hombre de Java, y el tigre de Java, y tampoco tienen nada que ver :)

Total, los desarrolladores seguro que no saben nada... ¡Menudos estúpidos son esos! Cambiar código C/C++ que ellos mismo han escrito por código en "Java". ¡Serán subnormales! Pa eso me voy a Opera...

Y bueno, ya sabes como fucnionan las cosas aquí, mucho criticar que no se habla de cosas técnicas, y cuando se habla, se lían a tirar despropósitos, porque no tienen NPI... Ni quiere aprender, claro.

El problema no es que te lo creas o no, el problema es que tu no tienes la menor idea de qué es el tema, porqué ellos si que son competentes y tu no. Si fueras competente, no confundirias C con C++ y Java con Javascript...

me encantaría probar el navegador "algo" debe ser buenisimo.

Si el 99% ya esta en javascript. Pero es que el 1% en C restante es el "mozilla trunk" que debe ser un pedazo de codigo fuente de 15 millones de lineas de codigo, por lo menos.

Ir pasando cosas que se hacen ahora con C del mozilla trunk a Javascript se puede hacer lentamente. Incluso se puede parar uno y quedarse donde este. Si es que no le ve sentido a la aventura.

En cambio lo que tu propones no tendria forma de hacerse, ni habria donde cogerlo.
Fijate que esas 15 millones de lineas de codigo interpretado (por decir un numero bruto) no se tocan.

Lo que se propone entiendo que es reescribir como javascript cosas que estan en C. Lo que tu propones solo tendria sentido si se reescribiera C como C#, pero no tienen ninguna intencion de tocar el C para nada.

De todos modos ya veremos. Quizas esta idea de pasar mas cosas a javascript se quede en nada.

El otro objetivo de firefox es que funcione bien en sistemas operativos como macintosh, solaris, y todas las derivaciones de linux.

Aunque existe mono ese es aún bastante deficiente y ni siquiera está incluido en la mayoría de las distribuciones.

Además no están pensando dejar de usar c++ para las operaciones críticas para la velocidad.

Así que .net no pasa de ser una opción "interesante" que no sería practico y la verdad pasarlo a .net haría que todo sea más lento ya que no tendrían los procesos críticos en c++

No debería dar de comer al troll ni continuar con un flame FF vs. Opera, pero lo haré para que no desinforme al personal... Y ya de paso, nos reimos un poco...

Si es cierto eso de que Opera no "crea" (¿inventa quieres decir?) explícame entonces qué navegador fue el primero en emplear las pestañas, el etiquetado de mensajes (popularizado por GMail), los gestos de ratón, el zoom, las sesiones, la navegación por voz... Mira, mira y aprende [operawiki.info]...

Sobre la última frase, te daré un consejo: no seas tan obvio cuando trates de extender un FUD...
Si hubieses dicho que copió el motor de Mosaic, puede que a lo mejor colase y todo... pero dificilmente un navegador que ya existía en 1994 va a copiar el motor de otro que empezó a conocerse casi cinco años después...

Luego nos quejamos de las acciones de ms, que si FUDs, que si no respeta los estándares, ... y resulta que se utilizan las mismas artimañas sucias y rastreras para vender Firefox.