Ya hemos hablado otras veces de estos temas: la seguridad hoy por hoy no constituye un argumento de venta. Los usuarios nos fijamos más en las funcionalidades, diseño y otros argumentos. Muchas veces la seguridad la vemos como algo molesto, que nos frena.

Por eso traigo aquí una nota de prensa que ni siquiera conozco si ha tenido efecto en las ventas y si el programa sigue activo Panda Security compensará a sus clientes en caso de infección. Indudablemente, utiliza la seguridad como argumento de ventas (algunos dirán que es trampa puesto que publicitan programas anti-virus que van, precisamente, de eso) pero hasta donde yo se, es la primera (o una de las primeras veces) que un anti-virus ofrecía ese nivel de garantía. Se pueden leer los términos en Garantía Panda y dice:

Si te infectas tienes 6 meses de servicio gratis. Y si tienes daños, o no te lo resolvemos en 24 horas, te devolvemos el diner.

Uno de los problemas cuando queremos tener un sistema seguro es que hay demasiados sitios donde alguien puede querer probar a atacarnos y es bastante difícil que seamos expertos en todo y/o que podamos dedicarle atención a todos los problemas durante todo el tiempo.

Como ejemplo, en Veneno, manzanas y un amargo despertar nos cuentan la historia de un rootkit que se podía instalar en el firmware de todos los MacBooks anteriores al año 2014 mediante un ataque bastante sofisticado, que se basaba en que las protecciones contra escritura de la BIOS se encontraban desactivadas tras la vuelta del sistema desde el modo Sleep.

Hay más detalles en The Empire Strikes Back Apple – how your Mac firmware security is completely broken pero el aviso es claro: los malos tienen muchas puertas de entrada.

Llevo dándole vueltas a este tema una temporada (incluso investigué un poquillo para un proyecto personal Storing credentials of your Python programs in the keyring, y ando jugando con el keyring en Python; se pueden ver ejemplos en cleanImapFolders.py, addToSieve.py . Tengo pendiente comentar sobre estos programas. Además he descubierto el proyecto passpie que aporta una solución de almacenamiento interesante también).

Pero me está quedando un preámbulo muy largo y en realidad quería comentar Storing Passwords Securely que es una introducción genérica (pero no superficial) y que aporta una buena panorámica a los temas que hay que prestar atención incluyendo algunos ejemplos. Lectura recomendable.

Este tema me resulta muy interesante: hemos vivido (y seguimos viviendo en muchos casos) como si los programas no pudieran ocasionar daños y, si los causan, el desarrollador/vendedor no tiene ninguna responsabilidad. Eso va cambiando con el tiempo, claro. Ya hablámbamos de Las actualizaciones … ¿como ventaja competitiva? y en los casos de los coches ha habido demandas y juicios Desbordamientos de memoria y Toyota.

En este caso traemos Insurer tells hospitals: You let hackers in, we’re not bailing you out que iría en la misma línea. En este caso se observó que la seguridad informática era muy deficiente y en consecuencia la aseguradora se niega a abonar los costes asociados, reclamando su devolución:

Columbia argues that it is not liable for the payout because Cottage did not provide adequate security for its documents, a clause the California hospital network agreed to when it signed the insurance policy.

Among the allegations, Columbia claims that Cottage failed to check for and apply security patches within 30 days of release, replace default access settings on security devices, undergo annual security audits, and outsourced data to firms with poor security. Cottage is also accused of failing to provide adequate detection and tracking of changes to its network and data.

El año pasado Java cumplía 20 años. Por ese motivo se publicaba Java at 20: How it changed programming forever donde se hace un resumen de sus ventajas más notables.

Según el autor, su principal fortaleza consistiría en ser una herramienta para tener el trabajo hecho:

But Java’s core strength was that it was built to be a practical tool for getting work done. It popularized good ideas from earlier languages by repackaging them in a format that was familiar to the average C coder, though (unlike C++ and Objective-C) Java was not a strict superset of C. Indeed it was precisely this willingness to not only add but also remove features that made Java so much simpler and easier to learn than other object-oriented C descendants.

Habla sobre el problema de los ‘applets’ (casi en fase de certificación oficial de su muerte, en estos momentos):

The irony is that applets never worked very well. They were completely isolated from the content on the page, unable to read or write HTML as JavaScript eventually could. Security constraints prevented applets from interacting with the local file system and third-party network servers. These restrictions made applets suitable for little more than simple games and animations.

Por completar, traigo un elogio del Java hecho por un desarrollador de Python que se autocalifica como converso: Why Java? Tales from a Python Convert que destaca la máquina virtual, las bibliotecas, la robustez de los tipos de datos y la concurrencia. También habla de las construcciones más modernas. Nos ha recordado aquella serie de la que hablábamos en Motivos por los que debería gustarnos Java donde se daba un buen repaso a las principales características de Java.