No me gusta Java, casi podría decirse que lo odio, pero esa me parece una palabra con la que hay que tener cuidado.
Hace unos días tuve que realizar un trámite en FACe (punto general de entrada de facturas electrónicas)… y tuve que utilizar Chrome porque Firefox no está soportado. Bueno, en realidad si, pero para hacer los trámites hay que realizar firmas, y se utiliza un applet de Java y como dicen claramente en la sede electrónica de la Seguridad Social:
Requiere la configuración específica detallada en el documento de Configuración de los navegadores para el uso de firma electrónica.
- MOZILLA FIREFOX 51 o inferior (*)
- CHROME 45 o inferior (*)
- SAFARI
(*) Importante: Como algunos de los servicios disponibles en la Sede Electrónica de la Seguridad Social requieren Java, NPAPI (tecnología necesaria para los applets Java) ya no está soportada en:
- Mozilla Firefox ha dejado de tener soporte NPAPI a partir de la versión 52, actualización de Marzo de 2017.
- Google Chrome dejó de admitir el uso de complementos el 1 de septiembre de 2015 (versión 45 de Chrome en adelante).
Los complementos que utilicen NPAPI, como Silverlight, Java y Unity, ya no funcionarán en Chrome y Firefox. Si quiere utilizar un sitio web que use estos tipos de complementos, debe usar otro navegador. Si tiene problemas para acceder a las aplicaciones Java con Chrome o Firefox, Oracle recomienda utilizar Internet Explorer (Windows) o Safari (Mac OS X) en su lugar.
Para Chrome se puede utilizar la aplicación AutoFirma, pero no con Firefox.
Al final ocurre lo de siempre: todo entorno donde se incluye algo con Java las cosas se complican, y mucho. Es cierto que hace años en el lado del cliente no había muchas opciones de incluir cosas como firma de documentos… pero hoy en día los navegadores son capaces de firmar documentos mediante JavaScript, el ejemplo claro es Mega, que cifra y descifra mediante JavaScript.
Java no me ha gustado nunca, en parte porque la idea del lenguaje era como un amor platónico: muy bonito pero no es real. Además, como parte de mi trabajo como administrador de sistemas he sufrido innumerables batallas para hacer funcionar distintos applets. Claro, mis compañeros de trabajo me tienen a mi… ¿y el común de los mortales?. Porque se da la casualidad que muchos de esos applets son imprescindibles para trámites con las administraciones públicas.
Podría dar muchos motivos técnicos, sin embargo los motivos prácticos y de usabilidad son más fáciles de entender por todos y ya son un motivo evidente y de peso como para PROHIBIR el uso de ciertas tecnologías (JAVA, en este caso).
Esta sufrida relación con Java viene de muy lejos, así que esta postura no es cosa de un pronto, es algo que tengo claro desde hace más de una década y por fin la expreso en palabras.
El problema concreto del que hablas es que ha habido un lapso de tiempo en el que JavaScript no podía hacer cosas bien. De hecho, lo de la criptografía con JavaScript…. Es bastante dudoso, ya que el generador de números aleatorios (Math.random) que tiene no tiene calidad criptografíca, y se lo criticaron a Mega en su día.
Ahora existe y funciona en las últimas versiones de los navegadores la API de WebCrypto que ya genera números aleatorios con calidad criptográfica, pero claro, ha habido un lapso de tiempo ahí donde los applets de Java ya estaban viejos y funcionaban mal pero a la vez no había sustituto.
No había leído este artículo en su momento, y esto de acuerdo. Java que debería ser un entorno ligero por su concepción, se convierte en pesado. Su portabilidad, está alejada de la de Javascript por ejemplo.
El rendimiento de Javascript va mejorando notablemente, aún es más lento que Java, pero unido al mejor hardware hace que cosas impensables hace 10 años, ya se puedan hacer sin problemas en JS.
En cuanto a la criptografía, existe RandomSource.getRandomValues().
Todos estos programas siempre dan por saco con los temas de cuentas de usuario normales… y desde XP en entorno profesional ya ha llovido un poco y podría estar resuelto… con tecnologías del lado cliente.
Pero en lugar de impulsar tecnologías estándar (JavaScript lo es, Java no) se siguen empecinando en seguir con Java, en este caso.
Me pena que no exista nadie que se diera cuenta desde el inicio que el Java era una pesadilla y siguiera una vía paralela de investigación de su cambio por JS… unirse o crear un equipo de desarrollo para un framework de criptografía en JS hubiera sido fácil, se habrían obtenido recursos fácilmente (al menos en cuanto a colaboradores) y estoy seguro que en poco tiempo habríamos tenido algo usable.
Hay que tener en cuenta que aunque JS era lento y las máquinas de hace 5-10 años no son las de ahora, las funciones de firma tampoco tienen por qué ser rápidas.