Al igual que en el artículo anterior, quiero insistir en que [...]]]> En el artículo de hoy de esta pequeña mini-serie sobre herramientas gratuitas para la firma electrónica basada en certificado de documentos PDF (y también otros formatos) presentaremos las herramientas ESecure de KSI y XolidoSign de Xolido.

Al igual que en el artículo anterior, quiero insistir en que no se trata de una comparativa (no se han hecho pruebas exhaustivas con cada una), sino de un vistazo un poco más a fondo a cada herramienta para obtener unas primeras impresiones de lo que ofrecen al usuario.

Animo desde aquí a los fabricantes y/o usuarios que lean el artículo a que añadan en los comentarios las observaciones que consideran oportunas para completar o, en su caso, corregir aspectos comentados en el artículo.

Bueno, pues vamos allá con la primera herramienta.

ESecure

En el caso de ESecure, la versión probada ha sido ESecure 1.8.51.39, esta versión soporta tanto firma electrónica como el cifrado con contraseña o certificado para cualquier formato de fichero y decenas de algoritmos que van desde las opciones muy básicas como RC2 hasta opciones muy avanzadas como AES256.

Estándares soportados, versiones y principales funcionalidades

ESecure dispone de varios modelos de licenciamiento: una versión gratuita para ciudadanos (licencia USER), una licencia EDU condicionada a la realización de un curso online gratuito y las versiones de pago PRO y PYME que se salen del alcance de esta serie por este motivo.

La versión USER soporta los formatos de firma PKCS#7/CMS/CAdES (X-L), la versión EDU soporta además PDF/PAdES (basic y enhanced) y las versiones de pago permiten firmar en formato XMLDsig/XAdES (X-L) junto con funcionalidades adicionales como una funcionalidad de portafirmas electrónico o correo electrónico seguro S/MIME.

Limitaciones de las versiones

Las versiones gratuitas USER y EDU cuentan con limitaciones, algunas importantes. En el caso de la licencia USER:

• Soporta la firma de PDF sólo para tamaños <1Mbyte, aunque permite emplear el formato PAdES.
• No soporta el trabajo con servidores  OCSP para la consulta del estado revocación de los certificados, ni con servidores TSP para el sellado de tiempo.
• No soporta el trabajo con múltiples documentos (portafirmas)

En el caso de la licencia EDU elimina las limitaciones de los ficheros PDF, pero mantiene las demás limitaciones.

La interfaz de usuario de ESecure se ha inspirado en el explorador de ficheros de Windows

El conjunto completo de funcionalidades sólo está disponible en las versiones de pago.

Plataformas

ESecure es compatible solamente con plataformas Windows. El manual menciona que la versión USER puede utilizarse en Linux con WINE, aunque esto supone limitaciones importantes como poder trabajar solamente con ficheros PKCS#12 y las propias de la versión USER.

Posibilidades de Configuración

La aplicación se integra con el almacén de certificados de Windows y permite además importar certificados, soporta tanto ficheros PKCS#12, como librerías PKCS#11 para el uso de tarjetas criptográficas como el DNIe, soporta  y dispone de una larga serie de posibilidades de configuración (con los límites según la licencia en cuestión) que permiten una configuración muy detallada de las funcionalidades antes comentadas y que son tantas que sobrepasan por completo el alcance de este artículo, remito al lector interesado al extenso manual que proporciona KSI para ESecure (>300 páginas) para más detalles.

Interfaz, Usabilidad y Documentación

La interfaz se asemeja al explorador de ficheros Windows de XP (mantiene esta apariencia también en Windows 7). Me gusta la idea por la familiaridad que le supone al usuario, aunque no se trata de una integración dentro del auténtico explorador, quizás algo a tener en cuenta para el futuro. De todas formas, favorece que, de alguna manera, la lógica de las operaciones de firma y cifrado se perciba de forma más natural y práctica en el trabajo con el ordenador.

Fortalezas y Debilidades

Entre las principales fortalezas de ESecure se pueden destacar la gran riqueza de su funcionalidad y número de estándares de firma y cifrado soportados que cubre incluso formatos aún no ampliamente soportados como lo es PAdES, una filosofía de interfaz de usuario que le resultará intuitiva a muchos usuarios, aunque necesite quizás una pequeña puesta al día (para asemejarse más a Windows 7) y una enorme capacidad de configuración.

Incluso en funcionalidades como la firma visible (un gráfico que se imprime en el documento como indicativo de que contiene una firma digital) de los documentos PDF  permite una configuración muy detallada que en este caso incluye, por ejemplo, un diseñador de los widgets empleados para la firma.

La únicas debilidades claras que he podido encontrar es una política comercial bastante restrictiva que llega a limitar a las versiones de pago incluso en cosas básicas como la validación de los certificados vía OCSP y que la falta de soporte a las plataformas Mac OS y Linux.

XolidoSign

XolidoSign es una herramienta completamente gratuita, sin limitaciones en su funcionalidadcolectivos, ni colectivos de usuarios. Es decir, es 100% legal utilizarla tanto en el sector público como privado. El modelo de negocio de Xolido parece apostar en ese sentido por generar sus ingresos mediante su cartera de servicios en la nube y sus servicios de consultoría y auditoría.

Estándares soportados

La versión probada ha sido la versión 2.1.0.2 que soporta la realización de firmas electrónicas basadas en certificado en los formatos PKCS#7/CMS, CAdES-C y CAdES-XL, PDF signature/PAdES y el sellado de tiempo. En el lado de la validación soporta los siguientes formatos: PKCS#7/CMS, CAdES, XMLDsig, XAdES, PDF signature/PAdES, sellos de tiempo RFC3161 y OASIS XML TST.

En cuanto a los certificados que se pueden utilizar se reconocen tanto certificados en formato PKCS#12 como dispositivos PKCS#11.

Plataformas

XolidoSign soporta solamente la familia Windows, incluyendo las plataformas de 64bits.

Funcionalidades y Posibilidades de Configuración

Dentro de las funcionalidades soportadas habría que destacar que soporta funcionalidades de portafirmas electrónico al poder firmar lotes de documentos a la vez, elegir entre firmas PDF incrustadas o externas, permite la inclusión de una firma visible bastante configurable, y la inclusión de un registro de firmas (como fichero CSV).

La interfaz de usuario de XolidoSign es muy claro y fácil de utilizar

Además se pueden configurar una larga serie de parámetros relacionados con las carpetas de entrada y salida de los documentos, preselección de certificados, parámetros de uso de los certificados y firma (por ejemplo: aceptar o no el uso de certificados caducados para firmas), etc.

Interfaz, Usabilidad y Documentación

El interfaz de usuario de esta herramienta también me ha gustado, es muy diferente a ESecure, pero resulta un planteamiento alternativo muy limpio y sencillo de utilizar.

Hay que destacar además que la Web de XolidoSign me ha resultado extraordinariamente clara, bien organizada y con información muy completa. Permite conocer el producto bastante bien en poco tiempo, sin apenas esfuerzo, hay muchos empresas (y Administraciones) que podrían tomar nota.

A la aplicación la acompaña un manual de usuario de unas 53 páginas que me ha parecido bien redactado y completo. La diferencia en páginas con ESecure refleja en parte que se trata de una herramienta algo más sencilla, aunque lo que hace, lo hace muy bien.

Xolido complementa además este manual con los servicios online como su canal Youtube en el cual se pueden encontrar demos del uso de la herramienta. Otra buena práctica de la que muchas empresas (y Administraciones) deberían tomar nota.

Fortalezas y Debilidades

Al igual que en el caso de ESecure, se trata de una magnífica herramienta y más aún si se tiene en cuenta que es completamente gratuita. Quizás su único “punto débil” sea que, en comparación con ESecure, tiene una funcionalidad algo más limitada (por ejemplo, no firma en XAdES ni tiene funcionalidades de cifrado). Sin embargo, la funcionalidad debería ser suficientemente completa para la enorme mayoría de usuarios y a cambio no sufre las limitaciones en puntos básicos que adolecen las versiones gratuitas de ESecure.

Por lo demás comparte con ESecure la misma carencia, incluso un poco más acusada, en cuanto a falta de soporte de Mac OS y Linux.

Por si fuera poco que una herramienta tan completa sea completamente gratis, en la versión probada (publicada hace apenas unas semanas) incluye como novedad un servicio gratuito de sellado de tiempo basado entidades reconocidas. He podido comprobar que ya vienen preconfiguradas concretamente las autoridades ACCV e IZENPE.

Se trata sin duda de una prestación con un gran valor añadido que hace la herramienta, si cabe, aún más completa.

Por otra parte, me parece muy positivo que Xolido haya cuidado tanto su excelente Web como su presencia en las redes sociales Facebook y Twitter y disponga de un canal Youtube con vídeos de presentaciones y demos del producto. Creo que en esta parte está muy por delante de su competencia.

Aquí dejo un vídeo de demo:

Conclusiones

Ambas herramientas me parecen buenos productos, aunque con filosofías bastante diferentes, suficientemente completos y potentes para cubrir en la práctica las necesidades de usuario en el trabajo ad hoc en la firma electrónica basada en certificado de documentos PDF y otros formatos. La decisión de elegir una u otra será más cuestión de los requerimientos concretos del cliente que de la superioridad de una frente a otra. En cualquier caso, ambas son muy superiores a las vistas en el primer artículo de esta serie.

Me ha llamado la atención la política comercial que KSI sigue con ESecure: habiendo herramientas completamente gratuitas del calibre de XolidoSign, introducir de restricciones tan importantes como limitar el protocolo OCSP a las versiones comerciales me parece una política arriesgada, ya que es muy fácil que un potencial cliente, especialmente si no es muy experto en la materia, se incline ante los primeros inconvenientes directamente por una alternativa como XolidoSign sin llegar a probar ni siquiera Esecure.

Tampoco ayuda que los diferentes niveles de limitaciones que tiene cada una de las versiones de ESecure dificultan entender bien las posibilidades del producto. De hecho, ha sido un factor importante que me ha dificultado y retrasado este artículo que, a priori, era bastante sencillo de hacer.

Me parece una pena que KSI corra ese riesgo comercial cuando ofrecen un buen producto que cuenta frente a sus alternativas con factores diferenciales como reunir en una sola herramienta todos los formatos de firma importantes, incluyendo XAdES y PAdES.

Siendo XolidoSign un producto más limitado funcionalmente, creo que han tenido un gran acierto en ofrecer un producto gratuito que satisface muy bien lo que a día de hoy un usuario puede necesitar hacer con documentos PDF. Xolido acompaña a su producto además de una Web atractiva y fácil de entender y aprovecha también los nuevos canales como las redes sociales y Youtube. Xolido ofrece todo lo importante y ha sabido añadir un envoltorio atractivo, lo cual puede ser una clave importante para que triunfe en la Administración y sector privado.

Finalmente, dada la creciente importancia de sistemas operativos que no sean Windows, como los propios de Apple y las variantes de Linux (incluyo Android en el saco) creo que ambos fabricantes deberían atacar este objetivo a corto/medio plazo para que sus productos queden realmente “redondos”.

Se puede decir que [...]]]> Después de analizar diferentes aspectos de las experiencias con la utilización de certificados electrónicos caben varias conclusiones. En primer lugar, resulta irónico observar que en cierto modo el uso de los certificados electrónicos en vez de simplificarse con el tiempo se ha vuelvo más difícil en la actualidad.

Se puede decir que los problemas descritos redundan en una deficiencia de la usabilidad y la calidad de los productos y aplicaciones (DNIe, firma electrónica en aplicaciones Web, etc.). Esto ha creado barreras que la mayoría de los usuarios no están dispuestos a superar y que además probablemente en la mayoría de los casos no sepan cómo superar.

Esta situación resulta especialmente acusada en el caso del DNI electrónico. Si se quiere corregir esta situación, el único nivel de usabilidad realista es el propio del principio “plug&play”: la experiencia del usuario tiene que ser enchufar y listo, ocultándole cualquier detalle técnico, no se le pueden imponer condiciones adicionales como la adquisición de un lector para el caso del DNIe.

O se entrega con el propio DNIe en la comisaria o bien se impulsan políticas que fomenten su inclusión con los equipos. Cualquier tarea o gasto adicional para el usuario supone una barrera que la mayoría de ellos no van a estar dispuestos a cruzar. Muy recomendable, por cierto, también este artículo para profundizar un poco más en el tema.

El principio de neutralidad tecnológica de la Ley 11/2007 (que el usuario pueda elegir los productos como navegadores que quiera utilizar con la Administración) resulta encomiable y va la dirección correcta, pero hoy por hoy, debido a la falta de los estándares adecuados, resulta realmente problemático de implementar en la práctica.

Esto implica una situación insatisfactoria para todas los partes:

• Para Administración porque aumenta la complejidad y costes de desarrollo, y disminuye la calidad de las aplicaciones finales. Mi experiencia personal, desde luego, es que el desarrollo de soluciones fiables e interoperables con firma electrónica es un dolor.

• Para los fabricantes porque frena la demanda activa de los usuarios, su motivación de utilizar aplicaciones de Administración electrónica. El impulso no deja de ser “artificial”, impuesto por una Ley, no por convencer al usuario. Esto es mejor que la ausencia total de impulso, pero no es la fórmula idónea de impulsar la Administración electrónica.
• Para el ciudadano porque no puede aprovechar todo el potencial que la Administración electrónica le puede ofrecer y resulta muy frustrante fracasar en el intento de utilizar estos nuevos servicios.

¿Quiere decir esto que utilizar los certificados X.509 en la Administración electrónica ha sido una equivocación?

En mi opinión personal, ésta sería una conclusión muy equivocada.

Se trata de una tecnología demasiado buena y segura como para descartarla, en realidad es una tecnología ideal para implementar la identidad digital y la realización de firmas electrónicas que merezcan ese nombre. El problema es que esta tecnología  ha sido perjudicada por problemas ajenos a ella, problemas del entorno tecnológico en el que debe operar Merece la pena esforzarse para solucionar los problemas y aprovechar las magníficas  prestaciones que ofrecen los certificados electrónicos y la firma electrónica basada en certificados.

Por tanto, el problema no es la tecnología en sí, como se ha podido ver, es la falta de una estandarización suficiente en determinadas cuestiones técnicas e impulso insuficiente por parte de los fabricantes y las instituciones interesadas ya que la demanda del sector privado de esta funcionalidad es baja. Cualquier tecnología similar sufriría problemas parecidos ante la situación similar en el entorno tecnológico.

Para solucionar los problemas es necesaria una doble perspectiva: una visión nacional (en el caso de España, por ejemplo, solucionar los problemas técnicos del DNIe e impulsar políticas que eliminen las demás barreras de uso) y otra internacional en el cual la instituciones responsables del impulso de la Administración electrónica, como aquellas propias de la UE logren los acuerdos necesarios con los fabricantes y organizaciones de normalización pertinentes para evolucionar hacia un entorno tecnológico adecuado.

Existen, no obstante, alternativas interesantes como incorporar sistemas de identidad digital no basados en certificados que aseguren un registro fiable de sus usuarios para poder comprobar a la postre de modo fehaciente su identidad.

¿Pero tiene realmente sentido a estas alturas emprender un camino nuevo con los esfuerzos que implicaría para consolidarlo y no sería además la excusa perfecta para emitir el certificado de defunción definitivo de los certificados electrónicos dejando así de lado todo lo recorrido?

Parece un contrasentido cuando ya hay tanto conseguido, una infraestructura considerable de servicios como se puede comprobar fácilmente a través de la Red 060 y un marco legal también muy desarrollado. Sobre todo cuando lo que falta no es tanto. En realidad son unas pocas barreras perfectamente identificadas, las que están siendo un freno para acceder a un conjunto enorme de servicios, remover esas barreras sería el paso a la eclosión del acceso a los servicios electrónicos.

Solucionar los problemas expuestos es posible y técnicamente en realidad ni siquiera muy difícil. Lograrlo es principalmente una cuestión de coordinación y voluntad de todos los actores implicados: fabricantes, instituciones de normalización, Gobiernos y Administración.

Al principio (finales [...]]]> En el artículo anterior hemos podido ver las grandes virtudes de los certificados electrónicos para la implementación de una solución de identidad digital y de firma electrónica, sin embargo, su adopción en la Administración Pública y por parte del ciudadano no ha sido nada fácil.

¿Cómo se explica esto?

Al principio (finales 90, principios año 2000) el entorno tecnológico del usuario se mantiene razonablemente sencillo. Entonces, prácticamente en el 100% de los casos el entorno de usuario es la combinación de Windows + Internet Explorer + certificado en formato PKCS#12 (certificado electrónico en forma de fichero que se instala en almacén de certificados del ordenador). Habría que añadir que este certificado electrónico procede prácticamente en el 100% de los casos de la FNMT (Fábrica Nacional de Moneda y Timbre) gracias a que lo ofrece gratuitamente a los ciudadanos.

Además, en los primeros años es natural que el perfil de usuario tipo de la Administración electrónica tienda a ser un usuario interesado en las nuevas tecnologías y motivado para conocer nuevas experiencias tecnológicas.

Por tanto, se puede decir que los servicios electrónicos dan sus primeros pasos con un entorno relativamente homogéneo, relativamente simple y con usuarios con un nivel técnico por encima de la media. Esto facilita las cosas, tanto a la propia Administración como al ciudadano.

Sin embargo, a lo largo de la primera década del año 2000 esta situación cambia: la heterogeneidad del entorno crece sustancialmente, lo que multiplica los problemas de una tecnología no trivial como lo son los certificados digitales.

Se diversifican los sistemas operativos de los usuarios (Windows, Mac OS, Linux, …), y los navegadores (IE, Firefox, Chrome, Safari, Opera, …). Además se lanza en el año 2006 el DNI electrónico que trae consigo sus propios problemas: la necesidad de adquirir un lector, la necesidad de instalar el software del DNI y en algunos casos también para el lector, problemas específicos del DNIe como una gran lentitud o peticiones excesivas del PIN, confusión creada por la temprana caducidad de sus certificados, mucho más corta que la validez del DNI en sí (30 meses frente a 5/10 años), etc.

El resultado es que a día de hoy España hay más de 21 millones de DNIe expedidos, pero ni un 5% de sus titulares han utilizado sus certificados alguna vez[1]. Se puede leer con frecuencia la afirmación del liderazgo mundial de España en la introducción de un documento de identidad nacional electrónico, pero estas cifras sugieren que hay que relativizar mucho este logro.

Con la creciente heterogeneidad del entorno se hace patente el hecho fatal de que los fabricantes no siguen pautas comunes del uso de certificados X.509 en sus productos, junto con deficiencias y fallos particulares según el caso.  Esta situación se puede comparar en cierta medida en los problemas con la visualización de páginas Web en los primeros años de Internet debido al uso de elementos no estándar e incumplimiento de los estándares en algunos de los navegadores, lo que se traducía en problemas para visualizar correctamente algunas páginas.

Todo esto provoca en definitiva que los detalles complejos de la tecnología no le queden los suficientemente ocultos al usuario, se ve expuesto a ellos sin estar preparado para manejarlos. Para solucionar sus problemas en muchos casos el ciudadano ha de enfrentarse a conceptos no triviales que le suenan simplemente a chino: almacén de certificados, certificado raíz, clave privada, etc.

Otro gran foco de problemas es el uso de la firma electrónica en la Web debido a que los navegadores no disponen de manera “nativa” de la funcionalidad necesaria para realizar firmas electrónicas y con los formatos necesarios, esto no llega a formar parte de los estándares Web. La firma electrónica basada en certificado electrónico en sí está perfectamente normalizada, pero no hay ningún estándar Web que diga que esta funcionalidad deba formar parte de un navegador y como habría de ser utilizada en tal caso por la aplicación Web.

Por tanto, la organización, pública o privada, que quiera utilizar firmas electrónicas vía Web se ve obligada a desarrollar componentes específicos para ello, pequeños programas (del tipo “Applet” o “ActiveX”), que se incrustan dentro de la página donde el usuario ha de firmar y que se encargan de realizar la firma.

Estos componentes se enfrentan a un problema doble problema: son considerados como potencialmente peligrosos por el navegador y están por tanto sujetos a importantes restricciones de seguridad que pueden llegar incluso al extremo de la prohibición de su ejecución. La consecuencia es que aparece el problema de la correcta configuración del navegador del usuario para que se puedan ejecutar.

Por si esto fuera poco, contamos además con el problema antes comentado de la heterogeneidad de los navegadores, con un soporte desigual al uso de certificados y un amplio abanico de versiones que han ido saliendo a lo largo del tiempo y que hoy conviven felizmente en el parque de los equipos de los ciudadanos. He aquí otra gran fuente de incidencias.

De nuevo se producen los problemas propios de la falta de estandarización: pautas de uso distintas y explosión de la combinaciones de productos tecnológicos y versiones de los mismos diferentes (sistema operativo + navegador + componente de firma).

Todo esto ha supuesto un problema enorme para poder desarrollar aplicaciones Web de servicios electrónicos que usen certificados electrónicos y firma electrónica. La realidad es que se genera una excesiva cantidad de incidencias y la usabilidad de cosas como la correcta instalación y ejecución de los componentes de firma electrónica.

La faena se ha rematado con los graves problemas de usabilidad con los que ha nacido el DNI electrónico, lo que ha provocado que mucha gente prefiera el certificado “de toda la vida” de la FNMT, a pesar de ser, en teoría, una solución peor al DNIe.

No obstante, recientes novedades crean una cierta esperanza de que los problemas de usabilidad del DNIe puedan mejorar sensiblemente a medio plazo, aunque aun así queda por solucionar el problema del entorno tecnológico que no se encuentra en un estado adecuado para que la Administración electrónica pueda eclosionar verdaderamente dando paso a un uso masivo de los servicios electrónicos.

Conclusiones

Queda claro por tanto, que en la actualidad la situación del uso de certificados electrónicos en los servicios públicos dista mucho del ideal. La pregunta que surge es naturalmente cuales son las alternativas. Sobre esta cuestión intentará arrojar algo de luz el siguiente artículo de esta serie.

Actualización importante [20-04-2011]

David Blanco y Julián Inza han publicado justo al día siguiente de salir esta entrada dos post que he enlazado desde sus nombres y que analizan los problemas y perspectivas del DNIe. Me parecen lecturas imprescindibles sobre la materia. Se refieren ambas a este artículo que pertenece a una serie en la que hemos colaborado con el Diario de Navarra.

Lo dicho: imprescindible.

También se ha hablado mucho de los peligros, sobre todo, de las redes de sociales. Hay [...]]]> Todos los que nos movemos habitualmente dentro del mundo de la blogosfera somos partidiarios y reconocedores de los grandes beneficios de los nuevos medios de expresión, comunicación y modo de relacionarse que aporta la Web 2.0

También se ha hablado mucho de los peligros, sobre todo, de las redes de sociales. Hay peligros de todo tipo, el abuso en la comercialización de los datos, robos de identidad o los datos preocupantes sobre el comportamiento de los adolescentes en la red son ejemplos que probablemente la mayoría de los lectores de este artículo ya conozcan. El lector interesado que aún no conozca mucho esta problemática puede encontrar aquí una introducción a los peligros de las redes sociales.

Sin embargo, de vez en cuando te encuentras un ejemplo con una vuelta de tuerca sorprendente. En esta ocasión fue un artículo que contaba un experimento realizado por el periódico alemán Frankfurter Allgemeine Zeitung y que me sorprendió, sobre todo, por lo trivial que resulta alcanzar el resultado deseado.

Solemos asumir casi todos que los riesgos e invasiones de intimidad se producen dentro de los miembros de las redes sociales, especialmente entre aquellos menos prudentes. Pues bien, en este experimento la vuelta de tuerca consistía en demostrar lo fácil que es exponer y analizar también a las personas sin relación alguna con Facebook saltándonos los principios básicos de protección de datos sin ningún esfuerzo.

Sorprendente, ¿verdad?

Los usuarios de Facebook aportan una gran cantidad de datos a esta red social: sus gustos personales, ideología, religión, su paradero, sus amigos, sus aficiones… Pero esto no es todo. Facebook también recoge datos de un sinfin de personas que no tienen relación alguna con esta empresa, incluyendo direcciones de correo electrónico, personas que posiblemente no quieren tener nada que ver con esta empresa y a las cuales nunca se las ha preguntado sobre ello.

Para este experimento, el periódico alemán se inventó una identidad ficticia, pero con una dirección de correo electrónico real, la de la señora Bárbara L. Unos cuantos clics más adelante Facebook ya había sugerido unos 20 contactos con sus fotos a la redacción, de los cuales Bárbara L. reconocía inmediatamente a 18 personas.

Esto es posible porque, por una parte, Facebook no comprobó la identidad de la persona que se acaba de afiliar (no se espera a la confirmación de la cuenta de correo electrónico para completar mostrar la lista de potenciales amigos) y, por otra parte, muchos usuarios de Facebook “abren” sus cuentas de correo electrónico a Facebook proporcionando, en mi opinión imprudentemente, incluso su contraseña de la cuenta de correo para que sean rastreadas por esta empresa en búsqueda de “amigos” también dados de alta en Facebook.

De este modo, Facebook encontró a la dirección de Bárbara en cuentas de correo de usuarios que las habían abierto para su rastreo e indirectamente, sin que Bárbara tenga relación alguna con esta empresa, fácilmente cualquier persona analiza su red de contactos y perfiles de personas con las que ella se relaciona.

Si alguna vez le han extrañado, como a mi, las sugerencias de contactos con personas que no entiende como las ha podido relacionar, ahora ya tiene una de las explicaciones posibles.

Por encima de todo me llama la atención es el increible nivel de irresponsabilidad y neglicencia asumido por esta empresa al no implementar una medida tan sencilla como, por ejemplo, la comprobación de la identidad del usuario a través de un correo de confirmación. Personalmente no soy capaz de encontrarle más explicación que una avaricia comercial sin escrúpulos.

Con el uso de esta “técnica” se han conseguido cosas como, por ejemplo, hacerse pasar por el CEO de Google, Eric Schmidt pudiendo hacerse con sus contactos personales como el fundador de Youtube, Chad Hurley.

He hecho la prueba con una de mis propias direcciones de correo electrónico y he podido comprobar que en España la cosa es exactamente igual que en el caso del experimiento alemán, sin confirmación previa alguna de la identidad dada de alta, Facebook propone inmediatamente al final del registro una larga serie de posibles amigos que en su gran mayoría son personas que efectivamente conozco.

Obviamente este caso hace saltar alarmas en relación con la protección de datos. Desde el punto de vista de la LOPD en principio parece una infracción como una catedral de su artículo 11 según el cual “los datos de carácter personal objeto del tratamiento sólo podrán ser comunicados a un tercero para el cumplimiento de fines directamente relacionados con las funciones legítimas del cedente y del cesionario con el previo consentimiento del interesado.” a las cuales en principio no veo aplicables las excepciones definidas tales como la pertenencia a fuentes accesibles al público de los datos cedidos.

Dentro del análisis meramente superficial al que puedo llegar no siendo un experto en los aspectos jurídicos de la protección de datos entiendo que a primera vista parece bastante evidente que se trata de una infracción muy grave. Pero, por otra parte, veo una cuestión peculiar de este escenario que quizás lo complique todo: y es que entiendo por la redacción del artículo 44 (tipos de infracciones), que la responsabilidad de la infracción la ley la pone del lado del cedente que entiendo es en este caso el usuario al abrir y proporcionar los contactos de su cuenta de correo electrónico y resulta que el cedente en este caso es una persona física y los datos, datos que en principio están fuera del ámbito de aplicación de la LOPD al ser “mantenidos por personas físicas en el ejercicio de actividades exclusivamente personales o domésticas”

¿Dejan de serlo al cederse a una empresa? ¿Hay que multar por tanto en realidad a los usuarios que han abierto sus cuentas? Sobre todo, esto último parece un despropósito, aparte, naturalmente, de inviable. Sin embargo, existen precedentes que van en esta línea.

Si se entiende también responsabilidad por parte del cesionario y no solamente del cedente, la cosa ya estaría mucho más clara. Quizás algún lector más experto en los aspectos jurídicos la materia pueda ayudar a aclarar esta duda con sus comentarios. Pero en principio, aunque moralmente está muy claro el caso, legalmente, al menos a mi, me genera dudas.

De todas formas, es un hecho conocido que la relación entre Facebook y las diversas agencias nacionales de protección de datos es conflictiva. En el caso de Alemania, esta cuestión concreta se está tratando por la agencia alemana de protección de datos, en el caso de España se están investigando cuestiones parecidas, pero no he encontrado una investigación concreta sobre este tema, así que quizás sea cuestión de abrirla.

En cualquier caso, el hecho es que hoy por hoy este mecanismo de Facebook sigue siendo funcionando y esta gente sigue actuando con absoluta impunidad porque sí, porque no les da la gana de verificar la identidad de quien se da de alta con ellos, tanto en Alemania como en España.

Edición del 9/11/2010:

Aprovecho que acaba de salir hoy este post de Enrique Dans y que viene muy al caso porque pone otro ejemplo tremendo de la más absoluta irresponsabilidad que reina en muchos sitios de los nuevos servicios de la Web 2.0. Recomiendo encarecidamente su lectura, no tiene desperdicio:

Firesheep: una llamada de atención muy necesaria

Seguramente entre todas expliquen porque aún [...]]]> Hace poco escribí un artículo que narraba mi experiencia personal en la renovación de los certificados electrónicos de mi DNIe. Una experiencia que no deja de ser una perspectiva negativa más entre toda una serie de ellas, ya ampliamente discutidas en diversos foros.

Seguramente entre todas expliquen porque aún a día de hoy, con casi 20 millones de DNIs electrónicos en la calle, su uso como medio de identificación, autenticación y firma electrónica aún es absolutamente residual.

Tuve la suerte que entre las personas que dejaron algún comentario al artículo se encontraba también David Blanco, CEO de Tractis, una empresa que se dio a conocer principalmente por su novedoso servicio de negociado y firma de contratos en Internet con la misma validez legal que la firma manuscrita, un servicio en el cual uno de los tipos de certificados electrónicos más importantes entre los admitidos lo son los del DNIe. Sobra por tanto decir que se trata de alguien que se conoce muy bien el terreno.

David me puso sobre aviso de una noticia muy reciente, y a mi juicio bastante relevante, que se había publicado poco antes y que personalmente desconocía. Después de indagar un poco he podido ver que, salvo en foros muy especializados como en Kriptópolis o el blog del propio David, la noticia ha tenido mucho menos publicidad de lo que, en mi opinión, se merece.

Por tanto, después de hablar con David, he considerado que podría ser interesante comentarla aquí de nuevo en un artículo aparte, basándome en lo que David nos cuenta en sus propios comentarios siendo además un contrapunto positivo a anteriores artículos que se centraban más en los aspectos negativos que rodean, hoy por hoy, el asunto del DNIe.

La noticia se centra en la necesidad de instalación de los Drivers, como dice David:

“Este último punto, la necesidad de instalar que el ciudadano instale los drivers del DNIe, ha sido una de las principales barreras (sino la principal) al uso del DNIe en España. La complejidad y problemas de esta instalación han dado dolores de cabeza y causado frustración a docenas de miles de ciudadanos (sobre todo a los usuarios de GNU/Linux y Mac). Afortunadamente, la buena noticia es que, desde hace dos semanas, ya no es necesario instalar los drivers del DNIe para poder utilizarlo.”

Hace dos semanas, la Dirección General de la Policía (DGP), publicó el “Manual de Comandos APDU del DNIe“. La información contenida en este manual, hasta ahora solo en poder de la DGP, permite conectarse y “hablar” directamente con el chip del DNIe sin necesidad de pasar por los drivers oficiales de la DGP. En otras palabras, con esta información cualquier empresa puede desarrollar sus propios drivers de DNIe y, más aún, integrarlos dentro de sus servicios de forma que el usuario pueda utilizar su DNIe sin tener que instalar los drivers. Se trata de un anuncio largamente esperado por el sector privado. La semana pasada lanzamos en Tractis una nueva versión en la que nos integramos con el DNIe a través de comandos APDU. Estoy seguro de que otras empresas y colectivos (ver la comunidad OpenSC en Kriptópolis) están trabajando en desarrollos similares. Ahora mismo ya existen los medios para que los ciudadanos puedan utilizar su DNIe para autenticarse o firmar sin tener que instalar antes los drivers. Solo hay que enchufar el lector, insertar el DNIe y listo. Tal y como debería haber sido desde el principio.

En resumen, barreras hay muchas, afortunadamente, poco a poco (indudablemente, no con la rapidez que nos gustaría), van desapareciendo.”

En otro comentario nos da más perspectiva sobre las implicaciones de estos cambios, relacionadas con otros problemas que ya hemos identificado repetidamente:

“La lentitud del DNIe y la solicitud repetida del PIN, también se soluciona con la publicación de los Comandos APDU. Este miércoles 13 anunciábamos tiempos de uso de autenticación/firma en Tractis de 20 segundos (ver vídeo). Hoy viernes 15, solo dos días después, ya hemos conseguido bajar a 18 segundos (y seguimos iterando…). De igual forma, gracias a la integración con el DNIe vía Comandos APDU, la contraseña solo se pide una vez y damos feedback al usuario sobre si:

- El lector de DNIe está conectado o no,
- el DNIe está dentro del lector o no,
- la contraseña introducida es correcta o no (y el nº de intentos que quedan),
- el DNIe está bloqueado o no,
- los certificados están caducados o no,
- el chip de la tarjeta está dañado o no.

A medida que todas las soluciones, proveedores, empresas, administraciones públicas, etc… vayan incorporando estas nuevas funcionalidades (para todos los usos -autenticación y firma-, navegadores y sistemas operativos), disfrutaremos de una experiencia de uso del DNIe sensiblemente mejorada y, por tanto, de mayor interés por parte de los ciudadanos y el sector privado. Hay motivos para ser optimistas.”

En fin, creo que son muy buenas noticias.

Naturalmente habrá que ser cautos y esperar que los servicios electrónicos se adapten y ver entonces también en qué medida el entorno de los usuarios supone desafíos en cuanto a las nuevos problemas que esta vía puede suponer en factores como el sistema operativo, navegadores y máquina virtual Java utilizada por los ciudadanos.

Con esto tampoco se resuelven todos los problemas, pero cabe tener la esperanza de que efectivamente se trate de un hito importante que permita eliminar de un plumazo, al menos, varias de las mayores barreras existentes a día de hoy y que permita darle un impulso de verdad al DNIe para que realmente se utilice para lo que fue realmente concebido en su momento.

A mi juicio, si este cambio da sus frutos en la práctica y se impulsan además las iniciativas adecuadas para que el tema del lector deje de ser un problema, la combinación de todos estos factores puede tener el potencial de mejora suficiente para que percibamos un aumento claro en la tasa de uso del DNIe, quizás suficiente como para que a medio plazo llegue a tasas de uso parecidas a las de los certificados de la FNMT.

Quedarían aún otros temas por ver como la imposibilidad de renovar los certificados en casa, lo que implica un desplazamiento excesivamente frecuente a las comisarias (cada 30 meses) pero creo que esto serían males menores en los que ya se puede trabajar con más clama si se consiguiese primero que lo antes expuesto cuaje en la práctica.

Esta revisión la quise rotular en un principio como 2ª edición, ya que la envergadura de los [...]]]> Después de la primera edición publicada en febrero de este año, he editado una nueva revisión del Manual Práctico de Supervivencia en la Administración Electrónica, como siempre, la podéis descargar aquí.

Esta revisión la quise rotular en un principio como 2ª edición, ya que la envergadura de los cambios es importante, suficiente como para justificar una segunda edición, pero por problemas “técnicos” relacionados con el ISBN que he tenido que solicitar para la edición en papel, he tenido que seguir etiquetándola como 1ª Edición. Para diferenciarla de la edición anterior, la he etiquetado como revisión de la primera edición de septiembre del 2010. Pido disculpas de antemano por la confusión que pudiera generar este lío de ediciones, pero en la solicitud del ISBN no he tenido opción con esta cuestión.

Con la edición en papel espero poder dar ahora también una respuesta satisfactoria a aquellas demandas que me han preguntado por una edición impresa. En la página dedicada al manual podéis encontrar información detallada sobre los canales disponibles para adquirir ejemplares impresos y las ventajas específicas de cada una de ellos, de modo que espero que según el caso (adquisición individual, pedidos de múltiples ejemplares, etc.) cada cual encuentre así la opción que más ventajas le ofrezca.

Quiero aprovechar la ocasión del anuncio de esta nueva edición para hacer hincapié en el hecho de que en la revisión en profundidad de algunas partes y las ampliaciones de contenidos de otras ha sido fundamental la participación de los lectores con sus comentarios, críticas y sugerencias, al más puro estilo Web 2.0. Espero que en ese sentido, los lectores perciban en esta edición una mejora y puesta al día clara y que sigan ayudándome con sus comentarios para seguir evolucionando esta publicación en futuras ediciones.

A continuación, reproduzco el nuevo apartado de historial de cambios que he introducido en esta edición para que tengáis un pequeño resumen de los cambios más importantes:

• Cambio de formato del libro a Crown Quarto y cambios en tipografía y colores
• Inclusión de un historial de revisiones
• Revisión y actualización de los contenidos e imágenes
• Explicación paso-a-paso para importar un certificado electrónico en los almacenes de Windows y de Firefox
• Ampliaciones, correcciones menores y actualizaciones en capítulo “Cosas fundamentales que hay que dominar”
• Nuevo apartado dedicado al uso de Applets y ActiveX en la firma electrónica