Me llegaba el otro día una entrada del blog de Oracle (EN) donde Nandini Ramani, desarrollador jefe de Java en la empresa, habla sobre el futuro de su tecnología en referencia a la seguridad.


java-oracle

Como bien sabréis, Java es una de las tecnologías más inseguras de la red (ojo al dato, que hablo de Java como complemento de navegador, no a Java como lenguaje). De hecho, suele colmar los primeros puestos en todos los rankings, lo que ha llevado a empresas de la talla de Apple a directamente eliminarlo de sus servicios, o a un servidor a explicaros cómo desactivarlo para no correr riesgos innecesarios.

Lo cierto que para el usuario normal, hoy en día se puede vivir sin problemas sin tener Java activo, gracias en buena parte a HTML5 y el avance de los navegadores, que han sabido comerse el terreno transformando esta tecnología en algo prescindible.

Por ello me sorprende que Oracle, siendo como es (no hay más que ver lo que ha hecho por MySQL desde que lo comprara…), le siga dando cancha a Java, que ya ni viene por defecto en la nueva generación de SO móviles (descontando BB, que es otro mundo).

Entrando ya en materia, básicamente ofrece un cambio radical (se supone) entre lo que venían haciendo y lo que harán a partir de ahora, y sobre las que haré mis propias matizaciones:

  • Aumento del parcheo de bugs: En el 2012 arreglaron 58 vulnerabilidades, y en lo que va de año unas 100. Aquí quería recordarles a los señores de Oracle que el número no importa, sino la gravedad. Chrome puede que sea el navegador con más vulnerabilidades que hay en el mercado, pero paradójicamente es de los más seguros. El objetivo por tanto es evitar los 0days y aquellos saltos del applet que ponen en peligro sistemas críticos del SO, no arreglar chorraditas sin futuro.
  • Bloqueo por defecto de applets no firmados: Virgen santa, han tardado en enterarse… No es la solución a todos los males, puesto que internauta y sentido común no suelen ir de la mano, pero es un principio. Todo aquel applet que no esté firmado o tenga un firma desconocida, pedirá permiso al usuario para ejecutarse. Y digo que no es la panacea, porque presupone que una firma certificada y conocida es legítima, lo cual podría ser pecar de incauto. No es la primera vez que una empresa certificadora tiene fugas de certificados que acabamos encontrando en el mercado negro. Pero es un paso.
  • Lista negra actualizada: Otro punto candente. Las black lists son útiles hasta cierto punto, y la de Java, que se actualizaba con cada nueva versión a lo sumo, no lo era en absoluto. Ahora aseguran que lo harán diariamente. Mal no va a venir.

Unos cambios que aunque necesarios, llegan varios años tarde. Java applet no debería volver a usarse masificadamente. De hecho habría que huir de ellos, acogiendo estándares HTML5 que sí van a recibir soporte adecuado, y que no dependen de una sandbox más agujereada que un queso gruyer.


Otros artículos relacionados