Propuestas para el desarrollo futuro de @firma

1 Flares Twitter 0 Facebook 0 Google+ 1 LinkedIn 0 Email -- Filament.io Made with Flare More Info'> 1 Flares ×

Hoy continuamos con el segundo post de un autor invitado muy especial como lo es Tomás García-Meras Capote.

Si te has perdido la primera parte de este post, simplemente aclararte que Tomás ha liderado el equipo de desarrollo de @firma durante estos últimos años y nos va a exponer las dificultades que genera la conciliación del principio de neutralidad tecnológica de la Ley 11/2007 con la realidad del entorno tecnológico en el que deben funcionar las aplicaciones de Administración Electrónica.

Aparte de ser un ejemplo ilustrativo de los problemas inherentes a este principio legal, Tomás nos ofrecerá también una visión de la situación actual del cliente de firma electrónica @firma, perspectivas  y propuestas para su futura evolución:

Propuesta de iniciativas en el desarrollo futuro de @firma

Una vez diagnosticados los problemas que vimos en el post anterior, hay muchas formas de afrontarlos… ¿Cómo lo veo yo desde dentro del proyecto?

Yo marcaría dos grandes líneas de trabajo en este sentido:

1. Simplificación del código a mantener y probar

1.1. Eliminación del número de aplicaciones a mantener

Actualmente el proyecto Cliente @firma tiene distintas aplicaciones pensadas para distintas necesidades:

  • Applet Cliente @firma: la aplicación más conocida
    • Con 6 variantes:
      • LITE Java 5, LITE Java 6, MEDIA Java 5, MEDIA Java 6, COMPLETA Java 5 y COMPLETA Java 6.
  • MiniApplet Cliente @firma: una remodelación desde cero del Applet, compacta y rápida.
    • Con dos variantes:
      • Despliegue clásico y despliegue modular.
  • Aplicación de escritorio “StandAlone”: todas las funcionalidades accesibles desde un interfaz gráfico accesible como aplicación Java independiente.
  • Aplicación de escritorio “Firma Fácil”: las funcionalidades de firmas más comunes desde un simple y fácil de usar interfaz gráfico como aplicación Java independiente.

¿Qué sobra en todo esto?

En mi opinión, el Applet Cliente @firma, la versión clásica, es prescindible.

Como suele pasar típicamente en los proyectos de desarrollo de software, con el paso de los años se ha convertido en una aplicación grande, difícil de integrar e incómoda de usar. A la vez la remodelación de esta apliación, el MiniApplet Cliente @firma, ha madurado lo suficiente para que  puede ser un sustituto perfecto en los casos en los que solo se requiera realizar firmas electrónicas AdES.

No obstante, hay un problema: Desgraciadamente, dado el número de implantaciones de esta aplicación, dejar de probarlas y evolucionarla de golpe originaría muchos problemas a los integradores, que en época de crisis pueden no tener los recursos necesarios para una migración al MiniApplet. Una situación con la cual hemos de ser respetuosos al máximo.

Con este escenario, una nueva versión previa a su completa desaparición podría ser una buena solución. En esta versión podrían eliminarse ciertas funcionalidades marginales o indeseables y limitar la distribución a una única versión, que equivaldría a la “COMPLETA Java 6” (con lo que dejaría de soportarse Java 5 por completo).

Respecto al MiniApplet, esta aplicación es compacta y está bien diseñada, pero el hecho de disponer de dos versiones (según tipos de despliegue) no aporta mucho, ni a integradores ni a usuarios, por lo que descartar el despliegue modular y mantener únicamente el clásico parece un buen movimiento (el despliegue clásico se comporta mejor en entornos con HTTPS y autenticación con certificado cliente).

¿Y las dos aplicaciones de escritorio?

El dejarlas tal y como están tiene mucho sentido, ya que los esfuerzos de mejora y evolución se podrían centrar en “Firma Fácil”, y “Cliente @firma Standalone” se convertiría en una especie de aplicaciones “legacy”, donde se mantendría operativa cualquier operación retirada de otras aplicaciones, dejando siempre una opción para aquellos que no puedan prescindir de ellas.

1.2. Simplificación de las funcionalidades de las aplicaciones actuales

El Cliente @firma realiza muchas operaciones criptográficas distintas, pero… ¿Cuáles son realmente las usadas por más del 90% de sus integradores?

Evidentemente, la firma electrónica en un formato AdES. Con esta premisa siempre presente, eliminemos funcionalidades de las aplicaciones (aunque manteniéndolas en “Ciente @firma Standalone” como refugio):

  • Eliminación de firmas no AdES: CMS, XMLDSig, OOXML, ODF, XML explícitas, etc.
  • Eliminación de cifrados asimétricos.
  • Eliminación de sobres digitales.
  • Eliminación de funcionalidades auxiliares depreciadas:
    • Firma Web.
    • Filtros de certificados mediante expresiones regulares “clásicas”.
  • Eliminación del componente “BootLoader”.

1.3. Reducción de los entornos operativos soportados.

En una época de crisis, el optimizar la distribución de los recursos es crítico, y un buen punto de partida para la distribución de esfuerzo entre los entornos operativos es conocer las preferencias de los ciudadanos, ¿no?

Echemos un ojo a las estadísticas de acceso a la página Web de la AEAT durante junio de 2012:

Accesos Sistema Operativo
191.102.940 Windows
1.491.481 Mac OS X
333.945 Linux

Con las cifras en la mano, se ve claro que los usuarios de Linux no son muy dados a entrar en la página de la AEAT, o visto de otra manera, la AEAT no tiene muchos usuarios en Linux (y lo mismo podemos decir de Mac OS X).

Sin embargo, son estos dos sistemas operativos los que más esfuerzo de mantenimiento requieren… ¿Tiene esto sentido?

Aunque desde un punto de vista de apoyo al software libre (Linux) o el evitar la concentración del mercado, sí, desde un punto de vista de buscar la satisfacción del mayor número de usuarios, no.

Hay que hacer sin duda una reflexión profunda de hasta que punto se puede, por ejemplo, mantener un sistema operativo como Linux, con decenas de distribuciones y variantes y un grado de heterogeneidad enorme, o también Mac OS X, un sistema operativo tan cerrado que provoca continuos problemas de compatibilidad.

Pretender ofrecer compatibilidad con estos sistemas es un principio muy loable y lógico, pero creo que también hay que saber rectificar a tiempo cuando la realidad te confronta con los problemas que esto supone y que a la luz de lo comentado parece claro que derivan en un esfuerzo excesivo y, en ciertos aspectos, incluso imposible de llevar a cabo en la práctica.

Desde el punto de vista de Java (JRE), la decisión es más cómoda, la supresión del soporte a Java 5 (ya muy obsoleto) y el apoyo a Java 7 u 8 en detrimento de Java 6, aunque sin abandonar por completo este último.

2. Automatizar por completo el entorno de construcción, pruebas y publicación de las aplicaciones.

Bien, se supone que en este punto ya tenemos un Cliente @firma más pequeño y fácil de probar y una reducción de los entornos operativos a probar… ¿Siguiente paso?

Automatización por completo (dentro de la medida de lo posible) de las pruebas de los productos y su publicación final.

La entrada de la UJI (Universidad Jaume I de Castellón) en el proyecto ya un año fue una brisa de aire fresco, que introdujo un servidor de integración continua que automatizaba la ejecución de las pruebas unitarias, el control de calidad y la construcción de los “artefactos”, pero aún quedan tareas por ejecutar:

  • Las pruebas unitarias deben replantearse para garantizar por completo la funcionalidad interna de cada componente, y la cobertura de estas no debe ser la única (ni la más importante) métrica a tener en cuenta.
  • La construcción automatizada (Apache Maven) debe generar exactamente los mismos entregables que actualmente se publican en el CTT (Centro de Transferencia Tecnológica).
  • Deben integrase (vía Hudson/Jenkins) todas las herramientas con las que cuenta el proyecto para probar (como Test@Firma), y el código fuente de estas a su vez estar abierto e integrado en el sistema continuo.
  • Deben integrarse las herramientas de apertura de tickets de soporte con la integración continua, para la generación automática de incidencias.
  • Hay que plantear un ambicioso proyecto de pruebas finales basado en macros de actividad de usuario en navegador Web sobre múltiples (tantas como entornos operativos soportados)  máquinas virtuales, con servidores que recojan los resultados de las pruebas y compongan informes finales.
  • Hay que implantar mecanismo de análisis remoto de registros (la Java Logging API lo soporta perfectamente) e incluso de gestión remota del software (JMX).

Si consiguiésemos levantar un entorno de este estilo, podríamos obtener un software de más calidad, en menos tiempo, y con un coste significativamente menor, ya que la inversión se amortizaría en muy poco tiempo (es importante considerar el Cliente @firma como un proyecto de larga duración).

Conclusiones

Como resumen, propongo un futuro cercano del proyecto Cliente @firma centrado en la simplificación y en el incremento de la calidad reduciendo costes, en base a una pequeña revolución en la forma de hacer las cosas en el proyecto.

Esta simplificación debe facilitar además que nuevos colaboradores se sumen al proyecto (recuerdo que el Cliente @firma es 100% software libre), aspecto vital para cualquier proyecto abierto que ya durante 2012 se ha trabajado con buenos resultados.

Así que creo sinceramente que a pesar de las dificultades inherentes a la actual situación económica y las correspondientes restricciones, con la estrategia adecuada, es perfectamente posible que este proyecto continúe siendo un proyecto ilusionante y que aporte aún más valor a los numerosos proyectos que ya lo han integrado y aquellos que lo integrarán por primera vez.

No obstante, hay un efecto lateral que no vamos a analizar hoy, y es que el ahorro de costes en tareas como las pruebas y la publicación puede repercutir en poder destinar más esfuerzos a investigación en firma electrónica, en nuevos canales de comunicación con el ciudadano… O simplemente en ahorrar, que buena falta nos hace.

avatar

About Alberto

Jefe de Servicio de Proyectos Tecnológicos en la Acción Estratégica en Salud (Plan Nacional I+D+i) & Profesor INAP

Subscribe

Subscribe to our e-mail newsletter to receive updates.

16 Responses to Propuestas para el desarrollo futuro de @firma

  1. avatar
    Jorge 20 de enero del 2014 at 12:53 #

    Hay varias cuestiones a tener en cuenta en este análisis:

    1. Si diseñas un sistema para Windows y luego intentas que funcione también en Linux, es seguro que el mantenimiento en Linux te va a dar más problemas y costes.

    2. En mi grupo de investigación somos 10 miembros, la mayoría ingenieros informáticos, todos usamos Linux habitualmente y todos tenemos instalada un máquina virtual con Windows para hacer gestiones con las administraciones que usan @firma. Esto es: muchos usuarios de Linux (la inmensa mayoría) se ven obligados a usar Windows porque la la administración electrónica porque @firma simplemente NO funciona con linux, o el coste de hacer que funcione es totalmente desproporcionado. Claro que este dato es difícil verlo en las estadísticas.

    3. Hacer que @firma funcione en Windows tampoco ha sido tradicionalmente tarea fácil. En ocasiones se necesita alguna combinación mágica de ciertas versiones del cliente, de la versión de Java (no basta con la última versión) y de versión del navegador. Todo ello instalado en un determinado orden, porque si no no funciona. Varios colegas usuarios de Windows me han pedido copia de mi máquina virtual de Windows que conseguí hacer funcionar con @firma hace años y que guardo como oro en paño.

    4. Si @firma sólo soportase Windows, ¿regalará la administración una licencia de este sistema a todos los ciudadanos (y sus correspondientes actualizaciones) para garantizar el acceso a la administración electrónica? Si es el caso seguro que Microsoft estaría encantada de hacer descuentos. ¡Pobre balanza de pagos!

    5. La clave de la administración electrónica es emplear estándares abiertos y tecnología independientes de la plataforma (y no me refiero a Java). Desarrollar más el sistema sobre la tecnología web (Javascript, HTML5, etc.) que sobre el cliente (Java, S.O.). Esta claro que la arquitectura de @firma está obsoleta en este sentido y seguirá siendo una fuente de problemas y costes y no precisamente por culpa de los usuarios de estándares abiertos y software libre.

  2. avatar
    Daniel 20 de junio del 2013 at 8:30 #

    Despreciar el soporte a un sistema operativo claramente superior técnicamente, más estable, seguro y encima gratuito, que garantiza la inclusión digital, por el mero hecho de que tiene menos usuarios en Administración Electrónica es sencillamente lamentable, una de las peores decisiones que se podían tomar.
    Claro, en su lugar, sigamos alimentando las arcas de Microsoft y de Apple, no incidamos en la independencia tecnológica de España y de Europa, vamos a rendirnos a la evidencia, Windows es “fácil de usar” y es muy bonito, así que dale más soporte.
    ¿Nos hemos parado a pensar porqué tiene menos usuarios? ¿no será porque no nos preocupamos de que funcione bien en linux?
    Yo por mi parte sigo con mi batalla, haciendo funcionar a la perfección el cliente de @firma en linux -no después de mucho trabajo- y ofreciendo los resultados en una “virtual appliance” de libre descarga, libre uso y libre redistribución. Si quereis probarla por aquí anda: http://www.danieldianes.nom.es/2013/04/distribucion-linux-para-administracion-electronica-en-espana/
    Funciona perfectamente con @Firma con certificado y lo he hecho funcionar con DNIe. Hasta he presentado la declaración telemáticamente.

    • avatar
      Alberto 22 de junio del 2013 at 10:43 #

      Hola Daniel,

      Te felicito por tu trabajo, ¡está genial! Y, sobre todo, es algo que le puede aportar mucho valor a la gente.

      Es más, me parece una cosa tan loable y positiva que te invito, si tienes ganas de que hagas un post de invitado relatando tu trabajo porque, como te digo, me parece algo con muchísimo valor.

      Dicho esto, aunque estoy 100% de acuerdo en el fondo de lo que dices en cuanto a la falta de apoyo de los Gobiernos (y me refiero al europea, sobre todo), sí me parece algo dura tu postura al juzgar la situación con tanta ligereza con aquello de “una de las peores decisiones que se pueden tomar”. Es muy difícil, por no decir, imposible para los equipos responsables de la Administración mantener una compatibilidad amplia teniendo en cuenta el presupuesto que tienen.

      Ahora bien, desde un punto de vista de toma de decisiones en las altas esferas políticas (que me parece en la vida se dignarán a leer un blog como este…), 100% de acuerdo.

      Un saludo,
      Alberto

      P.D.
      Y ya sabes: anímate con tu post :-)

      • avatar
        Daniel 27 de junio del 2013 at 10:53 #

        Hola Alberto, muchas gracias.
        Hombre siempre “peor decisión” es relativo, claro está. Mi postura es que, llegado el caso de tener que favorecer una plataforma sobre otra, comprendo que Microsoft es “lo que todo el mundo tiene”, pero también creo que deberíamos remar por la independencia tecnológica de este país. Estamos acostumbrados a que todo el mundo lo tiene pero ¿quien lo ha comprado? Si en España no fueramos tan dados a la copia no autorizada se daría otro caso bien distinto y casi nadie tendría Windows. Por eso creo que se debería prima una plataforma estable, segura y encima de libre acceso que contribuya a romper la brecha digital.
        Pero bueno que veo que en el fondo estamos de acuerdo en ese punto y que desde el punto de vista práctica es muchísimo trabajo. Quizá la solución podría venir de abandonar Java y que firefox incorporara criptografía de manera nativa. Y como firefox es multiplataforma, problema resuelto. A ver si avanza el estándar http://www.w3.org/TR/WebCryptoAPI/

        Respecto a la colaboración, me sentiría honrado y encantado ;) ¿como lo hacemos? ¿me envias un email a esta dirección con los detalles?

        Un saludo.

        • avatar
          Alberto 1 de julio del 2013 at 9:41 #

          Perfecto, así lo hacemos.

          Te contacto y organizamos el tema. Eso sí, en cuanto a la fecha de publicación, creo que lo suyo es pensar en septiembre por el bajón de verano que ya se está empezando a notar :-)

          Un saludo,
          Alberto

  3. avatar
    Richard Stallman 14 de marzo del 2013 at 16:26 #

    Las administraciones públicas y las agencias gubernamentales deben dejar de usar programas privativos. Sólo así podrán ser responsables del control que los ciudadanos les otorgan. La soberanía informática excede la cuestión económica, que es importante, pero hay algo más importante que es la cuestión moral, usar el software que le garantiza la libertad al ciudadano y que no lo deje indefenso ante las corporaciones. Los ciudadanos no conocen el Software Libre porque no se fomenta su uso desde el Estado y las Administraciones Públicas.

    ¡Hay que dar ejemplo señores!

  4. avatar
    Montaña Merchán 5 de febrero del 2013 at 12:54 #

    Como responsable del proyecto durante los últimos años puedo comentar que, el cliente de @firma es uno de los pocos aplicativos de la AGE que ha sido liberado bajo licencia GPL-EUPL. Esto nos ha llevado tiempo y dinero pero ahí está, con una comunidad de desarrollo que está aportando iniciativas.
    Por otro lado también ha sido enorme el esfuerzo de actualizar el cliente: la modularizacion precisamente ha ido encaminada a simplificarlo, y SI, se ha desarrollado una versión de firma en movilidad para Android.
    La version firma fácil es muy útil para PYMES pero no es muy conocida por falta de promoción. Una de las ventajas es que realiza cofirmas y contrafirmas (o firmas en casacada) con el formato normalizado.

    Yo creo que lo importante es que la admiinistración debería utilizar un sólo cliente de firma, lo cual simplificaría la vida al ciudadano y reducidría costes., además de no dispersar esfuerzos.

  5. avatar
    Jorge 1 de febrero del 2013 at 23:25 #

    ¿Alguien sabe por qué no se ha incorporado ya la firma electrónica a los navegadores de forma nativa? ¿Por qué no podría funcionar el uso de certificados para firma de una forma similar a como funciona la autenticación mutua? ¿Se podría incluir en una especificación HTML 6 o 5.1?

    • avatar
      Alberto 3 de febrero del 2013 at 18:18 #

      Hola Jorge,

      Has dado en el clavo. La firma nativa resolvería muchísimos problemas de raíz. Para mí, este punto es la madre de todos los males en cuanto a los problemas de usabilidad que presenta la firma electrónica en la web.

      No tengo información sobre el tema, pero me temo a que responde simplemente a que en el sector privado no ha habido suficiente interés como para que la industria por propia iniciativa regule este tema y que, por otra parte, un síntoma más de la incapacidad manifiesta (o falta de interés verdadero) principalmente de la Comisión Europea (hay que recordar que es el máximo órgano responsable de las políticas en esta materia) para impulsar las cosas de verdad a través del desarrollo de los estándares pertinentes junto con el impulso de su implementación y no solamente de cara a la galería.

      Un saludo,
      Alberto

    • avatar
      ClawGrip 4 de febrero del 2013 at 16:43 #

      Hay un borrador de la W3C (http://www.w3.org/TR/WebCryptoAPI/) en progreso, y una extensión de Firefox que permite ir haciendo las primeras pruebas.

      Justo hablando de esto con la AEAT comentaba yo que es la opción ideal, tendríamos un API (ASN.1 para CAdES y XML para XAdES) en JavaScript, que se podría ejecutar en cliente o en servidor según las preferencias del integrador y un acceso a la WebCryptoAPI para el PKCS#1, que es la parte de la firma electrónica dependiente de la clave privada.

      Otra dificultad añadida sería la implementación de PAdES 100% en JavaScript (tarea dura), pero siempre se puede optar por una firma trifásica donde la parte PDF se haga en el servidor y se deje en JavaScript únicamente el CAdES o incluso solo el PKCS#1.

      Vale, pero aun con esto nos siguen quedando interrogantes… ¿Quién se anima a financiar un proyecto de firma electrónica 100% desde cero? ¿Implementarán los navegadores esta normativa del W3C? ¿Incluidos los navegadores de los dispositivos móviles?

      Tal y como yo lo veo, tenemos muchos meses por delante antes de que podamos tomar esto como una solución factible.

      • avatar
        Alberto 5 de febrero del 2013 at 13:06 #

        La cuestión es esto, en mi opinión, ya tenía que haber sido la vía hace años atrás, todo respaldado con una fuerte liderazgo de las instituciones europeas que son el origen de las iniciativas públicas nacionales en materia de certificado y firma en los países de la UE.

        Mover a organizaciones de la talla de la W3C y a los grandes jugadores de la industria para que haya resultados en un plazo aceptable requiere, a mi entender, que las cosas se muevan a estas esferas. Mi figuro que incluso para los Gobiernos nacionales ya no es fácil moverse a estos niveles.

        Por eso me entristece enormemente que a algo tan importante es obvio que no se le prestado atención suficiente desde la UE y que, como consecuencia, en los niveles más bajos nos estemos dando cabezazos contra una situación que está llena de problemas técnicos y organizativos en el fondo absurdos porque responden a que en vez de sentar las bases técnicas y organizativa correctas nos estemos buscando la vida con todo tipo de inventos (Applets, etc.) que son en el fondo artificiales y por tanto tan problemáticos.

        Lo más triste es que no estamos hablando de enviar un cohete a la luna, estamos hablando de actuaciones técnicas y organizativas bastante asequibles, diría que incluso muy pequeñas, comparado con la transcedencia y beneficios que tendrían si se llevaran a cabo correctamente.

        Un saludo,
        Alberto

  6. avatar
    Álvaro 31 de enero del 2013 at 8:00 #

    Gracias a Tomás y a Alberto por el post.

    En lo relativo al punto 2, no estoy del todo de acuerdo en el planteamiento relativo a Mac Os X y Linux. Creo que el argumento del coste (cuyos datos son irrefutables) justificaría la supresión del soporte en el sector privado. No obstante, creo que en el sector público no debemos mirar únicamente ese criterio. Creo que hacerlo desnaturaliza la Administración Pública y nos acaba convirtiendo en una copia mala del sector privada.

    Tal vez se podría ajustar el alcance del soporte a estos dos sistemas operativos. Por ejemplo, soportando únicamente la última versión estable de Mac OS X y Ubuntu LTS. No creo que ni los más acérrimos defensores del software libre defiendan que se de soporte hasta a la última distribución Linux que exista.

    Una pregunta, ¿existen relaciones con la comunidad de software libre? Tal vez se les podría proporcionar toda la información necesaria para que la comunidad pudiera dar soporte a entornos “no oficiales”. Por ejemplo, tal vez se podría colgar el código fuente en github. Actualmente creo que el código sólo está en la parte privada del PAE.

    En cualquier caso, muchas gracias a Tomás y su equipo por el trabajo que realizan, del que nos beneficiamos todos.

    Un saludo

    • avatar
      Alberto 31 de enero del 2013 at 19:46 #

      Hola Álvaro,

      La verdad es que me parecen dos objeciones muy sensatas y a tener en cuenta. De todas formas, entiendo que Tomás le ve también en esta línea, en el sentido de que no hay que llegar a los extremos, sino encontrar efectivamente un punto de equilibro intermedio.

      Un saludo,
      Alberto

      P.D

      Aprovecho para comentar que por problemas con mi ordenador privado estoy tardando más de lo normal aprobar los comentarios.

      Os pido disculpar por adelantado por ello.

    • avatar
      ClawGrip 3 de febrero del 2013 at 12:51 #

      > ¿existen relaciones con la comunidad de software libre? Tal vez se les podría
      > proporcionar toda la información necesaria para que la comunidad pudiera
      > dar soporte a entornos “no oficiales”. Por ejemplo, tal vez se podría colgar el
      > código fuente en github. Actualmente creo que el código sólo está en la parte
      > privada del PAE.

      Esta es una de las recomendaciones que hizo la Universitat Jaume I en los comienzos de la apertura del Cliente @firma como Software Libre, especialmente en lo referente a github.

      Por ahora las relaciones con las comunidades de Software Libre no son muy activas, pero estamos ya recibiendo colaboraciones en el proyecto del Cliente @firma ¿De quién? Cito unos pocos casos a modo de reconocimiento por su esfuerzo:

      -La Diputación Provincial de Ciudad Real ha mejorado el soporte de PAdES, y ahora gracias a ellos tenemos firmas PDF habilitadas para LTV y firmas PAdES en tres fases (aspecto que están ellos mismos integrando en AL-SIGM).

      -La Agencia Tributaria está actualmente apoyando directamente el soporte nativo de Windows 8 en “modo Metro”, Windows RT y Windows Phone, apoyo que se complementa con la ayuda de Microsoft Ibérica.

      -RIM BlackBerry ha hecho tímidas aproximaciones al proyecto (propiciadas por CENATIC), pero, por desgracia, aun estamos muy lejos de tener el Cliente @firma en BlackBerry 10.

      Yo particularmente echo en falta algo de ayuda por la parte de Linux (¿No se anima nadie de Guadalinex?), y doy por imposible el recibir ayuda por parte de Apple…

  7. avatar
    Angel 30 de enero del 2013 at 22:15 #

    En mi opinión, cuando se aportan estadísticas para argumentar decisiones, como las incluídas en el artículo:

    Accesos Sistema Operativo
    191.102.940 Windows
    1.491.481 Mac OS X
    333.945 Linux

    Deberían tomarse datos relevantes (por ejemplo, cuántos de esos accesos han realizado una firma electrónica). De lo contrario las decisiones tomadas pueden resultar erróneas.

    Y tampoco se ha hablado nada del mundo móvil, a pesar de que ya existan implementaciones Android e iOS para el cliente @firma. El futuro de esta herramienta pasa por adaptarse a los nuevos usos de los usuarios, en caso contrario, tanto la firma electrónica como el DNIe caerán en el olvido.

    No obstante, me ha gustado descubrir, como usuario de la plataforma, algunas de las reflexiones que dictan el rumbo de la plataforma.

    • avatar
      Alberto 31 de enero del 2013 at 19:52 #

      Hola Ángel,

      Te doy la razón en las dos cosas, efectivamente cabe pensar que el uso de certificados no es proporcional. Es decir, cabe pensar que un perfil de usuario seguramente más “técnico” es muy posible que muestre una tendencia bastante mayor a utilizar certificados electrónicos. Me parece que es un aspecto que efectivamente se merece un análisis para averiguar cuál es la situación.

      En cuanto al mundo del móvil te puedo adelantar que se está trabajando ello. No sé exactamente el estado en el que se encuentra el proyecto ahora mismo, pero es una tema del que se ha tomado conciencia.

      De dejo esta referencia de cursos que se han impartido sobre la materia para que tengas una primera orientación del estado de las cosas.

      Quizás podamos animar a Tomás a que nos lo cuente en otro post :-)

      Saludos,
      Alberto

Deja un comentario

1 Flares Twitter 0 Facebook 0 Google+ 1 LinkedIn 0 Email -- Filament.io 1 Flares ×